|
|
XML Envelopes...
|
[
Lists Home |
Date Index |
Thread Index
]
Got a bit of a tough one (for me anyway...).
Got an XSD Envelope that we wish to
use for all messages. It's generic.
At the body node though, we wish to
specialise that node & add the specific schemas for that particular
service.
Now, there's a couple of ways to do
this:
Option 1) The way I've done it in
the past (ESB.NET) - pure but not very friendly/descriptive.
==>Define the actual details of the
payload in a service definition only, not as part of the envelope.
This makes it easy for the framework
in a way, but makes it a bit of a pain to develop with as you effectively
have no document schema (only the envelope schema). The envelope manifest
then tells you what's in the body & you take it from there. Note very
WSDL tools friendly!
One advantage is that the schemas are
completely Envelope Agnostic.
Option 2) Somehow come up with a
new schema for each service, that's a specialization of the Envelope
This option involves either the schemas
having knowledge of the envelope (which is very limited - eg. a particular
request can have many different schema documents included), or the creation
of a specialization of the Envelope which contains the details of all the
documents possible for that request. For example, the WfXml can be viewed
as such a specialization, where the specialization of the body node
is an enumeration of the possible schemas available for WfXml. This is
an effective way of reducing the number of specialized schemas.
Note, however, that it's a WfXml specific
Envelope Schema, and we need a generic Envelope Schema that can be used
for building any service.
With Option 2 then...I have a bit of
a problem...
If I've got: ( Generic Envelope...)
<nsEnv::ESBEnvelope>
<nsEnv:header>...blah...complex type in here...</nsEnv:header>
<nsEnv:body>
<!-- documentBody is an
xsd:any ...-->
<nsEnv:documentBody></nsEnv:documentBody>
<nsEnv:documentBody></nsEnv:documentBody>
<nsEnv:documentBody></nsEnv:documentBody>
...
</nsEnv:body>
</nsEnv:ESBEnvelope>
documentBody above is
defined like this:
<xsd:element
name="documentBody">
<xsd:complexType>
<xsd:sequence>
<xsd:any
namespace="##any"
processContents="skip"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Ideally, I wanted an Envelope Specialization...for
Spec1...
<nsEnv::ESBEnvelope>
<nsEnv:header>...blah...complex type in here...</nsEnv:header>
<nsEnv:body>
<!-- documentBody is an
xsd:any ...-->
<nsEnv:documentBody>
<nsEnvSpec1:SomeSpecializedBody>
(with a bunch of stuff under here...)
</nsEnvSpec1:SomeSpecializedBody>
</nsEnv:documentBody>
<nsEnv:documentBody></nsEnv:documentBody>
<nsEnv:documentBody></nsEnv:documentBody>
...
</nsEnv:body>
</nsEnv:ESBEnvelope>
How exactly do you do this?
Inheritance (derived by extension
or restriction) falls short (unless I stuffed it...) in that I need to
not only specialize documentBody , but also ESBEnvelope and
body which has the ugly side-effect of duplication, and worse, a
new namespace for the node!
Remember that you can have multiple
documents in the Body, from completely unrelated Schemas. As such, the
coupling of Envelope and Document needs to be done on a "Per Service"
Basis or something, not on a "Per Schema" basis.
Other options?
Thanks
Cheers
Minas Casiou
| ESB Technical
Architect I&I |
MRP - Mainframe Replacement Program |
BTS |
New South Wales Police
Phone: 02 9689 7610 |
Eaglenet: 79610 |
Mobile: 0431 103 925 |
email: casi1min@police.nsw.gov.au
This message and any attachment is confidential and may
be privileged or otherwise protected from disclosure. If you
have received it by mistake, please let us know by reply
and then delete it from your system; you should not copy
the message or disclose its contents to anyone.
|
|
|
|
|
|
|