Download SOA

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/enus/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