Constructing Software For Service Oriented Architecture

Jean-Jacques Dubray, Ph.D.

Architect
[email protected]

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