Service Oriented Architecture

SOA

SOA

SOA has been the New New Thing for the last few years in enterprise software

As with everything that gains visibility in IT, separating hype from reality quickly becomes a chore

SOA is being promoted by several enterprise software consulting groups: IBM, Sun, SAP, Oracle, Microsoft

Always keep an eye on your wallet when this happens. It doesn’t always wind up badly, but there is substantial early adopter risk as new technology and standards sort themselves out

SOA

SOA is (ostensibly) a software architecture or design approach that may have many implementations

The most typical implementation of the design approach uses web services, to the extent that the term “SOA” is nearly synonymous with “uses web services”

SOA Objectives

The SOA approach emphasizes• Business processes exposed as

interoperable services• Loosely coupled• Services interoperate by passing data• Services can be combined into larger

business processes• Services can (in principle) be combined

across business boundaries

Example

You want to book a trip. You go to an airline web site and select a flight

Behind the scenes the airline web site may present you with options for booking a hotel room, rental car, and restaurant reservations

This automated process may be done on your behalf by the airline web site

The various business processes at the car rental and hotel enterprises are exposed to at least trusted partners and can be combined into a larger business process

SOA

In many ways the SOA approach is architecturally obvious and breaks no new software engineering ground.

The real value lies in the agreement among sites to use interoperable standards. The SOA design is obvious; an interoperable standard is where the value proposition lies

SOA & Web Services

Web services are an obvious way to implement the SOA idea. In concept they expose services, and the use of XML gives a good foundation or start to being interoperable

Use of SOAP is also helpful, as are standards like WSDL, UDDI, etc

But we need a software framework layered on top of web services to be really useful. We can use WSDL and UDDI to describe individual web services, but we also need a framework to coordinate combining them and working together

SOA Frameworks

A framework should supply• Security• Reliable messaging and message routing• Coordination of services• Transaction support• Policy support• Metadata support that describes the services

and dataIdeally the services should use the same

framework so everyone can be interoperable

SOA

The dream is to have enough metadata to combine services on the fly across business boundaries

The reality is that few business would expose their services to non-trusted partners that have not been vetted in advance

In practice today most web services combined are in the same business domain or with trusted partners

Primitive SOA

You can think of mashups as a sort of primitive type of SOA

Realtor.com web site

MS Virtual Earth mapping,realtor.com listing data,presented on web page

Mashups

Mashups are usually visually oriented; they’re intended to be looked at by a user

SOA may simply be a business process with no view or visual representation

There may be multiple mashup inclusions on a single page

Few standards; Google Maps API not necessarily similar to the Microsoft Maps API, which makes it difficult to generalize

WS-*

WS-* is a catch-all term for a series of WS-SOA frameworks, including security, transactions, etc. Also called BPEL, Business Process Execution Language

Generally speaking the effort is led by Microsoft and IBM, though there are many participants. Standards group is www.oasis-open.org (not W3C), an industry-driven standards group

http://msdn.microsoft.com/en-us/library/ms951274.aspx

WS-*

In general, WS-* relies on SOAP, WSDL, etc as the underlying infrastructure. (Even then it may use something like SMTP as a transport mechanism, but this is somewhat unusual)

You can think of WS-*/BPEL as a uniform, standardized framework for combining web services to perform a task

It’s useful to the extent that it is popular

Orchestration vs. Choreography

There are two basic approaches to composing web services:

• Orchestration: a single process controls the order in which operations/services are performed

• Choreography: Execution of the overall task is a collaborative process in which each web service may participate

BPEL uses the orchestration approach

BPEL Language

BPEL uses an XML dialect to define the business process being conducted

• Invoke: call a web service• assign: data variables• Sequence: invoke services in a sequence,

waiting for each step to finish• Flow: a set of activities invoked in parallel• While: loops• Switch, Pick for branching

BPEL<receive partnerLink=“client” portType=“com:partsSupplier operation=“partsSupplier” variable=“partRequest” createInstance=“yes”/><flow><invoke partnerLink=“providerA” … inputVariable=“partRequest” outputVariable=“providerAResponse”/><invoke partnerLink=“providerB”…inputVariable=“partRequest” ouputVariable=“providerBResponse”/></flow>

BPEL

Note that it’s possible for services to take hours to complete; request sent over SMTP, and requires human approval

Often a dedicated BPEL server will preserve state information while this is executing

BPEL can be implemented in .NET as wellMicrosoft biztalk serverOracle BPEL Process ManagerOpen source applications that run in Tomcat

(activevos.com)

Netbeans

Netbeans has a BPEL module