Category Archives: SOA

How Loosely Coupled is Your SOA?

Posted on: August 22, 2005 | Posted in: SOA

SOA is the all about loosely coupled services, right? The Web service behind
WSDL is an opaque black box, i.e., it might be implemented by an EJB today and
by some COTS package tomorrow. XML must to be used for passing data between
layers; we can‘t assume that service provider and service consumer understand
the same binary protocol.

What does it mean to a typical J2EE application? For the sake of the discussion,
let‘s assume that our application has rich domain object model (say, POJOs with
Hibernate persistence), EJB session fasade classes and Struts/JSP on the front-end.
Domain classes are directly used in the UI tier; there are no DTOs.

Now, some business functions of our application turned out to be pretty useful
so we now want to build Web services to allow the entire organization (or may be
even business partners) to benefit from these functions.

“Pure“ SOA would require us to change the UI so that it would rely on Web
services API and XML instead of POJOs to communicate with the back-end.
Potentially, we‘d also have some kind of ESB /messaging solution in the middle.
With that, the service becomes fully de-coupled from the UI and we‘re well on
our way to SOA nirvana. Now the implementation of the Web service can be changed
without affecting anything on the client‘s side.

But if you look at this approach closely, it immediately raises some nagging
questions:

  • Both UI and back-end still depend on the same object model. So whenever object
    model classes change, we want to re-deploy both the service and the UI component.
  • If data model changes, object model, UI and may be APIs will be affected anyway.
  • We loose the ability to call the service from other EJBs (still co-deployed
    with the UI) as part of the same transaction unless some kind of proprietary
    SOAP binding is implemented (and then we need two different WSDL files, one for
    external consumers, one for internal).
  • There are also some “minor“ issues, like concurrency. Let‘s say each updatable
    POJO has a version number and the UI keeps the object in session for each form.
    This is not exactly the best model for Web services that are supposed to be
    stateless; perhaps we should not assume that all service consumers will be able
    to comply with that.

The list can go on, but I‘ll stop here. Doesn‘t look like we‘ve accomplished
much by “SOA-izing” our application, does it? Perhaps, what we should‘ve done is
to leave the application alone and build the service just for the external
consumers. Oh, and it would be nice to know what their requirements are before
we do that, may be we should not assume that one size will fit all of them.

Are Web Services Suitable for SOA?

Posted on: August 14, 2005 | Posted in: SOA, Web services

SOA may mean different things to different people (to me, SOA is just an
architectural style), but one thing is certain – SOA is being touted as the next
generation enterprise integration technology and architecture. And yes, SOA is
not all about Web services; however, Web services (SOAP and WSDL specifically)
are immediately brought into conversation when SOA is mentioned.

But do Web services today provide necessary enterprise-level capabilities?

Take transaction support. Ideally, we should be able to wrap any access to a
remote resource in a transaction since remote resources are prone to failing. In
J2EE , this is certainly supported for JMS , JDBC and RMI . Yes, two-phase
commit comes at a price, but it‘s nice to have it available when it‘s needed.
Now, SOA is all about remote calls (synchronous or asynchronous, does not matter).
So where is the transaction support? Well, there is WS-AtomicTransaction
specification that in theory should provide it. But where are the products that
support it today? Also, this specification is not currently part of any WS-I
profile, so interoperability is a big question.

WS-ReliableMessaging is in the similar situation, and so the rule of thumb today
is that Web services should conform to WS-I basic profile, which does not
include any of the advanced specifications.

In theory, one could use SOAP over JMS supported by many J2EE vendors today
which immediately makes SOA implementation more robust. But this approach is
hardly interoperable with non-Java technologies and what is it really buying for
J2EE applications? JMS is already an abstraction of the messaging middleware, so
why do we need another abstraction on the top of it?

I concede that describing JMS destinations using WSDL might be useful for some
environments, but in many cases it is simply overkill (if you must use BPEL ,
use the BPELJ variant which directly supports JMS ).

Using JAX-RPC or WSIF to communicate with JMS does not sound like a good idea
either. These APIs are not JMS -aware, so, for example, how do I get/set
messageID or correlationID?

I do realize that developing true enterprise-level integration technologies
takes time, and so perhaps in a couple years most Web services products will
provide WS-Transaction and WS-ReliableMessaging support out of the box. But are
Web services really ready to take on the enterprise today?

Hurdles with Document-Style Web Service

Posted on: June 26, 2005 | Posted in: Web services

Lat week I spent some time prototyping a simple document-style web service. Basically, I wanted to figure out how to pass an XML document with several nested repeating groups to a web service. Apache Axis was the obvious choice for a SOAP engine-I did not want to install anything heavy.

I totally expected it to be a half an hour deal at most — after all, SOAP is already XML, so wrapping my XML message in SOAP envelope should not be a big deal, right?

In reality though, I immediately ran into issues. My first approach was to try to pass an object graph (a la order with line items). Turned out, Axis does not know how to serialize objects in case of “document literal“ service; serialization only works for “soap encoded“. I can understand that-since this is custom XML, rules for serialization are not defined. Although it could‘ve generated some default names based on reflection (I wish we could use annotations for that, but that would have to wait until JAXB 2.0).

Then I tried passing XML as a string (still with “document literal“ in wsdl). Axis had some problems recognizing the name of the operation (basically, the name of the parameter had to match the name of the operation) and then it escaped the XML string (using entities such as “& lt;“). This was not acceptable-I could not count on all clients uniformly escaping their XML before calling the service

So I ended up using DOM and special “message“ style web service that Axis supports-in this case the signature of the service would be “public Document process( Document message )”. This works fine, although I still had to mess with SOAPElement on the client and I could not pass the XML string directly. I actually ended up writing a simple utility class to convert XML string to SOAPElement. Unfortunately, this approach is not portable-WebSphere, for instance, does not support it. So much for JAX-RPC spec support.

This article explains how it should work by the spec but it is obvious that support for at least this part of the spec varies among different implementations.

Morale of the story? “document literal“ web service style is touted everywhere as the “right” way to implement the service but its support leaves a lot to be desired.