Service Chart Diagrams - Description & Application
School of Computer Science & Engineering
The University of New South Wales
Sydney NSW 2052, Australia
College of Information Systems
P.O. Box 19282, Dubai, U.A.E
H.4.5Information Systemsservice-oriented applications. Modeling, Diagrams. state, service, diagram, conversation.
With the rapid development of information and communication technologies,
users are becoming more and more demanding on businesses to provide them
with relevant and up-to-date information. Furthermore, needs of users continue
to grow and change becoming overtime more complex to satisfy. Needs vary
from basic ones such as weather forecast of city X, to complex ones
such as stock quotation of business Y and its direct competitors since
last fall. This situation appeals for advanced approaches and tools to support
software designers and developers in their work. Service-driven applications
are deemed appropriate to deal with the aforementioned situations [4,15]. The following example motivates
the importance of service-driven applications. Paul is planning for his
vacation; (i) he wants to book a domestic flight and an accommodation;
(ii) he, also, wants to find some attractions for visit; (iii) he
would like to rent a car if the location of the major attraction is far from
the location of the booked accommodation. To handle Paul's request, the
collaboration of multiple services1
is required. These services are: flight reservation, hotel booking, attraction
search, and car rental. All the services have to be connected according to
a specific flow of control. First, flight reservation is completed. Then,
hotel booking and attraction searching are triggered concurrently. Each business
being involved in the vacation scenario provides its services that may have
to collaborate with other services if needed and vice-versa. Rather
than just being invoked through their application programming interfaces,
we advocate that services should be given the opportunity to engage conversations
if they wish. There is an increasing trend towards run-time composition,
where services choose dynamically with whom they would like to trade. The
composition of services from multiple origins calls for new design approaches
and representation formalisms. This is motivated by the following elements:
- Distribution: businesses that provide services are most of the time spread across multiple locations. These businesses have to get together in order to be aware of their respective capabilities and constraints.
- Heterogeneity: services are developed independently from each other with diverse technologies. It is agreed that programmers who implement services are unlikely to collaborate with each other during development.
- Autonomy: services carry out operations without considering the operations of other services. Services are considered as self-contained components.
Regardless of its type (E-service or M-service), a Web service is a set
of ordered operations to perform according to certain inputs. The order
can be sequential or concurrent. Samples of Web services are currency conversion
and cinema ticket purchasing. Potential users have to know how to request
a service for execution. However, users do not have to know neither how
to operate the service nor how the service operates or is operated.  distinguishes between
two types of services: E-services and M-services (M for Mobile).
In this paper, a composite services consists of several component services
whether composite services or services. Multiple technologies are associated
with the success of Web services: WSDL, UDDI, and SOAP. These technologies
aim at supporting the definition of Web services, their advertisement, and
their binding for triggering purposes .
a. E-servicesAn E-service is a component that an organization provides in order to be assembled and re-used in a distributed, Internet-based environment. A component is an E-service if it is : 1) independent as much as possible from specific platforms and computing paradigms; 2) developed mainly for inter-organizational situations rather than for intra-organizational situations; and 3) easily composable, its assembling with other E-services does not require the development of complex adapters.
b. M-servicesTwo definitions are associated with an M-service. The "weak" definition is to trigger remotely an E-service from a mobile device for execution. In that case, the E-service is an M-service. The "strong" definition is to transfer wirelessly an E-service from its hosting site to a mobile device where its execution takes place. In that case, the E-service is an M-service that meets the following requirements : 1) transportable through wireless networks; 2) composable with other M-services; 3) adaptable according to the computing features of mobile devices; and finally 4) runnable on mobile devices. In this paper, we focus on the M-services that comply with the "strong" definition. Figure 1 illustrates a snapshot of a mobile service running on a cell-phone. The service provides information to tourists visiting Dubai. Upon request of tourists, the service is downloaded to their mobile devices.
c. E-services vs. M-servicesThe difference between an E-service and M-service occurs at two levels. The first level concerns the communication channel, i.e., wired vs. wireless. The second level concerns the location of where the processing of the service occurs: server side on a fixed platform for an E-service vs. user side on a mobile platform for an M-service.
Description of service chart diagrams
RationaleThe current requirements of designing applications call for new representation formalisms and design approaches. Designers are faced with multiple obstacles that need to be dealt with quickly and efficiently. An example of these challenges consists of maintaining the coherence of the content of a database of an e-commerce site. Thousands of customers from over the world may initiate at the same time multiple purchase requests for the same product but with different selection criteria. This scenario puts forward new demands not only on support and delivery information technology, but also on the way business processes have to be designed, developed, and maintained. Another example of challenges that face designers consists of dealing with the issues and obstacles of mobile applications. Designers and programmers are put on the front line of satisfying the promise of businesses and service providers of delivering Internet content to users of mobile devices. Service-driven applications seem to be one of the relevant technologies that could help in addressing the aforementioned challenges and obstacles. Services, rather than code, are emerging as the key artifacts of software design and development, raising therefore the level of abstraction. Service chart diagrams are among the pillars on top of which the trend of service-driven applications can be built. Services in such diagrams are not only invoked for their operations but rather asked to establish conversations before joining any service composition process.
Concepts & FormalismsA service-driven application is a process that connects multiple services. The connection is an outcome of the conversations that take place between services. Different parameters are included in those conversations, e.g., workload and location of a service. Having several services enables the consideration of multiple businesses that offer those services. Quality and execution cost of a service are among the selection criteria that affect the shape of any composite service in terms of number of services to be considered and execution chronology of these services. Service chart diagrams are based on UML state chart diagrams. This time, the emphasize is on the context surrounding the execution of a service rather than on the states that a service takes. Services are represented from five perspectives. Besides the state perspective that includes the states of a service (see Section 2), the flow perspective corresponds to the execution chronology of the connected services. Here, the flow is conversation-based. The organization perspective identifies the business that supplies a service. The information perspective identifies the data that are exchanged between services. These data are identified during conversations and packaged into XML documents. A service that completes its execution may have to leave certain data to the next services that are due for execution, so they could resume pending operations. Finally, the location perspective identifies the current site of a service. A service can be in one of the two sites: 1) business site waiting to be selected and inserted into a composite service; or 2) execution site under performance. According to Section 3, an execution site corresponds to a business site for an E-service or client site for an M-service. A service chart diagram enhances a state chart diagram with details obtained from the various perspectives of Figure 2. Therefore, the service chart diagram of a composite service consists of connecting the service chart diagrams of all the services that constitute that composite service. Table 1 summarizes the three layers that constitute a service chart diagram. Interesting is layer 2 which contains the states that a service takes. These states constitute themselves a state chart diagram that is wrapped in the different perspectives. It should be noted that the states of layer 2 integrate both normal and ad-hoc operating of a service. Ad-hoc operating corresponds to the exceptional cases that may occur, e.g., execution failure. Thus, back-up states and also, extra services can be requested to deal with the exceptional cases.
|3||Data from previous services
Data for next services
In Table 1, next services field represents the list of services that are due for execution after a service completes its execution. This list is an expression that combines services over logical operators (AND, OR). For instance, services that are connected with an AND operator have to be triggered in a concurrent way. A similar description applies to OR operator. Each service that appears in next services field is also annotated with the following elements:
- The protocol that enables the invocation of the service. SOAP
over HTTP is among the protocols that can be used .
- The conditions to check before the service is invoked. The elements of a condition are obtained from the states of the service that is under execution.
Application of service chart diagramsIn Section 1, the vacation of Paul motivated our discussions on the importance of new design approaches. We pointed out that 4 services were required to handle Paul's request. Figure 3 is a sample of travel planning composite service that will be used in the rest of this paper. In addition to these services, 2 new services are added: driving time calculation that checks the distance between the location of the hotel and the location of the main attraction, and user notification that provides responses to user.
According to the location perspective, a service (i.e., an instance)
can be in one of the following two sites: business site or execution site.
Both types of site influence the content (in term of states) and shape (in
term of chronology) of a service chart diagram. In what follows, the conceptual
description of the service chart diagram of Figure 2 is applied according to the features
of each site. Flight reservation service of Figure 3 is used for illustration purposes.
service takes stand by state waiting, first to be selected among multiple
services by the composition process and then, connected to other services.
Figure 4 is the service chart
diagram of the service in business site. In this diagram, certain fields
of Table 2 (e.g., business, next services,
and site) are filled with values. In addition, stand by, preparation, and
transfer are the states that the service takes. Different activities are
undertaken within each state. Transfer state only applies to M-services.
Indeed, the execution of M-services takes place in a different site to the
business site. Flight reservation service is followed by two services: hotel
booking and attraction searching. Both services are triggered in case a flight
reservation is confirmed.
Service chart diagrams vs. Sites
|Next services||(Reservation(?).Hotel Booking)
|Business||Business (offers the service)|
|States||Stand by, Preparation, /Transfer|
|Data from previous services||null|
|Data for next services||?Destination_city, ?Departure_date,?Return_date|
|Site||Site (where the service is located now)|
service is due for execution. This execution occurs either in the business site for an E-service or client site for an M-service. Figure 5 is the service chart diagram of flight reservation service in execution site. Preparation state only applies to M-services; they need to be checked and installed upon arrival from the business site to the site of user which is a mobile device. Table 3 illustrates how the fields of Table 1 are instantiated according to execution site. After finishing the execution of flight reservation service, the relevant information such as date of departure and date of return are obtained and afterwards, submitted to the next services.
|Next services||(Res.(y).Hotel Booking)/Pro.
|Business||Business (offers the service)|
|Data from previous services||null|
|Data for next services||Value(Des._city,Dep._date,Ret._date)|
Note: In Table 3, Protocol and Protocol correspond respectively to the protocols that trigger Hotel Booking service and Attraction Searching service.
Conversation-driven compositionIn Section 5.1, we pointed out that a service is initially in a selection stage (i.e., business site) and afterwards, enters an execution stage (i.e., execution site). We advocate that services must be able to talk to each other before they decide if to join a composition process, what states they take according to the outcome of conversations, and what activities they perform within these states. Conversations are based on a Conversation Language (CL) and are of different types, e.g., representatives, directives, commissives, and permissives . When services engage conversations, they need a-priori to agree upon the exchange protocol to communicate with each other. In our research, the use of conversations aims at raising the level of services to the level of autonomous components that are able to make independent decisions . This aids in building composite services at run-time instead of design-time. What is interesting to point out is the concurrency that exists between the selection and execution stages of a service in an execution site. When a service is under execution, it has at the same time to initiate conversations with the services that are due for execution (see next services field). The purpose of these conversations is twofold: invite the services to join the composition process and make sure that the services are ready for execution after they agreed on joining the process. Since service chart diagrams of Figure 4 and Figure 5 do not contain any conversation state, we deemed appropriate to complete these diagrams with the missing states.
a. Business SiteFigure 6 illustrates a light version (i.e., with no perspectives) of the new service chart diagram in business site after introducing the conversation state. The main difference with the service chart diagram of Figure 4 is that now a service can either accept or reject joining a composition process. Without conversations, it was granted that a service will take part to the composition process. A service can turn down an invitation to join a process of composing services for various reasons; e.g., the maximum number of the instances that can be deployed at the same time of that service has been reached.
b. Execution SiteFigure 7 illustrates a light version of the new state chart diagram in execution site after introducing the conversation state. While a service is being executed, it engages conversations with the next services that are due for execution. It should be noted that execution and conversation states are concurrent.
|Deadline-to-respond: time & date|
- Case a. -
- In case service declines the invitation, a conversation message is sent back from service to service for notification (2.1). Thus, service enters again the conversation state, asking another service to join the composite service (1). It could be assumed that there is always one service that returns a positive response to the invitation of joining a composite service.
- Case b. -
- In case service cannot make a decision before the deadline of response that service has fixed, service requests from service to extend this deadline (2.2). Service has two alternatives: a) refuse the request of service which means that service has to look again for another service (Case a.), or b) accept the request of service which means service will get notified about the acceptance of service (2.2.1). In alternative b), service enters the assessment state again in order to make a decision. Service may request an extension of the deadline for several reasons. For example, it cannot commit additional instances of service while other instances have not yet completed their execution. Indeed, it is argued that for service composition it is desirable to dynamically choose service providers, and service instances based on current network and servers loads.
- Case c. -
- In case service accepts to join the composite service it notifies its acceptance to service (2.3), so a Service Level Agreement (SLA) can be established . At the same time, service enters the preparation state to get itself ready for execution. It should be noted in Figure 8 that Accept-to-join link between conversation and preparation states of service plays two roles: a transition to enter the preparation state and a trigger for a conversation message to notify service .
The Web Service Conversation Language (WSCL) of  describes the structures (types)
of documents a service expects to receive and produce, as well as the order
in which the interchange of documents takes place. In fact, the conversation
component of a service is seen as a way to describe the kinds of operations
the service supports (e.g., clients to log in first and then request
catalog). In our work, we see conversations as a means for services to discuss
the establishment of a composite service at different levels: if to join,
when to join, and with what to join. A service enters different states depending
on the outcome of conversations. The interactions that a service supports
are part of the activities undertaken within the states. In , the authors discussed the way
DAML-S organizes a Web service description into three conceptual areas.
The profile area describes what the service does in terms of advertising,
discovery, and matching. This is the kind of information service-seeking
agents require in their work. The process model area tells how the
service works, including information about the service's inputs, outputs,
pre-conditions, and effects. The process model is also important in composing
and monitoring processes. Finally, the grounding area tells how an
agent can access a service. Typically, it specifies a communication protocol
and provides details such as port numbers used in contacting the service.
The conceptual areas that DAML-S puts forwards have a lot of similarities
with the perspectives that embed a service chart diagram. First, the profile
can be associated with the organization perspective. Indeed, an organization
that provides a service decides what functionalities and capabilities to
put into a service. Second, the process model corresponds to the flow perspective
at the composite service level and to the state chart diagram at the service
level. Finally, the grounding corresponds to the next services field of the
flow perspective. A service that is listed in that field is annotated with
the protocol that enables its invocation. Conversations between Web services
have attracted the attention of Ardissono et al. . Ardissono et al.
worked on a conversational model that aims at supporting complex interactions
between clients and Web services, where several messages have to be exchanged
before the service is completed. Conversation may evolve in different ways,
depending on the state and the needs of the participants. While we view
the conversations of  as
application-domain dependent and execution-driven, our suggested conversations
are application-domain independent and composition-driven. It should be
noted that both types of conversations complement each other. Composition-driven
conversations are part of the initial exchange of messages that takes place
during the preparation of a composite service (e.g., does a Web service
have an interest in joining a composition process?). While execution-driven
conversations illustrate the exchange of messages that occur during the
deployment of a composite service (e.g., how to submit a user's request
to a Web service?). Therefore, the chronology of conversations starts with
composition-driven conversations and continues with execution-driven conversations.
ConclusionIn this paper, we presented an approach for designing service-driven applications. Service chart diagrams constitute the backbone of the approach; they leverage the traditional state chart diagrams of UML. Additional elements are added to state diagrams, such as the organization that offers a service and the place of where the execution of the service takes place. The specification of a composite service consists of connecting the service chart diagrams of all the services that are involved in that composite service. Before connecting them, contributing services engage conversations to decide if they join the composite service or not. Conversations aim at raising raise the services to the level of autonomous components. As stated in , the services that are capable of engaging intelligent interactions would be able to discover and negotiate with each other, mediate on behalf of their users, and compose themselves into more complex services. One of the main issues that needs to be dealt with during conversations is scalability. If a service is requested by a great number of services, a bottleneck situation may happen. Indeed, the requested service has to engage conversations with each service which could definitely take time and require computing resources.
AcknowledgmentsThe authors would like to thank Aysha Alsayed Mohamed Ismail Almarzouqi, a fourth year student at ZU for her tourist mobile-book service.
- Simple Object Access Protocol (SOAP).
http://www.w3.org/TR/SOAP/, Visited July 2002.
- S. Akhil, M. Vijay, S. Mehmet, L. Li Jie,
and C. Fabio.
Automated SLA Monitoring for Web Services.
Technical Report HPL-2002-191, HP Laboratories, Palo Alto, California, USA, 2002.
- L. Ardissono, A. Goy, and G. Petrone.
Enabling Conversations with Web Services.
In Proceedings of the Second International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS'2003), Melbourne, Australia, 2003 (forthcoming).
- B. Benatallah and F. Casati (Editors).
Special Issue on Web Services.
Distributed and Parallel Databases, An International Journal, Kluwer publishers, 12(2-3) September 2002.
- B. Benatallah, Q. Z. Sheng, and M. Dumas.
The Self-Serv Environment for Web Services Composition.
IEEE Internet Computing, 7(1), January/February 2003.
- D. Beringer, H. Kuno, and M. Lemon.
Using WSCL in a UDDI Registry 1.02.
UDDI Working Draft Best Pratices Document, Hewlett-Packard Company.
- J. J. Bryson, D. L. Martin, S. A. Mcllraith, and L. A.
Toward Behavioral Intelligence in the Semantic Web.
IEEE Computer, 35(11), November 2002.
- B. Chaib-draa and F. Dignum.
Trends in Agent Communication Language.
Computational Intelligence, 2002.
- L. L. Constantine.
Fundamentals of Object-Oriented Design in UML.
- F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi,
and S. Weerawarana.
Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI.
IEEE Internet Computing, 6(2), March/April 2002.
- M. Huhns.
Agents as Web Services.
IEEE Internet Computing, 6(4), July/August 2002.
- H. Ludwig, A. Keller, A. Dah, and R. King.
A Service Level Agreement Language for Dynamic Electronic Services.
In Proceedings of the 4th IEEE International Workshop on Advanced Issues of E-Commerce and Web-Based Information System (WECWIS'2002), Newport Beach, California, USA, 2002.
- Z. Maamar, B. Benatallah, and Q. Sheng.
Towards a Composition Framework of E-/M-Services.
In Proceedings of The 1st International Workshop on Ubiquitous Agents on Embedded, Wearable, and Mobile Devices held in conjunction with the 1st International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS'2002), Bologna, Italy, 2002.
- Z. Maamar, W. Mansoor, and Q. H. Mahmoud.
Software Agents to Support Mobile Services.
In Proceedings of the First International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS'2002) (Poster Session), Bologna, Italy, 2002.
- J. Roy and A. Ramanujan.
Understanding Web Services.
IEEE IT Professional, November/December, 2001.
- ... services1
- Services are also known as Web services.