The service oriented architecture (http://en.wikipedia.org/wiki/Service-oriented_architecture) is a proper architecture for enterprise messaging systems (http://en.wikipedia.org/wiki/Enterprise_Messaging_System). It's primary focus is the handling of "long running transactions", like B2B communication. When you look at this powerpoint presentation of Pat Helland (http://www.pathelland.com/) you can see how messages are treated in a SOA architecture: http://www.pathelland.com/presentations/2004/powerpoint/040317-EastCoastRAF-Helland-ThoughtsOnData-04b.ppt .
It's about:
- versioning messages
- trust levels
- data description / service contracts
The goals for tiering your monolythic application are not necessarily the same as the ones for implementing SOA, since the first one tries to:
- improve code reuse by componentizing the application
- therefor improve the # of types of consumers that can use the business logic (web environment, B2B-communication, traditional rich GUI client, mobile devices)
A tiered and loosely coupled application architecture does not necessary require an AppServer to run the middle tier logic. You can imagine a web server deployment schema that runs everything from one box (which imposes a security thread).
The B2B-communication requires network access and is simply another communication protocol on top of your business logic. But we tend to mix the two topics when we talk about "creating a future proof architecture" for the next development cycle. I think this is one of the reasons why adopting a new architecture is hard: we want to create a single service that can handle everything under the name of "single point of definition". Any thoughts on this?
Theo.
The B2B-communication requires network access and is
simply another communication protocol on top of your
business logic. But we tend to mix the two topics
when we talk about "creating a future proof
architecture" for the next development cycle. I think
this is one of the reasons why adopting a new
architecture is hard: we want to create a single
service that can handle everything under the name of
"single point of definition". Any thoughts on this?
All good points. But even if I agree that SOA doesn't equate to N-Tier, I view them as merely different perspectives/approaches to distributed computing.
I view N-Tier as an approach to partitioning and distributing an application in correlation to technology: different and disparate platforms/technologies respectively for presentation layers, business logic layers, data layers, service layers, etc. For N-Tier, the issues seems more centered around a "technical" architecture.
In a similar yet distinctly different fashion, SOA is an approach to partitioning and distributing an "application" more in correlation to the business processing: order entry communicates with financials @HQ and inventory @WH, inventory @WH communicates with financials @HQ and shipping @Fleet, financials communicate with CRM @branch office, etc. For SOA, it seems more relevant to talk in terms of a "business" architecture.
And there is of course an intersection where these two perspectives meet.
Just my 2 cents.
I think the service oriented architecture "extends" the N-tier architecture by introducing a new "service integration" layer to provide a common point of integration by the concept of encapsulating business logic within services. Also I don't think SOA necessarily means enterprise SOA / EAI.
While you are right that the driving forces behind SOA and the driving forces behind N-tier come from somewhat different stimuli, what has happened in modern application architectures is that they have converged into an overall architectural concept, as personified by OERA.
10+ years ago when I was working with Forté, whose reason for being was distributed architectures, the ultimate N-tier, one of the really strong architectural messages was designing components as services. No one had coined SOA as a term yet, but the idea that a distributed N-tier application needed to be defined in terms of services was still a very strong, clear message.
The ESB flavor of SOA has gotten strong interest in recent years because of its capabilities for integrating multiple applications (EAI) due to the need to add web interfaces interacting with multiple applications, the need to integrate multiple applications within an organization, and the need for supply chain integration, among other similar factors. Because these are different applications in different technologies and distributed widely, the service orientation is crucial to the integration approach.
But, at the bottom, these different forces are pointing to the same architecture and the principles of SOA and even ESB are applicable within a single integrated application suite just as much as they are in an EAI project. See my discussion of this here http://www.cintegrity.com/PDF/ESBAsAnApplicationArchitecture.pdf
Yes, the overlap isn't 100%. Externalizing business processes into a workflow engine is more of an aspect of SOA/ESB than it is of N-tier. Designing UI to use MVC is more an aspect of N-tier than SOA/ESB. But, the real point is that these are just components of an overall architectural model, not something that competes.
I think there is also the distinction between SOA and SOBA. To my mind SOA is the overall architecture design and the plumbing, and you design and architect an SOBA using SOA principles. So within an SOA you can have participating applications that are a mixture of architectural designs, each application does not have to be N-Tier or OERA, one could equally be a host based application with a single web service.
In the same way SOA != OERA, nor to does SOA = Web Services.
In an ideal world you would have many SOBA designed and architected along the principles of the OERA, that then participate within an SOA.