Lecture #10 (F10) 30 March 2006 Service-oriented architecture (SOA), COMET architecture modelling method, PIM4SOA

Transcription

1 Lecture #10 (F10) 30 March 2006 Service-oriented architecture (SOA), COMET architecture modelling method, PIM4SOA Brian Elvesæter, SINTEF ICT Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) Outline Service-oriented architecture (SOA) SOA and Web service architectures COMET (service) architecture modelling method ATHENA service-oriented interoperability (SOI) framework Rapid prototyping framework for SOA Baseline modelling methodology for SOA Platform independent model for SOA (PIM4SOA) Modelling tools and services Case study AIDIMA e-procurement scenario References Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 2 1

2 Service-Oriented Architecture (SOA) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 3 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 4 2

3 Service-oriented model Service provider: A service provider is the party that provides software applications for specific needs as services. Service providers publish, unpublish and update their services so that they are available on the Internet. Service requester: A requester is the party that has a need that can be fulfilled by a service available on the Internet. A requester could be a human user accessing the service through a desktop or a wireless browser; it could be an application program; or it could be another service. A requester finds the required services via a service broker and binds to services via the service provider. Service broker: A service broker provides a searchable repository of service descriptions where service providers publish their services and service requesters find services and obtain binding information for these services. Examples of service brokers are UDDI (Universal Description, Discovery, and Integration) and XMethods. In many cases the role of the service broker is not explicitly needed. Services can be discovered by marketing channels or by referrals. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 5 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 6 3

4 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 7 From isolated application systems to service-oriented systems SOA (architectural style) Web service (enabling technology) 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, System A System B System C System D Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 8 4

5 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 9 New mode of collaboration Enterprise X Collaboration space Enterprise Y? Composed business services? Shared business model Business services Internal services Enterprise Service Bus Enterprise A Public view Private view Knowledge model Service Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 10 5

6 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? Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 11 COMET (service) architecture modelling method Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 12 6

7 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) tier reference architecture Application Tool User Service Domain Business Service Domain User Interface Tier User Service Tier User Resource Service Tier Business Service Tier Resource Service Tier RA Presentation Tier User Dialog Tier LA LS RA Component Infrastructure Legacy Key Component LA Local Adapter LS Local Storage RA Resource Adapter Database Inter-component communication Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 14 7

8 System boundary model Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 15 Architecture model (1/2) The architecture model describes the overall architecture of the system and its partitioning into components The collaborations of components are described in terms of component interactions, component interfaces and protocols. The architecture model describes two aspects of the system; the static (structure) and dynamic (behaviour). The structural model describes the components, their dependencies, and internal component design the dynamic model describes the component interfaces, interactions and protocols. The architecture model is a platform independent system specification. To keep platform independence there is a need to be able to also specify the data types in a platform independent way. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 16 8

9 Architecture model (2/2) Component Structure and Internal Design describes the static aspect of the system. It includes the overall architecture and the partitioning into components as well as the internal design of the components. Interface and Interaction Specification describes the dynamic aspect of the system. It specifies the interfaces and related protocols as well as defining the interactions between sets of components necessary to provide the required services. The abstract object model provided through an interface are also described PIM data types contains the platform independent data-types used in the architecture model. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 17 Component structure metamodel Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 18 9

10 Survey booking model structure Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 19 Architecture model template in RSM Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 20 10

11 Reference Architecture Analysis Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) Reference architecture analysis Recall the Reference Architecture with associated tiers and component types. Analyse the System Boundary part of the Use Case Model with regards to the Reference Architecture. The System Boundary correspond to the boundaries of the component of concern for the actual project, typically an Application Component. After the identification of this "main" component the next step is to analyze the System Boundary Model with respect to its set of use cases and actors. Divide the System Boundary Model into a set of subsystems. Each subsystem will cover a collection of the System Boundary use cases. The subsystems are non-exclusive, implying that a use case might be part of more than one subsystem. The result of this task is a functional decomposition of the main component, with reiterated versions of the use cases. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 22 11

12 Subsystem grouping Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 23 Component identification BookingEditor BookingViewer SubscriptionEditor Component Infrastructure BookingService SubscriptionService ActivityInfo S ubscriptioninfo Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 24 12

