1. Service Oriented Architecture
SOA

2. 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

3. 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”

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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 (not W3C), an industry-driven standards group

13. 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

14. 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

15. 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

16. 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>

17. 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)

18. Netbeans
Netbeans has a BPEL module