Message-style approach versus a method-invocation style

Message-style approach versus a method-invocation style

We are building our first Web service on J2EE platform (BEA WebLogic application server). I have been a keen follower of advice coming from you and other experts at SearchWebServices.com.

I am dealing with a question, which is gradually turning in to a religious issue. The key consumers of our Web services are a PB9 application, a .NET application and another J2EE application. The value proposition of using Web services here is that it provides a solution to integrate these diverse set of applications.

We correctly started first with a WSDL (as opposed to starting with components on J2EE which can be converted into Web services by tools). But next the important question is about XML schemas. We can define types inside the WSDL as follows: 

<wsdl:types>
        <xsd:schema>
	<xsd:complexType>
	.....
       </xsd:schema>
</ wsdl:types>

OR alternatively import the schema types in the WSDL. In either cases, when the Web services toolkits (on various platforms) are ran (either to generate shell or to a generate proxy), we get language specific classes for schema types defined within the WSDL.

The toolkits are at various maturity levels and their support for various schema features is limited. Just getting a base minimal WSDL that correctly generates and handles all the XML schema types on all the platforms is a challenge. Additionally, I loose the rich validation aspects offered by the schema because the types generated does not do cool things like pattern checks or check for nulls, etc., and I have to code for those things.

All the platforms support strings, so my solution to this problem was to simplify the WSDL by not having types at all -- have a basic contract using strings. The service consumers pass XML documents (adhering to schemas defined but not part of WSDL) via these strings. The service provider uses the XML schema (agreed upon earlier) to validate the XML passed over.

Now I am losing the language specific types, but I have made the interface simple and loosely coupled. Also, I don't have to worry about any platform specific support for a particular XML schema feature, which may work on one platform but not on other.

What is wrong with this approach versus using (or importing) types within WSDL?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

You're using a message style approach rather than a method invocation style approach. Rather than letting the middleware convert XML into language-specific types, you leave it to the application to process the XML. In some cases, this is a more effective way to achieve interoperability, but you lose a lot of the productivity benefits associated with using SOAP and WSDL.

If possible, I recommend using types rather than just sending an XML message. Here are my recommendations for making it work:

  1. Use Document/Literal
  2. Follow the "wrapped" programming convention -- most toolkits can simulate the RPC programming invocation model when using Document/Literal with the "wrapped" programming convention. See my blog for more information on the wrapped style.
  3. Keep your types relatively simple. Use simple types, structures of simple types, and arrays of simple types or structures of simple types. Your structures should be defined as sequences. Avoid using choice groups, unions, etc.
  4. Define your types in a separate schema and import them into the WSDL. If a toolkit can't process your type definition, then you can develop a custom de/serializer, or that specific application can process the SOAP message by hand (they way you're doing it today).

This was first published in November 2004

Back to top