13 Component structure and internal design Use the reference architecture to define components. The following factors might be considered when dividing into components: Functionality and usage Technology. This includes for instance network, component infrastructure, reference architecture, distribution mechanisms, operating system, data storage frameworks and standards that should be followed. Organization. This might be how the development team is organized or how the end users are organized. Distribution. This includes distribution of people, equipment and systems; both at build time (development environment) and run time (end user environment). Use case actors. Grouping of functionality based on the actors of the use cases. Physical nodes. What nodes are available, and where are the locations. Parallel work. How to subdivide to maximize parallel work, this might be during in build time and/or run time. Non-functional requirements such as availability, performance, security, scalability etc. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 25 Application component (AC) structure BookingEditor BookingViewer SubscriptionEditor Browser IBookingService ISubscription POP INotify SubscriptionService SMTP Server BookingService ISubscriptionInfo Existing Service IActivityInfo SubscriptionInfo ActivityInfo Survey Booking AC Subscription Management AC Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 26 13

14 Component model in RSM Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 27 Booking editor tool in RSM Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 28 14

15 Interface and interaction specification Goals Capture and describe component interface and interactions. The behaviours of the architectural elements should be understood and described, i.e. how components collaborate. Methods and techniques Inputs are the Business Model the Requirements Model (including the Reference Architecture Analysis and the work element analysis). In addition the Component Structure and Internal Design defines the component structure and interface dependencies and is obviously an important input to this model. Vice versa the Interface and Interaction Specification is key input to the Component Structure and Internal design as these models forms different viewpoints of the same part of the full model and thus, have to be fully consistent. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 29 Booking editor tool: Component structure Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 30 15

16 Booking editor tool: Business resource analysis Identify the business resources that should be available through the tool by: Examining the use cases for the tool Examining the screenmockups (developed for the prototype) Old GUI Prototype GUI Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 31 Booking editor tool: Business resource analysis result Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 32 16

17 Booking editor tool: User service interface specification IUserService +O PERA T ION _A : integer=1 +startbrowser(in scheduledata:project) +login(in username:string,in password:string,in url:url):loginstatus +exit() +hasaccessrights(in operation:integer):boolean +createschedule(in subregionslist [*] string,in vessellist [*] string,in starttime:date,in endtime:date):project +getusername(in loginstatus:loginstatus):string +isnew(in scheduledata:project):boolean +ism odified(in scheduledata:project) +checkdirectory (In dir:string):string +getschedulebuffernames(): [*] string +getschedulefilenames(): [*] string +getschedulefilenames(in directory:string): [*] string +getschedule(in name:string):project +closeschedule(in scheduledata:project) +getscheduledirectory(in scheduledata:project):string +getschedulefilename(in scheduled ata:project):string +openschedule(in directory:string):project +saveschedule(in directory:string,in filename:string,in steallock:boolean):boolean +importschedule(in schedule:project,in subregionlist [*] string,in vessellist [*] string,in includeownactivities:boolean,in includecompetitoractivities:boolean):exportresult +mergeschedule(in schedule:project,in data:exportresult,in localids [*] string):project +exportschedule(in schedule:project,in localid [*] string,in force:boolean):exportresult +createorgunit(in scheduledata:project,in type:string,in name:string):orgunit +createproject(in scheduledata:project,in type:string,in name:string):project +getcountrylist(): [*] OrgUnit +getregions(): [*] OrgUnit +getcorporationcodes(): [*] OrgUnit +getcompanies(in onlycompetitors:boolean): [*] OrgUnit +getowncompany():orgunit +getallvessels(): [*] OrgU nit +getvessels(in companyname:string): [*] OrgUnit +getvessels(in companynames [*] string): [*] OrgUnit +createpreferences():parameterset +getpreferences():parameterset +savepreferences(in data:parameterset):boolean Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 33 Booking service business service: Component structure IBookingService BookingService ISubscription IActivityInfo INotify Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 34 17

18 Booking service business service: Interface specification IBookingService +username : string +user address : string +importschedule(in subregionlist [*] List(string),In vessellist:list(string),in starttime:date,in endtime:date,in existingglobalids:vector,in companyfilter:companyenum):exportresult +exportschedule(in _scheduleproperties:vector,in _force:boolean):exportresult <<CompositeData>> ExportResult GLOBAL_ID : string LOCAL_ID : string LAST_UPDATED : string scheduleproperties : Vector conflictproperties : Vector Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 35 ATHENA Service-Oriented Interoperability (SOI) Framework Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 36 18

