© The ATHENA Consortium. AP1 – Introduction to Service-Oriented Interoperability (SOI) Learn about service-oriented architecture (SOA) and its application in developing interoperable enterprise software systems.

2 © 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 re- configuration 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).

3 © The ATHENA Consortium. 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.

4 © The ATHENA Consortium. SOI training track NoTopicPresenter AP1AP1 1-1Interoperability & Service-Oriented Architecture (SOA) Motivation,, AP2AP2 2-1ATHENA Service-Oriented Interoperability (SOI) Framework PIM4SOA MDD Tools Johnson Service Enactment,, 2-2Model-driven development with PIM4SOA,, 2-3Web services architectures,, 2-4Legacy Integration,, 2-5Enterprise Integration,, AP3AP3 3-1SOA and Agents WSDL Analyzer,, 3-2Agent Technologies What is an Agent? BDI Agents Modelling Multiagent Systems,, 3-3An MDA Approach to Agent Design,,

5 © The ATHENA Consortium. SOI website

© The ATHENA Consortium Interoperability & Service-Oriented Architecture (SOA),

7 © The ATHENA Consortium. Outline Interoperability Service-oriented architecture (SOA) SOA platforms SOA challenges Introduction to the ATHENA Service-Oriented Interoperability (SOI) Framework References

8 © The ATHENA Consortium. Interoperability

9 © The ATHENA Consortium. 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

10 © The ATHENA Consortium. System implementation budgetApplication integration license revenue B$ (Source: the Yankee Group 2001) Integration 40% Imp. Services 20% Software 10% Hardware 10% Misc. 20% 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 The cost of non-interoperability are estimated to 40% of enterprises IT budget. Rationale for interoperability

11 © The ATHENA Consortium. 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 Enterprise Modelling Ontology ATHENA –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.

12 © The ATHENA Consortium. 4-layered view of an enterprise Business Operational Architecture Enterprise Knowledge Architecture (EKA) Information and Communication Technology (ICT) Architecture Semantics Software platforms EKA servicesBusiness and user services Modeling tools Infrastructure services Management tools Nomenclatures Classifications Ontology tools Ontology services Dictionaries Ontologies Business terms Laws, rules, principles Agreed norms and practices Operations Strategy Procedures and routines Governance Enterprise models Metamodels and languages Enterprise templates Enterprise methodology Reference architectures Product models

13 © The ATHENA Consortium. 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 –ICT layer: applications, data and communication components –Semantics: support mutual understanding on all layers Application Data Business Knowledge Application Semantics Business Knowledge Semantics Enterprise AEnterprise B Data Communication ICT 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

14 © The ATHENA Consortium. (Uddi, Soap) Bpml, Bpel, Xpdl? Enterprise model interoperability (UEML) Network protocols 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 Interoperability objective Interoperability challenges

15 © The ATHENA Consortium. Service-oriented architecture (SOA)

16 © The ATHENA Consortium. 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 architectural styles to designing software systems –Data-orientation –Procedure-orientation –Object-orientation –Component- and message-orientation –Service-orientation

17 © The ATHENA Consortium. 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).

18 © The ATHENA Consortium. Motivation Enterprise 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 ICT 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 Requirements Enterprises require operational enterprise architectures ICT solutions must be designed to be inherently interoperable

19 © The ATHENA Consortium. 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. 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”

20 © The ATHENA Consortium. System ASystem DSystem CSystem B From isolated application systems to service-oriented systems “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, SOA (architectural style) Web service (enabling technology)

21 © The ATHENA Consortium. System ASystem DSystem CSystem B From isolated application systems to service-oriented systems “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, SOA (architectural style) Web service (enabling technology)

22 © The ATHENA Consortium. System ASystem DSystem CSystem B From isolated application systems to service-oriented systems

23 © The ATHENA Consortium. System CSystem B From isolated application systems to service-oriented systems

24 © The ATHENA Consortium. 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

25 © The ATHENA Consortium. SOA platforms

26 © The ATHENA Consortium.

27 © The ATHENA Consortium. 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)

28 © The ATHENA Consortium.

29 © The ATHENA Consortium. Enterprise service bus (ESB) GARTNER

30 © The ATHENA Consortium. Integration services

31 © The ATHENA Consortium. Workplaces/Interaction services

32 © The ATHENA Consortium. Business process management (BPM) services

33 © The ATHENA Consortium. Information services (overview)

34 © The ATHENA Consortium. Information services (detailed)

35 © The ATHENA Consortium. 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,

36 © The ATHENA Consortium. SOA challenges

37 © The ATHENA Consortium. 8 SOA challenges 1.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? 2.Service location. Where should a service be located within the enterprise? 3.Service domain definition. How should services be grouped together into logical domains? 4.Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services? 5.Service orchestration. How are composite services to be orchestrated? 6.Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain? 7.Service governance. How will the enterprise exercise governance processes to administer and maintain services? 8.Service messaging standards adoption. How will the enterprise adopt a given standard consistently?

38 © The ATHENA Consortium. 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)

39 © The ATHENA Consortium. 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

40 © The ATHENA Consortium. New mode of collaboration ? Private view Public view Business services Internal services Enterprise Service Bus ? Enterprise A Enterprise XEnterprise Y Knowledge model Service Collaboration space Composed business services Shared business model

41 © The ATHENA Consortium. Introduction to the ATHENA Service-Oriented Interoperability (SOI) Framework

42 © The ATHENA Consortium. Background Service-Oriented Architecture –architectural style –gaining momentum –mainstream in enterprise computing Four tenets of service- orientation (Box 2004) –explicit boundaries –autonomy of services –declarative interfaces and data formats –policy-based service description Web services architecture –technology most often used for implementing SOAs –standards-based stack of specifications –enable interoperable interactions between Web- based applications

43 © The ATHENA Consortium. 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.

44 © The ATHENA Consortium. Framework overview PIM4SOA MDD Framework WSDL Documents BDI Teams WSDL Analyzer External WSDL Documents Lyndon Johnson Jack «invoke» 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 Services Agents 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 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 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) 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 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

45 © The ATHENA Consortium. Framework overview PIM4SOA MDD Framework WSDL Documents BDI Teams WSDL Analyzer External WSDL Documents Lyndon Johnson Jack «invoke» 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 Services Agents 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 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

46 © The ATHENA Consortium. References

47 © The ATHENA Consortium. References [ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST ). [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, [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, [ATHENA A5 2006] ATHENA A5, "D.A5.3: Architecture of SOA Platforms", ATHENA IP, Deliverable D.A5.3, [ATHENA A5 2006] ATHENA A5, "D.A5.4: Execution Framework(s) for Planned and Customisable Service-Oriented Architectures", ATHENA IP, Deliverable D.A5.4, [ATHENA A5 2006] ATHENA A5, "D.A5.5: Validation of Research Results", ATHENA IP, Deliverable D.A5.5, [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.

48 © The ATHENA Consortium. 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 In other cases please, contact at the same 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