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
SP1
Service Providers
SP2
Business Process
Model
SP3
Service Consumers (Requesters)
SR1
Business Goal
SR2
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.
How to translate user requirements
Into service specifications?
How to automatically match
User requirements with service
profiles?
Find services.
Compose services.
Deliver services.
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
S1
S2
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
S1
S2
The interface behavior of this SPL
instance can be written as:
F1 + F 2
A1 * A 2
SPL_instance
S11 S12 S13
S21
S23
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_I1
UML Sequence
Diagram
E1
E2 E3
SCF_I2
SCF_In
First-Order Logic
Expressions
Non-Functional Requirements
Obligations
Policies and resource constraints
Services
Document Types
How services interact and
document types flowWan, Mohammad, and Alagar - SOFSEM 09
12
SCF Process Model
SRL
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
Ticketing
Policies
Booking
Center
PFP
PFE
PT
Payment Center
PFT
SCF
Wan, Mohammad, and Alagar - SOFSEM 09
27
Behavior Specification
Wan, Mohammad, and Alagar - SOFSEM 09
28
Service Configuration
( (t1 >> t2) || (t3 >> t4) || (t5 >> t6) || (t7 >> t8) ) >> t9 || t10 || t11 || t12
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