19 Registry Repository Internal Infrastructure Services Legend Business Process/Agent Active (Business) Model Web/Server Component Middleware Process/Agent Middleware Component Service Wrappers (Enterprise X) Service Wrappers (Enterprise Y) Public Infrastructure Services Crossorg. Service Wrappers (Enterprise A) Intraorg. Evaluation & Negotiation of Available Functionality Process Goal-oriented Active Adaptive Composed Execution Execution Model WebService Platform Platform Platform Platform (BPEL) (Agents) (AKMii) (WebServices) Adaptive Distributed Resource Mgt Platform Enhanced Service Interconnection Bus (P2P) Server-side Message- Existing Enterprise Applications Component Oriented Platform Platform (.NET, J2EE) (MQSeries) Rapid prototyping framework for SOA 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 External WSDL Documents WSDL Documents PIM4SOA MDD Framework BDI Teams WSDL Analyzer Lyndon «invoke» Johnson «invoke» Jack Services 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 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 37 Reference Ontology annotated with annotated with Business Requirements Analysis Enterprise Model Model to Model Transformation Service-Oriented Architecture Model Model to Model Transformation Architecture Specification Model Transformation UML Profile for POP* Process Organisation Product UML Profile for SOA Information Service Process QoS annotated with UML Profile for Web Services UML Profile for Agents Web Service Specification Model Agent Specification Model BPEL Specification Model P2P Specification Model UML Profile for BPEL UML Profile for P2P Model to Text Transformation Model Transformation annotated with OWL Ontology Semantic Space Web Service Execution Artefacts ATHENA Integrated Execution Infrastructure Agent Execution Artefacts BPEL Execution Artefacts P2P Execution Artefacts Deployment ATHENA baseline methodology for SOA (overview) 19

20 External Registry Model Registry (A6) Composition Contract Models Models Service Models Evaluation Platform Models Mediation Brokering Composition Internal Service Interconnection Bus Execution Wrappers Reference Ontology annotated with annotated with Enterprise Model 1 1 SOA Model Web Service Model 1 1..* Process View Information View XML Message Organisation View Business Requirements Analysis Service View Service Description Product View Model to Model Transformation Process View Model to Model Transformation Process Execution View QoS View QoS Description UML Profile for POP* Process Organisation Product UML Profile for SOA Information Service Process QoS UML Profile for Web Services XML Message (XSD) Service Description (WSDL) Process Execution (BPEL) QoS OWL Ontology annotated with ATHENA Web Service Execution Infrastructure Web Service Documents Other Company 1..* 1..* OWL-S Document XSD Document Publishing Negotiation Interaction WSDL Document ARES(A3) Model to Text Transformation BPEL Document BrokeringTool (A5) Nehemiah(A2) BDI Plan JACK Service WS-? Document... Service LegacyAplications Method chunks for SOA and Web Service Interoperability ATHENA baseline methodology for SOA (detailed) ATHENA Platform Independent Model for SOA (PIM4SOA) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 40 20

21 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) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 41 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 42 21

22 Metamodel and profile development Understanding of SOA concepts and interoperability issues Initial (interoperability) requirements SOA concepts Partitioning of the metamodel into structures Architectural style for developing interoperable software systems Document the metamodel in RSM (.uml2) and develop it in EMF (.ecore) Feedback Iterative development Modifications according to test and evaluation 4. Feedback Add, remove, and modify concepts 1. Metamodel Scope, concepts, style 3. Test Evaluate in user scenarios 2. UML profile Map metamodel concepts to UML Define how SOA models should be specified using UML Map metamodel concepts to UML types Define UML stereotypes and tagged values Define new visual symbols Define model views Define validation rules Implement UML profile in RSM Evaluate and test UML profile in user scenarios Four ATHENA use cases (pilots) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 43 PIM4SOA platform specific models PIM4SOA Metamodel Symbols PIM Metamodel Concept Relationship Correspondence PSMs Web Services Metamodel Agent Metamodel (AgentMM) P2P Metamodel Grid Metamodel Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 44 22

