OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML Envelopes...

[ Lists Home | Date Index | Thread Index ]
  • To: "'Fraser Goffin'" <goffinf@googlemail.com>
  • Subject: RE: [xml-dev] XML Envelopes...
  • From: "Minas Casiou" <minas@optusnet.com.au>
  • Date: Mon, 24 Jul 2006 08:30:53 +1000
  • Cc: <xml-dev@lists.xml.org>
  • In-reply-to: <88aed1ea0607230800h57b4ca82ucd9dc4fd213ab340@mail.gmail.com>
  • Thread-index: AcauaLALAKxN4wmORSaNrTl4YLpamAAOh7pg

Hi Fraser,

You’re exactly right. Some things in my envelope cross over to transport, however they’re at a level that a Business Person would also understand.

There’s a manifest, which contains details about the message at a relatively simplistic & high level.


Remember that it’s also used outside of solutions that use SOAP. Eg. Plain old FTP-aware systems that don’t support SOAP. Sure, SOAP is transport agnostic, but the other end MUST be able to process a SOAP message to process it. Much older systems cannot do this – although the numbers are decreasing, you’d still need to do some work to get a SOAP compliant system in some areas.

Coupled with SOAP versioning and associate logistical problems, of keeping stuff stable over a long period of time (say 5 years or more) whilst SOAP envelopes & parsers etc. change to meet other requirements & compatibility issues, none of which are related to the business domain it is I’m working with, relying on SOAP to do this is not a good strategy. It’s sort of like saying I’ll use SOAP to Walk, when SOAP is more targeted at doing the work of Aeroplanes, Trains, Cars etc. My Envelope sort of does the final few steps, which are best done by foot.


Here’s maybe a sort of example/comparison (lost for words now…just need to get out of here & get to work…J )

Eg. Move a parcel from US to Australia

  1. (My Envelope) Person constructs a message containing Business Level Data and then Packages it up & puts a meaningful address to him/herself on it…
  2. (SOAP equivalent)Courier picks it up & may make more specific requirements of the address, add a return address in case it can’t be delivered, with Insurance etc…
  3. (SOAP equivalent, inc. transport level details) Plane ships it to Australia…with associated routing info
  4. (SOAP equivalent, inc. transport level details) Gets received in Australia put in a Van/courier to move it to a closer place to it’s ultimate home (which is logically some place in a Business Person’t mind…) who ships it to a particular address
  5. (My Envelope) Business Person opens up the Package and looks at the Contents of the message (Manifest etc.) at a level that’s sensible & directly meaningful to the business. They then proceed to process it.


Note the emphasis on the Business Person. They’re the only thing that matters to this message.

There’s address info in both SOAP (as well as lower level representations… MacAddress etc.) but they’re not very meaningful to the Business Person. Sometimes though, it gets a little grey. At that point, always put the Business Perspective forward, and handle the grungy stuff at the lower (Technical) layers. Important thing is that Business View is not obscured, as that’s the ultimate purpose of the software being built – the business.

In this case, having Business People’s data mixed in with SOAP tags & treated as extensions of SOAP doesn’t work too well. Things aren’t separated very well. That’s my view.


Having thought it through yourself, you can see it’s not something to be taken too lightly. I’m glad this user base is growing. Just came across someone in another small co. the other day with the similar dilemma & solution. Key thing to note is that development tools aren’t addressing this area at the moment, which is a little unfortunate.


I view it as something WS-BPEL should look at doing. It should be split into 2 layers. Abstract the WSDL & SOAP stuff away at the bottom level, and do something more high level like this when associating to the Business Process being built. I’m not holding my breath though…


Here’s my Envelope schema (attached).

Also, see how it correlates to the service definition at:


(contains description of important fields etc.).


As you mention, there’ll be duplicated effort, but the essence of it is to separate away the Business View…and somehow get the technical stuff done from this info.

It’s both simple & complex depending upon your viewpoint…





Minas Casiou

Keystroke IT




From: Fraser Goffin [mailto:goffinf@googlemail.com]
Sent: Monday, 24 July 2006 1:00 AM
To: Minas Casiou
Subject: Re: [xml-dev] XML Envelopes...




