Q
Problem solve Get help with specific problems with your technologies, process and projects.

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?

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

Dig Deeper on Topics Archive

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close