• Post Reply Bookmark Topic Watch Topic
  • New Topic

Mark Hansen: Specificity of Payloads  RSS feed

 
Michael Nygard
author
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark,

Neal Ford has advocated a style of argument passing for web services in which the payload of a service call is treated as a Document object. In other words, avoiding the use of parameter encoding by the toolkit and instead using JDOM calls to deal with the arguments inside the service call.

His argument for this style is that it provides better decoupling between caller and provider, since the protocol can now be upgraded and the provider's endpoint doesn't need to change. (I.e., you won't have a bunch of "FooService2" and "FooService3" endpoints laying around.)

This is the opposite of the typical style of parameter passing, which treats the service parameters in as strongly-typed a way as possible. The strong-typing approach reduces the amount of code needed in the service itself and lets the framework handle validation and enforcement for us.

What's your position? Strongly-typed parameters or "big bag of bytes"?

Cheers,
-Mike Nygard
 
Mark D. Hansen
author
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good question I think that "strongly typed" and "bag of bytes" both have advantages.

And now I see where you were going with "Example 3" from the previous post! You are right that one advantage of "bag of bytes" is that you get more flexibility with change management. I.e., your endpoint can accept *both* old and new versions of a message standard, and let the internal application logic straighten it out.

By the way, the Java Web Services @Provider annotation and Provider<Source> interface are designed to support this "bag of bytes" approach. That is what gets used in the SOA-J framework I describe in Chapter 11.

In general, I think it boils down to this:
* "strongly typed" allows for faster and safer development of Web services. When the XML Schema for a message (provided by the WSDL) is mapped to Java parameters via the JAX-WS standard Java/WSDL binding, then your Web service is guaranteed to reject badly formed messages. Also, you don't have to write JDOM code (or any other parsing code) to map the incoming message to useful Java classes.
* "bag of bytes" allows for a lot more flexibility at the endpoint. In addition to the example given for change management, this approach also lets you handle malformed messages without necessarily returning a fault. It also let you handle a greater variety of message structures than can be expressed in XML Schema.

But, it is a lot of work to parse XML in your endpoint code. In Chapter 7 of my book, I provide an example (Example 7-5) that shows the use of DOM for doing this kind of "bag of bytes" processing. The simple order processing example there uses 80 lines of DOM code. The same processing, done using JAXB and "strongly typed" messages, shown in Example 7-3, uses 20 lines of code.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!