1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Example 4: Modular code generation</title>
</head>
<body class="composite">
<div id="bodycol">
<div class="app">
<div class="h3">
<a name="intro"></a><h3>Splitting and sharing code</h3>
<p>Large organizations often have separate teams working with different parts of
a large set of schemas. For instance, the full set of OTA schemas include groupings
used for air travel, hotels, automobile rentals, cruises, and more. Different teams
within a single company may be working with one or more of these groupings. It's often
useful to let the teams working with particular portions of the schemas handle their
own data models, while still using a common model for the shared portions (so that
application code working with the shared portions will be compatible organization-wide,
facilitating code reuse and making it easy to combine different projects, when
necessary). This localized control of the data model is even more important when the
organization is building schemas for data exchange, rather than just using supplied
schemas.</p>
<p>CodeGen suports modular code generation to allow organizations flexibility in their
use of schema-based data models. With modular code generation, you start by generating
one or more self-contained schema subsets. The code and binding generated for each
self-contained subset is a base module which can be compiled into class files and bound
by the JiBX binding compiler. The bound class files can be kept as loose files, or more
commonly assembled into a jar file.</p>
<p>You can then generate other modules extending those already generated, from schemas
which build on the previously-generated schemas. The code in the extension modules
reference the Java classes and data bindings generated for the base modules. Each separate
module can again be compiled and bound by the JiBX binding compiler independently, only
needing access to the binding definitions and bound classes (whether loose, or in a jar)
of the appropriate base modules.</p>
<p>To demonstrate how modular generation works, this example splits the OTA schema
subset used by all the CodeGen examples into two modules. The first module consists of
common definitions used across the full range of OTA schemas, and is generated from the
<i>OTA_CommonPrefs.xsd</i>, <i>OTA_CommonTypes.xsd</i>, and <i>OTA_SimpleTypes.xsd</i>
schemas. The second module consists of the air travel-related definitions, generated
from the <i>OTA_AirCommonTypes.xsd</i>, <i>OTA_AirLowFareSearchRQ.xsd</i>,
<i>OTA_AirLowFareSearchRS.xsd</i>, and <i>OTA_AirPreferences.xsd</i> schemas.</p>
</div>
<div class="h3">
<a name="common"></a><h3>Common definitions module</h3>
<p>Since the code generation is done in two parts there are two separate customizations
used. Both customizations are based on the <a href="%cgexample3%#custom">Example 3 customizations</a>.
Here's the <i>custom3a.xml</i> customization file, used for the first generation step
(common definitions module):</p>
<div id="source"><pre><schema-set prefer-inline="true" package="org.ota.common"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
type-substitutions="xs:integer xs:int xs:decimal xs:float"
binding-file-name="base-binding.xml">
<name-converter strip-prefixes="OTA_"
strip-suffixes="Type AttributeGroup Group Attributes"/>
<schema-type type-name="dateTime" java-class="org.joda.time.DateTime"
serializer="org.jibx.runtime.JodaConvert.serializeUTCDateTime"
deserializer="org.jibx.runtime.JodaConvert.deserializeUTCDateTime"/>
<schema-type type-name="date" format-name="LocalDate.default"/>
<schema-type type-name="time" format-name="LocalTime.local"/>
<schema name="OTA_CommonTypes.xsd" excludes="ConnectionType">
<complexType name="SourceType">
<element path="**" name="Position" ignore="true"/>
<element path="**" name="BookingChannel" ignore="true"/>
</complexType>
</schema>
</schema-set>
</pre></div>
<p>This <i>custom3a.xml</i> customization only applies to the common definitions, so
the portions of the <i>custom2.xml</i> customization which apply to the air travel
schemas are removed. The <i>custom2.xml</i> file has an attribute <code>generate-all="false"</code>
on the root <schema-set> element, which has been removed from this customization.
This change is necessary so that CodeGen will actually generate all the components
necessary to represent the common definitions. Alternatively, if you knew you were only
going to be using some specified components from the common definitions you could keep the
<code>generate-all="false"</code> attribute and just list the components to be generated,
as done for Example 3 (and as also done for the second generation step in this modular
approach).</p>
<p>The target package used for the generated classes is also different in this customization.
The different package is necessary when using modular generation to prevent conflicts
when running the JiBX binding compiler, but generally convenient in any case to make it
easy to keep classes from different modules separate.</p>
<p>Finally, there's an added
<a href="%cgcustoms%#binding-file-name"><code>binding-file-name="base-binding.xml"</code></a>
attribute on the root <schema-set> element. This attribute gives a name to be used for
the generated root binding. It's not necessary to specify a name in this way when using
modular generation, but it does help clarify the use of the different generated bindings.</p>
<p>There's one quirk in generating the common definitions as a separate module. The OTA
schemas are structured so that only the top-level message schemas
(<i>OTA_AirLowFareSearchRQ.xsd</i> and <i>OTA_AirLowFareSearchRS.xsd</i>, in the subset
of OTA schemas used for these examples) define a target namespace. All the other schemas
function as what are called "chameleon schemas", meaning that they do not define a target
namespace directly but instead assume a target namespace when they are included (directly
or indirectly) into one of the message schemas.</p>
<p>To generate the common definitions in the OTA namespace another CodeGen parameter
needs to be used. This is the "-u" parameter, which tells CodeGen to force a namespace
for schemas which do not specify one. Here's the complete Ant target used for generating
the common definitions:</p>
<div id="source"><pre><!-- modular generation of common types -->
<target name="custgen3a" depends="check-runtime,clean">
<echo message="Running base code generation from schema"/>
<delete quiet="true" dir="${basedir}/gen"/>
<java classname="org.jibx.schema.codegen.CodeGen" fork="yes"
classpathref="classpath" failonerror="true">
<arg value="-t"/>
<arg value="${basedir}/gen/src"/>
<arg value="-c"/>
<arg value="${basedir}/custom3a.xml"/>
<arg value="-u"/>
<arg value="http://www.opentravel.org/OTA/2003/05"/>
<arg value="otasubset/OTA_Common*.xsd"/>
</java>
</target>
</pre></div>
</div>
<div class="h3">
<a name="common"></a><h3>Air travel module</h3>
<p>The <i>custom3b.xml</i> customization file is used for the second generation step
(air travel module):</p>
<div id="source"><pre><schema-set prefer-inline="true" generate-all="false" package="org.ota.air"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
type-substitutions="xs:integer xs:int xs:decimal xs:float">
<name-converter strip-prefixes="OTA_"
strip-suffixes="Type AttributeGroup Group Attributes"/>
<schema-type type-name="dateTime" java-class="org.joda.time.DateTime"
serializer="org.jibx.runtime.JodaConvert.serializeUTCDateTime"
deserializer="org.jibx.runtime.JodaConvert.deserializeUTCDateTime"/>
<schema-type type-name="date" format-name="LocalDate.default"/>
<schema-type type-name="time" format-name="LocalTime.local"/>
<schema name="OTA_AirLowFareSearchRQ.xsd" includes="OTA_AirLowFareSearchRQ">
<element name="OTA_AirLowFareSearchRQ" class-name="LowFareSearchRequest">
<element path="**" name="AlternateLocationInfo" ignore="true"/>
<element path="**" name="SpecificFlightInfo" ignore="true"/>
<element path="**" name="ProcessingInfo" ignore="true"/>
</element>
</schema>
<schema name="OTA_AirLowFareSearchRS.xsd" includes="OTA_AirLowFareSearchRS">
<element name="OTA_AirLowFareSearchRS" class-name="LowFareSearchResponse"/>
</schema>
<schema name="OTA_AirCommonTypes.xsd">
<complexType name="FareType">
<element path="**" name="Taxes" ignore="true"/>
<element path="**" name="Fees" ignore="true"/>
<element path="**" name="FareConstruction" ignore="true"/>
<element path="**" name="UnstructuredFareCalc" ignore="true"/>
</complexType>
<complexType name="FareInfoType">
<element path="**" name="Date" ignore="true"/>
<element path="**" name="FareInfo" ignore="true"/>
</complexType>
<complexType name="PricedItinerariesType">
<attribute path="**" name="OriginDestinationRefNumber"
value-name="refNumber"/>
</complexType>
<complexType name="PricedItineraryType">
<element path="**" name="AirItinerary" ignore="true"/>
<element path="**" name="AirItineraryPricingInfo"
value-name="pricingInfo"/>
<element path="**" name="Notes" ignore="true"/>
<element path="**" name="TicketingInfo" ignore="true"/>
</complexType>
<complexType name="AirItineraryPricingInfoType">
<element path="**" name="PTC_FareBreakdowns" ignore="true"/>
</complexType>
<complexType name="TravelerInformationType">
<element path="**" name="AirTraveler" ignore="true"/>
</complexType>
<complexType name="TravelerInfoSummaryType">
<element path="**" name="PriceRequestInformation" ignore="true"/>
</complexType>
</schema>
<schema name="OTA_AirPreferences.xsd">
<complexType name="AirSearchPrefsType">
<element path="**" name="VendorPref" ignore="true"/>
<element path="**" name="FlightTypePref" ignore="true"/>
<element path="**" name="EquipPref" ignore="true"/>
<element path="**" name="CabinPref" ignore="true"/>
<element path="**" name="TicketDistribPref" ignore="true"/>
</complexType>
</schema>
</schema-set></pre></div>
<p>This is essentially identical to the <i>custom2.xml</i> file used for Example 3,
differing only by missing the reference to the schemas in the common definitions.</p>
<p>CodeGen has to know about the existing modules in order to use them when generating
an extension module. This is done by using the "-i" command line parameter to give the
paths to the binding definitions for any existing modules. CodeGen will use the supplied
binding definitions for any matching schema components, rather than generating new
classes and bindings. Here's the complete Ant target used for generating the air travel
extension module:</p>
<div id="source"><pre> <target name="custgen3b" depends="check-runtime,check-base,clean-partial">
<echo message="Running extension code generation from schema"/>
<java classname="org.jibx.schema.codegen.CodeGen" fork="yes"
failonerror="true">
<classpath>
<path refid="classpath"/>
<pathelement location="${basedir}/base.jar"/>
</classpath>
<arg value="-t"/>
<arg value="${basedir}/gen/src"/>
<arg value="-i"/>
<arg value="classpath:base-binding.xml"/>
<arg value="-c"/>
<arg value="${basedir}/custom3b.xml"/>
<arg value="otasubset/OTA_AirLowFareSearch*.xsd"/>
</java>
</target>
</pre></div>
</div>
<div class="h3">
<a name="code"></a><h3>Generated code</h3>
<p>First run the 'custgen3a' target and view the common definitions module code in the
<i>base/src</i> directory, then run the 'buildbase' target to compile, bind, and jar the
common definitions. Once that's done, you can run the 'custgen3b' target and view the air
travel module code in the <i>gen/src</i> directory. To compile and bind the air travel
module use the 'buildext' target. Finally, you can run the test program to roundtrip the
sample documents with the 'runmodular' target. You can also just run the 'modular' target
to perform all these steps in sequence.</p>
<p>The generated code is very similar in structure to that from the prior examples, so
is not shown here. The main difference is that since all the common definitions were
generated separately they're in unique classes and cannot be inlined at the point of
use (though there are exceptions - by default, CodeGen always inlines attribute group
or group definitions which only contain a single component).</p>
<p>Since all the common definitions are generated as separate classes (except trivial
attribute groups and groups) the total number of classes is considerably higher than in
the last example: 185 top-level classes and 67 inner classes, for a total of 252, in the
common definitions module; plus 7 top-level classes and 26 inner classes, for a total
of 33, in the air travel module. This increased number of classes from the last example
represents a tradeoff for the convenience of a separate common definitions module.</p>
</div>
</div>
</div>
</body>
</html>
|
