1 / 27

A Formal Model of Business Application Integration from Web Services (Position Paper)

SOFSEM 2009 Špindlerův Mlýn , Czech Republic. A Formal Model of Business Application Integration from Web Services (Position Paper). Authors: Kaiyu Wan: East China Normal University , Shanghai, China. Mubarak Mohammad Concordia University , Montreal, Canada.

lynton
Download Presentation

A Formal Model of Business Application Integration from Web Services (Position Paper)

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. SOFSEM 2009 ŠpindlerůvMlýn, Czech Republic A Formal Model of Business Application Integration from Web Services(Position Paper) Authors: Kaiyu Wan:East China Normal University, Shanghai, China. Mubarak MohammadConcordia University, Montreal, Canada. VasuAlagar: X’ianJiaotong-Liverpool University, Suzhou, China.

  2. Agenda • Service-Oriented Architecture • Proposal • Abstract Model • Service Creation Fascility Process • Example Wan, Mohammad, and Alagar - SOFSEM 09

  3. Service Oriented Architecture Service Providers SP1 SP2 Business Process Model SP3 Service Consumers (Requesters) SR1 SR2 Business Goal Building software by composing services allows companies to collaborate together to execute business processes. Wan, Mohammad, and Alagar - SOFSEM 09

  4. Challenges How to state user requirements? State user requirements. How to translate user requirements Into service specifications? Find services. How to automatically match User requirements with service profiles? Compose services. How to compose services automatically to provide business transactions? Deliver services. How to ensure that non-functional requirements are preserved in composition? How to ensure that policies are respected? How to ensure that services are trustworthy? Wan, Mohammad, and Alagar - SOFSEM 09

  5. Proposal • An intelligent automation factory: • translate user requirements into service specifications, • match making skills, • compose web services to accomplish the business process requirement, and • maintain non-functional requirements and policies. • Providing formal foundation to support the method. Wan, Mohammad, and Alagar - SOFSEM 09

  6. Abstract Model Service Presentation Layer (SPL) Service Request Layer (SRL) Service Requirements Specification Non-Functional Requirements Constraints And Obligations Service Creation Facility (SCF) Service Composition Generator Service Configuration Generator Optimal Configuration Formal Validation of Configuration Service Delivery (Deployment) Wan, Mohammad, and Alagar - SOFSEM 09

  7. Characteristics of SCF • Autonomy • Task assessment • Service discovery • Service qualification • Candidate selection • Candidate composition • Composition qualification • Optimality • Self monitoring Wan, Mohammad, and Alagar - SOFSEM 09

  8. Service Presentation Layer (SPL) SPL S1 S2 Sn Semantic: Extended-Timed Automata, Ai Syntax for interface type Si is • Fi : I(Si)  O(Si) • where I(Si) is the typed argument list , • and O(Si) is the typed output of the service Fi. Wan, Mohammad, and Alagar - SOFSEM 09

  9. SPL_template S2 S1 • The interface behavior of this SPL instance can be written as: • F1 + F2 • A1 * A2 SPL_instance S23 S11 S12 S13 S21 Wan, Mohammad, and Alagar - SOFSEM 09

  10. Trustworthy Component Type* Functional Contract Structure Data Pre/Post Conditions Architecture Services Timeliness Connector Interfaces Safety Configuration Properties Security Constraints Reliability Availability * Mohammad and Alagar. TADL - An Architecture Description Language for Trustworthy Component-Based Systems. ECSA 2008. Wan, Mohammad, and Alagar - SOFSEM 09

  11. Service Request Layer (SRL) • A service is a functionality to be constrained by certain quality attributes. • Service requests are formalized as requirements. • The request for service should include: • Functionality • Non-functional (quality of service attributes) • Obligations • Policies Wan, Mohammad, and Alagar - SOFSEM 09

  12. Formalizing Service Requests SRL SCF_I1 SCF_I2 SCF_In UML Sequence Diagram First-Order Logic Expressions Non-Functional Requirements Obligations Policies and resource constraints E1 E2 E3 Services Document Types How services interact and document types flow Wan, Mohammad, and Alagar - SOFSEM 09

  13. SCF Process Model SRL Transform UML into Chore Expressions Request Chore Expressions Apply policies and obligations Match Chore Expressions with the services SPL SCF Optimal configuration Candidate services Check non-functional requirements Compose Services and check optimality Trusted services Wan, Mohammad, and Alagar - SOFSEM 09

  14. 1. From Sequence Diagram to Chore Expressions • The sequence diagram consists of entities, message sequences, and data parameters for messages. • We transform: • Messages into tasks (services). • Data parameters are associated with tasks. • Relations among messages into composite operators with tasks as operands. Wan, Mohammad, and Alagar - SOFSEM 09

  15. Chore Expressions • The semantics of a sequence diagram are precisely expressed by the semantics assigned to chore expressions. • Sequential composition: a>>b • After a is completed, its output may be used by b. • Parallel composition:a||b • Simultaneous execution of a and b with no data sharing. • Composition with no order (and): a o b • Conjoined evaluation with no order, order is not important. • It is possible to share data • The result is the set of results produced by the evaluation of a and b • Nondeterministic choice (or): a ∫ b • One of the actions is evaluated nondeterministically. • Priority Construct: a ◊ b • a is evaluated first, and if it can be successfully completed, then b is discarded; otherwise, b should be evaluated (order). • Commit Construct: com(e) • The state changes that happened during the evaluation of expression e are made permanent. Wan, Mohammad, and Alagar - SOFSEM 09

  16. 2. Matching Services with Requests • A chore expression may require investigating more than one sequence of actions against services (e.g., choice or priority operators) • Example: a ∫ (b ◊ c) • Consider both : a ∫ b and a ∫ c • Determine the matching service sequence. • Reject an expression only if its corresponding service sequence does not satisfy the non functional properties. • If both sequences satisfy the stated non-functional properties, then both should be examined for optimality criteria. Wan, Mohammad, and Alagar - SOFSEM 09

  17. 3. Algorithm for constructing Chore service Expressions do 1. Choose an expression f from He do 2. Choose the next action a in f (left to right) do Choose a service provider P in SPL 3. Determine the service interface x in P whose signature matches the arguments and their types in a 4. Substitute the arguments for interface signature parameters and check the satisfaction of precondition of the interface function sa 5. Execute the behavior at the interface 6. If the outcome satisfies the post-condition of the interface function then accept The service sa; replace a by sa in f 7. 8. If any of the previous steps fail then Exit Forever P Forever a 9. Put f in Se Wan, Mohammad, and Alagar - SOFSEM 09 Forever f

  18. We assume that SCF uses an ontology to match user specific task names with the service names at the interfaces. • The SCF passes either the service names or the display name, from the profile of each service, to the SRL. Wan, Mohammad, and Alagar - SOFSEM 09

  19. Service Configuration Templates • Construct a configuration template from a chore expression. Wan, Mohammad, and Alagar - SOFSEM 09

  20. a >> b || c Wan, Mohammad, and Alagar - SOFSEM 09

  21. 4. Checking Optimality • The service configurations that satisfy the contract specification are selected for further processing. • Based upon an optimality criteria, an optimal service configuration can be obtained. • Examples of optimality criteria include: • minimizing the total cost of service delivery • minimizing the execution time • maximizing the reliability of a service configuration. Wan, Mohammad, and Alagar - SOFSEM 09

  22. Example: Travel planning • Book a round trip flight ticket and stay at a four star hotel, rent a car, and make an appointment with a friend at specific place and time. • There are four SPLs, one for each service: • Airline reservation • Hotel booking • Care rental • Appointment arranging. Wan, Mohammad, and Alagar - SOFSEM 09

  23. Sequence Diagram Wan, Mohammad, and Alagar - SOFSEM 09

  24. Airline SPL CF Flight Schedules Current Booking PP PT Pricing Ticketing Booking Center Policies Payment Center PFP PFE PFT SCF Wan, Mohammad, and Alagar - SOFSEM 09

  25. Behavior Specification Wan, Mohammad, and Alagar - SOFSEM 09

  26. Service Configuration ( (t1 >> t2) || (t3 >> t4) || (t5 >> t6) || (t7 >> t8) ) >> t9 || t10 || t11 || t12 Wan, Mohammad, and Alagar - SOFSEM 09

  27. Conclusion • In order that the SCF be trusted, it should accept only the services from a platform that itself is certified to be trustworthy. • We are developing tools and methods to build a framework for the development of trustworthy services for the SPL. • The role of context awareness. Wan, Mohammad, and Alagar - SOFSEM 09

More Related