1 / 38

From art to engineering: CDL and interaction oriented design

7th February 2008 Steve Ross-Talbot Chair ∏ 4 Technologies Foundation CTO Hattrick Software Ltd Co-Chair W3C Web Services Choreography WG Thanks to Pi4 Technologies Foundation Ltd ( http://www.pi4.org ) Hattrick Software Ltd ( www.hattricksoftware.com )

akiva
Télécharger la présentation

From art to engineering: CDL and interaction oriented design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 7th February 2008 Steve Ross-Talbot Chair ∏4 Technologies Foundation CTO Hattrick Software Ltd Co-Chair W3C Web Services Choreography WG Thanks to Pi4 Technologies Foundation Ltd (http://www.pi4.org) Hattrick Software Ltd (www.hattricksoftware.com) World Wide Web Consortium (Choreography Working Group) From art to engineering:CDL and interaction oriented design

  2. “As soon as we started programming, we found out to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs”. Maurice Wilkes, 1949Can I reduce debugging time? Motivation

  3. From Art to Engineering Example Challenge What we need Solution “The hardest single part of building a software system is deciding precisely what to build”. Frederick P. Brooks

  4. An Example • A sort of auction • List of roles (behaviors or actors) • Sender/Seller, Receiver/Bidder, Broker/Auctioneer • A set of scenarios (sequence diagrams) • A set of example messages

  5. Roles

  6. Scenarios …

  7. Scenarios …

  8. Messages … <hw:HelloWorld xmlns:hw="http://www.hattricksoftware.com/helloworldloop"> <hw:id> 99 </hw:id> <hw:message> Hello world </hw:message> <hw:value> 105 </hw:value> <hw:provenence> Sender </hw:provenence> </hw:HelloWorld> Hello World

  9. Messages … <hw:Acknowledgement xmlns:hw="http://www.hattricksoftware.com/helloworldloop"> <hw:HelloWorld> <hw:id> 99 </hw:id> <hw:message> Hello world </hw:message> <hw:value> 105 </hw:value> <hw:provenence> Receiver, Broker </hw:provenence> </hw:HelloWorld> </hw:Acknowledgement> Acknowledgement

  10. Messages … <hw:Update xmlns:hw="http://www.hattricksoftware.com/helloworldloop"> <hw:HelloWorld> <hw:id> 99 </hw:id> <hw:message> Hello world </hw:message> <hw:value> 105 </hw:value> <hw:provenence> Receiver, Broker </hw:provenence> </hw:HelloWorld> </hw:Update> Update

  11. Messages … <hw:Error xmlns:hw="http://www.hattricksoftware.com/helloworldloop"> <hw:HelloWorld> <hw:id> 99 </hw:id> <hw:message> Hello world </hw:message> <hw:value> 105 </hw:value> <hw:provenence> Receiver, Broker </hw:provenence> </hw:HelloWorld> </hw:Error> Error

  12. Challenge • Do you feel lucky enough to build the system based on the information given? • What is missing that you would like to have? • There are no identities so tracking transactions across services is impossible. • There is no unambiguous description of the overall behavior of the system (just scenarios), so no code generation.

  13. Challenge • So do (you feel lucky)?

  14. Challenge • Create some UML models for the static data part. • Create some UML state charts for the dynamic part. • Hope the the state machines are compatible. • Test to make sure and iterate until you think it works correctly. • More art than engineering.

  15. What we need • Strong description to model the overall behavior • Strong notion of identity • Model that can be tested against requirements (messages, scenarios) • Model against which we can generate code (to ensure compatible behaviour) • Model that can be used to check runtime behaviour for conformance. • Methodology to link requirements to models to runtimes and tools to support it.

  16. Methodology

  17. Static: Example business message, Example FpML Iterative process to encode examples Meet and agree that use case example represent requirements Dynamic: Example exchange of messages Methodology Meet and gather requirements

  18. Validate Using use case example EA encodes static and dynamic models and validates them against use case examples BA hands off to Enterprise Architect Validate Meet and agree models meet requirements Methodology

  19. DBMS Schema Generate Unit test input for message instances Uses Enterprise Architect generates XML Schema Generate Implementer adds business logic Unit test message sequences for services Java code Executable services Methodology

  20. Monitor against the dynamic model Methodology Executable services Executable services

  21. no gaps Tools • Define Requirements • Roles • Create Messages • Create Scenarios • Describe Models • Validate Models against requirements • Stimulate models (internal and distributed) • Generatethe service state machines against models • Monitor the system against model • www.p4.org SOA Tool Suite (DEMO)

  22. Roles

  23. Scenarios

  24. Messages <hw:HelloWorld xmlns:hw="http://www.hattricksoftware.com/helloworldloop"> <hw:id> 99 </hw:id> <hw:message> Hello world </hw:message> <hw:value> 105 </hw:value> <hw:provenence> Sender </hw:provenence> </hw:HelloWorld> Hello World

  25. Modeling

  26. Modeling • Sequence : Main Flow • Interaction Send2Broker : sendMessage request of type (hw:HelloWorld) • from role SenderRole to BrokerRole over the brokerChannel channel • Choice • Sequence : Ok • Interaction Broker2Receiver : sendMessage request of type (hw:HelloWorld) • from role BrokerRole to ReceiverRole over the receiverChannel channel • Assign : set finished to cdl:getVariable('helloWorldMessage', '', • '/hw:HelloWorld/hw:value/text()','ReceiverRole') < 100 • Whilefinished is false • Interaction Receiver2BrokerUpdate : sendMessage notification of type (hw:Update) • from role ReceiverRole to BrokerRole over the receiverChannel channel • Interaction Broker2ReceiverUpdate : sendMessage request of type (hw:Update) • from role BrokerRole to ReceiverRole over the receiverChannel channel • Assign : set finished to cdl:getVariable('updateMessage', '', • '/hw:Update/hw:HelloWorld/hw:value/text()','ReceiverRole') < 100 • Interaction Receiver2Broker : sendMessage notification of type (hw:Acknowledgement) • from role ReceiverRole to BrokerRole over the receiverChannel channel • Interaction Broker2Sender : sendMessage response of type (hw:Acknowledgement) • from role BrokerRole to SenderRole over the brokerChannel channel • Sequence : NotOk • Interaction Broker2Sender : sendMessage response of type (hw:Error) • from role BrokerRole to SenderRole over the brokerChannel channel

  27. Validation

  28. Generation

  29. Generation

  30. Monitoring

  31. Monitoring

  32. Monitoring

  33. Monitoring

  34. Monitoring

  35. Monitoring

  36. From art to engineering • Requirements correctly captured • Requirements validate models • Models ensure structure of generation • Models ensure identification of existing services to re-use • Models ensure runtime validation • More engineering than art

  37. Q&A

More Related