SOA vs. Java EE (Part 1)

I'm tracking the SOA movement since several years, but I still do not understand how it is possible NOT to implement a SOA with a clean component architecture. Regardless whether .NET or JEE5, almost every technology provides a notion of a component architecture. In my last J2EE projects we designed business components as Java packages with a defined specification. The specification to the component was realized with the Business Delegate pattern. Actually it was a "plain java", J2EE independent interface (in JEE5 the remote interface of the Session Facade can be used for this purpose), which was implemented by an POJO, which communicates with a remote Session Bean.

The Business Delegate is already an almost platform neutral interface (still Java, but can be also easily expressed with an UML-interface, IDL oder WSDL) which represents a Use Case, which can  be absolutely compared with a business component service. The Business Delegate can be decorated and so exposed with SOAP, XML-RPC or even sockets.This realization fits perfectly to the SOA definition:"A service-oriented architecture can be defined as a way of designing and implementing enterprise applications that deals with the intercommunication of  loosely coupled, coarse grained (business level), reusable artifacts (services). Determining howto invoke these services should be through a platform independent service interface."

The Session Facade, can be compared with a controller or even use case controller. It manages independent, fine grained services (Stateless Session Beans, POJOs or BOTH), which are similar to the Component Services. The Session Facade can be decorated with some aspects like remoting, transactions, security etc. The idea of the Session Facade Pattern can be compared with the a hardwired Composite Service from the SOA world. DAO-Frameworks, OR/Mappers are similar to the Data Services from the SOA world.

I think it is nearly impossible to build JEE architectures without Session Facades and Business Delegates. So it is also impossible to build JEE applications WITHOUT the SOA ideas.

Of course some non-functional requirements like reuse, robustness, high availability require some additional information associated with the service - so called metadata. Also a versioning and management strategy is needed. BUT: this is nothing new for a JEE developer.

The real problems in SOA/JEE world are:

- the realization of reuse between departments
- the semantic (not syntactical) compatibility between sevice parameters (business objects)
- versioning of services: a once deployed service has to remain stable
- distribution, transactions and partial failure
I suppose, that SOA is only interesting for monolythic, spaghetti applications, where it is hard to recognize a business service. For JEE developer, which follows some common principles like JEE patterns or GoF patterns, Separation Of Concerns or even Divide And Conquer, SOA is only an enrichment (especially meta data) BUT really nothing exciting.

Is it possible to implement structured JEE applications WITHOUT SOA? I still do not understand the hype. SOA has real impact to the organization of an enterprise, but almost no impact to the technology or architecture of well-designed applications. 


NEW: Online Workhop Effective WebApps without Frameworks is also coming to: MUC Airport.

Airport MUC workshops: Web (SPA, PWAs, Offline, Desktop, Mobile) Applications Essentials and Effective Web Applications. No migrations. #usetheplatform

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

I work in the Java Brand Marketing Team here at Sun Microsystems. I realize that there is some confusion regarding the renaming of the Java platform last year. So I hope you don't mind if I ask that you re-post your page by replacing "JEE" with "Java EE". Part of the impetus in our renaming is to move away from confusing acronyms. We have some additional information posted at: http://www.java.com/en/about/brand/naming.jsp. There you find FAQs, and 1-page summary of the change. If you have any questions, please do not hesitate to contact me at 415-294-5391, or temi.ojo@sun.com. Thank you for your help and understanding.

Temi Ojo
Java Brand Marketing Team

Posted by Temi Ojo on July 29, 2006 at 04:26 AM CEST #

Well said!

Posted by Arne Berner on October 05, 2006 at 08:34 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License