SOFSEM 2009 pindlerv Mln Czech Republic A Formal

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. Vasu Alagar: X’ian Jiaotong-Liverpool University, Suzhou, China.

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

Service Oriented Architecture SP 1 Business Process Model Service Providers SP 2 SP 3 Service Consumers (Requesters) SR 1 Business Goal SR 2 Building software by composing services allows companies to collaborate together to execute business processes. Wan, Mohammad, and Alagar - SOFSEM 09 3

Challenges How to state user requirements? State user requirements. Find services. Compose services. Deliver services. How to translate user requirements Into service specifications? How to automatically match User requirements with service profiles? How to compose services automatically to provide business transactions? 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 4

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 5

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

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 7

Service Presentation Layer (SPL) SPL S 1 S 2 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. Sn Semantic: Extended-Timed Automata, Ai Wan, Mohammad, and Alagar - SOFSEM 09 8

SPL_template S 1 S 2 The interface behavior of this SPL instance can be written as: F 1 + F 2 A 1 * A 2 SPL_instance S 11 S 12 S 13 S 21 S 23 Wan, Mohammad, and Alagar - SOFSEM 09 9

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 10

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 11

Formalizing Service Requests SRL SCF_I 1 UML Sequence Diagram E 1 E 2 E 3 SCF_I 2 SCF_In First-Order Logic Expressions Non-Functional Requirements Obligations Policies and resource constraints Services Document Types How services interact and document types flow. Wan, Mohammad, and Alagar - SOFSEM 09 12

SRL SCF Process Model Transform UML into Chore Expressions Request Apply policies and obligations SCF Chore Expressions Match Chore Expressions with the services Optimal configuration Candidate services Compose Services and check optimality Check nonfunctional requirements Trusted services Wan, Mohammad, and Alagar - SOFSEM 09 SPL 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. 2. 3. Choose an expression f from He do Choose the next action a in f (left to right) do Choose a service provider P in SPL 4. Determine the service interface x in P whose signature matches the arguments and their types in a 5. Substitute the arguments for interface signature parameters and check the satisfaction of precondition of the interface function sa 6. Execute the behavior at the interface 7. If the outcome satisfies the post-condition of the interface function then accept The service sa; replace a by sa in f 8. If any of the previous steps fail then Exit Forever P Forever a 9. Put f in Se Forever f Wan, Mohammad, and Alagar - SOFSEM 09 19

• 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 20

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

• a >> b || c Wan, Mohammad, and Alagar - SOFSEM 09 22

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 24

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 25

Sequence Diagram Wan, Mohammad, and Alagar - SOFSEM 09 26

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

Behavior Specification Wan, Mohammad, and Alagar - SOFSEM 09 28

Service Configuration ( (t 1 >> t 2) || (t 3 >> t 4) || (t 5 >> t 6) || (t 7 >> t 8) ) >> t 9 || t 10 || t 11 || t 12 Wan, Mohammad, and Alagar - SOFSEM 09 29

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 30