Presentation is loading. Please wait.

Presentation is loading. Please wait.

© 2005-2006 The ATHENA Consortium. 6-2. Model-Driven Development with PIM4SOA,

Similar presentations


Presentation on theme: "© 2005-2006 The ATHENA Consortium. 6-2. Model-Driven Development with PIM4SOA,"— Presentation transcript:

1 © 2005-2006 The ATHENA Consortium. 6-2. Model-Driven Development with PIM4SOA,

2 2 © 2005-2006 The ATHENA Consortium. Outline PIM4SOA Rapid prototyping with PIM4SOA Case study: AIDIMA e-procurement scenario References

3 3 © 2005-2006 The ATHENA Consortium. PIM4SOA

4 4 © 2005-2006 The ATHENA Consortium. The problem Currently, enterprises face many difficulties related to lack of interoperability. ATHENA Overall objective: Contribution to enabling enterprises to seamlessly interoperate with others Seamlessly involves reducing as much as possible the effort required to translate the interoperability rules specified by the business expert to suitable technical platform (SOA). PROBLEMS: –Several ways to specify interoperability at business level –Several kinds of SOA platforms –Too big gap

5 5 © 2005-2006 The ATHENA Consortium. Alternatives 1: Too big gap Business expert IT infrastructure GAP ArisGraiMetisMoogo GRIDP2PBDI Teams WSA POP* CIM PSM

6 6 © 2005-2006 The ATHENA Consortium. Alternatives 2: Too big gap Business expert IT infrastructure GAP ArisGraiMetisMoogo GRIDP2PBDI Teams WSA POP*CIMPIM PSM PIM4SOA

7 7 © 2005-2006 The ATHENA Consortium. The challenge Business expert IT infrastructure GAP CIMPIM PSM The goal of creating the PIM4SOA metamodel was to define a language that could be used to describe SOAs at a platform independent level. –Which are the collaborations that need to be implemented to perform the interoperability objectives stated at the business level? –What is the sequence of messages exchanged to perform the collaboration? –Which is the information exchanged? –Which are the non-functional requirements that the interaction has to meet? –…. The resulting PIM4SOA should be able to support a formal transition between enterprise models and IT implementations

8 8 © 2005-2006 The ATHENA Consortium. PIM4SOA objectives Platform independent model for specifying service-oriented architectures –Represent SOA solutions in a platform independent way –Integrate and define mappings to Web services, agents, peer-to-peer (P2P) and Grid execution platforms. –Bridging the gap between the enterprise layer and the technical layer –Establishing relationships between layers through model-based transformations –Two-way transformations supporting both model-driven development (MDD); and architecture-driven modernisation (ADM)

9 9 © 2005-2006 The ATHENA Consortium. PIM4SOA requirements Depending on the source of requirements From the enterprise or business viewpoint –Process, Organisation, Product and System (POPS) dimensions –Mapping enterprise and business model elements to PIM4SOA From the platform point of view –What are the necessary PSM elements to be represented at PIM level? –How do we identify these elements? –We need identify overlapping elements amongst platforms

10 10 © 2005-2006 The ATHENA Consortium. Characteristics for metamodel Suited for target roles –Support domain concepts and scenarios of target roles –Ease-of-use and understandable for business modeller (use terms) –Support precise details and correctness for solution architect Avoid unnecessary complexity –Keep it simple stupid (KISS) –Number of elements and associations –Type and navigation of associations Make it modular –Provide core with extensions –Define and illustrate possible subsets (”dialects”) that support scenarios –Consider integration and extension points Suited for implementation –EMF representation –Transformation from/to UML profile –Transformation to PSM

11 11 © 2005-2006 The ATHENA Consortium. Metamodel for (software) servicesMetamodel for (automated software) processes Metamodel for information Metamodel for quality of service (QoS) PIM4SOA addresses four system aspects Services are an abstraction and an encapsulation of the functionality provided by an autonomous entity. Service architectures are composed of functions provided by a system or a set of systems to achieve a shared goal. Web Services Architecture as proposed by W3C (W3C 2004) UML Profile for Enterprise Distributed Object Computing (OMG 2002) Information is related to the messages or structures exchanged, processed and stored by software systems or software components. Structural constructs for class modelling in UML 2.0 (OMG 2003) UML Profile for Enterprise Distributed Object Computing (OMG 2002) Processes describe sequencing of work in terms of actions, control flows, information flows, interactions, protocols, etc. Business Process Definition Metamodel (BPDM) (IBM et al. 2004) UML Profile for Enterprise Distributed Object Computing (OMG 2002) Extra-functional qualities that can be applied to services, information and processes. UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms (OMG 2004)

