Tag Archives: Web services

OOPSLA’07 – SOA and Web Services

After arriving in Montreal Saturday evening, on my first day at OOPSLA, I attended the Fifth International Workshop on SOA & Web Services Best Practices. The workshop consisted of a couple of keynote talks, presentation of papers, and group work.

Olaf Zimmermann stepped in for Ali Arsanjani, giving a keynote on SOA. One of the things he talked about was three central patterns that are central for SOA, namely

  • Service composition
  • Registry
  • Enterprise Service Bus

So, I guess if you have none of these in your architecture, you are not doing SOA. 😉

The second keynote of the day was given Gregor Hohpe, author of the seminal book Enterprise Integration patterns. He talked about the usage of patterns in general, and in the context of integration and SOA in particular. One of the points he made was that the “WebMethod” approach to making services is flawed in the context of SOA. It is certainly buzzword compliant, but that’s all. (By “WebMethod”, I refer to the approach where you declaratively annotates your existing class to generate a Web Service interface for it)

Gregor went on to talk about design patterns in general, and summarized the aspects of design patterns:

  • They are “Mind sized” chunks of information (attributed to Ward Cunningham)
  • They are used for human-to-human communication
  • They express intent (the “why” vs. the “how”)
  • They are observed from actual experience
  • They do not firm a rule (rather guidance)
  • They are not copy-paste code

He also made a point that sketches are important in patterns. However, it should be emphasized that
sketches should not be mistaken with blueprints. Furthermore, he made a point that patterns could effectively be used to test products/frameworks by testing to see that the product or framework could cover design patterns.

Yet another point made (which I think makes much sense) was that declarative programming brings you further away from the execution model, which makes it hard to understand what’s going on, and harder to debug since the the execution path is chosen at run-time. Certainly something to think about, as we see
the use of declarative programming (through annotations in Java, attributes in .NET, XSLT, and various

rules engines) is growing.Looking at SOA and integration in general, Gregor went on to point out that SOA means event-based, asynchronous programming, or “programming without a call stack”. Furthermore, he warned about trying to “program in pictures”. Looking at pictures to understand the architecture is OK, but trying to program pictures brings on problems like scalability, lack of support of diff and merge, etc.Another part of the workshop consisted of group work, where various topics around SOA and web services were discussed.
One of the most important point I think was that we should strive for simplicity in SOA. As vendors bring on more and more products, we should really look at how we can scale down solutions, and make middleware simpler.

A Theory of Compatible Versions

Creating a versioning scheme for web services is a challenge that I have faced on a few occasions before. My experience is that creating compatible versions of a web service takes a lot of consideration, and I have not really found any good approach. The article ‘A Theory of Compatible Versions‘ gives a very good foundation for making compatible versions of an XML document, which can be used as a foundation for making compatible web services.

I think compatibility underlines the fact that a web services interface needs to be carefully designed, for instance using the contract first approach. You cannot simply have your WSDL file generated from existing code and publish it.

OOPSLA Workshop

I attended the 4th International Workshop on SOA & Web Services Best Practices workshop at OOPSLA today. The workshop brings together people with theoretical and practical background with the respect to SOA and Web Services.

Services versioning

One of the things that were discussed was the versioning of (web) services, i.e. how to handle web service upgrades and discontinuance. What we found, with good help from Nico Josuttis who attended the workshop, can be summarized into these three points:

  • Each modified service is a new service
  • Each modified data type is a new data type
  • Don’t use service types in your application

Basically, this gives how you should handle creating new versions of a service while providing older versions of the service to “old” client. The thing is that when you create a new version of the service, that’s a new service that gets deployed aside the old service that clients that are aware of the new version can connect to. Old clients can still, at least for a certain period, connect to the old version. The same goes for data types, typically defined using XML Schema Definitions.
I think that versioning is a very important architectural decision that you need to make when you create services in a large organization, or between organizations, where services and clients have different owners, funding, and life-cycles.

Automated robustness testing

One of the interesting papers submitted to the workshop presented an approach for generated robustness tests for web services from the WSDL of the web service. Basically, the approach was that the WSDL was used to generate tests that could be run using a unit testin tool such as JUnit, and using a tool like JCrasher to generate different kinds of inputs to the web service in order to test that the service is able to handle these. I think this is a good idea that has a lot of potential in automatically assessing the robustness of the service.

Transferring binary documents in web services – MTOM

I am currently grappling with the challenge of transferring large binary documents in Web Services in an efficient manner. Finally, some of my colleagues came up with the suggestion to use MTOM, which seems to be very promising.

From my initial understanding of the protocol, I would think that MTOM has the  following advantages compared with the approach of including large documents base64 encoded or hex encoded within the SOAP envelope itself:

  • Smaller messages – less bandwith intensive communication
  • No base64 or hex encoding and decoding needed – less CPU resources needed
  • Easier XML parsing since the large document is not included in the XML document (probably both less CPU intensive and memory intensive, depending on the parser)

I would expect that the removal of base64 (or hex) encoding and decoding, together with potentially much swifter XML parsing would significantly lower latency at intermediaries in the value chain. My problem now, is that this is only a gut feeling, rather than hard facts. So, I am preparing to set up a test of MTOM in this respect, with different document sizes to try to measure the differences.

Further reading:

To be continued…