aspose file tools*
The moose likes Web Services and the fly likes Book Promo: Definition of SOA? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Book Promo: Definition of SOA?" Watch "Book Promo: Definition of SOA?" New topic
Author

Book Promo: Definition of SOA?

Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
What definition of Services Oriented Architecture (SOA) do you use in your book SOA Using Java� Web Services (Sample Chapter: Basic SOA Using REST, amazon US)? Is it closer to IBM�s vision of an architectural style that integrates a business as a group of services that can be dynamically linked on demand (SOA antipatterns) or is it closer to Robert C. Martin�s
SOA is nothing more (and nothing less) than separating changeable elements from unchangeable elements.

(What is SOA, really?)?
[ May 29, 2007: Message edited by: Peer Reynders ]
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
Along with SOA definition, I am very much interested to know how you go about describing various chapters in your book to match your definition. As often times I have seen SOA definition deviating from actual description of the content in one or the other way.

Cheers,

H. Kanthi
Mark D. Hansen
author
Ranch Hand

Joined: May 29, 2007
Posts: 61
Well, I'm not sure that Uncle Bob and IBM are that far apart on this one. If I understand Uncle Bob's post, the services in a SOA are essentially the "unchangeable elements". Whereas the business processes are the "changeable elements" implemented in some business process language like BPEL.

This seems consistent with the IBM vision where the "unchangeable elements", or services, are dynamically aggregated into business processes.

My book does not provide a definition of SOA. I rely on Thomas Erl's Service-Oriented Architecture book to provide my working definition of SOA. Page 40 of his book lists the primary characteristics of what he calls a "Contemporary SOA". The most important characteristics that he lists, from my perspective, are:
* Contemporary SOA is based on open standards.
* Contemporary SOA fosters intrinsic interoperability.
* Contemporary SOA promotes architectural composability.
* Contemporary SOA promotes loose coupling throughout the enterprise.

The way that these characteristics match the material in the book is as follows:

(1) Open standards implies the emphasis in my book on WSDL, SOAP, XML Schema, and the Java Standards (i.e., JAX-WS, JAXB, and JSR-181).
(2) Interoperability and composability imply the emphasis on "Start from WSDL". That is because, if you "Start from Java", the Web services that you generate will not be composable or interoperable.
(3) Loose coupling implies the emphasis on document-oriented Web services.

But, I want to emphasis that my book is first and foremost a book for Java programmers who need real-world advice on how to work with Java Web Services (JWS) to implement SOA. So, I don't get too hung up on the definition of SOA. Rather, I embrace those characteristics listed above and then show how to write code using JWS that supports Erl's definition of SOA.


Mark D. Hansen
Founder and President, AgileIT LLC http://agileitinc.com/
Author of "SOA Using Java Web Services" - http://soabook.com/
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
The characteristics from Thomas Erl's definition of Contemporary SOA seem quite pragmatic from an architectural perspective.

My main concern with IBM's definition is the requirement to support "dynamic aggregation". It is clear that "dynamic aggregation" has to be supported for flexible support of WSBPEL. However the somewhat reluctant adoption of, for example, UDDI repositories by the mainstream makes me wonder which aspects of SOA are truly needed be the majority of IT architectures/infrastructures. All the wonderful flexibility of the grand SOA vision comes at a cost.

I see some disturbing parallels to the evolution of J2EE and EJB in particular. After some time, some EJB experts came to the realization that only "10% of applications need distributed business objects" (Ron Johnson, J2EE Development without EJB) which ultimately lead to the emergence of the rebel platforms (Spring, Nano Container, Pico Container, Hibernate, Ibatis, etc.). Similarly 90% of all organizations may only a require few aspects of SOA (like the ones you outline) to maximize their "value proposition of SOA adoption" while a large part of the grand SOA vision at best fades into obscurity at worst encumbers the truly useful parts hindering widespread adoption (leading to the ultimate failure of SOA).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Book Promo: Definition of SOA?