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 data Ideally 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 well Microsoft biztalk server Oracle BPEL Process Manager Open source applications that run in Tomcat (activevos.com)

Netbeans Netbeans has a BPEL module