12 12 © 2005-2006 The ATHENA Consortium. Service metamodel Collaboration –Collaboration represents a pattern of interaction between participating roles –A binary collaboration specifies a service CollaborationUse –The model element to represent a usage of a service Role –The model element to represent a usage of a service RoleBinding –Relates a role with a usage of a service. RoleType –In a service oriented domain two are the RoleTypes identified: the requester and the provider Behaviour –An abstract class for the specification of messages sequence within a service ServiceProvider –Specify an entity describing and specifying in its turn services, roles and constraints ProviderType –The ServiceProviers can have to types: Abstract ore Executable EndPoint –Represents an address identifying a service Registry –A Registry model element is based on index approach containing addressable services RegistryItem –Represents a service and an end point.

13 13 © 2005-2006 The ATHENA Consortium. Information metamodel Item –Defines the set of elements that a role manages. ItemType –Represents simple types: string, integer and boolean. Role –is imported from the service metamodel. PackageableElement –Extracted from the UML2.0 specification. Association –Represents the association between two entities. –It is used to describe complex types Package –Extracted from the UML2.0 specification. Document –Represents an object with a specific structure and composed by entities. TypeLibrary –defines a packaging structure containing some types of the application BusinessTypeLibraryEntity –represents a structure element of information AttributeNameElement –extracted from the UML2.0 specification. Element –extracted from the UML2.0 specification.

14 14 © 2005-2006 The ATHENA Consortium. Process metamodel Process elements Process aspect Scope –Scope is an abstract container for individual behavioral steps Step –Step is a single node in a process, such as making a decision or calling an external service. The ‘everyday’ specialization of Step is Task Process –Implements a behaviour for a service provider, as a set of tasks and decisions (Steps) linked by control flows (Flows), optionally including detail on the exchanged messages / items. StructuredTask –A composite task consisting of a collection of Steps related to a specific subsection of a Process Task –The low level ‘building blocks’ of a process calls to another service require manual intervention Task –Defines an interface for input or output flows on a Step Pin –Input or output for a specific item type when a flow connects to a Step in the Process Flow –Provide the links between Steps (tasks etc.) in the behavior. A flow may be associated with a message type being transported. ItemFlow –A flow between specific pins on interactions to show precise relationships between output from one Step/Interaction and input on another JoinSpecification –Defines convergence behaviour when two flows provide input to a single Step/Interaction GuardSpecification –Defines conditions (e.g. in terms of Pin contents) under which an output flow is or is not activated

15 15 © 2005-2006 The ATHENA Consortium. Non-functional metamodel NFA –Represents Non-Functional Aspects for a specific usage of a service. defined in Collaboration and ServiceProvider specification related with CollaborationUse element All Others –Defined in the OMG standard for specifying quality of service

16 16 © 2005-2006 The ATHENA Consortium. Rapid prototyping with PIM4SOA

17 17 © 2005-2006 The ATHENA Consortium. Rapid prototyping framework for SOA 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 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) Agents Services Modelling

18 Semantic Space Service-Oriented Architecture Model Web Service Execution Artefacts Agent Execution Artefacts BPEL Execution Artefacts P2P Execution Artefacts Web Service Specification Model Agent Specification Model BPEL Specification Model P2P Specification Model Model Transformation UML Profile for Web Services UML Profile for Agents UML Profile for BPEL UML Profile for P2P Model Transformation Architecture Specification ATHENA Integrated Execution Infrastructure Deployment UML Profile for SOA Information Service Process QoS Reference Ontology annotated with Model to Model Transformation Model to Text Transformation OWL Ontology annotated with annotated with Enterprise Model UML Profile for POP* Process Organisation Product … Model to Model Transformation Business Requirements Analysis annotated with ATHENA baseline methodology for SOA (overview)

