Composite Applications: Value Proposition and Architecture Jean-Jacques Dubray, Ph.D. Attachmate...

Composite Applications:Composite Applications:Value Proposition and Value Proposition and ArchitectureArchitectureJean-Jacques Dubray, Ph.D.Jean-Jacques Dubray, Ph.D.

[email protected]

May 2005May 2005

There is a newer (flash) presentation available here

mailto:[email protected]

http://www.ebpml.org/com/an_introduction_to_SOA.htm

Attachmate Copyright 2005 2

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


Outline

• Evolution of the Software Industry• Composite Application Model• Service Orientation and Composite

Applications• Resources in Composite Applications• Conclusion

Evolution of the Evolution of the Software IndustrySoftware Industry

Problems and opportunitiesProblems and opportunities


1 23 4

56

78

S1S2

S3S4

S5S6

S7S8

0

2

4

6

8

10

12

Attributes

Systems

Business Objects

Business Object Attributes in different systems

The software industry has failed to create normalized information systems

ER

P

1CR

MS

CM

PLM

Por

tal

PR

MH

CM

…

…

Order

Customer

Product

BOM

InvoiceEmployee

Source: David McComb et al, www.SemanticArts.com


Current Application Models (all based on MVC) Couple UI, Processes and Data

CI

CI

CI

CI

Broker

Broker

1 23 4

56

78

S1S2

S3S4

S5S6

S7S8

0

2

4

6

8

10

12

Attributes

Systems

Business Objects



I argue here that the notion of “system of record” must become irrelevant

• UI, Processes and Data span beyond the boundary of any single system

• All systems in operation today require to be connected to many other systems to perform their tasks

• Any new development must face an increasingly complex integration project– And/Or, users must start using more than one

application to perform any given activity


So how do we normalize IT?

• The “Common Database”• Integration

– EAI– EII– ETL

• Standardize on a single vendor “business suite”• Portals• The problem has not gotten simpler

– Mergers/Acquisitions/Outsourcing– Rogue developments– Customer facing Web apps (scalability)


The “denormalization” has forced organization to cross the point of negative ROI

Number ofSystems10 100 1000

Cost

Value

11


We must seek all opportunities bring projects back in the positive ROI area


Cost

Value

11


Moving back to a lower number of systems of records is not really an option


Cost

Value

11


The software industry attempting to improve software construction along multiple dimensions

SoftwareConstructio

n

DistributedComputing

CORBA, J2EE

DCE

WS, ebXML

ApplicationModel Mainframe

Client/Server

Web Apps

SAP, Oracle…

SalesForce.com

Solutions ComputingModel

StructuredProgramming

Object Orientation

Middleware

MQ

EAI, B2B

BPM

RUPXP

MDD

Service Orientation

Methodologies

Portals


groupware

EII

BPM

However, it has often resulted in a lack of long range coherence in IT with punctual or no ROI improvement

Mainframe

Form TitleForm Title

Mainframe

EAI

BrowserPortal

B2Bi

ETL

BAM

WS

Form TitleForm Title

RichClient

Mainframe

Mainframe

Mainframe

Mainframe

MOM

Application Server


Yet, architecturally, the end point of this evolution is relatively well understood

• Federated and Collaborative point of usage– Identity and activities

• Clients May work in disconnected mode• No technical or physical boundaries

– Process and Data federation• Easy to deploy and evolve

– Without breaking existing systems and activities• As little Integration as possible

– Data federation– « right-time » integration

• Able to deal with unreliable environments• Scalability and availability of web

applications


So…

• No single information system can live in isolation from other information sources– Business activities and business processes span an

increasingly larger number of systems of record

• IT can no longer afford to build assets that cannot be reused in future contexts

• New assets must be built in a way that enable them to be “composed” in future solutions– Current application models and middleware are not

capable of “composition”

• A new application model must support UI, Process and Data federation

Composite Application Composite Application ModelModel

Federating UI, Processes and DataFederating UI, Processes and Data


Let’s look at the Requisition-to-Invoice Process

RFQ

OrderManagement

Procurement

ERP

RFQ Suppliers

Quotes Orders

Suppliers Billing

Orders Invoices

Order

Invoice


How can we reuse these two systems to create new solutions or create new activities ?

SI

1 23 4

56

78

S1S2

S3S4

S5S6

S7S8

0

2

4

6

8

10

12

Attributes

Systems

Business Objects


SI SI

clientclient

clientclient

clientclient

SI Service Interface

Activity

Coordinator

Service

Resource


The coordinator has two roles: a) normalize the business logic of business objects

1 2 3 4 5 6 7 8

S1

0

2

4

6

8

10

SC

M

PLM

Por

tal

PR

M

HC

M

…

ER

P

CR

M Order

Customer

OrderService

CustomerService


This normalization can be achieved with orchestration programming languages such as BPEL, BPEL-J

Purchase Request

Cancel Order

Order

Material Receipt

Invoice

receive

invoke

send

Create PO

receive

invoke

invoke

send

Cancel

Create PO CRM

Create PO ERP

Order Service


b) Manage the Business Process level which can be achieved via choreography languages (WS-CDL, ebBP) and technologies (WS-CAF)

RFQService

OrderService

InvoiceService

PurchasingRequest

InvoiceOrder

BuyerCancel

Cancel

Invoice

MaterialReceipt

Supplier OrderService


Orchestration and Choreography are two forms of Coordination which are complementary• Not everything needs to be nor can be

“orchestrated”– B2B for sure– Even internally, orchestrating everything is

creating a maximum coupling at the business level

