Hva er SOA og Web services? (SOA: Service-oriented architecture / Tjenesteorientert arkitektur)

Transcription

1 Hva er SOA og Web services? (SOA: Service-oriented architecture / Tjenesteorientert arkitektur) Brian Elvesæter, SINTEF IKT Avdeling for samvirkende og tiltrodde systemer, Oslo brian.elvesater@sintef.no NorStella-DND Web services seminar, Oslo, 9. juni 09:00-09:30

2 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

3 Tjenesteorientert arkitektur

4 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) Evolution of styles/approaches to designing software systems Data-orientation Functional-orientation Object-orientation Component- and message-orientation Service-orientation

5 MS SOA Definition - Knowledge about the business - What are they? The goal of a SOA is to allow business activities to be orchestrated as components in applications targeting both internal and extraorganizational actors, ultimately process enhancing business agility Business and IT alignment: mapping between business activities and - Flexibility components - Re-wire as needed - Notion of business - Value chains traversal - Beyond the firewall - Cross trust boundaries - Autonomous / Independent actors Andreas S. T. Brunvoll, From EAI to SOA, Presentation given at The Roots Conference, April 2005, Bergen

6 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

7 This image cannot currently be displayed. This image cannot currently be displayed. Fra monolittiske systemer til en tjenesteorientert arkitektur System A System B System C System D

8 Web services

9 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) SOA ~ architectural style Web services stack ~ technology/protocol standards SOA =/= Web services

10 The Waves of Client/Server Technology First Wave Second Wave Third Wave Fourth Wave Fifth Wave File Servers Base Source: Client/Server Survival Guide, 1994 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2004 MDA, Web Services,.Net Distributed Server-side Service-oriented Objects componentsc Architecture OMG CORBA J2EE/EJB SOAP, XML COM/OLE COM+ WSDL/WSFL Web/Internett Corba Comp Java Agents, P2P FIPA Grid

11 Synchron. request Deferred Synch request Message Streaming Event - publish & subscribe Naming service Trading service Multi Media, QoS Security service Interaction/Pres services User services (application/process) Shared Business Services Data services & Legacy systems Integration service User Interface Document model Web interaction XML Workflow service System/Use Mngt Server Components Concurrency service Transaction service Persistence service

12 OMG (Object Management Group) OMA (Object Management Architecture) Application Objects Vertical CORBA Facilities Horizontal CORBA Facilities Object Request Broker (CORBA) Lifecycle Events Naming Persistence Transactions Concurrency CORBA Services Externalization Security Time Properties Query Licensing

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

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

15 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 WS-Notification WS-Coordination WS-Addressing SOAP WSDL XML BPEL UDDI WS-Policy WS-ReliableMessaging WS-Federation WS-Security WS-CDL WS-Transfer WS-MetadataExchange WS-Resource

16 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 WS-Notification WS-Coordination WS-Addressing SOAP WSDL XML BPEL UDDI WS-Policy WS-ReliableMessaging WS-Federation WS-Security WS-CDL WS-Transfer WS-MetadataExchange WS-Resource

17 WS-* specifications / metamodels <<Metamodel>> Coordination + WS-Coordination. <<Metamodel>> Reliability + WS-ReliableMessaging. <<Metamodel>> Eventing + WS-BaseNotification. + WS-BrokeredNotification. + WS-Eventing. + WS-Topics. <<Metamodel>> Resource Access and Management + WS-Enumeration. + WS-Resource. + WS-ResourceLifetime. + WS-ResourceProperty. + WS-Transfer. <<Metamodel>> Registry + UDDI. <<Metamodel>> Endpoint Description + WS-MetadataExchange. + WS-Policy. + WS-PolicyAttachement. <<Metamodel>> Messaging + SOAP. + WS-Addressing. <<Metamodel>> Transport + HTTP. <<Metamodel>> Service Interface Description + WSDL WSDL 2.0. <<Metamodel>> Security + WS-Security. <<Metamodel>> XML + XML Core / XSD. + XML Encryption. + XML Signature. + XPATH. <<Metamodel>> econtract <<Metamodel>> Composition

18 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

