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 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” - 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 extra- Notion of business process organizational actors, ultimately enhancing business agility - Value chains traversal Business and IT alignment: mapping between business - Flexibility activities and components - “Re-wire” as needed - 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 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 Fra monolittiske systemer til en tjenesteorientert arkitektur This image cannot currently be display ed. This image cannot currently be display ed. System A System B System C System D 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 First Wave Second Wave Third Wave Fourth Wave Fifth Wave MDA, Web Services, .Net Server-side Distributed Service-oriented componentsc Objects Architecture J2EE/EJB OMG CORBA SOAP, XML COM+ COM/OLE WSDL/WSFL Corba Comp Web/Internett Agents, P2P Java File Servers FIPA 1982 1986 1990 1994 Grid 1998 1999 2000 2001 2002 2003 Base Source: Client/Server Survival Guide, 1994 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2004 ICT User Interface Document model Web interaction Synchron. request Deferred Synch request Interaction/Pres services XML Message Streaming Multi Media, QoS Event - publish & subscribe Workflow service User services (application/process) System/Use Mngt Server Components Shared Business Services Concurrency service Naming service Security Trading service service Data services & Legacy systems Integration service Transaction service Persistence service ICT 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 Externalization Security Time Properties Query Licensing CORBA Services 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 WS-Addressing WS-Notification WSDL SOAP WS-Coordination XML WS-Security BPEL WS-CDL WS-Federation UDDI WS-Policy WS-ReliableMessaging WS-MetadataExchange WS-Resource WS-Transfer 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 WS-Addressing WS-Notification WSDL SOAP WS-Coordination XML WS-Security BPEL WS-CDL WS-Federation UDDI WS-Policy WS-ReliableMessaging WS-MetadataExchange WS-Resource WS-Transfer ICT WS-* specifications / metamodels <<Metamodel>> Eventing <<Metamodel>> Registry + UDDI. <<Metamodel>> Coordination <<Metamodel>> Reliability + WS-Coordination. + WS-ReliableMessaging. <<Metamodel>> Endpoint Description + WS-MetadataExchange. + WS-Policy. + WS-PolicyAttachement. <<Metamodel>> Service Interface Description + WSDL 1.1. + WSDL 2.0. <<Metamodel>> eContract + WS-BaseNotification. + WS-BrokeredNotification. + WS-Eventing. + WS-Topics. <<Metamodel>> Messaging + SOAP. + WS-Addressing. <<Metamodel>> Security + WS-Security. <<Metamodel>> Transport + HTTP. <<Metamodel>> XML + XML Core / XSD. + XML Encryption. + XML Signature. + XPATH. <<Metamodel>> Composition ICT <<Metamodel>> Resource Access and Management + WS-Enumeration. + WS-Resource. + WS-ResourceLifetime. + WS-ResourceProperty. + WS-Transfer. 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 metamodel WSDL Component A container for data type definitions WSDL Document 0..1 Include + Location Import + NameSpace + Location A collection of related endpoints 0..1 Definition Element + Name + TargetNameSpace + Name 0..* + Name An abstract, + BaseType + MinOccurs typed definition + MaxOccurs of the data being communicated 1..* Port 0..* Part + Name 0..* Message 1 + Name 0..1 A concrete protocol and data format specification for a particular port type + TargetNameSpace 0..* Service A single endpoint defined as a combination of a binding and a network address Schema Types 1 Binding 0..* 0..* Port Type + Name 0..1 +fault 0..1 + Name + Type + Element +output +input + Name 1 1 An abstract set of operations supported by one or more endpoints 1..* Operation + Name An abstract, description of an action supported by the service ICT WSDL 2.0 metamodel +extended interfaces 0..* Interface +interfaces+ name : wsdls_NCName 0..* + target namespace : wsdls_anyURI Definitions +bindings 0..* +interface 0..1 1 Binding +interface + name : wsdls_NCName + target namespace : wsdls_anyURI + type : wsdls_anyURI +faults Interface Fault + name : wsdls_NCName 0..*+ target namespace : wsdls_anyURI +fault reference 1 1 reference +fault 0..* +properties 0..* +properties Property +properties 1 +properties 0..* + name : wsdls_anyURI +faults +binding + required : wsdls_boolean 0..* +properties 0..* Binding Fault 0..* +properties +features +properties 0..* +operations0..* +properties 0..* 0..* 0..* +properties 0..* +properties 0..* +properties 0..* 0..* +features +features +features0..* Feature Interface Operation +operations +features +features + name : wsdls_anyURI 0..* +operation reference + name : wsdls_NCName 0..* + required : wsdls_boolean Binding Operation + target namespace : wsdls_anyURI +features 0..*0..* + message exchange pattern : wsdls_anyURI +features 0..* +features 1+ style [0..*] : wsdls_anyURI +features +features 0..*0..* 0..* 0..* + safety : wsdls_boolean +message references 0..* Binding Message Reference + message label : wsdls_NCName + direction : wsdls_token +services +fault references 0..* +message references 0..* Message Reference + message label : wsdls_NCName + direction : wsdls_token + message content model : wsdls_token Fault Reference + message label : wsdls_NCName + direction : wsdls_token 0..* Service + name : wsdls_NCName + target namespace : wsdls_anyURI Endpoint +endpoints + name : wsdls_NCName 1..* + address : wsdls_anyURI 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 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 Misc. 20% B$ Integration 40% Hardware 10% Imp. Services 20% Software 10% (Source: the Yankee Group 2001) 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. Knowledge integration for Interoperability research Architectures & Platforms Enterprise Modelling INTEROP Ontology ICT ATHENA - Partners • • • • • • • • • • AIDIMA COMPUTAS CRF DFKI EADS ESI FORMULA FHG/IPK GRAISOFT IBM Contacts: • • • • • • • • • IC FOCUS INTRACOM LEKS/IASI-CNR SAP SIEMENS SINTEF TXT UNI.BORDEAUX I UNINOVA Rainer RUGGABER; rainer.ruggaber@sap.com Klaus-Dieter PLATTE, kdplatte@platteconsult.com ICT 25 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 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) Ontology methodology Reference ontology Information and Communication Technology (ICT) Architecture Business and user services Infrastructure services EKA services Ontology tools Software platforms Modeling tools Management tools Ontology services ICT Holistic Approach to Interoperability Enterprise A ICT Systems Application Knowledge Application Data Data Semantics Knowledge Business Semantics Business Enterprise B 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 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 “Adaptive” service-oriented architecture (ASOA) MDD “PIM” ASOA SOA ASOA ASA “PSM” Service Agent (Web) Service Agent P2P GRID 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 ICT GRID Granularity of services User-composable service layer a (use-case-driven composition of services) Shared and network-visible service layer (fine/coarse-grained reusable services) a r y a r b c t s t z y x z1 z2 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, … eContract Mutual agreement Service Service (consumer) (provider) Black-box vs. White-box vs. Grey-box (autonomous) local service 3rd party service local service 3rd party dependency ICT Hva er hensikten med denne nye teknologien, og hvilke muligheter åpner seg? Towards an Integrated Enterprise Service Architecture ICT 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 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 ICT