Composite Applications: Value Proposition and Architecture

gabonesedestructionΛογισμικό & κατασκευή λογ/κού

17 Φεβ 2014 (πριν από 3 χρόνια και 4 μήνες)

59 εμφανίσεις

Composite Applications:

Value Proposition and Architecture

Jean
-
Jacques
Dubray
, Ph.D.

Attachmate

jdubray@gmail.com



May 2005

There is a newer (flash) presentation available
here


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



Attachmate Copyright 2005

3

Outline


Evolution of the Software Industry


Composite Application Model


Service Orientation and Composite Applications


Resources in Composite Applications


Conclusion

Evolution of the

Software Industry

Problems and opportunities

Attachmate Copyright 2005

5

1
2
3
4
5
6
7
8
S1
S2
S3
S4
S5
S6
S7
S8
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

Order

Customer

Product

BOM

Invoice

Employee

Source:

David McComb et al,

www.SemanticArts.com

Attachmate Copyright 2005

6

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

C

I

C

I

C

I

C

I

Broker

Broker

1
2
3
4
5
6
7
8
S1
S2
S3
S4
S5
S6
S7
S8
0
2
4
6
8
10
12
Attributes
Systems
Business Objects
Business Object Attributes in different systems
Attachmate Copyright 2005

7

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

Attachmate Copyright 2005

8

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)


Attachmate Copyright 2005

9

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

Number of

Systems

10

100

1000

Cost

Value

1

1

Attachmate Copyright 2005

10

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

Number of

Systems

10

100

1000

Cost

Value

1

1

Attachmate Copyright 2005

11

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

Number of

Systems

10

100

1000

Cost

Value

1

1

Attachmate Copyright 2005

12

The software industry attempting to improve
software construction along multiple dimensions


Software

Constructio
n

Distributed

Computing

CORBA, J2EE

DCE

WS, ebXML

Application

Model

Mainframe

Client/Server

Web Apps

SAP, Oracle…

SalesForce.com

Solutions

Computing

Model

Structured

Programming

Object Orientation

Middleware

MQ

EAI, B2B

BPM

RUP

XP

MDD

Service Orientation

Methodologies

Portals

Attachmate Copyright 2005

13

groupware

EII

B

P

M

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


Mainframe
Form Title
Form Title
Mainframe
EAI

Browser

Portal

B2Bi

ETL

B

A

M

WS

Form Title
Form Title
Rich

Client

Mainframe
Mainframe
Mainframe
Mainframe
MOM

Application Server

Attachmate Copyright 2005

14

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


Attachmate Copyright 2005

15

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 Model

Federating UI, Processes and Data

Attachmate Copyright 2005

17

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

RFQ

Order

Management

Procurement

ERP

RFQ

Suppliers

Quotes

Orders

Suppliers

Billing

Orders

Invoices

Order

Invoice

Attachmate Copyright 2005

18

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

SI

1
2
3
4
5
6
7
8
S1
S2
S3
S4
S5
S6
S7
S8
0
2
4
6
8
10
12
Attributes
Systems
Business Objects
Business Object Attributes in different systems
SI

SI

client

client

client

SI

Service Interface

Activity

Coordinator

Service

Resource

Attachmate Copyright 2005

19

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
Order

Customer

Order

Service

Customer

Service

Attachmate Copyright 2005

20

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

Attachmate Copyright 2005

21

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

RFQ

Service

Order

Service

Invoice

Service

Purchasing

Request

Invoice

Order

Buyer

Cancel

Cancel

Invoice

Material

Receipt

Supplier

Order

Service

Attachmate Copyright 2005

22

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

Attachmate Copyright 2005

23

User Activities fit right in a service oriented
composite application model

RFQ

Service

Order

Service

Invoice

Service

RFQ

Cancel Request

Invoice

Material

Receipt

Create

RFQ

Approve

Order

Query

Orders,

Invoices,…

RFQ

Order

«

Activities

»

«

Services

»

Attachmate Copyright 2005

24

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

Activity

Coordinator

Service

Ressource

Ressource

Ressource

SACRe Pattern

Attachmate Copyright 2005

25

Service Interface

Composite Application Architecture

Business Activity

Business Service

Business Process

Initiates

Initiates

Participates in

Invokes

Invokes

Attachmate Copyright 2005

26

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
w

(Microsoft)


The formalism of the application model can go far beyond
«

principles

» of Architecture and Design

Attachmate Copyright 2005

27

Shift To A Service
-
Oriented Architecture and Composite
Applications


Function oriented


Build to last


Prolonged development
cycles

From

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

Source: Microsoft (Modified)

Service Orientation and
Composite Applications

Attachmate Copyright 2005

29

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




Attachmate Copyright 2005

30

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?



Attachmate Copyright 2005

31

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

Attachmate Copyright 2005

32

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

Attachmate Copyright 2005

33

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


Attachmate Copyright 2005

34

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

Attachmate Copyright 2005

35

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


Attachmate Copyright 2005

36

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
Applications

Attachmate Copyright 2005

38

“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.


Attachmate Copyright 2005

39

Information Entities (Resources) in SOA


Several dimensions appear when managing an
Information Aggregate in a SOA



Information

Entity

Identity

Content

State

Location(s)

Replication

Privacy

Specific

to SOA and
Composite Apps

Attachmate Copyright 2005

40

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

Conclusion

The Future Belongs to Whom Can Master Connectivity

Attachmate Copyright 2005

42

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


Attachmate Copyright 2005

43

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


Attachmate Copyright 2005

44

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