Transcript Introduction to Service-Oriented Interoperability (SOI)

AP1 – Introduction
to Service-Oriented
Interoperability (SOI)
Learn about service-oriented
architecture (SOA) and its application in
developing interoperable enterprise
software systems.
© 2005-2006 The ATHENA Consortium.
Course description
• According to W3C, a service-oriented architecture (SOA) specifies a
set of components whose interfaces can be described, published,
discovered and invoked over a network.
• SOA aims to promote software development in a way that leverages
the construction of dynamic systems that can easily adapt to volatile
environments and be easily maintained, as well.
• The decoupling of system constituent parts enables the reconfiguration of system components according to the end-user’s
needs and the system’s environment.
• Furthermore, the use of widely accepted standards and protocols that
are based on XML and operate above internet standards (HTTP,
SMTP, etc.) enhances interoperability.
• The course gives an overview of interoperability and SOA, and
introduces the ATHENA Service-Oriented Interoperability (SOI)
Framework, which provides guidelines for how to integrate enterprise
software systems in a service-oriented architecture (SOA).
© 2005-2006 The ATHENA Consortium.
2
Course objective
• The participants will learn about interoperability
and SOA and get an overview of the ATHENA
SOI Framework.
• The course aims to increase awareness of how
SOA can be applied to solve interoperability
issues.
• The courses AP2 and AP3 explores the SOI
framework in more detail.
© 2005-2006 The ATHENA Consortium.
3
SOI training track
No
Topic
Presenter
A
P
1
1-1
Interoperability & Service-Oriented Architecture (SOA)
• Motivation
<Person>, <Company>, <Country>
A
P
2
2-1
ATHENA Service-Oriented Interoperability (SOI)
Framework
• PIM4SOA MDD Tools
• Johnson Service Enactment
<Person>, <Company>, <Country>
2-2
Model-driven development with PIM4SOA
<Person>, <Company>, <Country>
2-3
Web services architectures
<Person>, <Company>, <Country>
2-4
Legacy Integration
<Person>, <Company>, <Country>
2-5
Enterprise Integration
<Person>, <Company>, <Country>
3-1
SOA and Agents
• WSDL Analyzer
<Person>, <Company>, <Country>
3-2
Agent Technologies
• What is an Agent?
• BDI Agents
• Modelling Multiagent Systems
<Person>, <Company>, <Country>
3-3
An MDA Approach to Agent Design
<Person>, <Company>, <Country>
A
P
3
© 2005-2006 The ATHENA Consortium.
4
SOI website
http://www.modelbased.net/soi
© 2005-2006 The ATHENA Consortium.
5
1-1. Interoperability
& Service-Oriented
Architecture (SOA)
<Presenter>
<Company>, <Country>
<E-mail>
© 2005-2006 The ATHENA Consortium.
Outline
•
•
•
•
•
Interoperability
Service-oriented architecture (SOA)
SOA platforms
SOA challenges
Introduction to the ATHENA Service-Oriented
Interoperability (SOI) Framework
• References
© 2005-2006 The ATHENA Consortium.
7
Interoperability
© 2005-2006 The ATHENA Consortium.
8
Definition
Interoperability (def.) is “the ability of
two or more systems or components to
exchange information and to use the
information that has been exchanged”
– IEEE Standard Computer Dictionary
© 2005-2006 The ATHENA Consortium.
9
Rationale for interoperability
• Interoperability is the key to increase competitiveness of enterprises.
• “Enterprise systems and applications need to be interoperable to achieve
seamless operational and business interaction, and create networked
organizations” – European Group for Research on Interoperability, 2002
Application integration license revenue
System implementation budget
Misc.
20%
B$
Integration
40%
Hardware
10%
Imp.
Services
20%
Software
10%
The cost of non-interoperability are estimated to
(Source: the Yankee Group 2001)
© 2005-2006 The ATHENA Consortium.
40% of enterprises IT budget.
10
Knowledge integration
The originality of the ATHENA project is to take a multidisciplinary
approach by merging three research areas supporting the
development of Interoperability of Enterprise Applications and
Software.
– Architecture & Platforms: to
provide implementation
frameworks,
– Enterprise Modelling: to
define interoperability
requirements and to support
solution implementation,
– Ontology: to identify
interoperability semantics in
the enterprise.
© 2005-2006 The ATHENA Consortium.
Architecture
& Platforms
ATHENA
Enterprise
Modelling
Ontology
11
4-layered view of an enterprise
Business Operational Architecture
Operations
Strategy
Governance
Laws, rules,
principles
Agreed norms
and practices
Procedures
and routines
Business terms
Enterprise
methodology
Enterprise
models
Enterprise
templates
Metamodels
and languages
Product
models
Reference
architectures
Semantics
Enterprise Knowledge Architecture (EKA)
Dictionaries
Ontologies
Nomenclatures
Classifications
Information and Communication Technology (ICT) Architecture
Business and
user services
Infrastructure
services
EKA services
Ontology
tools
Software
platforms
Modeling
tools
Management
tools
Ontology
services
© 2005-2006 The ATHENA Consortium.
12
Holistic approach to interoperability
Enterprise A
Enterprise B
Application
ICT
Knowledge
Application
Data
Data
Semantics
Knowledge
Business
Semantics
Business
Interoperability (def.) is “the
ability of two or more systems
or components to exchange
information and to use the
information that has been
exchanged” – IEEE Standard
Computer Dictionary
Communication
To achieve meaningful interoperability between enterprises, interoperability must be achieved on
all layers:
– Business layer: business environment and business processes
– Knowledge layer: organisational roles, skills and competencies of employees and
knowledge assets
– ICT layer: applications, data and communication components
– Semantics: support mutual understanding on all layers
© 2005-2006 The ATHENA Consortium.
13
Interoperability challenges
Enterprise
model
Platform
independent
Model (PIM)
Platform
Specific
Model
Enterprise
model
AKM ii - EM
execution
platform
PIM execution platform
PSM execution platform
Enterprise model
interoperability
(UEML)
Ontology-.based
semantic
interoperability?
Web services
(Uddi, Soap)
Bpml, Bpel, Xpdl?
AKM ii - EM
execution
platform
Interoperability objective
Platform
independent
Model (PIM)
PIM execution platform
Platform
Specific
Model
PSM execution platform
Integrate enterprise models
across companies and EM
tools
Exchange information despite
semantic and syntactical
incompatibility
Enable enterprises to invoke
services (and processes
packaged as services) from
each other, and include remote
services in local processes
Network protocols
© 2005-2006 The ATHENA Consortium.
14
Service-oriented architecture (SOA)
© 2005-2006 The ATHENA Consortium.
15
SOA definition
• Service-oriented architecture (SOA)
– “A set of components which can be invoked, and whose interface
descriptions can be published, discovered and invoked over a
network.” (W3C)
• http://www.w3.org/
• Evolution of architectural styles to designing software
systems
–
–
–
–
–
Data-orientation
Procedure-orientation
Object-orientation
Component- and message-orientation
Service-orientation
© 2005-2006 The ATHENA Consortium.
16
Service-oriented model
•
Service provider
– Provides software applications for specific needs as services.
•
Service requester
– A requester could be a human user/application program/another service accessing
the service through a desktop or a wireless browser; it could be an application
program.
•
Service broker:
– A service broker provides a searchable repository of service descriptions.
– Examples of service brokers are UDDI (Universal Description, Discovery, and
Integration).
© 2005-2006 The ATHENA Consortium.
17
Motivation
Enterprise
ICT
•
•
Challenges
– Business agility
– Flexibility and adaptability
•
Enterprise architecture frameworks
+ Holistic approach
+ Different views of an enterprise as
related (visual) knowledge models
- Current enterprise architectures
are only blueprints
Requirements
 Enterprises require operational
