LAS VEGAS -- In a presentation at TheServerSide Java Symposium last week, Gregor Hohpe, enterprise integration practice leader at Chicago-based ThoughtWorks Inc. and co-author of the book Enterprise Integration Patterns, played down some of the hype around service-oriented architecture (SOA) and offered some practical advice to developers and architects.
According to Hohpe, SOA lacks a consistent definition throughout the development community.
Hohpe suggested some "alternative" meanings for SOA such as: same old architecture, some other architecture, SOAP without the P and stupid over-hyped acronym. His point was that the term SOA is overused and advised the audience to not look for one proper formula.
Hohpe advised the audience to forget about SOAP and design patterns. The characteristics of a service are that it is well-defined and self-contained, independent of consumer context and accessible without individual deployment.
The main characteristic of an SOA is that of a loosely coupled, document-oriented interaction model, according to Hohpe. He didn't think that SOA is a new, life-changing architecture because XML messaging-based services have been around for a while.
"Popular architectural styles are often a product of the weaknesses of their predecessors," Hohpe said, as he reviewed a progression of architectural styles over the last 20 years.
He described how distributed component architectures provide a layer of transparency, allowing developers to access remote resources via object orientation. However, Hohpe said there are problems with that architecture, including things like the network, lack of shared memory, partial failures and system coupling.
The SOA architecture is a different approach to distributed services, Hohpe said. It provides simple messaging-based interactions. Messages are more self-contained, lack object-oriented complexities and better accommodate asynchronous communications.
"Today's system is tomorrow's legacy," Hohpe said, as he reminded the audience that each strategy has its strengths and shortcomings.
Hohpe provided some sound advice for project managers choosing an SOA architecture.
Architecture is based on patterns and intent, not technology selection, according to Hohpe. Conversation models, asynchrony, document-orientation, granularity, decoupling and management are more important.
He described how composability of services can be well accomplished via dependency injection; however, this requires that configuration be treated as a first-class construct.
Configuration is still code and must be tested, Hohpe said. Bugs in production deployments are frequently the result of differences between test and production configurations.
Hohpe concluded that SOA brings changes in architectural style, programming models, best practices, patterns, testing and management approaches and that the collective learning cycle will take some time.