Web Cornucopia

Gopalan's Profile

« November 2009
Sun	Mon	Tue	Wed	Thu	Fri	Sat
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

Today

Tags

bpel choreography ejb esb http integration javacaps javaee javaone jax-ws jbi management openesb orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd

Links

Referrers

Today's Page Hits: 211

Map of Visitors

Caveat Emptor

This is my personal weblog. The contents of this Weblog represent my personal opinion which may differ from the official views of my employer, Sun Microsystems, Inc. or any past employers. I do not speak for my employer or any past employers.

« JBI/SOA Tips: Use... | Main | JBI/SOA Tips: As... »

Friday Apr 27, 2007

Apr

JBI/SOA Tips: Use strongly typed messages - Avoid use of xsd:any to represent the entire message Body

As I mentioned in my previous JBI/SOA Tip-Use strongly typed messages - Avoid use of xsd:string to represent the entire message Body, you have to clearly define a strongly typed XML schema for the messages that you exchange between a provider and a consumer and ensure that each of your message exchanges are strongly typed. This also ensures that you establish well-defined and well-understood semantics for communication between your external partners even though each of your internal implementations may evolve independent of each other. Just because having a strongly typed schema for the message is not enforced anywhere, you have to stay away from the tendency to use an xsd:any element to represent your entire message body.

If you are exchanging SOAP messages, an xsd:any type, maps to a SOAPElement. Since the element is named in the WSDL, it can be used to inter-operate with any custom binding framework if that's what you are trying to achieve since the schema is not strongly typed. Moreover, the schemas for message exchanges between your partners can evolve independent of each other as long as both of you know how to process a message sent by each other.

However the big downsides to this approach are as follows:

Using xsd:any requires low level manipulation of SOAPElement objects in your service implementations
Your Service Interface is not descriptive anymore since the document type is just a wild card xsd:any element which could represent any arbitrary XML content in the schema.
Since the schemas defining the documents are not referenced directly, these schemas may have to be handled out of band in your service implementations

Like this write-up? Subscribe to receive more like it.

Posted at 12:05AM Apr 27, 2007 by Suresh Gopalan in A Tip a Day | Listen to this article

Listen to this entry | Comments added

Comments[0]

Tags: bpel choreography ejb esb http integration javacaps javaee jax-ws jbi management orchestration process-oriented sca service-oriented soa soap wsdl xml xsd
Share This Post:

Comments: