BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Top Ten Web Service "Issues"

Top Ten Web Service "Issues"

Bookmarks

Andre Tost, IBM Technical Staff Member has posted an article on IBM Websphere Developer Technical Journal describing the top ten issues around Web services. David Chappell also posted his own "Top Ten List" on ZdNet.

Full text of Andre's article can be read here.

While this article has a number of IBMisms (such as the suggestion to use IBM Datapower boxes to handle XML slowdowns), it does serve as a useful jumping off point for the community to add and discuss their own top ten lists in this category.

His Personal List (and top recommendations) looks like this:

1. What really is a document/literal Web service?

Advice: 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?

Advice: 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

Advice: read the following two articles Use polymorphism as an alternative to xsd:choice and How to choose a custom mapping technology for Web services

 

4. What about UDDI? Is anyone using it?

Advice: 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

Advice: 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

Advice:

  1. An Enterprise Service Bus is an architectural pattern. Products can facilitate the creation of specific instances of that pattern.
  2. 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.
  3. The ESB is a conceptual hub that will in almost all instances be physically deployed in a very distributed fashion.
  4. 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.

 

7. Headers and other contextual data

Advice: 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.

 

8. How many (Web) services will I end up with?

Advice: 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

Advice: 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”

Advice: 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!”

 If any of this sounds useful to you, please read the original article.  This short teaser is only intended to whet your appetite for a discussion of your own top ten issues and advice you give to people beginning the whole SOA Web services journey.

Rate this Article

Adoption
Style

BT