enterprise architectures
 ICT solutions must be designed to be
inherently interoperable
© 2005-2006 The ATHENA Consortium.
•
Challenges
– Inflexible and difficult to adapt
– Enterprise application integration
(EAI)
Service-oriented architecture (SOA)
+ Loosely coupled systems
+ Horizontal integration between
different business domains
+ Use case oriented service
composition
+/- Web services (enabling
technology)
- Discussion about architectural
style
18
Business and technology alignment
• Business
– Services can be seen as
business capabilities that
support the enterprise.
– Services usually represent a
business function or domain.
– Services provide the ‘units of
business’ that represent value
propositions within a value
chain or within business
processes.
– Traceability between the
service as a business
capability and its technical
implementation.
– Services will improve delivery
methods that are an integral
part of the business product.
© 2005-2006 The ATHENA Consortium.
• Technology
–
–
–
–
Modular design
Compositions and granularity
Services are loosely coupled
From compile-time and
deployment-time dependencies
to run-time dependencies
– Dynamic discovery and binding
– Services are standardized
(“platform independent”)
– Standard Internet and Web
protocols as the common
“glue” to provide “syntactical
interoperability”
19
From isolated application systems
to service-oriented systems
SOA
(architectural
style)
Web service
(enabling
technology)
• “A set of components which can be invoked, and whose interface descriptions can be published
and discovered.”
• “A Web service is a software system designed to support interoperable machine-to-machine
interaction over a network. It has an interface described in a machine-processable format
(specifically WSDL). Other systems interact with the Web service in a manner prescribed by its
description using SOAP-messages, typically conveyed using HTTP with an XML serialization in
conjunction with other Web-related standards.”
- W3C Web Services Glossary, http://www.w3.org/TR/ws-gloss/
System A
© 2005-2006 The ATHENA Consortium.
System B
System C
System D
20
SOA and Web services
• SOA is the blueprint for IT infrastructure of the
future.
• SOA extends the Web services value proposition
by providing guidance on how enterprise IT
infrastructures should be designed using
services.
• Four step migration process.
1. Implementing individual Web services: Creating
services from tasks contained in new or existing
applications
2. Service-oriented integration of business functions
3. Enterprise-wide IT transformation
4. On-demand business transformations
© 2005-2006 The ATHENA Consortium.
24
SOA platforms
© 2005-2006 The ATHENA Consortium.
25
© 2005-2006 The ATHENA Consortium.
26
SOA platform consolidation
• Applications (EAI + BPM + B2B) ➪ Integration
Suite (Application Server Platform)
• Processes (BPM) ➪ Business Process
Management Suite
• Information (EII + ETL+ ) ➪ Information Fabric
• Infrastructure (MOM, EAI, ..) ➪ Enterprise
Service Bus (ESB)
© 2005-2006 The ATHENA Consortium.
27
© 2005-2006 The ATHENA Consortium.
28
Enterprise service bus (ESB)
GARTNER
© 2005-2006 The ATHENA Consortium.
29
Integration services
© 2005-2006 The ATHENA Consortium.
30
Workplaces/Interaction services
© 2005-2006 The ATHENA Consortium.
31
Business process management (BPM) services
© 2005-2006 The ATHENA Consortium.
32
Information services (overview)
© 2005-2006 The ATHENA Consortium.
33
Information services (detailed)
© 2005-2006 The ATHENA Consortium.
34
Support services - checklist
• User interfaces, user experiences, Interaction services
• Communication abstractions (synch, asynch, event, …),
QoS
• Business rules (ILog, Pegasus, Fair-Isac, BR
community..) **
• Process (Workflow, Service orchestration)
• Services – functional interfaces (SOA), m/QoS
• Multi-user services (Transactions)
• Information Management (Data, Transformations)
• Legacy integration, Adapter services
• Trust Management (Security, Identity, Authorisation, …)
• System Management (Users, Monitoring, …
• Other: “Modelling” (MDA/DSL), Agents,
© 2005-2006 The ATHENA Consortium.
35
SOA challenges
© 2005-2006 The ATHENA Consortium.
36
8 SOA challenges
1.
2.
3.
4.
5.
6.
7.
8.
Service identification. What is a service? What is the business
functionality to be provided by a given service? What is the optimal
granularity of the service?
Service location. Where should a service be located within the
enterprise?
Service domain definition. How should services be grouped together into
logical domains?
Service packaging. How is existing functionality within legacy mainframe
systems to be re-engineered or wrapped into reusable services?
Service orchestration. How are composite services to be orchestrated?
Service routing. How are requests from service consumers to be routed
to the appropriate service and/or service domain?
Service governance. How will the enterprise exercise governance
processes to administer and maintain services?
Service messaging standards adoption. How will the enterprise adopt a
given standard consistently?
© 2005-2006 The ATHENA Consortium.
37
Trends
• Merging of Human Workflow and System
Orchestration/Process services
• Integration of Business Rules Engines
• Support for Event Notification services (publish
and subscribe)
• Integration of Model-generated workplaces and
role/task-oriented user interfaces, user interaction
services, portals, and multi-device interfaces
• Explicit use of models (Enterprise and System)
© 2005-2006 The ATHENA Consortium.
38
New mode of collaboration
Enterprise X
?
Enterprise Y
Collaboration space
?
Composed business services
Shared business model
Business
services
Public
view
Enterprise Service Bus
Internal
services
Private
view
Knowledge model
Service
Enterprise A
© 2005-2006 The ATHENA Consortium.
40
Introduction to the ATHENA
Service-Oriented Interoperability
(SOI) Framework
© 2005-2006 The ATHENA Consortium.
41
Background
• Service-Oriented Architecture
– architectural style
– gaining momentum
– mainstream in enterprise
computing
• Four tenets of serviceorientation (Box 2004)
– explicit boundaries
– autonomy of services
– declarative interfaces and data
formats
– policy-based service
description
© 2005-2006 The ATHENA Consortium.
• Web services architecture
– technology most often used for
implementing SOAs
– standards-based stack of
specifications
– enable interoperable
interactions between Webbased applications
42
Motivation
• Prototyping SOAs
– working implementation of an SOA that can be used for validating the
initial design choices
• Different compared to traditional application development
– need to take into account existing services
– developed by organisations over which we have no control
– introduces constraints into the prototyping exercise
• Current state of the art tools
– assumes that we are starting with a blank page
– merely extends the approach of regular software prototyping to the scale
of SOAs
– they make the implicit assumption that services will behave as expected
• This is why we designed an approach that
– from the start, takes into account the fact that parts of the SOA needs to
be considered as a given; and
– should be treated with a healthy dose of caution.
© 2005-2006 The ATHENA Consortium.
43
Framework overview
• The ATHENA baseline methodology for SOA
provides guidelines for developing platform
independent models for SOA (PIM4SOA).
• Provides a set of modelling tools and services for
mapping between PIM4SOA and platform specific
models (Web services and BDI agents)
Modelling
• Johnson
and
Lyndonbaseline
providemethodology
enactment of all the
• The
ATHENA
• The Web service extensions PIM4SOA
to the JACK
roles External
found
in
an
SOA
(consumer,
provider,
forWSDL
SOA
provides
guidelines
for
Documents
autonomous
agents platform allow SOAs to
intermediary)
andWSDL
flexible
between
developing
platform
independent
Documents communication
MDD Framework
BDI Teams
use agents for brokering, mediation and
Web services
intuitive user interface
models through
for SOA an
(PIM4SOA).
negotiation between
Web
services
WSDL Analyzer
Lyndon
• The WSDL
Analyzer
detected syntactical
• Provides
a settool
of modelling
tools and
• BDI teams provide a flexible and composable
mismatches
between
servicebetween
descriptions and
services
for mapping
Jack
alternative to «invoke»
traditional Johnson
approaches
«invoke»to Web
provides
a basis and
for runtime
of Web
PIM4SOA
platformmediation
specific models
service composition
service(Web
messages
services and BDI agents)
Agents
Services
• Johnson and Lyndon provide enactment of all the roles found
in an SOA (consumer, provider, intermediary) and flexible
communication between Web services through an intuitive user
interface
• The WSDL Analyzer tool detected syntactical mismatches
between service descriptions and provides a basis for runtime
mediation of Web service messages
© 2005-2006 The ATHENA Consortium.
• The Web service extensions to the JACK
autonomous agents platform allow SOAs to use
agents for brokering, mediation and negotiation
between Web services
• BDI teams provide a flexible and composable
alternative to traditional approaches to Web service
composition
44
References
© 2005-2006 The ATHENA Consortium.
46
References
[ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST507849). http://www.athena-ip.org/
[ATHENA A5 2005] ATHENA A5, "D.A5.1: Perspectives on Service-Oriented Architectures
and there application in environments that require solutions to be planned and
customisable", ATHENA IP, Deliverable D.A5.1, 2005.
[ATHENA A5 2005] ATHENA A5, "D.A5.2: Model and Specification of Service Descriptions
and Usage as well as Advanced Concepts", ATHENA IP, Deliverable D.A5.2, 2005.
[ATHENA A5 2006] ATHENA A5, "D.A5.3: Architecture of SOA Platforms", ATHENA IP,
Deliverable D.A5.3, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.4: Execution Framework(s) for Planned and
Customisable Service-Oriented Architectures", ATHENA IP, Deliverable D.A5.4, 2006.
[ATHENA A5 2006] ATHENA A5, "D.A5.5: Validation of Research Results", ATHENA IP,
Deliverable D.A5.5, 2006.
[Vayssière, et al. 2006] J. Vayssière, G. Benguria, B. Elvesæter, K. Fischer, and I.
Zinnikus, "Rapid Prototyping for Service-Oriented Architectures", presented at the 2nd
Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.
© 2005-2006 The ATHENA Consortium.
47
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification
is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please,
contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported
in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright
holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder.
© 2005-2006 The ATHENA Consortium.
48