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.