19 Method chunks for SOA and Web Service Interoperability Reference Ontology annotated with WSDL Document OWL-S Document BPEL Document BDI Plan XSD Document WS-? Document ATHENA Web Service Execution Infrastructure OWL Ontology annotated with UML Profile for POP* Process Organisation Product … Enterprise Model Process View Organisation View Product View … View 1111 Model to Model Transformation Business Requirements Analysis SOA Model Information View Service View Process View QoS View UML Profile for SOA Information Service Process QoS annotated with XML Message Service Description Process Execution QoS Description Web Service Model UML Profile for Web Services XML Message (XSD) Service Description (WSDL) Process Execution (BPEL) QoS Model to Model Transformation 1 1..* Model to Text Transformation Web Service Documents 1..* ATHENA baseline methodology for SOA (detailed)

20 20 © 2005-2006 The ATHENA Consortium. MDI modelling environment ATHENA Execution Infrastructure Model Repository Model Transformation (ATL, MTF) Execution Platform and Infrastructure Services (WS, Agents, BRMF, …) Eclipse/RSM Platform Collaborative Enterprise Modelling Cross- Organisational Business Process Modelling Service Integration and Composition Modelling Information Mapping Modelling Platform Integration Modelling

21 21 © 2005-2006 The ATHENA Consortium. PIM for SOA InformationServiceProcessQoS CBP XSDWSDLBPELWS-? BRMF Jack ARISPOP* UML Profile for SOA UML* Maestro Model 2 Model Model 2 Text Import / Export Model 2 Model Export + XML 2 Model CBP: Collaborative Business Process PIM: Platform Independent Model SOA: Service-Oriented Architecture XSD: XML Schema Definition BRMF: Business Resource Management Framework WSDL: Web Service Description Language BPEL: Business Process Execution Language Tools and services (overview)

22 22 © 2005-2006 The ATHENA Consortium. RSM and UML profile for PIM4SOA

23 23 © 2005-2006 The ATHENA Consortium. Case study: AIDIMA e-procurement scenario

24 24 © 2005-2006 The ATHENA Consortium. Introduction to business scenario Scenario is based on the current situation of the furniture SMEs regarding the procurement issues Value in the furniture industry is concentrated in design, manufacturing, sales and marketing –Clear benefit from the adoption of e-commerce initiatives Initiatives in the field of e-procurement of raw and semi- finished materials in the coming years –Significant benefits to be achieved in terms of cost reduction and efficiency Distribution in the furniture industry is structured in a complex way –Extranets and Internet-enabled supply-chain automation should optimize the relationships Order management and logistics with e-commerce implementations –Beneficial to the furniture industry

25 R3. Order R1. Request for Quotation R2. Quotation R4. Order Confirmation Interior Decoration Project M2. Quotation M1. Request for Quotation M3. Order M4. Order Confirmation MANUFACTURER RETAILER PROVIDER ● Retailer-Manufacturer ● 1. RFQ ● 2. Quote ● 3. Order ● Manufacturer-Supplier ● 1. RFQ ● 2. Quote ● 3. Order ● 4. Order Confirmation ● Retailer-Manufacturer ● 4. Order Confirmation

26 26 © 2005-2006 The ATHENA Consortium. Selling process: Customer-oriented scenario Delivery R5. Delivery Note R6. Packing List R7. Invoice Customer communication R3. Order R1. Request for Quotation R2. Quotation R4. Order Confirmation Interior Decoration Project Looks for furniture Invoice Delivery MANUFACTURER RETAILER

27 27 © 2005-2006 The ATHENA Consortium. Procurement process: Supplier-oriented scenario M2. Quotation M6. Invoice M1. Request for Quotation M3. Order M4. Order Confirmation MANUFACTURER PROVIDER M5. Delivery Note Delivery

28 28 © 2005-2006 The ATHENA Consortium. 5 main problems 1.Repetitive manual process for regular bulk orders –Much of the manufactured products are generic and this involves repeated periodic processing of similar or identical orders 2.Confusion resulting from poor product descriptions –Clients very often order the wrong products! 3.Missing information (both from supplier and buyer!) –Permasa have 3 people employed on the client site and 1 person employed on the supplier side to ensure the integrity of orders and RFQs 4.Lag time from product order to delivery could be shorter. –Shortening time from ordering to receiving raw materials from the supplier has a direct effect on the delivery date of the finished product 5.Time spent rating supplier –Permasa conducts tri-monthly reviews of their suppliers to ensure that standards are kept

