First, in one short paragraph, give me a clear introduction to service oriented architectures (SOA).
Service Oriented Architectures put a new face on an old idea – the concept of simply dividing up software capabilities across remote machines and calling those remote routines from a single application. It’s an architectural pattern that facilitates reuse across platforms. Software capabilities are published as “services” and called in sequence to accomplish a larger task. A service might be “schedule this order for production”, “see if this inventory item is in stock”, or “cancel reservation at Neverland Ranch”. Often the interface to a service (like what parameters it expects and what it will return when it's done) is described in some kind of neutral format that masks the technologies used for the underlying implementation (although this is certainly not true for all SOAs, it is a central idea behind “web service” SOAs). By segmenting the architecture into bite size pieces, the system is more readily understandable, modular upgrades are possible, and development, debugging, and testing can be parallelized. With SOAs, chains of services can be quickly strung together into larger tasks and easily rearranged, which is exactly what business process modeling software is about.
What this about "web services"?
The term “SOA” is often used as a synonym for Web Services, but Web Service technology is really one of many possible underlying implementations of a SOA. Web Service-based SOAs rely on a number of emerging standards (like WSDL, UDDI, SOAP, etc.) that may be completely absent in other SOAs. Be aware though, unless you’re in a room full of annoying academic ivory tower pin heads , if you start talking about “SOAs”, people are likely to think you’re talking about web services.
How do SOA architectures differ from traditional architectures?
SOAs, which are loosely coupled architectures, tend to separate the service interface definition from the service’s actual implementation, making for even more "loosiness". In other words, traditional multi-tier architectures look something like this:
while SOAs often insert an additional “service” layer and end up looking like this:
So if a service is ultimately implemented in the business layer with, say, Java, developers in the presentation layer don’t have to be able to read a single line of Java in order to talk to the service. They just have to be able to read the interface definition (in the case of Web Service SOAs, this definition is in a "WSDL" file in the supposedly human readable “XML” format.) Since the interface is separated from the implementation, SOA service consumers don’t give a hoot about the service’s underlying implementation. Their only concern is supplying the service with the input information listed in the interface definition and getting the results back. Since the service layer frees consumers from caring about the underlying technologies in the business layer, software reuse is far more likely. The service consumer is free to use the service regardless of whether it is implemented using .NET, J2EE, Java, Cobol, C++, C, PRI , C#, or Fortran.
Is that all there is to SOAs?
Many SOAs augment their service layer with monitoring and administration tools. Transactions can be dynamically inspected and mechanisms for intervention may exist. Some SOAs allow services to be restarted or even upgraded on the fly. Displays may be provided to view the quantity of queued requests, the frequency and volumes of transactions, and peak load information.
SOAs are frequently assumed to possess a number of properties, although strictly speaking there is no formal SOA definition. For example, SOAs are usually thought to provide some sort of dynamic discovery mechanism to find and bind to services on the fly at runtime . Protocol independence is often assumed, so that applications can talk to their services using CORBA, ftp, SMTP, HTTP, or whatever communication standards they like. But SOAP over HTTP is the most common protocol.
What's this I hear about Enterprise Service Buses?
Enterprise Service Buses (ESBs) are frequently talked about in the context of SOAs. ESBs are the layer of software that provides communication between services and their multiple consumers. They are always created as part of a SOA (even if they are not called or thought of as ESBs). ESBs are increasingly thought of as possessing sophisticated traits such as providing open-standards based messaging, performing intelligent routing and data transformation, and relying on web services, but their core function is to simply connect services to multiple consumers. (See our ESB web page for an explanation of why you may have been using an ESB for the past 40 years and not even known it.)
And what's this about "Business Process Modeling"?
Business Process Modeling is another term frequently encountered in the context of SOAs. The rapid chaining and rearranging of a number of corporate services is the central idea behind Business Process Modeling and execution. A service oriented architecture is a natural choice for “BPM”, which is ultimately realized by the coarse grained integration of a company’s various software systems. Business Process “engines” are very frequently implemented with a series of web service calls across an enterprise service bus.
In a business process modeling environment, the multi-tier architecture referred to on the previous page typically gets transformed into an architecture that looks like this:
So rather than having a human sit in front of a presentation layer manually directing work flow by interacting with a number of corporate systems, an automated business process layer is used to pass orders, inventory, customer, and various other objects between software systems running on different computers throughout the company.
What are the common mistakes that companies continually make with SOA?
Industry tends to only cover the benefits of SOA, but what’s really important to know is when to avoid a SOA approach and why. Frequently SOA "experts" are so focused on the SOA domain that they not even familiar with the alternatives to SOA or dismiss them with little consideration. There's no shortage of SOA advocates, but the IT industry is rife with SOA fiascos. There are far more SOA failures than successes. On the other hand, it is possible to use service oriented architectures in an effective and meaningful way. Steer your SOA project clear of the rocks. Keep it from exploding, scattering debris for miles and miles, and killing innocent bystanders. Our book is an easy and quick read but it has some very important advice too. Don't just settle for the excerpt on this page. Click the “Buy Now” button below. You'll learn a lot and have a few chuckles too - I personally guarantee it (except for the "guarantee" part).