Model-Driven Deployment of Services to Standards Compliant Reliable Middleware

1. Model-DrivenDeployment of Services to Standards Compliant Reliable Middleware Dániel Varró(varro@mit.bme.hu) in collaboration with László Gönczy, János Ávéd, András Kövi Budapest Univ. of Technology and Economics Research supported by SENSORIA EU FET-IST project and HIDENETS European STREP

2. Conversation • Daniel: Good afternoon. My good old service got broken yesterday so I am afraid I need a new service. • Shopkeeper: Oh, we have a brand new collection of services. What kind of service do you need? • Daniel: Well, in fact I don’t care what the service actually does, only the quality of service that counts for me. It should not break that easily as the old one. • Shopkeeper: What about this? WS-Security. It is a standard solution, a real bargain. • Daniel: No, thanks, our dog provides quite good security. Noone ever tried to tamper with our services. What else can you offer? Dániel Varró, Dagstuhl, February 6th, 2007

3. Conversation (ctd.) • Shopkeeper: I think I have found something for you. WS-ReliableMessaging! Standard quality! • Daniel: Hmm, I have never heard of this. What does this service do for me? • Shopkeeper: It assures quality of service in an unreliable transport environment. • Daniel: Does that mean that I will get a compensation if my service is broken again? • Shopkeeper: No. But it guarantees that your messages will finally arrive to the receiver, and in the exact order you sent them. • Daniel: Hmm, sounds quite handy. Do you have something similar? • Shopkeeper: Well, there is WS-Reliability, and the new WS-ReliableExchange. The producer is OASIS, you must have heard about it. • Daniel: And if my service needs to be available for me all the time? • Shopkeeper: In this case, I would probably recommend AIS services from SA-Forum. They are really specialized in highly available services. Dániel Varró, Dagstuhl, February 6th, 2007

4. Conversation (ctd.) • Daniel: Are these services compatible with each other? I mean, if I finally manage to configure one of them, can I use the same configuration for the others? • Shopkeeper: Well, the configuration parameters are quite similar, so if you managed to do it once, it should not be difficult for an alternate service provider. But you see, as they are different services, they have to be different, otherwise they cannot be sold . • Daniel: And do I need anything special to run my service? • Shopkeeper: You need a dedicated middleware to run a high-quality service, which has a special software architecture. You cannot just run some more tests to guarantee quality of service. Reliability starts with architecture. • Daniel: And, I guess, there are different vendors of middleware with slight incompatibilities between each of them. • Shopkeeper: You are quite right. Dániel Varró, Dagstuhl, February 6th, 2007

5. Conversation: Conclusion • Daniel: Let me just briefly summarize • There are many standards for reliable services • Each standard contains similar configuration parameters selected ad hoc • Each middleware implements the standard differently • My hardly designed service configurations are not portable for different reliable services • HOW CAN I EFFICIENTLY DESIGN AND DEPLOY RELIABLE SERVICE CONFIGURATIONS? Dániel Varró, Dagstuhl, February 6th, 2007

6. Non-functional aspects of Web services • Assure QoS over unreliable transport layers (pl. Policy, Security, Transaction, Reliable Messaging …) • Messaging semantics (AtLeastOnce, InOrder, …) • Standards for Reliable Messaging: • WS-Reliability (RM4GS) • WS-Reliable Messaging (RAMP) WS-Reliable Exchange (WS-RX) • Communication middleware implemented in application servers Dániel Varró, Dagstuhl, February 6th, 2007

7. Parameters of Reliable Messaging • Based on SOA standards • Message Delivery • AtLeastOnce, AtMostOnce, ExactlyOnce • Sequence Ordering • Number of Retransmissions • Quantitative parameters • Expiration time of messages • Retransmission interval (frequency) • Parameters of SOA primitives (Invisible for business users) Dániel Varró, Dagstuhl, February 6th, 2007

8. Our approach • Model-driven approach • Precise modeling of service configurations • Transformation to designated (standard-compliant) middleware • Adaptable to changing standards • Enables the automatic generation of • Deployment configuration (for IBM RAMP) • Service descriptors (WSDL) • (Ontological description - OWL) • By Model Transformations (in VIATRA2) Dániel Varró, Dagstuhl, February 6th, 2007