19 WSDL 1.1 metamodel WSDL Component 0..1 WSDL Document A container for data type definitions Include + Location Import A collection of related endpoints + NameSpace + Location 0..1 Types Schema + TargetNameSpace 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 Service + Name 1..* Port + Name 1 1 Binding + Name 1 1 Definition + Name + TargetNameSpace Port Type + Name An abstract set of operations supported by one or more endpoints input 1..* Message + Name +fault 0..1 Operation + Name An abstract, typed definition of the data being communicated output Element + Name + BaseType + MinOccurs + MaxOccurs Part + Name + Type + Element An abstract, description of an action supported by the service

20 WSDL 2.0 metamodel +extended interfaces Interface Definitions +interfaces + name : wsdls_ncname +faults Interface Fault + target namespace : wsdls_anyuri + name : wsdls_ncname + target namespace : wsdls_anyuri +bindings +interface fault reference 1 +fault 1 reference Binding +interface 1 + name : wsdls_ncname + target namespace : wsdls_anyuri + type : wsdls_anyuri +properties +properties Property 1 +properties +faults +properties + name : wsdls_anyuri +binding + required : wsdls_boolean +properties Binding Fault +operations +properties +properties +properties +properties +features +properties +properties +features +features +operations Interface Operation +features Feature +features +operation reference + name : wsdls_ncname +features + name : wsdls_anyuri Binding Operation + target namespace : wsdls_anyuri + required : wsdls_boolean +features + message exchange pattern : wsdls_anyuri 1 +features +features + style [] : wsdls_anyuri +features +features + safety : wsdls_boolean +message references Binding Message Reference + message label : wsdls_ncname + direction : wsdls_token +services Service + name : wsdls_ncname + target namespace : wsdls_anyuri +message references Message Reference + message label : wsdls_ncname + direction : wsdls_token + message content model : wsdls_token Endpoint +endpoints + name : wsdls_ncname 1..* + address : wsdls_anyuri +fault references Fault Reference + message label : wsdls_ncname + direction : wsdls_token

21 Oversikt over utviklingen innen EU på dette området

22 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: 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:

23 Rationale Interoperability, key to increase competitiveness of enterprises The cost of non-interoperability are estimated to 40% of enterprises IT budget. Application integration license revenue System implementation budget B$ Misc. 20% Integration 40% Hardware 10% Imp. Services 20% Software 10% (Source: the Yankee Group 2001)

24 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. Knowledge integration for Interoperability research Architectures & Platforms Enterprise Modelling INTEROP Ontology

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; rainer.ruggaber@sap.com Klaus-Dieter PLATTE, kdplatte@platteconsult.com 25

26 Hvilke krav bør stilles til grunnleggende IT-arkitektur?

27 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 solutions Inflexible and difficult to adapt to meet the requirements of those changing enterprises Future 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 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

28 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 Knowledge Architecture (EKA) Enterprise methodology Metamodels and languages Enterprise models Product models Enterprise templates Reference architectures Semantics Ontology methodology Reference ontology Information and Communication Technology () Architecture Business and user services Infrastructure services EKA services Ontology tools Software platforms Modeling tools Management tools Ontology services

29 Holistic Approach to Interoperability Enterprise A Business Enterprise B Business Systems Knowledge Application Data Semantics Knowledge Application Data Semantics Use SOA principles and Web services to re-architect application systems 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 Applications, data and communication components Semantics: support mutual understanding on all layers

30 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?

31 Adaptive service-oriented architecture (ASOA) MDD PIM ASOA ASOA SOA ASA PSM (Web) Service Agent P2P GRID Service Agent ASOA: Adaptive service-oriented architecture SOA: Service-oriented architecture ASA: Adaptive software architecture MDD: Model-driven development PIM: Platform-independent model PSM: Platform-specific model P2P GRID

32 Granularity of services User-composable service layer (use-case-driven composition of services) a r y a t z Shared and network-visible service layer (fine/coarse-grained reusable services) a b c r s t x y z 1 z 2 Too fine-grained services => Scalability problem (performance) Too coarse-grained services => Adaptability/interoperability problem (flexibility) Cost, performance, flexibility choose any two!

33 econtract, grey-box, Service (consumer) econtract Mutual agreement Service (provider) Black-box vs. White-box vs. Grey-box (autonomous) local service local service 3rd party service 3rd party dependency

34 Hva er hensikten med denne nye teknologien, og hvilke muligheter åpner seg? Towards an Integrated Enterprise Service Architecture

35 New mode of collaboration Enterprise X Collaboration space Enterprise Y? Composed business services? Shared business model Business services Public view Internal services Enterprise Service Bus Enterprise A Private view Knowledge model Service

36 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,