Experiment on BPM and SOA transformations

1,558 views

Published on

This is a slightly modified version of the slide I, as a student, presented last week at some workshop.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,558
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Experiment on BPM and SOA transformations

  1. 1. “Experimental” transformations between Business Process and SOA models<br />Akira Tanaka<br />view5 LLC<br />http://www.view5.co.jp/e/<br />
  2. 2. Agenda<br />Background<br />Problem statement<br />Example<br />Strategy<br />Modeling and model transformation<br />DSL design, modeling, template design, and model transformation<br />Framework<br />Findings<br />Summary and future work<br />2<br />
  3. 3. Background<br />Two major architectural styles exist in today’s distributed enterprise IT system designs:<br />Business Process-oriented architecture (e.g. using BPMN)<br />Business Service-oriented architecture (e.g. using SOA)<br />Business Rule<br />…..<br />Business Process<br />Business Service<br />Business Event<br />3<br />
  4. 4. Background: Business Process<br />“business process is a defined set of business activities that represent the steps required to achieve a business objective.” (BPMN specification)<br />4<br />
  5. 5. Background: BPM and distributed system<br />BPM related standards<br />BPDM, BPMN, UML, Workflow, IDEF, … and Enterprise Architecture such as FEA, DoDAF/MODAF, TOGAF<br />5<br />
  6. 6. Background: Business Service<br />“A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (SOA Reference Model)<br />Add business context to the services definition above.<br />6<br />
  7. 7. Background: SOA and distributed system<br />SOA related standards<br />SOA-RM, SoaML, SCA, WS-* as implementation standards<br />Service<br />Service<br />Service<br />Service<br />Service<br />7<br />
  8. 8. Background: Process & Service<br />Each one may be implemented using the other. <br />Business Process<br />Business Services<br />use<br />Service A<br />use<br />Step N<br />use<br />execute<br />use<br />Service C<br />Service B<br />use<br />implement<br />Service X<br />Business Process<br />Either style can be used for enterprise IT system development.<br />8<br />
  9. 9. Problem statement<br />Both can be used to build distributed enterprise IT systems, and each can be dependenton the other.<br />Are they essentially the same? If not, how similar/different are they, and where does the difference come from?<br />Should they be used at the same abstraction level? If not, which one should be positioned over the other?<br />Including but not limited to process and service relationship,<br />How can we compare models of different architecture styles?<br />How can we measure the similarity/difference between models of different architecture style?<br />9<br />
  10. 10. Example<br />Buy-Sell-Ship business process and business service<br />E.g. when you buy a book from online book store, or when a company buys office goods from online retailer<br />Notations<br />Business Process in RM-ODP Enterprise Language (extension of UML Activity)<br />Business Service in SoaML<br />10<br />
  11. 11. Process diagram example<br />11<br />
  12. 12. Service diagram example<br />12<br />
  13. 13. The strategy<br />Assumption:<br />if model A (conforming to metamodel MA) is successfully mapped to model B (conforming to metamodel MB), and the model B is successfully mapped back to the model A, then<br />A and B are semantically equivalent, and<br />Mappings can be defined between MA and MB as well.<br />Examine how much:<br />BPM based model can be transformed to a Service based model, and<br />Service based model can be transformed to a BPM model<br />Method:<br />By creating essential models, and<br />By applying model transformation to other type to measure the matching rate<br />13<br />
  14. 14. About MD*<br />Model Driven Engineering<br />is a filed of Software Engineering, where models are considered as important resources in software development processes.<br />MD*: Model Driven<br />engineering (MDE), design (MDD), development (MDD), software development (MDSD), architecture (MDA®), …<br />Popular terms<br />Model(ling), metamodel(ling), domain specific language (DSL), model transformation, model validation, … <br />14<br />
  15. 15. About DSL<br />Domain specific language<br />“a computer programming language of limited expressiveness focused on a particular domain.” (M. Fowler’s Domain Specific Languages book)<br />Could be internal (dependent on hosting programming language) or external<br />Could be graphical or textual<br />15<br />
  16. 16. Modeling and model transformation<br />Modeling<br />As a first step, used domain specific language for the purpose (“ProcessDSL” and “ServiceDSL” based on eclipse/Xtext) [to avoid the complexity UML may introduce at the next step]<br />Model Transformation<br />Used “Model to text (M2T)” rather than “Model to model (M2M)” to get flexibility in model navigation<br />M2M: MOF Query View and Transformation, ATL. …<br />M2T: Xpand, JET,MOF M2T, …<br />Used Xpand/Xtend template language/engine, a part of eclipse/Xtext<br />16<br />
  17. 17. The work flow<br />Domain Specific Language development<br />Created a grammar for each domain (process modeling and service modeling)<br />Modeling with generated DSL model editor<br />Generated a textual editor for model development<br />Created models that reflects sample process and sample services<br />Template development<br />Created “process->service” and “service->process” model transformation templates<br />Executed model transformations<br />Generated text or model for evaluation<br />17<br />
  18. 18. Domain Specific Language design<br />*partial grammar<br />18<br />
  19. 19. Modeling with model editor<br />19<br />
  20. 20. Template design<br />Import generated process metamodel<br />Create output file<br />Create service interfaces from crossing lane actions<br />Create participants from non-artifact lanes<br />Create messages from artifact lane<br />Create contracts from consumer and provider<br />20<br />
  21. 21. Generated text from the process<br />This text conforms to ServiceDSL<br />21<br />
  22. 22. Domain Specific Language design<br />22<br />
  23. 23. Modeling with model editor<br />23<br />
  24. 24. Template design<br />Import generated service metamodel<br />Create output file<br />Create process from SOA collaboration<br />Create role from SOA participant<br />Create step Request and Receive from messages<br />Create artifact roles from messages<br />24<br />
  25. 25. Generated text from the service<br />This text conforms to ProcessDSL<br />25<br />
  26. 26. Model transformation framework<br />Textual<br />representation<br />26<br />Source code, XML, text, …<br />
  27. 27. Results overview<br />Model Transformation<br />Sample ProcessDSL based Model<br />& lines of text<br />Generated ServiceDSL based Model<br />& lines of text<br />Compare<br />Sample ServiceDSL based Model<br />& lines of text<br />Generated ProcessDSL based Model<br />& lines of text<br />27<br />
  28. 28. 28<br />
  29. 29. Sample ProcessDSL based Model<br />227<br />Generated ServiceDSL based Model<br />88<br />38.7%<br />17.6%(~9%)<br />Compare<br />70.4%(~35%)<br />Sample ServiceDSL based Model<br />125<br />Generated ProcessDSL based Model<br />40<br />32%<br />29<br />
  30. 30. Findings<br />Something internal to a specific lane in a process will be lost when transforming process to service, and theywill not be generated from a set of services when transforming service to process.<br />Orchestration of all the participants in process model will be lost when transforming process to service, and they will not be re-created from service models when transforming service to process.<br />30<br />
  31. 31. Findings<br />Abstraction levels/target audience do not match completely.<br />Process models are at end users or business analysts level.<br />Service models further include software architects or developers perspective (e.g. service interface definitions).<br />If required, placing process model over service model will work better than the other way.<br />Model Transformation<br />Model transformation is not always possible.<br />Published cases are successful cases.<br />Even with unsuccessful cases, model transformation works as a tool for measuring how close two models are.<br />31<br />
  32. 32. Findings<br />Model Comparison<br />DSL for software architecturecan be used as a tool to create architecture based models.<br />Model transformations can be applied to compare models. <br />Two way model transformation could be a means to analyze the similarities of the two models. <br />Matching rate of “process to service” transformation is higher than “service to process” transformation.<br />Tooling<br />Open source Eclipse/Xtext is good enough tool for the experiment.<br />M2T transformation can be used to generate other DSL based model.<br />32<br />
  33. 33. Problem statement (again)<br />Both can be used to build distributed enterprise IT systems, and each can be dependenton the other.<br />Are they essentially the same? If not, how similar/different are they, and where does the difference come from?<br />Should they be used at the same abstraction level? If not, which one should be positioned over the other?<br />Including but not limited to process and service relationship,<br />How can we compare models of different architecture styles?<br />How can we measure the similarity/difference between models of different architecture style?<br />33<br />
  34. 34. Summary<br />Process-oriented and service-oriented architectures have some commonality but with different focused area. [i.e. not exactly the same]<br />Similarities and differences<br />Generated service model / hand-written service model = 70.4% (max)<br />Generated process model / hand-written process model = 17.6% (max)<br />Differences: internal activities, orchestration, service interface etc.<br />Process-oriented model should better be positioned over service-oriented model if both need to coexist.<br />This method can be used to compare architectures, and matching rate can be used as a metrics for comparison.<br />34<br />
  35. 35. Future Works<br />Mechanisms <br />to verify essential DSLs<br />to generate DSLs from UML models<br />to measure model transformability<br />to make currently lost internal information in a lane visible (by e.g. introducing local controller?)<br />to introduce orchestration into service architecture (as annotation?)<br />More experiments<br />use ODP model, including computation model, as a source process-based model<br />use M2M to improve formality/transformability of the method<br />35<br />
  36. 36. Questions?<br />Note<br /><ul><li>ProcessDSL and ServiceDSL with sample models are available on the web (http://sites.google.com/site/xtextusersjapan/files).</li></ul>36<br />
  37. 37. Backups<br />37<br />
  38. 38. Service vs. generated service<br />…<br />Example piece<br />Created with ServiceDSL editor (by hand)<br />Generated from ProcessDSL model<br />…<br />38<br />
  39. 39. Process vs. generated process<br />Example piece<br />Created with ProcessDSL editor (by hand)<br />…<br />…<br />…<br />Generated from ServiceDSL model<br />39<br />

×