Constructing Software For Service Oriented Architecture
Jean-Jacques Dubray, Ph.D.
Architect
jdubray@gmail.com
Lecture, 03/26/2004 The Pennsylvania State University The Smeal College of Business Administration
There is a newer version of this presentation available here
http://www.ebpml.org/com/an_introduction_to_SOA.htm
attachmate 2004
Copyright Notice
According to US and Worldwide Copyright laws, it
is forbidden to use all or part of this presentation without a written consent of Attachmate In particular, you are not allowed To remove attachmate logos or the authors name Change the title of the presentation Publish part or all of the presentation under your name or the name of another organization
attachmate 2004
Acknowledgments
This presentation was reviewed and
commented by
Jeff Schneider, CEO of OpenStorm Eric Newcomer, CTO of Iona Paul Brown, CEO of Fivesight Ben Gaucherin, CTO of Sapient
I greatly appreciate their feedback
attachmate 2004
Outline
Service Oriented Society The connected world From Component Orientation to Service
Orientation The Road to SOA
Three key concepts in software construction
Conclusion
attachmate 2004
The Service Oriented Society
Imagine if we had to do everything we need to get done by ourselves?
From Craftsmen to Service Providers
Our society has become what it is today through the
forces of
Specialization Standardization Scalability
It is now almost exclusively service oriented Transportation Telecommunication Retail Healthcare Financial services
attachmate 2004
Attributes of physical services
Well defined, easy-to-use, somewhat standardized interface Self-contained with no visible dependencies to other services (almost) Always available but idle until requests come Provision-able Easily accessible and usable readily, no integration required Coarse grain Independent of consumer context,
but a service can have a context
New services can be offered by combining existing services Quantifiable quality of service
Do not compete on What but How Performance/Quality Cost
attachmate 2004
Context, Composition and State
Services are most often designed to ignore the
context in which they are used It does not mean that services are stateless they are rather context independent ! This is precisely my / the definition of loosely coupled
Services can be reused in contexts not known at design time
Value can be created by combining, i.e. composing
services Book a trip versus book a flight, car, hotel,
attachmate 2004
Service Interfaces
Non proprietary All service providers offer somewhat the same interface Highly Polymorphic Intent is enough Implementation can be changed in ways that do not
break all the service consumers
Real world services interact with thousands of consumers Service providers cannot afford to break the context of their consumers
attachmate 2004
Intents and Offers
Service consumer expresses intent Service providers define offers Sometimes a mediator will:
Find the best offer matching an intent Advertise an offer in different ways such that it matches different intent
Request / Response is just a very particular
case of an Intent / Offer protocol
attachmate 2004
Service Orientation and Directories
Our society could not be service oriented
without the Yellow Pages Directories and addressing mechanisms are at the center of our service oriented society Imagine
Being able to reach a service just by using longitude and latitude coordinates as an addressing mechanism? Only being able to use a service if you can remember its location, phone or fax number?
attachmate 2004
Service Orientation is scalable
Consumers can consume and combine a lot
of services since they dont have to know or learn how to use a service Service providers can offer their services to a lot more consumers because by optimizing
The user interface Access (Geographical, Financial, ) They were able to provide the best quality of service and optimize their implementations
attachmate 2004
So
Service orientation allows us
Complete freedom to create contexts in which services are uses and combined Express intent rather than specific requests
Our society should be a great source of
inspiration to design modern enterprise systems and architectures or understand what kind of services these systems will consume or provide
attachmate 2004
The connected (new) world
Over the past 15 years, everything got connected to everything else
Connectivity Drives the Emergence and Convergence of Technologies
Internet 1980 LAN Web 1990 XML WS 2000 SOA 2010
Office Workflow EAI BPM B2B EDI WS Mainframe
Client / Server
attachmate 2004 Web/Portal
Business Integration
J2EE .NET
Connectivity Enables Global Processes and Information Access
Internet 1980 LAN LAN Web 1990 WAN XML WS 2000 Web SOA
2010
Information Local Business Processes Global
attachmate 2004
Seamless Connectivity enables On Demand Computing
Use software as you need Much lower setup time, forget about Installation Implementation Training Maintenance Scalable and effective usage of resources Provision Billed on true usage Parallelism (CPU, Storage, Bandwidth)
attachmate 2004
But Seamless Connectivity is also questioning all our beliefs
An application is NOT a single system running on a
single device and bounded by a single organization Continuum Object Document Messages and Services As opposed distributed objects Exchanges becomes peer-to-peer Asynchronous communications Concurrency becomes the norm while our languages and infrastructures did not plan for it
attachmate 2004
we are reaching the point of maximum confusion
Federation and Collaboration
As opposed to Integration Language(s) Semantic (not syntactic) Declarative and Model driven (not procedural)
Licensing and Deployment models
attachmate 2004
So
Today, the value is not defined as much by
functionality anymore but by connectivity
However, we need a new programming model We are reaching a new threshold of connectivity and computing power
Why SOA today?
Mainframe
Client Server
Web
SOA
attachmate 2004
Constructing Software In a Connected World
From Components to Services
Constructing software in the web era (J2EE, .Net, )
View
request response
Client Interne t b2b EAI
CCI
ERP
Controller
App Server
CCI CCI
Model
DB
ERP CRM
CCI: Client Communication Interface
attachmate 2004
Why do we Want to Move to a New Application Model Today?
We are moving away precisely because of
connectivity
J2EE, for instance was designed to build 24x7 scalable web-based applications Job well done
But this is very different from, I now want my
application to execute business logic in many other systems, often dynamically bound to me
JCA (J2EE Connector Architecture) is not enough EAI infrastructures are not enough
attachmate 2004
A Component now Becomes a Service Running Outside the Consumer Boundaries
Consumer 3 XML XML invoke Policies XML Registry Discover and/or Bind 2
SOAP
CCI
SOAP
CCI
SOAP
CCI
1 register
DB
ERP
CRM
Service
Service
Service
attachmate 2004
From Components to (Web) Services
Requires a client library Loose coupling via Message exchanges Policies Peer-to-peer Composable Context independent Some overhead Medium to coarse
Client / Server Extendable Stateless Fast Small to medium
granularity
granularity
attachmate 2004
Web Services: what is changing?
Loose coupling (of course)
Web Services dont require a CCI (Client side Communication Interface) Very few gears needed to consume a service Web Services can accept message content they do not fully understand or support XML, WSDL Web services are very late bound Location is independent of the invocation mechanism Directories
attachmate 2004
Web Services: What is Changing?
Peer-to-peer interactions are possible
Request / response is an inefficient and very limiting mode of interaction As components coarsen, it is difficult to differentiate a client from a server
attachmate 2004
What Happens to the Technical Services Typically Provided by an Application Server?
Transaction Security Connection pooling Naming service Scalability and failover They become the Service Fabric
attachmate 2004
What about the notion of Container? They become Service Domains
The notion of container shifts to the notion of
Domain Controller
A domain is a collection of web services which share some commonalities like a secure domain A container is a domain with one web service Web Services do not always need a container
Consumers invoke the domain rather than the service
directly This concept does not exist in any specification
attachmate 2004
A Service Fabric can be more than a Bus with a series of Containers / Adapters
Consumer Discover and/or Bind Policies
Tx XML
Domain Controller
Reliable Messaging
XML
XML
Process
Registry
Registry
CCI
CCI
CCI
register
DB
ERP
CRM
NEP
NEP
NEP
attachmate 2004
The road to SOA
NEP NEP Existing business logic, often model-oriented Global business logic (tax, trade, ) and data access Coordination logic (Tx, Process, ) Metadata driven User Interface NEPs NEP NEP
attachmate 2004
NEP
NEP
NEP
NEP
Shift To A Service-Oriented Architecture
From
Function oriented Build to last Prolonged development cycles
To
Coordination oriented Build to change Incrementally built and deployed
Application silos Tightly coupled Object oriented Known implementation
Enterprise solutions Loosely coupled Message oriented Abstraction
attachmate 2004
Source: Microsoft (Modified)
So Migrating to SOA
Would entail
Organizing the business logic in a context independent way
Typically, model oriented business logic is wrapped behind (web) services
Re-implementing the controller with
coordination technologies The view must be completely re-invented
attachmate 2004
From this point on
We will focus on 3 key aspects of the
controller
The coordination layer Information Entities The relationship between BPM and SOA
attachmate 2004
The Coordination Layer
Many, many, many overlapping concepts not
layered, not architected
Composition Orchestration Choreography Collaboration
What is the relationship between these
concepts?
attachmate 2004
Coordination Specification
OASIS/WS-CAF
Context management Coordination Transaction management
As one possible, yet very important example of coordination
attachmate 2004
What is Context?
S4 S1 CTX Service S2 S3
Peer to peer interactions mandate a context service (e.g. in this case S3 may need to know the state of interaction between S1 and S4 to provide its service)
attachmate 2004
What is an activity Lifecycle Service?
S4 S1 CTX Service S2 S3
ALS allow to demarcate units of work shared across several services
ALS Service
attachmate 2004
What is Coordination?
S4 S1 CTX Service S2 S3
A coordinator is an active component of the architecture It can support a service or provide services itself Multiple purposes: - Transaction - Orchestration - Choreography
ALS Service
Coordination Service attachmate 2004
What are the Coordination Topologies?
A B Binary relationship Context and Activity are most often implicit Self-coordination
A B C CTX A B C Coordinator ALS Hub
D E F
Hub and Spoke relationship Context and Activity are handled by the hub Coordination is handled by the hub exclusively
D E F
Multi party peer-to-peer relationship Context and Activity are explicit Context, ALS and Coordination are handled by the fabric
attachmate 2004
Coordination is a key abstraction
Rely on generic fabric services for types of
coordination
Not everything is a process
Different types of coordination can be
composed
A transaction may include an orchestration definition as part of an activity An orchestration definition may contain several transactions
attachmate 2004
Information Entity in SOA
at the heart of Web services is a very
complex problem: with distributed applications comes the need for distributed data sharing
Identification and equivalence authentication Authorization and privacy mediation synchronization
attachmate 2004
Source: The Dataweb: An Introduction to XDI, Drummond Reed et al.
Information Entities in SOA
Several dimensions appear when managing
an Information Aggregate in a SOA
Identity Content Information Entity State Location(s) Replication Privacy
attachmate 2004
Specific to SOA
Key problems to solve
Isolation
We cannot be guaranteed that the information we have is the information held by the system of record
Containment
We cannot be guaranteed that a service consumer is going to apply the same privacy rules to the information provided to it
attachmate 2004
Web standards vs. Dataweb standards
Web
100% resource addressability Common representation and linking format Common interchange protocol
Source: Drummond Reed
attachmate 2004
Dataweb
XRIs
URIs
HTML
XML/XDI XDI/HTTP XDI/SOAP
HTTP
Websites vs. Dataweb sites
HTML HTML XML/ XDI XML/ XDI
XDI Link contracts
HTML HTML HTML HTML XML/ XDI XML/ XDI XML/ XDI XML/ XDI
HTML
HTML
HTML
HTML
XML/ XDI
XML/ XDI
XML/ XDI
XML/ XDI
Website A Source: Drummond Reed
Website B
Dataweb site A
attachmate 2004
Dataweb site B
Information Elements and Aggregate Represent a Big Challenge in SOA
We have barely scratched the surface Thinking that we can get away by saying that
we are simply exchanging messages between services is IMHO a mistake SOA will not exist without its concept of information entity
Entity beans were clearly not a good solution .NET offers the concept of DataSet which I like better
attachmate 2004
SOA and BPM
SOA is about constructing software
components that can be reused in context unknown at design time
Composition versus Extension (OO)
BPM is about being able to precisely model
and possibly change the context in which enterprise components are used
But how the two meet?
attachmate 2004
Elements of BPM
Initiates Activity changes Event
State Entity performs Actor Services Represented by Content generates
attachmate 2004
How is BPM perceived today in the SOA community?
Two approaches Event Oriented BPML, BPEL Pi-Calculus (Also Event Calculus) Activity Oriented WfMC Petri nets IMHO, the approaches must be combined and state
must be part of the model Turing complete is the excuse for remaining pure (e.g. event oriented only)
attachmate 2004
Source: Paul Brown, FiveSight,
BPEL
BPEL is an XML language for defining the composition of (web)
services into (new) services (Paul Brown, FiveSight)
BPEL is above all a simple Orchestration language not a
Business Process Language BPEL would require that every process Either has a center of execution A process is composed of a large set of orchestration definitions interacting with each other
In pi-calculus, even a variable is a process
BPEL assumes that business processes can be fully captured in
a single definition, including all possible exception paths Not sure this is the right assumption
attachmate 2004
A business process does not have a centerit is de facto peer-to-peer
Sync ItemMaster Sync ProductionOrder Sync Routing Sync BillOfMaterial Manufacturing Capacity Analysis
Sync ItemMaster Sync ProductionOrder Confirm InventoryIssue Sync Routing Sync BillOfMaterial Sync Prodorder Sync Routing Sync BOM Sync Item Confirm InventoryIssue Update WIPConfirm ERP Update WIPConfirm
Manufacturing/ Production Planning
Sync DispatchList
OAGIS 8.1 Scenario 50
Get DispatchList Show DispatchList attachmate 2004
Manufacturing Execution (MES)
A very simple example
A buyer orders some goods from a supplier The supplier performs a series of steps to
fulfill the order
Approve the order Update the order entry system Update the billing system
attachmate 2004
Orchestration languages are a critical piece of the puzzle
They allow us to implement complex services
which involve:
Long running (from a few hours to a few months), And event driven business logic
They are not about modeling Business
Processes by themselves
Different orchestration (i.e. different services) can run within the same business process And vice versa
attachmate 2004
A Business Process can be Viewed as a Multi-Party Choreography (not orchestration) of Peer Services
Start
Buyer
RFQ
Supplier
Mapping Routing
SFA
RFQ Order
Quote
Sales person
RFQ Events
Account User Activity
ERP
Accounts
Order
Order Information Entity Invoice
Orders
Sales Order Billing Activity
Invoice
attachmate 2004 SalesTax.com
CreditCheck.com
Services in a SOA are orchestrated (BPEL) ! This is one of the best model to re-use existing business logic
Quote Service Orchestration Definition RFQ
<<receive>> RFQ
<<invoke>> GetQuote
Entity
No
RFQ Quote
Nack
sendNack
Entity State Ok?
<<invoke>> calculateSalesTax
Sales Tax
Quote Order
updateDB
<<send>> quote Transition
No
Ok?
Message flow
attachmate 2004
A Choreography Provides a Model of the Event Flow Between Activities
Start
Buyer
PO AckPO
Supplier
(Self)
PO PO
Order Entry
Manager
Billing
BTA1
Wit1
PO AckPO
Sales order
OpA1
OpA2
[BusinessFailure]
[Success]
Failure
attachmate 2004
Success
So
Orchestration is an emerging [concept] that would give programmers a way to formally describe processes underlying business applications so that they can be exposed and linked to processes in other applications Choreography Is a concept that specifies how these processes are linked together across the enterprise Choreography can be active when mapping and routing are necessary They are both a form of Coordination
attachmate 2004
Bringing BPM and SOA together
The foundation is becoming sound with strong
theoretical support
A big piece still missing: state (IMHO) Shift from Orchestration to Business Process Definition
Once the foundation is in place we should see
Domain Specific Languages (DSL) appear that are a lot closer to the way the users (not the programmers) think about a Business Process
attachmate 2004
A Technical Model for Constructing Software in SOA
We need to adapt the foundation of modern
application architecture
Model-View-Controller
Model Controller View
Services Coordination ?
attachmate 2004
The Model-View-Controller pattern Revisited
SelectView View Task Request
Controller
Query Model Changed UI Controller Task Engine Service Request
WS
SelectTask
WS WS
ChangeState Model Changed
Business Process Controller
Model
WS
attachmate 2004
SOA requires a Complete Separation of the Business Logic and UI
View
UI Controller Query Engine Task Engine Service Request
WS WS
Business Process Controller
WS
ERP
WS
PLM
WS
CRM
WS
attachmate 2004
WS
It is likely that BPM will be the main paradigm for the Controller in a SOA
View Business Process Execution
WS
Task Engine Context Registry ALS
Integration Server
(Decoupling for B2B and EAI)
WS
WS
Orchestration Engine
Orchestration Engine
ERP
PLM
WS
CRM
WS
Orchestration Engine
attachmate 2004
WS
WS
Conclusion
The Future Belongs to Whom Can Master Connectivity
Service Orientation is a New Computing Paradigm
Not as a new name for API Component A genuine set of concepts with which we can
construct new kinds of software
This is as significant if not more than Object Orientation
In particular SO forces us to think about enabling the
same piece of code to be leveraged
by large numbers of consumers in unforeseen context
attachmate 2004
SOA is still far ahead of us
We still need to shape what SOA means I have emphasized 3 concepts but there are a lot more and a lot more not even uncovered today BPM and SOA will complement each other We need lots of work to achieve and deliver the SOA
value and go beyond toy applications of SOA
At best we are capable of delivering web services today
Standards work is both a curse and a blessing They open the road but blur the space and bring confusion because of the lack of coordination
attachmate 2004
We can expect
A new gold rush to own and publish application
services
Mainframe and Client Server applications (ERP, CRM, SCM) will be impacted dramatically
Far richer and smarter software Could also become a nightmare if we look at all the security breaches that occur today However, some key enabling technologies are still
missing
Standards convergence is now of primary importance
attachmate 2004
