Naturally an article like this is exposed to leaving out the end of the spectrum that each one of us is particularly interested in seeing elaborated upon, but I was surprised to see that he touched on "Business Processes" so much w/o representing an architectural component resonsible for orchestrating business processes which can often stretch across multiple Business Service calls... typically over the course of being driven by various user actions in the front end... but should also be just as usable from a business process driven in a headless batch oriented manner as well.

This is a nice article that clearly explains the need for a service abstraction layer for building robust applications in a SOA-enabled environment. Clearly, as the author points out, SOA is a generic concept that goes well beyond Web Services and extends to include EJBs, other XML-based communications, JMS, Database Access, Java Bean Objects, and so on. Essentially, the best practice to accessing the service boils down to defining a unified service interface that is instantiated and executed by the client in the same fashion regardless of the underlying source of the business service.

As you design your service interfaces, it becomes important to pay attention to the level of abstraction, especially for business services. It is preferred to always use a coarse-grained service interface definitions with service operations that map to important business functionality. For data services and Java Objects, this may vary slightly depending on the nature of your service.

Another crucial aspect for getting your SOA implementation right is to consider having a vitualized and centralized service registry that serves as a single source for storing metadata about the services being used. This registry typically contains information about the service itself along with other details such as service location, operations and arguments, any data transformation requirements, and so on.

In summary, a service abstraction layer is definitely a key for a successful and scalable SOA implementation.

this is a good article about SOA and it is laudable. It serves as a good introduction to the specifics of SOA from a Java perspective. But with no mention of Jini, maybe it is still an incomplete article. However, the articulation of web services'' place is really good. is jsr 227 completed?

Hm. I see no reason why a SOI can't be implemented with POJO's instead of maps. Any service also provides a jar with POJO''s for a client to use in order to access the service. This allows for a more "natural" way of Java coding and one doesn''t have to typecast, etc.

Hmmmm... an article (albeit short) on SOA and Java and no mention of Jini? You do a disservice to your readers.

Bill