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.