9. Vendor-Specific Approach Vendor-specific tool WS-RelMsg Platform Editing RAMPConfiguration Dániel Varró, Dagstuhl, February 6th, 2007

10. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM Dániel Varró, Dagstuhl, February 6th, 2007

11. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM Dániel Varró, Dagstuhl, February 6th, 2007

12. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Computation Independent Model (CIM) • Requirements for deployment • Target QoS parameters Dániel Varró, Dagstuhl, February 6th, 2007

13. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Platform Independent Model (PIM) • Compliant with the WS-RelMsg* standard • Independent from the deployment platform Dániel Varró, Dagstuhl, February 6th, 2007

14. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Metamodel of • Service configurations • Reliability concepts Dániel Varró, Dagstuhl, February 6th, 2007

15. Core SOA metamodel (prev. work) Dániel Varró, Dagstuhl, February 6th, 2007

16. Port (Core) Message (from Core) Acknowledgement type Reliable Messaging Extensions RelMsgEnvelope runtimeValue providerSpec wraps RelMsgSpecification needsAck. filterDuplicates maxNumberOfRetrans. timeout describes clientSpec ackOf contentOf propOf runtimeOf ReliabilityProperty numberOfRetrans. elapsedTime success Dániel Varró, Dagstuhl, February 6th, 2007

17. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Model Validation • Is the configuration compliant with the standard? • Well-formedness of the model? Dániel Varró, Dagstuhl, February 6th, 2007

18. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Platform Specific Model (PSM) • Specific to the target deployment platform (e.g RAMP) • Restrictions / Enrichments vs. the standard Dániel Varró, Dagstuhl, February 6th, 2007

19. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • PIM2PSM mappings: • Model transformations • VIATRA2 framework @ www.eclipse.org/gmt Dániel Varró, Dagstuhl, February 6th, 2007

20. Model-driven development of service configs Modeling Tool Layer Vendor-specific tool Model Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Automatic config generation: • Model transformation (VIATRA2) Dániel Varró, Dagstuhl, February 6th, 2007

21. Modeling Front-End Modeling Tool Layer Vendor-specific tool Domain-specific editor UML Profile (IBM RSA) Core Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Domain-specific editor: • SRML-P, SRML-F? • SCA? UML Profile:Develop WSRel configs in a UML tool Dániel Varró, Dagstuhl, February 6th, 2007

22. Service configuration in UML Dániel Varró, Dagstuhl, February 6th, 2007

23. Model Analysis Modeling Tool Layer Vendor-specific tool Domain-specific editor UML Profile (IBM RSA) Core Layer WS-RelMsg Platform PlatformDescription Repository RAMPConfiguration CIM PIM PSM • Model Analysis: • Predict QoS (perform., avail.) Analysis SW Analysis model Dániel Varró, Dagstuhl, February 6th, 2007

24. Alternate instantiation: AIS (SA-Forum) Modeling Tool Layer Vendor-specific tool Domain-specific editor UML Profile (IBM RSA) Core Layer AIS Platform PlatformDescription Repository AMFConfiguration CIM PIM PSM Analysis SW Stochastic PN Dániel Varró, Dagstuhl, February 6th, 2007

25. Model-driven deployment by VIATRA2 Dániel Varró, Dagstuhl, February 6th, 2007

26. Model-driven deployment by VIATRA2 MDA PIM model MDA PSM model Dániel Varró, Dagstuhl, February 6th, 2007

27. MM MM MM MM Model-driven deployment (VIATRA2) Dániel Varró, Dagstuhl, February 6th, 2007

28. M2M M2T M2T M2M M2M M2T Model-driven deployment (VIATRA2) Dániel Varró, Dagstuhl, February 6th, 2007

29. SOA models in a VIATRA2 Dániel Varró, Dagstuhl, February 6th, 2007

30. Conclusions • Method for model driven deployment/development • Code generation • Deployment configuration • Service descriptors • Ontological description Dániel Varró, Dagstuhl, February 6th, 2007

31. Further work • WS-RX support? • Support for processing visual models • Extend the UML import  • Implement a Domain Specific Editor – Eclipse GEF) • Extending SOA descriptions • new „WS-* compliant” metamodels • Such as WS-Security, etc. • New deployment transformations • To other middleware • Testing the ontologies for large-scale models • Extending the approach • Combination of BPEL+WS-* descriptions Dániel Varró, Dagstuhl, February 6th, 2007