When not writing a column for the IBM WebSphere® Developer Technical Journal, I spend much of my time with architects and developers talking about the issues they face when designing and building solutions based on Web services and SOA. There are a number of issues, questions, and topics (which spark spirited debate) that surface over and over again, and so I thought I would share what has become my personal Top 10 list of Web services-related issues with you.
Note that I am not calling these best practices, simply because for many of them, there is no easy answer. By contrast, others have been answered many times, and for these I will just point you to my favorite resource that investigates the subject in more detail (most of these are developerWorks articles, of course). I realize that these topics go all over the board and that you may completely agree or completely disagree with some of my assertions; you may also have additional subjects to add. Realizing that I could be opening up a flood gate, I invite you to drop me a line with your comments.
1. What really is a document/literal Web service?
This is certainly the undisputed top question that I get to hear. In fact, we have been hearing it for several years now, so it is somewhat surprising that it still comes up so often and that there are still so many misconceptions about it. You may know that you can define both the invocation and the encoding style of a Web service in its WSDL definition. And while that has an impact on how exactly the wire SOAP message is built, it has very little effect on your overall solution, interaction style, or programming model. So my advice always goes like this:
- Don’t make it an enterprise-wide rule to use one particular style. There are reasons for having these different styles, and most likely you will come across all of them.
- Consider this subject an implementation detail and don’t let it drive or influence your system design.
- Read the great article Which style of WSDL should I use? by Russ Butek which in my opinion offers the best explanation of the differences.
2. Web services are slow -- or are they?
It is common wisdom that using Web services comes with a performance penalty. That hardly seems surprising, given that it usually involves building an XML document out of data that is formatted in some native format and sending this document across a network. While it is still true that crossing processes -- and even more so going across a network -- is always much slower than, for example, making a local invocation, you might be surprised to hear about some of the advancements that have been made for Web service performance.
There are a number of things that contribute to this; for example, intelligent XML parser technology (which is highly optimized to handle SOAP and XML artifacts), or the advent of XML appliances like IBM DataPower® (which support hardware-level XML processing). I’ll even add the Web services caching support in WebSphere Application Server as one more example that can help improve performance significantly. In fact, in some situations, SOAP over HTTP invocations on the latest WebSphere Application Server runtime are faster than invoking the same function with RMI over IIOP.
Hence, my recommendation is that you continue to apply the basic best practices for distributed computing (for example, reduce network traffic, and so on), but start considering Web services even for performance critical situations.
3. My XML schema doesn’t work with your products
Once you get past the stage of developing Hello World-style test applications, you may notice that some of the more advanced elements in the XML schema specification are either not supported or not well supported in your tools. For example, there is no mapping for the <xsd:choice> element -- which is very commonly used in schemas -- in the WebSphere tooling. The same is true for <xsd:group>. In these cases, you can choose to either change the schema, or develop your own code to process the XML that is based on such a schema. Be aware that manual intervention may be required to map your schema to your Web service implementation. Two articles I recommend are:
- Use polymorphism as an alternative to xsd:choice
- How to choose a custom mapping technology for Web services
Overall, there is no silver bullet here to resolve this issue once and for all. However, it is reasonable to expect future versions of the standards and products to also offer increasing support for advanced schemas.
4. What about UDDI? Is anyone using it?
When Web services first became popular, it was always pointed out that three main roles existed in any SOA environment:
- the service requester
- the service provider
- the service broker.
The role of the broker was typically represented by a registry following the UDDI standard. Public registries were made available for you to create your own entries and reuse others. WebSphere Application Server also comes with a private UDDI registry.
However, I still do not see much, if any, use of UDDI in real life situations. Most IT organizations build their own way of retrieving service definitions and endpoints (for example, using LDAP), or avoid the subject altogether, waiting for a new defacto approach to service registry. Others add proprietary extensions to UDDI. The public UDDI registries run by IBM and others have been discontinued.
My prediction in this space is that UDDI will over time be replaced by new technology that has yet to emerge.
5. The synchrony of Web services
Another subject of frequent debate is whether a service is synchronous or asynchronous, and what role the used communication protocol plays compared to the programming model. For example, assume that a Web service is offered with a SOAP over JMS binding. The use of JMS, which supports asynchronous interactions, seems to imply that this is an asynchronous Web service. However, if you are using the JAX-RPC support in WebSphere Application Server, the service consumer will wait until the response comes back before returning control. The reason for this is that JAX-RPC 1.1 enforces a synchronous interaction between requester and provider, regardless of the protocol that is used. In other words, the programming model that you use to invoke a Web service usually determines the synchrony of the call, and not the network protocol.
To build truly asynchronous interactions, you have two main options. Either you build a series of one-way services that exchange information, utilizing, for example, the WS-Addressing support in WebSphere Application Server V6.1. There is an article on developerWorks that I recommend for more details on this: The hidden impact of WS-Addressing on SOAP.
The other option is to leverage the Service Component Architecture (SCA) support for asynchronous invocations. SCA offers a client API that enables decoupling the sending of a request from the receiving of the response. In the future, the new JAX-WS 2.0 standard will provide similar support.
6. To ESB or not to ESB
There are a number of questions related to the subject of an Enterprise Service Bus (ESB):
- What is an ESB really? Is it a product or a pattern or both?
- Does every implementation of SOA require an ESB?
- Does the ESB present a potential bottleneck, given that it is a hub?
- What is in the ESB and what is on the ESB?
Before trying to answer these questions, let me point to a key resource that explains IBM’s vision of ESB in the context of the SOA programming model very well: An introduction to the IBM Enterprise Service Bus.
Answering the questions above could take a whole series of articles in itself, so I will just offer some brief responses here, to get you started; respectively:
- An Enterprise Service Bus is an architectural pattern. Products can facilitate the creation of specific instances of that pattern.
- A key characteristic of an ESB is separation of concerns. Things like communication protocol differences, routing and auditing of interactions, security, and so on, can be handled outside of the actual service requester and provider. If you can afford to start out your solution without this separation, you don’t need an ESB right away. In most projects, however, that’s not the case.
- The ESB is a conceptual hub that will in almost all instances be physically deployed in a very distributed fashion.
- While this is sometimes hard to tell (and is often driven by the product(s) you use), a good starting point for the discussion is to think of infrastructure logic versus business logic. Infrastructure-related things happen in the bus, whereas business-related things do not.
Again, I do not claim that these brief answers do the subject justice, but perhaps they might provide a flicker of understanding.
7. Headers and other contextual data
A key part of Web services design is to define the messages that go into and out of the service. It is probably safe to say that messages always have two key parts: the actual payload related to its business function, and contextual data (like message IDs, transactional or session IDs, security information, and so forth). Each messaging protocol provides a place for this contextual information: SOAP headers, JMS headers, WebSphere “workspaces,” just to name a few examples. The challenge is that there is not one consistent approach or API to deal with these different mechanisms, and in most real SOA environments, you will come across more than one messaging protocol.
The place that is best suited to handle such differences -- and, in essence, lets you map one header structure into another, is the ESB (take this as another hint that having an ESB is beneficial; you’ll find at least one more example further below). Most likely, this mapping will require some manual work.
Whatever your way of handling this might be, it is crucial that you plan and design a strategy for it early on, and try to keep it consistent across all of your projects.
8. How many (Web) services will I end up with?
My first reaction to this question always is to recommend a methodology that guides you in the process of identifying your services. One example for that is the Service Oriented Modeling and Architecture (SOMA) approach promoted by IBM Global Business Services. Combined with the IBM Rational® Unified Process (RUP), it can help drive your approach toward SOA in general.
Second, don’t wrap every piece of IT functionality into a Web service simply because you can. It is tempting sometimes to take an entirely “bottom-up” approach and utilize the rich tooling support for this. In most -- or even all -- cases where I have seen this approach being taken, it resulted in too many services, which were too fine grained, and had no reuse and no business relevance.
And again, no silver bullet tells you how to do this! It is hard work for both business analysts and IT architects to define and create the appropriate services, at the appropriate level of granularity.
9. Legacy applications as Web service consumers
Much focus is given to the enablement of existing functionality as a Web service. What I see discussed much less often, even though it is equally important, is the ability for existing applications to leverage new services. Assume, for example, that a company is following an evolutionary approach toward SOA, creating new services over time, and integrating them into the existing environment. One of the existing applications is written in RPG and runs on an IBM iSeries system. This application now needs to be changed to invoke one of the new services. But the developers responsible for this system are not skilled in SOAP or XML, nor do they have a RPG-based Web services package available.
The most common answer to this challenge is that the SOAP and XML processing is delegated to an ESB. Applications written in, say, COBOL or RPG, can easily exchange record-formatted messages with WebSphere MQ queues. Support for this is well established and often already in use. An ESB product like WebSphere ESB or WebSphere Message Broker can receive the data from MQ, transform it into XML, and then deal with the invocation of the new Web service.
In other words, it is typically advisable to keep the impact of new services to existing applications to a minimum and delegate the details of protocol and message formats to the ESB.
10. “The devil is in the details”
Recently, I visited an IBM Industry Solutions Center in France. It showcases IBM-based solutions for different industries like retail, healthcare, or banking. The presenter did not mention any specific IT products, instead highlighting the actual (business) function of the solution. But at one point he said, casually, “Of course, everything you see here is based on SOA.” I don’t think, though, that he was too concerned about how to maintain WS-Addressing headers across multiple protocols for asynchronous interactions...
However, architecting, designing, and implementing Web services and SOA introduces many detailed, technical IT challenges. We are using new standards, new programming models, and often new products. Creating solutions that support, for example, interoperability between heterogeneous platforms, enterprise-wide reuse of IT services, and frequent changes to the functional requirements of systems by line-of-business demands, leads to often unforeseen problems.
So, the next time your manager enters your office and says “I want you to build me one of those SOA solutions that everyone says are so easy to do,” you can say what my colleague Greg Flurry likes to say in those occasions: “The devil is in the details!”
- Which style of WSDL should I use?
- Web services tip: Use polymorphism as an alternative to xsd:choice
- Web Services Custom Data Binding, Part 1: How to choose a custom mapping technology for Web services
- The hidden impact of WS-Addressing on SOAP
- SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus