Upload
brian-elvesaeter
View
220
Download
1
Embed Size (px)
DESCRIPTION
“Hva er SOA og Web services?”, NorStella and DND seminar, Oslo, Norway, 9 June 2005.
Citation preview
ICT
Hva er SOA og Web services?(SOA: Service-oriented architecture / Tjenesteorientert arkitektur)
Brian Elvesæter, SINTEF IKTAvdeling for samvirkende og tiltrodde systemer, Oslo
NorStella-DND Web services seminar, Oslo, 9. juni09:00-09:30
ICT
Tjenesteorientert arkitektur Web services Oversikt over utviklingen innen EU på dette området? Hvilke krav bør stilles til grunnleggende IT-arkitektur? Hva er hensikten med denne nye teknologien, og hvilke
muligheter åpner seg? Towards an Integrated Enterprise Service Architecture
ICT
Tjenesteorientert arkitektur
ICT
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 styles/approaches to designing software systems Data-orientation Functional-orientation Object-orientation Component- and message-orientation Service-orientation
ICT
MS SOA “Definition”
The goal of a SOA is to allow business activities to be orchestrated as components in applications targeting both internal and extra-organizational actors, ultimately enhancing business agility
- Knowledge about the business- What are they?
- Notion of business process
Business and IT alignment: mapping between business activities and components
- Value chains traversal- Beyond the firewall- Cross “trust boundaries”- Autonomous / Independent actors
- Flexibility - “Re-wire” as needed
Andreas S. T. Brunvoll, “From EAI to SOA”,Presentation given at The Roots Conference, April 2005, Bergen
ICT
SOA characteristics
The service concept applies equally well to the business as it does to software applications. 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 Modular design
Compositions and granularity Services are loosely coupled
From compile-time and deployment-time dependencies to run-time dependencies (services)
Dynamic discovery and binding Services are standardized (“platform independent”)
Using Internet/Web protocols and standards as the common “glue” provide “syntactical interoperability”
ICT
This image cannot currently be displayed.
This image cannot currently be displayed.
System A System DSystem CSystem B
Fra monolittiske systemer til en tjenesteorientert arkitektur
ICT
Web services
ICT
Web service definition
Web service “Applications identified by a URI, whose interfaces and bindings
are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols.” (W3C)
http://www.w3.org/
SOA ~ architectural style Web services stack ~ technology/protocol standards SOA =/= Web services
ICT
The Waves of Client/Server Technology
Base Source: Client/Server Survival Guide, 1994Robert Orfali, Dan HarkeyOS/2 Edition, VNR Computer library + AJB update 2004
1982 1986 1990 1994 1998 1999 2000 2001 2002 2003
FileServers
DistributedObjects
FirstWave
SecondWave
ThirdWave
OMG CORBACOM/OLEWeb/InternettJava
J2EE/EJBCOM+Corba Comp
Server-sidecomponentsc
MDA, WebServices, .NetService-orientedArchitectureSOAP, XML
WSDL/WSFL
FourthWave
FifthWave
P2PGrid
Agents,FIPA
ICT
DeferredSynch request
Naming service
Persistence service
ServerComponents
Message
Transaction service
Concurrencyservice
XML
Synchron.request
Event - publish & subscribe
Data services &Legacy systems
Shared BusinessServices
User services(application/process)
Interaction/Presservices
Trading serviceSecurityservice
Workflowservice
Streaming
Integration service
User InterfaceDocument modelWeb interaction
System/Use Mngt
MultiMedia,QoS
ICT
OMG (Object Management Group) OMA (Object Management Architecture)
LifecycleEventsNamingPersistenceTransactionsConcurrency
ExternalizationSecurityTimePropertiesQueryLicensing
ApplicationObjects
HorizontalCORBA Facilities
Object Request Broker (CORBA)
CORBA Services
VerticalCORBA Facilities
ICT
Web services og port 80
Interessen for Web-tjenester har mye av sitt utgangspunkt i problemet for CORBA, MS DCOM og Java RMI med å slippe igjennom for kommunikasjon med ukjente klienter, på grunn av sperrer i brannmurer.
Det ble raskt oppdaget at port 80 (for http Web-browser) kommunikasjon var åpen i de fleste brannmurer, og man begynte å pakke inn informasjon (tunneling) i meldinger som ble sendt gjennom port 80, først innpakket i HTML, deretter i XML.
Dette gav både en teknologi- og markedsmulighet som først Microsoft, deretter IBM var tidlig ute med å utnytte og promotere.
ICT
Web services
Web services can be used to implement service-oriented solutions
They adhere to the set of roles and operations specified by the service oriented model.
They have also managed to establish a standardized protocol stack.
ICT
WS-* stack to-be
Simplified version of the to-be WS-* stack Families of related specs not expanded Competing spec families not shown “Historical” or abandoned specs not shown
XML
SOAP WSDL
BPEL
WS-CDLWS-Security
WS-Addressing
WS-ReliableMessagingWS-Coordination
WS-Policy
WS-MetadataExchange
WS-Notification
WS-ResourceWS-Transfer
UDDI
WS-Federation
ICT
WS-* stack as-is
Complete version of the as-is WS-* stack The 3 widely-accepted specs today are the same as 5 years ago Everything else is considered not mature enough Orchestration, discovery and brokering do not exist in today’s world In terms of development process, nothing has changed since CORBA
XML
SOAP WSDL
BPEL
WS-CDLWS-Security
WS-Addressing
WS-ReliableMessagingWS-Coordination
WS-Policy
WS-MetadataExchange
WS-Notification
WS-ResourceWS-Transfer
UDDI
WS-Federation
ICT
WS-* specifications / metamodels
Registry<<Metamodel>>
+ UDDI.
Endpoint Description<<Metamodel>>
+ WS-MetadataExchange.+ WS-Policy.
+ WS-PolicyAttachement.
Service Interface Description
<<Metamodel>>
+ WSDL 1.1.+ WSDL 2.0.
Reliability<<Metamodel>>
+ WS-ReliableMessaging.Coordination
<<Metamodel>>
+ WS-Coordination.
Eventing<<Metamodel>>
+ WS-BaseNotification.+ WS-BrokeredNotification.
+ WS-Eventing.+ WS-Topics.
Resource Access and Management
<<Metamodel>>
+ WS-Enumeration.+ WS-Resource.
+ WS-ResourceLifetime.+ WS-ResourceProperty.
+ WS-Transfer.
Transport<<Metamodel>>
+ HTTP.
Messaging<<Metamodel>>
+ SOAP.+ WS-Addressing.
XML<<Metamodel>>
+ XML Core / XSD.+ XML Encryption.+ XML Signature.
+ XPATH.
Security<<Metamodel>>
+ WS-Security.
eContract<<Metamodel>>
Composition<<Metamodel>>
ICT
Web Service Description Language (WSDL) XML-based language for describing functional properties of Web
services. A service consists of a collection of message exchange end points. An end point contains an abstract description of a service interface
and implementation binding. The abstract description of a service contains:
(i) definitions of messages which are consumed and generated by the service
(ii) signatures of service operations. The implementation binding provides a means to map abstract
operations to concrete service implementations. It essentially contains information about the location of a binding and the
communication protocol to use (e.g., SOAP over HTTP) for exchanging messages
ICT
WSDL 1.1 metamodelWSDL DocumentWSDL Component
0..10..1
Port+ Name
Operation+ Name
Part+ Name+ Type+ Element
Service
+ Name
1..*1..*
Binding
+ Name
1
1
1
1
Port Type
+ Name11 11
Message+ Name
1..*
0..1
1..*
+input
0..1 0..1+output
0..10..1+fault 0..1
0..*0..*
Import
+ NameSpace+ Location
Include
+ Location
Element+ Name+ BaseType+ MinOccurs+ MaxOccurs
Definition
+ Name+ TargetNameSpace0..*0..*
0..*0..*0..*0..*
0..*0..*
0..*0..*
Schema+ TargetNameSpace
Types
0..10..1
A collection of related endpoints
A single endpoint defined as a combination of a binding and a network address
A concrete protocol and data format specification for a particular port type
An abstract set of operations supported by one or more endpoints
An abstract, typed definition of the data being communicated
An abstract, description of an action supported by the service
A container for data type definitions
ICT
WSDL 2.0 metamodel
Definitions Interface Fault+ name : wsdls_NCName
+ target namespace : wsdls_anyURI
Interface Operation+ name : wsdls_NCName
+ target namespace : wsdls_anyURI+ message exchange pattern : wsdls_anyURI+ style [0..*] : wsdls_anyURI+ safety : wsdls_boolean
Message Reference+ message label : wsdls_NCName
+ direction : wsdls_token+ message content model : wsdls_token
0..*
+message references
0..*Fault Reference
+ message label : wsdls_NCName+ direction : wsdls_token
1+fault reference1
0..*+fault references0..*
Interface+ name : wsdls_NCName
+ target namespace : wsdls_anyURI0..*
+interfaces
0..*
0..*
+extended interfaces
0..*
0..*
+faults
0..*
0..*+operations0..*Binding Fault
1+fault reference
1
Binding Operation
1
+operation reference
1
Binding Message Reference+ message label : wsdls_NCName
+ direction : wsdls_token
0..*+message references
0..*
Service+ name : wsdls_NCName
+ target namespace : wsdls_anyURI
0..*+services 0..*
1+interface
1Binding
+ name : wsdls_NCName+ target namespace : wsdls_anyURI+ type : wsdls_anyURI
0..*
+bindings
0..*
0..1+interface
0..1
0..*+faults
0..*
0..*+operations
0..*
Property+ name : wsdls_anyURI+ required : wsdls_boolean
0..*+properties
0..*
0..*+properties
0..* 0..*+properties0..*0..*+properties0..*
0..*
+properties
0..*
0..*
+properties
0..*
0..*
+properties
0..*0..*
+properties0..*
0..*+properties
0..* 0..*+properties0..*
Feature+ name : wsdls_anyURI+ required : wsdls_boolean
0..*+features
0..*
0..*
+features
0..*
0..*+features
0..* 0..*+features
0..*
0..*
+features
0..*
0..*
+features
0..*
0..*
+features
0..*0..*
+features
0..*0..*
+features0..*0..*
+features0..*
Endpoint+ name : wsdls_NCName+ address : wsdls_anyURI1..*
+endpoints
1..*
1
+binding
1
0..*+properties0..*
0..*+features
0..*
ICT
Oversikt over utviklingen innen EU på dette området
ICT
Interoperability Research
Project type: Network of Excellence (NoE)
Full title: Interoperability Research for Networked Enterprises Applications and Software
Project duration: 3 years Project budget: 12.0 M€ Project funding: 6.5 M€ Partners/contractors: 50 Start date: Nov 1, 2003
Web page: www.interop-noe.org
Project type: Integrated Project (IP)
Full title: Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications
Project duration: 3 years Project budget: 26.5 M€ Project funding: 14.4 M€ Partners/contractors: 19 Start date: Feb 1, 2004
Web page: www.athena-ip.org
ICT
Rationale
System implementation budgetApplication integration license revenue
B$
(Source: the Yankee Group 2001)
Integration40%
Imp. Services
20%
Software10%
Hardware10%
Misc.20%
Interoperability, key to increase competitiveness of enterprises
The cost of non-interoperability are estimated to 40% of
enterprises IT budget.
ICT
Approach
The originality of the 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.
Architectures & Platforms
EnterpriseModelling Ontology
Knowledge integration for Interoperability research
INTEROP
ICT 25
ATHENA - Partners• AIDIMA• COMPUTAS• CRF• DFKI• EADS• ESI• FORMULA• FHG/IPK• GRAISOFT• IBM
• IC FOCUS• INTRACOM• LEKS/IASI-CNR• SAP • SIEMENS • SINTEF• TXT• UNI.BORDEAUX I• UNINOVA
Contacts: Rainer RUGGABER; [email protected] PLATTE, [email protected]
ICT
Hvilke krav bør stilles til grunnleggende IT-arkitektur?
ICT
Interoperability point of view Enterprises
Constantly faced with expectations to change Adapt more quickly to changes in the business and economic market Business agility
Current ICT solutions Inflexible and difficult to adapt to meet the requirements of those changing
enterprises Future ICT infrastructures
Need to separate out knowledge from non-interoperable application systems – from application systems to design services
Capture knowledge as formalised models that can be used to configure and adapt the ICT systems
Integration through metamodelling and different views pertinent to stakeholders of an enterprise
Sustainable and inherently adaptive and interoperable infrastructures User-interaction Trust and confidence
SOA and Web services – a step in the right direction
ICT
4-layered view of an enterpriseBusiness Operational Architecture
Enterprise Knowledge Architecture (EKA)
Information and Communication Technology (ICT) Architecture
Sem
antic
s
Laws, rules, principles
Agreed norms and practices
Operations
Enterprise models
Metamodels and languages
Enterprise templates
Strategy
Procedures and routines
Enterprise methodology
Software platforms
EKA servicesBusiness and user services
Modelingtools
Infrastructure services
Management tools
Reference ontology
Ontologytools
Ontologyservices
Ontology methodology
Business terms
Reference architectures
Governance
Product models
ICT
Holistic Approach to Interoperability
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 Applications, data and communication components Semantics: support mutual understanding on all layers
Application
Data
Business
Knowledge
Application
Sem
antic
s
Business
Knowledge
Sem
antics
Enterprise A Enterprise B
Data
Communication
ICTSystems
Use SOA principlesand Web services tore-architectapplication systems
ICT
8 SOA challenges
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?
ICT
MDD
GRID
“Adaptive” service-oriented architecture (ASOA)
SOA ASA
ASOA
(Web)Service Agent P2P
ASOA: “Adaptive” service-oriented architectureSOA: Service-oriented architectureASA: Adaptive software architectureMDD: Model-driven developmentPIM: Platform-independent modelPSM: Platform-specific model
GRIDAgent
ASOA
Service
P2P
“PIM”
“PSM”
ICT
Granularity of services
Shared andnetwork-visible
service layer(fine/coarse-grained
reusable services)
User-composableservice layer(use-case-driven
compositionof services)
ab c
r
st
xy
z1
at
zyr
z2
a
Too fine-grained services => Scalability problem (performance)Too coarse-grained services => Adaptability/interoperability problem (flexibility)
Cost, performance, flexibility – choose any two!
ICT
eContract, grey-box, …
Service(consumer)
Service(provider)
eContractMutual agreement
Black-box vs. White-box vs. Grey-box (autonomous)
3rd partyservice
local service
local service
3rd partydependency
ICT
Hva er hensikten med denne nye teknologien, og hvilke muligheter åpner seg?
Towards an Integrated Enterprise Service Architecture
ICT
New mode of collaboration
?
Privateview
Publicview
Business services
Internal services
Enterprise Service Bus
?
Enterprise A
Enterprise X Enterprise Y
Knowledge model
Service
Collaboration space
Composed business services
Shared business model
ICT
Integrated Enterprise Service Architecture
Service infrastructure ATHENA Integrated Execution Infrastructure Infrastructure services
Enterprise services Business services (providing the ‘units’ of business operations) EKA services for managing knowledge assets (including models and
metamodels) MUP services for developing model-generated workplaces
User platforms Model-generated workplaces and Web portals Modelling tools and rich clients
B. Elvesæter, R. K. Rolfsen, F. Lillehagen, D. Karlsen, “Integrated Enterprise Service Architecture”, Paper to be presented at CE 2005, http://www.ce2005.org