Transcript Constructing Software for Service Oriented Architecture

Composite Applications:
Value Proposition and Architecture
Jean-Jacques Dubray, Ph.D.
Attachmate
[email protected]
May 2005
There is a newer (flash) presentation available here
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
2
Outline
•
•
•
•
•
Evolution of the Software Industry
Composite Application Model
Service Orientation and Composite Applications
Resources in Composite Applications
Conclusion
Attachmate Copyright 2005
3
Evolution of the
Software Industry
Problems and opportunities
The software industry has failed to create
normalized information systems
Business Object Attributes in different systems
Attributes
12
10
8
6
Business Objects
Employee
S8
S7
Invoice
S6
BOM
S5
S4
Product
S3
Customer
S2
S1
Order
4
2
0
Source:
Systems
David McComb et al,
www.SemanticArts.com
1
2
3
4
5
6
7
8
Attachmate Copyright 2005
5
Current Application Models (all based on MVC)
Couple UI, Processes and Data
C
I
C
I
Broker
Broker
C
I
C
I
Business Object Attributes in different systems
Attributes
12
10
8
6
Business Objects
Attachmate Copyright 2005
4
S8
S7
S6
S5
S4
S3
S2
S1
2
0
1
Systems
2
3
4
5
6
7
8
6
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
7
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
8
The “denormalization” has forced organization
to cross the point of negative ROI
Cost
Value
1
10
100
Attachmate Copyright 2005
1000
Number of
Systems
9
We must seek all opportunities bring projects
back in the positive ROI area
Cost
Value
1
10
100
Attachmate Copyright 2005
1000
Number of
Systems
10
Moving back to a lower number of systems of
records is not really an option
Cost
Value
1
10
100
Attachmate Copyright 2005
1000
Number of
Systems
11
The software industry attempting to improve
software construction along multiple dimensions
Application
Model
Middleware
Mainframe
Distributed
Computing
MQ
Client/Server
DCE
EAI, B2B
Web Apps
Portals
BPM
CORBA, J2EE
WS, ebXML
SalesForce.com
SAP, Oracle…
Solutions
Methodologies
Software
Constructio
n
MDD
XP
RUP
Attachmate Copyright 2005
Service Orientation
Object Orientation
Structured
Computing
Programming Model
12
However, it has often resulted in a lack of long range
coherence in IT with punctual or no ROI improvement
groupware
Browser
Portal
Form Title
Rich
Client
Form Title
B
P
M
Application Server
B
A
M
EII
WS
EAI
Mainframe
Mainframe
Mainframe
MOM
B2Bi
Mainframe
Mainframe
ETL
Attachmate Copyright 2005
Mainframe
13
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
14
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
Attachmate Copyright 2005
15
Composite Application Model
Federating UI, Processes and Data
Let’s look at the Requisition-to-Invoice Process
Procurement
RFQ
RFQ
Suppliers
Quotes
Orders
Suppliers
Billing
Orders
Invoices
Order
ERP
Order
Management
Invoice
Attachmate Copyright 2005
17
How can we reuse these two systems to create
new solutions or create new activities ?
Activity
Coordinator
SI
SI
SI
client
client
client
Service
Resource
Business Object Attributes in different systems
Attributes
SI
12
10
Service Interface
8
6
Business Objects
Attachmate Copyright 2005
4
S8
S7
S6
S5
S4
S3
S2
S1
2
0
1
Systems
2
3
4
5
6
7
8
18
The coordinator has two roles: a) normalize the
business logic of business objects
Customer
Service
Order
Service
10
8
6
4
2
0
1
2
3
4
5
6
7
Attachmate Copyright 2005
Customer
S1
Order
8
19
This normalization can be achieved with orchestration
programming languages such as BPEL, BPEL-J
Cancel
Order
receive
Material Receipt
Purchase Request
invoke
receive
send
invoke
Create PO CRM
invoke
Create PO ERP
Cancel Order
send
Create PO
Order Service
Invoice
Attachmate Copyright 2005
20
b) Manage the Business Process level which can be
achieved via choreography languages (WS-CDL, ebBP)
and technologies (WS-CAF)
Order
Service
Supplier
Order
Cancel
Material
Receipt
Purchasing
Request
Order
Service
RFQ
Service
Cancel
Invoice
Invoice
Service
Invoice
Buyer
Attachmate Copyright 2005
21
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
22
User Activities fit right in a service oriented
composite application model
Create
RFQ
Query
Orders,
Invoices,…
Approve
Order
« Activities »
RFQ
Order
Material
Receipt
RFQ
Order
Service
RFQ
Service
Cancel Request
« Services »
Invoice
Service
Invoice
Attachmate Copyright 2005
23
MVC will progressively be replaced by the
Service-Activity-Coordinator-Resource pattern
SACRe Pattern
Ressource
Activity
Coordinator
Ressource
Service
Attachmate Copyright 2005
Ressource
24
Composite Application Architecture
Initiates
Business Activity
Business Process
Initiates
Participates in
Invokes
Business Service
Invokes
Service Interface
Attachmate Copyright 2005
25
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 Cw (Microsoft)
• The formalism of the application model can go far beyond
« principles » of Architecture and Design
Attachmate Copyright 2005
26
Shift To A Service-Oriented Architecture and Composite
Applications
From
To
•
•
•
Function oriented
Build to last
Prolonged development
cycles
•
•
•
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)
Attachmate Copyright 2005
27
Service Orientation and
Composite 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
Attachmate Copyright 2005
29
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
30
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
31
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
32
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
33
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
34
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
35
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
Attachmate Copyright 2005
36
Resources in Composite
Applications
“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
38
Information Entities (Resources) in SOA
• Several dimensions appear when managing an
Information Aggregate in a SOA
Identity
Content
Information
Entity
State
Location(s)
Replication
Privacy
Attachmate Copyright 2005
Specific
to SOA and
Composite Apps
39
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 Copyright 2005
40
Conclusion
The Future Belongs to Whom Can Master Connectivity
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
42
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
43
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
Attachmate Copyright 2005
44