23 PIM4SOA addresses four system aspects Metamodel for (software) services 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) Metamodel for information Metamodel for (automated software) processes 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) Metamodel for quality of service (QoS) 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) 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) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 45 Metamodel for (software) services Collaboration RoleBinding RoleType Behaviour ServiceProvider ProviderType RegistryItem CollaborationUse EndPoint Collaboration represents a pattern of Relates In An Specify The Represents Registry a abstract service ServiceProviers model interaction an a role model entity element class an oriented service with address between describing for element a to can domain usage the and represent identifying specification have participating an is of and based two end a to service. specifying a are types: point. usage a the of roles RoleTypes messages Abstract of service index its a service turn approach ore services, sequence identified: Executable containing roles within the and requester addressable a constraints serviceand A binary collaboration specifies a the services provider service Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 46 23

24 Metamodel for (automated software) processes Process elements Process aspect Step Scope Process StructuredTask Pin ItemFlow JoinSpecification GuardSpecification Step Scope Implements The Input Defines Provide A composite flow low is or between is a an convergence conditions the output level an single interface links a abstract task building behaviour for node specific between consisting a (e.g. specific for container behaviour blocks a input pins for process, Steps terms a of item or service of for a output when a (tasks collection of type process such Pin two as individual provider, of when etc.) interactions flows contents) Steps making calls provide a the flow a related to as under behavioral Step a another behavior. to a connects decision input set show which to of service a to tasks precise specific steps or A a to an single flow calling a output and Step relationships may subsection decisions an in flow be the external or of service. (Steps) Process associated between Step/Interaction is not require activated linked The output manual with everyday by a from control message intervention one specialization flows Step/Interaction type (Flows), being of Step optionally transported. and input is Task on including another detail on the exchanged messages / items. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 47 Metamodel for information ItemType Role PackageableElement Association Document BusinessTypeLibrary Entity Attribute NameElement Defines is Extracted Represents defines represents extracted imported a the packaging from a set the simple an structure the object of association the elements UML2.0 types: service structure with element string, a specification. between that metamodel. containing of a integer role two manages. and entities. structure some information boolean. types and of composed the application by entities. It is used to describe complex types Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 48 24

25 Metamodel for QoS All NFAOthers Defined Represents in the Non-Functional OMG standard Aspects for for a specifying specific usage quality of a of service. defined in Collaboration and ServiceProvider specification related with CollaborationUse element Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 49 Tools and services (overview) Export + ARIS XML 2 Model POP* Maestro Import / Export UML Profile for SOA CBP Model 2 Model PIM for SOA Information Service Process QoS Model 2 Model Model 2 Text XSD BRMF WSDL BPEL Jack UML* WS-? 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 50 25

26 Eclipse/RSM modelling environment 1. Build your PIM4SOA (.uml2) model in RSM using the UML profile for PIM4SOA and transform it to a PIM4SOA (.ecore) model in EMF. 2. Transform the PIM4SOA (.ecore) model to Web service (.ecore) models. 3. Transform the Web service (.ecore) models to Web service artefacts. 4. Model transformation for UML profiles for Web services Eclipse Modelling Framework (EMF) Rational Software Modeler (RSM) Web service artefacts XSD WSDL M2T 3 EMF Ecore Metamodels/Models PIM4SOA model (. ecore) M2M 2 WS-* models (.ecore) XSD WSDL M2M M2M RSM UML Models and Profiles 1 PIM4SOA model (.uml2) 4 UML profile for PIM4SOA M2M X WS-* model (.uml2) BPEL BPEL UML profile for Web services Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 51 UML extensions for service modelling Stereotype Collaboration CollaborationUse RoleBinding ServiceProvider Role EndPoint Registry RegistryItem Message Item Base Class Collaboration CollaborationUse (sometimes called CollaborationOccurence) Dependency Class Part Property Package Class, Part Operation Parameter Description This element represents the definition of a service. Each service description is viewed as a collaboration between roles A collaboration use represents the usage of a service. This service must to be defined previously. CollaborationUse specification must be encapsulated in a composition structure. This structure is provided by a collaboration definition or by a service provider. This is not a mandatory feature. It is used to connect two roles in the structural part of a class or collaboration This element represent the service provider A role represents a structural part in a collaboration An endpoint represent the address for a service Registry represents a container to know where the services are placed Registry Item is an entity to relate a collaboration and an address The message concept is related with a role through an interface. Item represents the data managed by a role Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 52 26

