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

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.

« JavaOne 2007 - Atten... | Main | JBI/SOA Tips: Use... »

Thursday Apr 26, 2007

Apr

JBI/SOA Tips: 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:string element to represent your entire message body.

If you go ahead and do represent your message body as an xsd:string type, you could probably develop some simple clients. There may be no issues with interoperability between the frameworks you use - be it Java or .NET - since your whole XML payload within the message body carries the message data as a string.

However the big downsides to this approach are as follows:

Your Service Interface is not descriptive anymore since the document type is just an xsd:string.
Any schema validation provided by the runtime cannot be used to validate the message body since the payload is no longer strongly typed.
It can also be memory intensive since the whole XML document may have to be read into memory as a string for each request.

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

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

Listen to this entry | Comments added

Comments[4]

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:

I don't agree. 1) The consumer does not always talk to the provider directly. When you use SOAP proxy, you do not care about the SOAP BODY. Even the SOAP HEADER is not always useful .... but the protocol headers are. Example routing message: ON SOAP/HTTP, I use the HTTP URI and SOAP action to determine the service to be called. If SOAP/JMS, I will use the JMS header. The content is useless to build such service and overall my implementation is much faster. 2) Sometimes you want to have some loose information. In this case xsd:any can be useful (not for the complete message but for a part of the message)... the problem is that it is not well supported by products. When I say loose information, I 'm talking about service that may change in the future (versioning/dynamicity).

Posted by Veton on April 27, 2007 at 06:10 AM PDT #

Strong typing--stronger, in fact, than has ever been attempted or proposed--is necessary. Yet in the same breath we must point out that schema validation at runtime is an antipattern. Message producers and consumers both validate de facto, and consumers can always redefine the type to suit their purposes, requiring elements that the schema says are optional, ignoring elements that the schema says are mandatory, imposing syntactic conventions that the schema doesn't care about, etc.

Posted by Frank Wilhoit on April 27, 2007 at 06:13 AM PDT #

Hello Veton

<Veton>
1) The consumer does not always talk to the provider directly. When you use SOAP proxy, you do not care about the SOAP BODY. Even the SOAP HEADER is not always useful .... but the protocol headers are. Example routing message: ON SOAP/HTTP, I use the HTTP URI and SOAP action to determine the service to be called.
</Veton>

Relying on SOAPAction is not a good idea since SOAPAction is really only an 'intent' as can be seen from the specification. In fact the SOAPAction field has been removed in SOAP 1.2 version of the spec.

<Veton>
If SOAP/JMS, I will use the JMS header.
</Veton>

JMS is for use within the enterprise. JMS cannot work across firewalls. If you are going to expose a service to external clients outside of your enterprise, you would expose it through SOAP/HTTP, not through SOAP/JMS.

<Veton>
Sometimes you want to have some loose information. In this case xsd:any can be useful (not for the complete message but for a part of the message)... the problem is that it is not well supported by products. When I say loose information, I 'm talking about service that may change in the future (versioning/dynamicity).
</Veton>

The are other ways to do versioning than providing xsd:any extensions in the schema.

Cheers
Gopalan.

Posted by Gopalan Suresh Raj on April 27, 2007 at 11:19 AM PDT #

Comment 1 : Loose typing doesn't mean shoving everything into xsd:string. Hashes of strings are also "Loosely typed", but still descriptive enough (e.g. attributes of a item)

Comment 2 : Strong typing forces clients to jump through hoops to transform the data when passing parameters. However, if the type definition in your interface is exactly the same as the type definition of data source, no transformation is required - even if the parameter is strongly typed.
That brings us to one of the biggest misconceptions of SOA design which is that service owner s are responsible for the type definition of all parameters of their interfaces. Service owners should instead strive to find the canonical sources of the data that is being passed to service, and reuse their type definition. If the service owner cannot find a canonical source - creating a strongly typed interface will simply make it difficult to reuse the service.

Posted by Alan Ho on April 28, 2007 at 01:32 AM PDT #