[
Lists Home |
Date Index |
Thread Index
]
Why can't you just use SOAP for the generic Envelope / header structure and consider something along the lines of the ebXML messaging standard for the payload (i.e. the payload of the first part of a multi-part message contains a manifest which points to each of the business payloads in other parts) ?
Fraser.
On 21/07/06, Minas Casiou <casi1min@police.nsw.gov.au> wrote:
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.
|
|