27 UML extensions for process modelling Stereotype Process Base Class Activity Description A process represents an activity diagram. This activity diagram is contained by a service provider or collaboration Task Structured Activity Node A structured task is related with a collaboration use. This element contains a set of interactions Interaction Interaction, Call behavioraction An interaction represents a reference to a message. It also contains a reference to an input pin or an output pin TagDefinition:JoinSpecification:string Flow ControlFlow This flow relates two interactions. TagDefinition: GuardSpecification:String ColaborationUsePath Dependency This dependency relates a structuredtask (source) with a collaboration use (target). This relationship contains a parameter indicating the order of containment. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 53 UML extensions for information modelling Stereotype Base Class Description <<Document>> Class, Package Assigned to class or package. Indicates root and packaging of a business document information model as a reusable asset. <<BusinessTypeLibrary>> Package Assigned to package. Indicates the business logic <<Entity>> Class Assigned to class. Represents elements used to describe complex types <<TypeLibrary>> Package Assigned to package. Indicates packaging of a reusable type library. Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 54 27

28 RSM and UML profile for PIM4SOA Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 55 Case study: AIDIMA e-procurement scenario Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 56 28

29 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 semifinished 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 57 M1. Request for Quotation M2. Quotation M3. Order M4. Order Confirmation MANUFACTURER Retailer-Manufacturer 1. RFQ 2. Quote 3. Order Manufacturer-Supplier 1. RFQ 2. Quote 3. Order 4. Order Confirmation R1. Request for Quotation R2. Quotation R4. Order Confirmation Interior Decoration Project R3. Order PROVIDER Retailer-Manufacturer 4. Order Confirmation RETAILER 29

30 Selling process: Customer-oriented scenario R1. Request for Quotation R2. Quotation R3. Order R4. Order Confirmation Interior Decoration Project Customer communication Delivery RETAILER Delivery Looks for furniture Invoice MANUFACTURER R5. Delivery Note R6. Packing List R7. Invoice Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 59 Procurement process: Supplier-oriented scenario PROVIDER M2. Quotation M1. Request for Quotation M4. Order Confirmation M3. Order Delivery M5. Delivery Note M6. Invoice MANUFACTURER Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 60 30

31 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 Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 61 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 subsystems) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 62 31

32 Possible solution Client Supplier Customer Order processing Procurement Web Services Layer Integration Layer LogisticsSales Mgmt. Manufacturing Purchasing Design (ILE) (ILE) (ILE) (ILE) (AutoCAD) Database (OS400) Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 63 Data exchange in e-procurement Send RFQ Retailer FrontEnd System (OMS Order Management System) Respond RFQ Quotation Approve Quotation Send Order Confirm Order Change Order Manufacturer FrontEnd System (ERP Enterprise Resource Planning) Confirm Order Changed Send Goods & Delivery Note Return Delivery Note signed Send Invoice Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 64 32

33 Enterprise model: e-procurement process Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 65 PIM4SOA: Order process Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 66 33

34 PIM4SOA: Services interfaces Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 67 PIM4SOA: Delivery and invoicing collaborations Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 68 34

35 PIM4SOA: Obtain quotation collaboration Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 69 PIM4SOA: Furniture procurement collaboration Three roles Retailer, Manufacturer Supplier Two usage of collaboration Goods Supply Materials Supply Relationships between role and collaboration use RoleBinding Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 70 35

36 PIM4SOA: Goods supply collaboration Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 71 PIM4SOA: Documents and type libraries Documents and type libraries Type library Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 72 36

37 PIM4SOA: Order document Model of an order document Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 73 References Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 74 37

38 References (ATHENA deliverables) [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, [ATHENA A6 2005] ATHENA A6, "D.A6.1: Specification of a Basic Architecture Reference Model", ATHENA IP, Deliverable D.A6.1, [ATHENA A6 2006] ATHENA A6, "D.A6.2: Enhanced Registry/Repository Infrastructure", ATHENA IP, Deliverable D.A6.2, [ATHENA A6 2006] ATHENA A6, "D.A6.3: Model-driven and Adaptable Interoperability Framework", ATHENA IP, Deliverable D.A6.3, [ATHENA A6 2006] ATHENA A6, "D.A6.4: Model-driven and Adaptable Interoperability Infrastructure", ATHENA IP, Deliverable D.A6.4, Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 75 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, presented at the 2nd International Conference on Interoperability of Enterprise Software and Applications (I-ESA 2006), Bordeaux, France, [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, [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 [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 [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, presented at the 2nd Workshop on Web Services Interoperability (WSI 2006), Bordeaux, France, [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, Based on material developed in ATHENA (IST ), INTEROP (IST ) and MODELWARE (IST ) 76 38