29 29 © 2005-2006 The ATHENA Consortium. 5 main expectations 1.Major reduction in false/incorrect orders 2.Dramatic shortening of time from order to delivery 3.Dramatic reduction in surplus stock in warehouse 4.Ability to search new providers and apply Permasa criteria to rate those providers 5.Better integration between internal systems. (i.e. Stock, purchasing, manufacturing, invoicing sub-systems)

30 30 © 2005-2006 The ATHENA Consortium. Possible solution Database (OS400) Sales Mgmt. (ILE) Manufacturing (ILE) Purchasing (ILE) Web Services Layer Customer Order processing Procurement Logistics (ILE) ClientSupplier Design (AutoCAD) Integration Layer

31 31 © 2005-2006 The ATHENA Consortium. Data exchange in e-procurement Retailer FrontEnd System (OMS – Order Management System) Manufacturer FrontEnd System (ERP – Enterprise Resource Planning) Send RFQ Respond RFQ Quotation Approve Quotation Send Order Confirm Order Change Order Send Goods & Delivery Note Return Delivery Note signed Send Invoice Confirm Order Changed

32 32 © 2005-2006 The ATHENA Consortium. Enterprise model: e-procurement process

33 33 © 2005-2006 The ATHENA Consortium. PIM4SOA: Order process

34 34 © 2005-2006 The ATHENA Consortium. PIM4SOA: Services interfaces

35 35 © 2005-2006 The ATHENA Consortium. PIM4SOA: Delivery and invoicing collaborations

36 36 © 2005-2006 The ATHENA Consortium. PIM4SOA: Obtain quotation collaboration

37 37 © 2005-2006 The ATHENA Consortium. PIM4SOA: Furniture procurement collaboration Three roles –“Retailer”, –”Manufacturer” –“Supplier” Two usage of collaboration –“Goods Supply” –“Materials Supply” Relationships between role and collaboration use –“RoleBinding”

38 38 © 2005-2006 The ATHENA Consortium. PIM4SOA: Goods supply collaboration

39 39 © 2005-2006 The ATHENA Consortium. PIM4SOA: Documents and type libraries Documents and type libraries Type library

40 40 © 2005-2006 The ATHENA Consortium. Model of an order document PIM4SOA: Order document

41 41 © 2005-2006 The ATHENA Consortium. Conclusions The PIM4SOA metamodel is a valid tool to decouple the logical solution from its technical implementation. It allows us to derive architectures that later could be implemented in heterogeneous environments. The PIM4SOA could be also used as an intermediate step when we plan to obtain platform assets from an enterprise model. Business expert IT infrastructure GAP CIMPIM PSM

42 42 © 2005-2006 The ATHENA Consortium. References

43 43 © 2005-2006 The ATHENA Consortium. References (ATHENA deliverables) [ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http://www.athena-ip.org/ 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. [ATHENA A6 2005] ATHENA A6, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP, Deliverable D.A6.1, 2005. [ATHENA A6 2006] ATHENA A6, "D.A6.2: Enhanced Registry/Repository Infrastructure", ATHENA IP, Deliverable D.A6.2, 2006. [ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, 2006. [ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, 2006.

44 44 © 2005-2006 The ATHENA Consortium. References (Papers) [Benguria, et al. 2006] G. Benguria, X. Larrucea, B. Elvesæter, T. Neple, A. Beardsmore, and M. Friess, ”A Platform Independent Model for Service Oriented Architectures”, to be presented at the 2nd International Conference on Interoperability of Enterprise Software and Applications (I-ESA 2006), Bordeaux, France, 2006. [Elvesæter, et al. 2005] B. Elvesæter, A. Hahn, A.-J. Berre, and T. Neple, "Towards an Interoperability Framework for Model-Driven Development of Software Systems", in Proc. of the 1st International Conference on Interoperability of Enterprise Software and Applications (INTEROP-ESA 2005), Geneva, Switzerland, 2005. [Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134. [Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B. Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 121-128. [Fischer, et al. 2006] K. Fischer, B. Elvesæter, A.-J. Berre, C. Hahn, C. Madrigal-Mora, and I. Zinnikus, ”Model-Driven Design of Interoperable Agents”, to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 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", to be presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, 2006.

45 45 © 2005-2006 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 rg@uninova.pt. 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.rg@uninova.pt


Download ppt "© 2005-2006 The ATHENA Consortium. 6-2. Model-Driven Development with PIM4SOA,"

Similar presentations


Ads by Google