Service and Service Behavior

What is a service?

     We define a service as a set of functionalities associated with a process or system that performs a task.

    (a service 由两部分组成：服务的功能funcitonality和服务的行为behavior)

Kind of Service:

      hardware devices as services：
         Most of the industrial service discovery approaches like (Jini, SLP, UPnP etc.) use hardware devices like printer, fax machine, etc. as networked services.
      software founction as services:

          On the other hand, the majority of WebService discovery approaches consider a software component, performing a specific functionality, as a service.

Another service definition:

     A service is an autonomous, platform independent component; frequently a software component.

     ---from Towards a Theory of Services, here he means  software founction as services.

      We can denote a service by a function f, and a resource by an
input variable x. The outcome of the service is then returned as f(x).

      Notice that a service can be invoked by another service. In this case, the outcome of the service f becomes a resource and is used by another service, say g. This is called service composition and the outcome of the service g becomes g(f(x)).

      Summing up, a service is a reactive system. An output item of a service A may serve as an input item of a service B.

What is service behavior?

     In a broad term, the behavior of a service describes the changes of its “states”.

    Depending on specific research topics, the “state” can be (a) the actual internal execution state, (b) only a part of the state of relevance to the parties connected with the e-service, or (c) the state of the “external world”.

 Kind of service behavior：

    Furthermore, different models rely on different kinds of “actions” to change state; these might be (i)messages, (ii) activities, and (iii) events.

(i) messages:

 The WSDL standard focuses heavily on passing messages between e-services. This leads naturally to behavioral models that use messages as the “actions”, and use (abstract) internal states of individual

e-services as the states that messages cause transitions between [6, 10]. This perspective is closely related to work on process algebras [17] and in the verification community [7], all of which study distributed automata with message passing of one form or another. It can also support investigations based on partial information of the internal states, as typical in the verification community.

   (Conversation model--X.Fu)

 (ii) activities: 

    The workflow community has traditionally focused on activity-based models. These represent a process by combining activities with essentially some forms of control flow. The typical formalisms in workflow community are flowcharts, Petri nets, and finite state machines or state charts.

    The semantic web services community also favors an activity-based perspective. Much of that work assumes that atomic services perform activities, which have the effect of changing the state of an “external world”.

   (the Roman model which represents eservices as activity-based finite state automata--D. Berardi)

 (iii) events

   Event-based formalisms have been used primarily in the context of workflows [22]. An event can be viewed as an abstract version of an activity. Event-based models allow declarative, logic based semantics and provide an alternative to analysis of workflow specifications [9].

   (ECA model)

The models represent a service behavior and are specified in rigorously defined concepts such as Petri nets or finite state machines.

Conversation model:

     Conversation models, as presented in [7], are a formalism for interaction models.They are finite state automata with an alphabet R ×M × R. R denotes the set of roles and M the set of message types. The 3-tuple (s, m, r) then describes the sender, the type and the receiver of a message.

 

     Figure 1 illustrates a number of sample interaction models. States are depicted by circles and the transitions by arrows. The initial state is targeted by an arrow without source state and the final state is denoted by a double-circle.

    Figure 1(a) shows the example described in the introduction. It is not possible to find interacting roles that exactly show the specified behavior. Nevertheless, it would be possible to find interacting roles that show a subset of the specified behavior: Imagine two roles A and B that interact and roles C and D simply do nothing. In this case, however, a conversation would not terminate properly, as the final state cannot be reached.

    Figure 1(b) shows a choice between two interactions. Similarly to the previous example, A and B cannot know whether C and D have already interacted and vice versa. In contrast to the previous example, we can find roles that collectively realize a subset of the specified behavior with proper termination. Imagine again
that only roles A and B interact while C and D do nothing. However, we are not able to find a set of roles that realize a subset of the behavior where all interactions from the conversation model are reachable.

   Similarly to the first example, the enablement dependency between the AB interaction and the CD interaction is the problem in Figure 1(c). As a solution, C could wait for the message from B before interacting with D. That way, the resulting behavior would be a properly terminating subset of the initially

specified behavior.

  Figure 1(d) shows an example containing a non-deterministic choice. This conversation model represents that A should internally be able to decide whether B will interact with C later on. However, B cannot observe this decision as in any case it will get a message x from A. As A does not have any control over the BC interaction, the decision whether this interaction takes place or not will be independent form A’s initial choice. When only considering the possible traces of the conversation model we can easily create roles that collectively produce exactly the same traces. The main difference is that B or C can decide whether the final interaction takes place or not in the realization. We see that considering the branching structure is crucial whenever the ownership of (and the moment of) choices is of importance. It might be argued that local choices are irrelevant in choreographies. This might be true if choreographies are considered to be a collection of mere interaction sequences. However, from a business perspective it

makes a major difference who makes a branching decision. Therefore, this should be reflected in the formal model as well.

    Figure 1(e) shows a cyclic example containing a choice between an AB interaction and a CD interaction, similarly to the second example. The difference here is that by expanding the cycle to a sequence, we can at least find roles that realize a subset of the behavior.

    Finally, Figure 1(f) shows an example that is perfectly realizable in a synchronous world, where C can block B until it has interacted with A. However, when considering an asynchronous world, where message sending and receiving do not happen in one step, the order of the send activities would not conform

to the order of interactions in the conversation model. (Realizability of Interaction Models--Gero Decker)

   As for  service conversation, Communication model(Synchronous communication and asynchronous communication) and Realizability should be further studied.(Realizability is controllability--Niels Lohmann)