thats quite interesting. Recently we've also been having some internal discussions about where meta-data related to the business payload could/should be located. On the one hand one might argue that if the data is concerned with the business process then it should be in the payload part of the message. We also recognise though that sometimes the same data is required BOTH for business processing and for [say] message delivery. For example, many of our messages contain an agent reference. This is used for determining business terms at the process level but also may be used to route the message ( i.e. it could be used as a QoS signal). In these cases it seems legitimate for it to be in both areas.


Incidentally I don't view SOAP as merely a transport layer, and SOAP headers are designed to contain meta -data for a number of purposes routing and delivery are just two, but business intent/semantics may also be there. SOAP headers also aren't the sole preserve of WS-* although these do provide some useful (and largely interoperable) standards. And MTOM / SwA are just packaging protocols. ebXML MS is different though in the sense that its vocabulary allows for multi-part messages to be described by a manifest (I wasn't especially referring to its capabilities for reliable messaging) which I thought was part of your original post problem space.


Anyway, it was perhaps the use of the term 'envelope' which threw me slightly from your original post. Tell me then, since the structure of your 'business' envelope is similar to SOAPs and pretty much any message model that describes a 'container' which includes a place for meta-data and a place for business payload, are you using your header and body sections in this way ? What sort of data exists in headers ?


I would have thought you would define some common/standard meta-data which applies across many services, some which apply specifically to a single service, together with transaction/service level schemata for the payload (which may in themselves utilise common data types and aggregates from your underlaying data model - you do have one of these don't you ?).




On 23/07/06, Minas Casiou <minas@optusnet.com.au> wrote:

Hi Fraser,


The reason boils down to "Separation of concerns…"


I don't want to use the SOAP Headers.

My Envelope contains Business Related Information, not implementation details.

I'll leave the SOAP headers to the WS-* people. As an example, ebXML and WS-RM have both worked in the area of Reliable Messaging. If I'd picked the ebXML SOAP extensions, I'd have issues converting my stuff to WS-RM…


Whilst the SOAP headers are effectively treated as another layer in the Network Stack, and stripped off before being passed into apps, my Envelope sits on top of that, and only gets pulled apart by the relevant business components that work with it. Kind of like the layer on the Network Stack that sits atop SOAP, but squarely in Business Layer land, not transport.


Also, it works whether or not SOAP is used. Not everything supports SOAP cleanly. At the end of the day, the business doesn't care how the message gets there, as long as it's all legible. My Envelope is the Business Message. Contains nothing related to transports & what have u…


I had a long design session years ago (late 1999), when I decided how this would work. I only started using the SOAP stuff a couple years later, but that same model is still working for me today.

Only difference is that the technologies these days are making my life easier.

For example, XSD include…woohoo. None of that in 1999 with XDR…

SOAP, attachments/DIME, then MTOM… made life easier for me. My architecture has not changed yet. And why would it? It's just messaging, with XML as the data format. A simple header to describe the message & we're set – can pretty much handle any request. It hasn't failed me yet, and I haven't even conceived any situation in the Enterprise that I may encounter that it won't work for. Don't get me wrong – I'm not saying it can do anything & replace everything else out there etc. It's got its drawbacks – relatively heavyweight, learning curve & hence slow adoption etc., but in complex integration scenarios, this model works very well, as it provides a nice way to abstract many common issues away from business specific logic, application layers etc.

Main reason for this is that it focuses on the Business data & services required, and ensures the implementation does not need to re-define data etc. etc.

The apps that process the message can add their own junk all over the shop, without corrupting the boundary between business data & technical data. It sounds simple, and it is…as long as you get it… J






Minas Casiou

Keystroke IT




From: Fraser Goffin [mailto: goffinf@googlemail.com]
Sent: Sunday, 23 July 2006 12:58 AM
To: Minas Casiou
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] XML Envelopes...


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) ?




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: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>

Ideally, I wanted an Envelope Specialization...for Spec1...
        <nsEnv:header>...blah...complex type in here...</nsEnv:header>
                <!-- documentBody is an xsd:any ...-->
                < nsEnv:documentBody>
                        < nsEnvSpec1:SomeSpecializedBody>        (with a bunch of stuff under here...)
                        </nsEnvSpec1: SomeSpecializedBody>        

                < nsEnv:documentBody></nsEnv:documentBody>

</ 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?


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.





News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS