BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Top Ten Web Service "Issues"

by Miko Matsumura on Aug 25, 2006 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Dave Chappell's Ten-Step Program by miko matsumura

By the way, I satirize Dave Chappell's Ten Step Program with my own 12-Step program...

Dave's 10 steps:
news.zdnet.com/2100-3513_22-6108621.html

My 12 Step Program for SOA

en.wikipedia.org/wiki/Twelve-step_program

1)We admitted we were powerless over inflexible IT systems?that our lives had become unmanageable.

?Hi my name is Brad and I?m a tighly coupled systems addict??

2)Came to believe that a power greater than ourselves could restore us to sanity.

I know? IBM!

3) Made a decision to turn our will and our lives over to the care of God as we understood Him.

Don?t worry, IBM Global Services will take care of us

4) Made a searching and fearless moral inventory of ourselves.

I dun wrong, I created redundant services in application silos boo hoo =(

5) Admitted to God, to ourselves, and to another human being the exact nature of our wrongs.

Marge, I done cheated on you with another IT Vendor?

6) We?re entirely ready to have God remove all these defects of character.

Don?t worry, IBM Global Services will take care of us

7) Humbly asked Him to remove our shortcomings.

Can you please rearchitect my services using model driven business process decomposition too while you?re at it?

8) Made a list of all persons we had harmed, and became willing to make amends to them all.

I hope Bob in IT operations will forgive me for delivering a hopelessly unscalable and unmaintainable application?

9) Made direct amends to such people wherever possible, except when to do so would injure them or others.

Here you go Bob, here?s a chargeback straight from my budget to yours.

10) Continued to take personal inventory and when we were wrong promptly admitted it.

I?ll just put all my wrongs into the CMDB defect tracking system.

11) Sought through prayer and meditation to improve our conscious contact with God, as we understood Him, praying only for knowledge of His will for us and the power to carry that out.

Thank god for prayer and meditation, reading all those white papers seems like the hard way to go.

12) Having had a spiritual awakening as the result of these steps, we tried to carry this message to alcoholics, and to practice these principles in all our affairs.

Gee, now that I?m enlightened, I?m an ?SOA Evangelist?! (tip of the hat (and RESPEC) to Dave Chappell)

Re: Dave Chappell's Ten-Step Program by John Harby

This is awesome Miko! Great work and laughs.

Granulartity by Jack van Hoof

With regard to point 8 about about granularity: I think there is a mixing up of services which are functional components, and "Web Services" which is an interface implementation technology. To me it makes more sense to ask at which levels of granularity the use of web services technology is appropriate. And that depends on system implementation characteristics such as degree of distribution and heterogeneity and desired openness. The granularity of functional components "goes to the bottom". It's just common modular and structured design and programming practice, originating from the 60's, every developer should now about. Read, for instance, "Reliable Software through Composite Design" by Glenford J. Myers, 1975). So in fact there is no conceptual granularity-issue.

Read my thoughts here

Jack van Hoof

Re: Granulartity by John Harby

Given that we assume web services are an interface implementation technology I try to apply a Shlaer-Mellor style approach with transfer vectors, bridges and wormholes to avoid the distributed objects antipattern and also consolidate the interfaces to my domains.

Internal services vs External by j c

So we jump on and "align" our app services with "the business"
Assuming that the fine grained things we do "should" be exposed.

And then low and behold my internal apps have to call a web service to access what they previously could have done themselves by going to the database but now have to make a network call and parse some XML...just to get some data from the DB.

Big problem: Still no customers for this "service" which is supposedly "aligned with the business".

Well, its not aligned, and it likely never will be. But at least in return I have had to create more infrastructure to centralize the approach and slowed down my apps (which hopefully arent mission critical) several orders of magnitude as each functional area is taken over by a "service" and I still dont have any business reason for doing this.

Who profits from this? Big consulting firms and thats all.

Show me your wsdl and Ill show you mine. Well when you show the big company your wsdl and they compare it to every other smaller company's wsdl and form a "standard" they will know your business from the interface and put you OUT of business.

That's the facts Jack.

Re: Granulartity by Jack van Hoof

Quite interesting, John. I perceive some sort of view-hierarchy:

  • 1. business events (triggers for business processes)

  • 2. business processes (responses to business events)

  • 3. applications, functional decomposition (supporting business processes)

  • 4. objects, semantic decomposition (application building blocks)


At what level(s) is the exposure of web services appropriate?

Jack

Re: Internal services vs External by Jack van Hoof

j c wrote:
Show me your wsdl and Ill show you mine. Well when you show the big company your wsdl and they compare it to every other smaller company's wsdl and form a "standard" they will know your business from the interface and put you OUT of business.

Do you really think so?

Re: Granulartity by John Harby

Ok, in theory the goal is to acheive the highest granularity with the lowest frequency, in other words rather than sending three separate messages/requests, bundle those up into the "transfer vector" and send them across the "bridge" and through the "wormhole". I don't know if you did any Shalaer/Mellor but bridge is what you would think and wormhole was targeted at isolating the communication points within the domain (business). E.G. If I have a CRM domain and a HR domain with HR keeping track of employees working in customer support then I should isolate any calls from CRM -> HR to a very specify area (class) in CRM and HR rather than having calls coming from all areas (mesh). It was a very heady methodology created by some sophisticated mathematicians. I don't necessarily advocate the entire process but think that there are some cool patterns to extract.

Re: Granulartity by miko matsumura

John this is extremely intriguing sounding stuff. I'm sure InfoQ readers would appreciate a deeper dive into this methodology..

Miko

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT