Constructing Software For Service Oriented Architecture Jean-Jacques Dubray, Ph.D.

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 author’s 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 don’t 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
LAN
Web
1980
XML
WS
2000
1990
SOA
2010
Office
Workflow
EAI
BPM
B2B
Business
Integration
EDI
WS
Mainframe
Client / Server
Web/Portal
© attachmate 2004
J2EE
.NET
?
Connectivity Enables Global Processes
and Information Access
Internet
LAN
1980
Web
XML
1990
LAN
WAN
WS
2000
SOA
Web
Information
Global
Local
Business
Processes
© attachmate 2004
2010
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
 Why SOA today?

We are reaching a new threshold of
connectivity and computing power
Mainframe
Client Server
Web
© attachmate 2004
SOA
Constructing Software In a
Connected World
From Components to Services
Constructing software in the web era
(J2EE, .Net, …)
View
Client
Interne
t
b2b
request
response
Controller
App Server
EAI
CCI
CCI
CCI
DB
ERP
CRM
Model
CCI: Client Communication Interface
© attachmate 2004
ERP
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
Discover and/or Bind
Consumer
2
3
invoke
Policies
XML
XML
SOAP
SOAP
1
SOAP
CCI
CCI
CCI
DB
ERP
CRM
Service
Service
Registry
XML
Service
© attachmate 2004
register
From Components to (Web) Services
 Requires a client library
 Loose coupling via
 Message exchanges
 Policies
 Client / Server
 Peer-to-peer
 Extendable
 Composable
 Stateless
 Context independent
 Fast
 Some overhead
 Small to medium
 Medium to coarse
granularity
granularity
© 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
Discover and/or Bind
Consumer
Policies
Reliable
Messaging
TxXML
XML
Domain
Controller
XML
Registry
Registry
Process
CCI
CCI
CCI
DB
ERP
CRM
NEP
NEP
NEP
© attachmate 2004
register
The road to SOA…
NEP
Existing business logic,
often “model-oriented”
NEP
NEP
NEP
NEP
NEP
“Global” business logic
(tax, trade, …) and data
access
Coordination logic (Tx,
Process, …)
Metadata driven
User Interface NEPs
NEP
NEP
© attachmate 2004
Shift To A Service-Oriented Architecture
From

To
Function oriented
 Build to last
 Prolonged development
cycles

Application silos
 Tightly coupled
 Object oriented
 Known implementation
Source: Microsoft (Modified)

Coordination oriented
 Build to change
 Incrementally built and
deployed

Enterprise solutions
 Loosely coupled
 Message oriented
 Abstraction
© attachmate 2004
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
S3
CTX
Service
S2
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?
ALS allow to demarcate
units of work shared
across several services
S4
S1
S3
CTX
Service
S2
ALS
Service
© attachmate 2004
What is Coordination?
A coordinator is an active
component
of the architecture
S4
S1
S3
CTX
Service
S2
ALS
Service
It can support a service or
provide services itself
Multiple purposes:
- Transaction
- Orchestration
- Choreography …
Coordination
Service © attachmate 2004
What are the Coordination Topologies?
A
B
A
B
Binary relationship
• Context and Activity are most often implicit
• Self-coordination
D
Hub
C
E
F
CTX
ALS
A
D
B
E
C
Hub and Spoke relationship
• Context and Activity are handled by the hub
• Coordination is handled by the hub exclusively
Coordinator
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
Source: The Dataweb: An Introduction to XDI, Drummond Reed et al.
© attachmate 2004
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
Dataweb
100% resource
addressability
URIs
XRIs
Common representation
and linking format
HTML
XML/XDI
Common interchange
protocol
HTTP
XDI/HTTP
XDI/SOAP
Source: Drummond Reed
© attachmate 2004
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
Content
Actor
Services
Represented by
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
“center”…it is de facto “peer-to-peer”
Sync ItemMaster
Sync ProductionOrder
Manufacturing
Capacity Analysis
Sync Routing
Sync BillOfMaterial
Sync ItemMaster
Sync ProductionOrder
ERP
Show DispatchList © attachmate 2004
Sync Item
Get DispatchList
Sync Prodorder
OAGIS 8.1
Scenario 50
Sync Routing
Sync DispatchList
Sync BOM
Update WIPConfirm
Confirm InventoryIssue
Manufacturing/
Production
Planning
Manufacturing
Execution (MES)
Update WIPConfirm
Sync BillOfMaterial
Confirm InventoryIssue
Sync Routing
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
Supplier
RFQ
Mapping
Routing
Sales
person
SFA
RFQ
Quote
RFQ
Events
Order
Order
ERP
Account
User
Activity
Accounts
Order
Information
Entity
Invoice
Orders
Sales
Order
Invoice
Billing
Activity
© 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
Entity
<<invoke>>
GetQuote
Entity
State
Ok?
Quote
No
Nack
sendNack
<<invoke>>
calculateSalesTax
Quote
updateDB
RFQ
Sales
Tax
<<send>>
quote
Transition
Order
No
Ok?
© attachmate 2004
Message flow
A Choreography Provides a Model of
the Event Flow Between Activities
Start
Buyer
Supplier
Order Entry
Manager
Billing
(Self)
PO
AckPO
PO
PO
BTA1
Wit1
PO
AckPO
Sales
order
OpA1
OpA2
[BusinessFailure]
Failure
© attachmate 2004
[Success]
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
 Services
 Controller  Coordination
 View
?
 Model
© attachmate 2004
The Model-View-Controller pattern
Revisited
SelectView
View
Task
Request
Controller
Task
Engine
WS
Service
Request
Model
WS
SelectTask
ChangeState
Model Changed
© attachmate 2004
WS
Model
Changed
WS
Query
UI Controller
Business
Process
Controller
SOA requires a Complete Separation
of the Business Logic and UI
View
Task
Engine
WS
Business
Process
Controller
© attachmate 2004
WS
CRM
WS
PLM
WS
ERP
Service
Request
WS
WS
Query
Engine
WS
UI
Controller
It is likely that BPM will be the main
paradigm for the « Controller » in a SOA
View
Business Process Execution
WS
Task
Engine
Integration
Server
Context
(Decoupling for
B2B and EAI)
ALS
© attachmate 2004
WS
WS
Orchestration
Engine
WS
CRM
WS
Orchestration
Engine
WS
PLM
WS
ERP
Orchestration
Engine
Registry
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