– Orchestration is best used for creating normalized business services

• There are two forms of coordinators– Orchestration Engine (WS-BPEL)– Choreography agents (WS-CDL, WS-CAF)

• Choreography participants can often self-coordinate


User Activities fit right in a service oriented composite application model

RFQService

OrderService Invoice

Service

RFQ

Cancel Request Invoice

Material Receipt

CreateRFQ

ApproveOrder

QueryOrders,

Invoices,…

RFQ Order

« Activities »

« Services »


MVC will progressively be replaced by the Service-Activity-Coordinator-Resource pattern

Activity

Coordinator

Service

Ressource

Ressource

Ressource

SACRe Pattern


Service Interface

Composite Application Architecture

Business Activity

Business Service

Business Process

Initiates

Initiates

Participates in

Invokes

Invokes


Software vendors are creating the technological foundation enabling this composite application model

• A new universal and ubiquitous distributed computing model– Web Services– Based on open standards– Would have far less value if this did not exists

• New programming languages (not application programming languages)– Where the message becomes a first class citizen along

with code and data, based on a new formalism: Pi-Calculus– WS-BPEL, BPEL-J ou C (Microsoft)

• The formalism of the application model can go far beyond « principles » of Architecture and Design


Shift To A Service-Oriented Architecture and Composite Applications

• Function oriented• Build to last• Prolonged

development cycles

FromFrom ToTo• Coordination oriented • Build to change• Incrementally built and

deployed

• Application silos• Tightly coupled• Object oriented• Known

implementation

• Enterprise solutions• Loosely coupled• Message oriented• Abstraction

Source: Microsoft (Modified)

Service Orientation and Service Orientation and Composite ApplicationsComposite Applications


Composite applications may rely on dozens systems geographically distributed

• There are five major concepts that represent the foundation of Service Orientation – Peer-to-peer message based interactions– Service Interfaces vs Object Interfaces– Policies and agreements (P&A)– Discovery– Composition– Coordination

• These concepts are critical to build successful composition applications


Peer-to-peer interactions

• Synchronous Request / Response are not adapted for long-running interactions which may occur at the service coordination level

• When you have dozens of systems interacting with each other, who is controlling who?


Service Interfaces

• Non proprietary– All service providers offer somewhat the same interface

• Highly Polymorphic – Intent is enough when invoking a service

• Implementation can be changed in ways that do not break service consumer operations– Real world services interact with thousands of

consumers– Service providers cannot afford to “break” the context

of their consumers


Policies, Agreements

• This topic is about governance and is critical to the success of composite applications– One needs to find the appropriate services as efficiently

as possible

• With possibly several hundreds services being consumed by a Composite Application it is essential to have a policy driven assembly mechanism– This is equivalent to type checking in compiled languages– Agreements are not yet very common in SOA, but they

are a natural extensions to policies and represent the runt-time contract between the service producer and Comp. Applications


Discovery is a feature that is fairly unique to SOA

• Services are autonomous entities often designed and managed outside the realm of their consumers

• Registries of Service Definitions facilitate the selection of a service during the design of a Composite Application

• Discovery mechanisms may also be invoked at run- time for dynamic or fail safe behaviors– However not all services can be replaced


The fundamental goal of service orientation is to create assets that are “composable”

• Structured programming and Object Orientation offer code level composition mechanism– Enabling code reuse but not asset reuse

• External interfaces of IT assets were often an after thought built in a proprietary way (semantically and technically) limiting any potential reuse of this asset in contexts that where not necessarily known when it was designed and implemented


Composition and Service Orientation

• Resource representation composition– Resources are represented in XML– XML documents are composable

• Service Composition Language– BPEL enables us to create services from other services– Supports two types of compositions

• operation composition • interface composition

• Ultimately, Service Orientation will only succeed if it enables data, process and UI federation via composition


Coordination

• Coordination technologies support the Business Process layer of Composite Applications

• The coordination infrastructure– Ensures state alignment between all

participants in a Composite Application – Generates exception when the coordination

does not proceeds as planned

Resources in Composite Resources in Composite ApplicationsApplications


“at the heart of [SOA] 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.


Information Entities (Resources) in SOA

• Several dimensions appear when managing an Information Aggregate in a SOA

InformationEntity

InformationEntity

Identity

Content

State

Location(s)

Replication

Privacy

Specificto SOA and

Composite Apps


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

ConclusionConclusion

The Future Belongs to Whom Can Master The Future Belongs to Whom Can Master ConnectivityConnectivity


Service Orientation is a New Computing Paradigm from which Composite Applications can be built

• 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


Composite Application are the latest iteration on Service Oriented Architecture

• Composite Applications add value to a SOA– SOA is not just a better integration strategy

• Composite Applications enable an Enterprise Architecture strategy– Application model shielded from technologies– Explicit Business process and information view

• Capable of returning IT projects to positive ROI– Built new solutions on existing assets– Application model built for evolution and no integration– Increased in productivity because of federated UI


Where do we start?

• Well that remains the big question– Build on the SOA momentum

• Vendors have started to market the concept– SAP (xApps)– Oracle (BPEL Engine)– BEA (Liquid Data)– Microsoft (CCF)– This is good news !

• Tons of technology components to build your own• The problem is critical mass, the more you have

in a Composite Model, the easier it is to add

Date post:	30-Mar-2015
Category:	Documents
Upload:	curtis-gartland
View:	215 times
Download:	2 times

Composite Applications: Value Proposition and Architecture Jean-Jacques Dubray, Ph.D. Attachmate...

Documents