Discovering Service Opportunities by Evaluating Service Goals Richard Torbjørn Sanders1,2 and Rolv Bræk2 Abstract-- In this paper we outline an approach to discovering and maintaining telecom Service Opportunities between distributed communicating peers. The approach is based on exchanging and comparing Service Goals.
When we use the term service in the context of this article, we consistently refer to communication control services, as opposed to application services in its widest sense, or to transport services within the telecom domain.
Index terms-- Telecom services, service discovery, behaviour arbitration, UML, SDL
A service is defined here as a collaboration between service roles played by computational objects (or agents, in the sense of objects behaving on behalf of someone, not as a particular technology such as intelligent agents), as illustrated in Figure 1. Complex peer-to-peer services involve more than two agents. An agent is typically capable of playing several roles, both simultaneously and/or alternately. Providing a service means offering a successful collaboration between service roles.
I. INTRODUCTION In a world of communicating devices supporting advanced telecommunication services from multiple service providers over heterogeneous networks, the task of maintaining Service Opportunities between devices becomes increasingly difficult. GSM users already experience this: determining if you can send an MMS message to a recipient based on the existence of a phone number is inadequate; the number may refer to a mobile phone with only SMS capability, or it may even be a POTS phone without any messaging functionality. Such shortcomings can perhaps be tolerated between humans, since they will figure out for themselves that the service cannot be achieved, while this would certainly be inadequate for machine-to-machine services.
II. OUTLINE OF APPROACH In our approach we advocate performing service arbitration at three levels, as illustrated in Figure 2. Here, Peer 1 and Peer 2 are peers in a wide sense of the term. Peer 1 Service Goals
Roles
abstraction
Roles projection composition
Figure 2: Levels of Service arbitration Each level addresses different objectives: 1.
2.
Agent1 Agent2 Agent3 Agent4 Agent5
Figure 1. Services as collaborations 3. SINTEF Information and Communication Technology, Trondheim, Norway:
[email protected] 2 NTNU, Department of Telematics, Trondheim, Norway {richard.sanders, rolv.braek}@item.ntnu.no
Role validation
intention
Role playing / Service invocation / Resources
Service 3
1
Service Goals
Execute services
Service 1 Service 2
Service Goal comparison
Peer 2
Verify good behaviour
In this article we suggest an approach to dynamically discovering and maintaining Service Opportunities on a peer-to-peer basis, across network and service provider boundaries. The approach is based on what we call Service Goals. We show how the approach can be used to determine what we call Service Opportunities, and how these goals can be associated with service behaviour, and thus contribute to the validation of liveness properties. Telecom services typically result from the collaboration between several active objects, see Figure 1.
Find service opportunities
Comparing Service Goals determines the Service Opportunities between peers. This comparison of service capabilities is performed in the background, and provides each peer with an indication of what services can be attempted towards which other peers. Performing Role Validation determines if two peers can perform a Service without undesired misbehaviour, meaning that safety conditions are satisfied, and with the possibility of achieving progress toward the Service Goal identified by progress labels, meaning liveness conditions are satisfied. Role Validation takes place at service invocation time, or in order to validate a Service Opportunity. In service execution, the actual service roles are played. Whether the Service Goal is achieved is ultimately determined by the specific resource situation and by actual events and subsequent behaviour.
Discovering Service Opportunities by Evaluating Service Goals While the lowest level of service arbitration is currently provided for by signalling and transport networks today, the two higher levels are our suggestions, and are introduced to support rapid service development over heterogeneous networks and multiple service providers.
Service someEntity some_attributes
The concept of Service Goals arises from the recognition that, in the telecommunication domain, behind each service invocation there lays some identifiable goal, which can be understood at a high level independent of the implementation details of terminals, networks and protocol software. Examples of Service Goals can be "talk to B", "send a message to B", "find out where B is". When ontologies for the telecommunication domain are defined, such generic goals could and should be identified. Currently no such ontologies have been standardised; in our work we simply assume that one exists. One benefit of defining such domain concepts is that service providers and service users can relate to constraints expressed in terms of such goals, and use them to determine opportunities for service invocation across network and service provider boundaries, as we shall see. A Service Goal is defined in the problem domain, rather than in the implementation. I.e. it is a concept from the Enterprise view, in ODP parlance [1]. In our approach, Service Goals focus on successful service invocations. Exceptional cases, error handling and the like are not defined; these issues are treated in models closer to implementation, and in the implementations themselves. Our motivation for this is to simplify service models, capturing only the essential intentions at a high level of abstraction. The failure of services to reach their goal is important, since subsequent services may not be possible. As we shall see, it should be possible to relate the fulfilment of a Service Goal with some event or condition in domain model, and subsequently in the implementation. Service Goals express service capabilities at the service logic level. A Service Goal can be informally defined as the desired outcome or result of a service invocation. Formally a Service Goal is in its simplest form an enumerated entity, i.e. an element in a list of possible Service Goals. In our approach services are modelled by UML [2] association classes in domain models of service logic, as illustrated in Figure 3 [3].
SomeRole 0..n
otherEntity OtherRole 0..n
other_attributes
{context Service inv ServiceGoal : self.someRole.some_attributes... self.otherRole.other_attributes... implies self.goal}
In the next sections we will present Service Goals and how they can be compared, followed by a brief introduction to Role Validation. How the two relate to each other is treated in a separate section. III. SERVICE GOALS
goal : Boolean service_attributes
Figure 3: Generic service goal modelling in UML3 The invocation of a service invariably involves establishing a time-limited relationship between distributed peers. This can typically be a call session, which lasts for some time, or the sending of a message between two terminals, which is performed in an instant. The links of the association class are instances of these relationships. A. Roles in Service Goals Teleservices involve complementary service roles; for instance a call is initiated by one entity, and is directed to another. In the telecom domain these roles are commonly recognized and defined by service designers, e.g. the former role is named caller or A, while the latter is denoted callee or B. An entity involved in a service invocation plays one of these roles in the service; this we model in UML as association roles (someRole and otherRole in Figure 3). Typically one of the roles will be the initiating or originating role, while the other is the target or terminating role.4 We suggest explicitly modelling the satisfaction of the Service Goal by including an attribute in the association class called goal. The fact that there is a service association instance, i.e. a link linking two entities, does not in itself imply that the Service Goal is reached; e.g. a call may be attempted, but the callee may not answer the call or the phone may be turned off. In this case we might not consider the goal to have been reached, although the service logic is designed to handle such cases. The association also thus also represents failed service invocation attempts, so reaching the ultimate Service Goal must indeed be explicitly expressed in the model. We let the association class represent service control protocols as well as media transport paths in the real world or in the detailed design. Since Service Goals are expressed at a high level, no such implementation issues should be found in the Service Goal models. We suggest expressing goal satisfaction in constraints. Such constraints will typically refer to attribute values representing states reached at the role playing entities, e.g. that connections are established at both ends, or 3
In this presentation we assume that the reader is familiar with UML [2] and OCL [4]. 4 The ITU-T standards for services typically describe services such as Originating Call and Terminating Call, which are the complementary roles of the Basic Call service.
EUNICE 2004
Tampere, Finland
certain constraints on data elements, such as expressing that messages received are the ones that are sent. Both are demonstrated in the examples below. In our approach we model these goal achievements as constraints in OCL [4], as indicated by Figure 3. We model the goals seen from the perspective of the service. The reason is that this allows us to compare the Service Goal expressions of potential peers, and determine if they match and thus represent Service Opportunities between the peers. Seen from the viewpoint of a communicating peer, we could explicitly distinguish between required and provided Service Goals. A required goal is what the peer is seeking for in terms of service invocation, while a provided goal describes what services the peer in question can satisfy. Although such information is interesting per se, we maintain that the notion "complementary roles" is sufficient for our purposes. I.e. there is no need to explicitly state which, if any, of the service roles play the originating or terminating role, only that they are complementary to each other. B. Examples To illustrate our approach we present a few simple examples. In Figure 4 we have modelled a simple Basic Call Service. UserAgent
connected: Boolean
0..2 callee
caller 0..2
{context Call inv CallGoal : self.caller.connected and self.callee.connected implies self.goal}
Call goal : Boolean
Figure 4: Example: Call The association class Call between UserAgent instances models the originating and terminating call relationships commonly known from the domain of telecoms services. This is a domain model of the communication service, hiding all implementation details related to signalling and transport networks, focussing solely on the relationship between the peers, which would be different instances of UserAgent. The association class Call models the Service, and the role names of the association distinguish between the originating (caller or A side) and the terminating (callee or B side) role of the service. The intended interpretation of this model is that an instance of UserAgent has the capability of initiating a Call, and receiving incoming calls. The association cardinality indicates that each relationship is optional, implying that there may be a call between the two parties, but not necessarily. One could say that there is an opportunity for such a relationship to exist. The cardinality constraints also express a maximum of two simultaneous calls being available for each role.
The model in Figure 4 can be used to express Service Goal constraints for the Call service, for example as follows: {context Call inv uniquePeers : self.callee self.caller} {context Call inv CallGoal : self.caller.connected and self.callee.connected implies self.goal}
The first constraint is an example of general constraints that can be expressed in such a model. It should be possible to express many typical constraints found in teleservices in this fashion, such as those related to security or other service quality issues. The second OCL expression is a constraint related to the fulfilment of the Service Goal. Such constraints are designed to be identified as Service Goal by their labelling, which we suggest is a concatenation of the association class name and the keyword Goal. This is a design choice intended to facilitate model parsing by a tool, and has no other semantic implication. In this case the goal of the service is expressed in terms of the states of the UserAgent instances, here modelled by the attribute connected. Although not visible in the models here, the implication is that the connected attribute is implicitly or explicitly set to True or False by the UserAgent at appropriate states in the behaviour of the entity. The interpretation of the model in terms of fulfilment of the Service Goal is that when both peers are in the connected state and are related by the Call association, they are in a call with each other, with the roles caller and callee respectively. The goal attribute of the association class is true in that case. We can proceed with examples of other typical services. A model of a rudimentary messaging service is depicted in Figure 5. {context Messaging inv MessagingGoal : self.sender.sentMsgAcked and (self.receiver.lastReceivedMsg = self.msg) implies self.goal}
UserAgent sentMsgAcked : Boolean lastReceivedMsg : Msg
0..1 receiver
sender 0..1
Messaging goal : Boolean msg : Msg
{context UserAgent inv : self.messaging.msg ocl_ IsTypeOf (Msg)}
Figure 5: Example: Messaging service The Messaging goal can be considered fulfilled when a message sent from one User Agent is acknowledged as received by another, and that the last received message is the one sent, as expressed by the OCL expression. The former part implies an acknowledgment mechanism in the underlying protocol. Without such a mechanism, the OCL constraint would have to be reformulated. Note also the constraint regarding the message type, a feature which could be used to distinguish between different message types like MMS and SMS messages in GSM.
Discovering Service Opportunities by Evaluating Service Goals These two examples involve services between similar entities, and use so-called recursive associations. This need not be the case. An example that involves different entity types is shown in Figure 6 below.
that a conferee can participate in up to two conferences. This encourages modular design and separation of concerns, something we are always trying to achieve in system design of any complexity.
Here the goal is for User Agents to log on or join socalled Meeting Places, a term borrowed from the AMIGOS service [5]. The goal is achieved when one or more participants have joined a Meeting Place, as can be deduced from the OCL constraints in Figure 6.
Notice how OCL permits us to traverse the binary associations in Figure 7 in order to express the conditions that we consider constitute reaching the Service Goal.
MpSession UserAgent
my_joined_mps : String[*]
MeetingPlace
goal : Boolean
participant 0..*
host 0..*
participants : String[*]
{context MpSession inv MpSessionGoal : self.host.participants->exist(n|n = self.participant.name) and self.participant.my_joined_mps->exist(n|n = self.host.name) implies self.goal}
Figure 6: Example: Meeting Place Session The examples above employ binary associations. As indicated in Figure 1, some services involve more than two entities and/or more than two entity types. We have attempted to represent such services using n-ary associations. But as it turns out, the interpretation of nary associations in general is not clear, with very divergent semantics [6]. The idiosyncrasies of n-ary associations in general, and in UML in particular, force us to refrain from using n-ary associations to express services involving more that two entities. Instead we revert to collections of binary associations, which have a clearer semantics, and which in addition prove to have other advantages. See [3] for a more detailed treatment of these issues.
C. Service Goal diagrams We now briefly introduce what we call service goal diagrams. They describe relationships between services in terms of Service Goals. They are based on high-level Message Sequence Charts (HMSC) [7], where we in MSC conditions insert UML class diagrams showing situations in terms of Service goals. As is apparent from the previous sections, the simplest Service Goal is expressed as a single binary relationship. However, even such services can be extensions of more primitive services, or require that other services have been successfully completed before they stand a chance of reaching their goals. For instance a Call may consist of Invite followed by SetUp. This we depict as follows: msc Call Invite
a:UA
Invitee Inviter
b:UA
Setup
a:UA
A
B
Inviter
b:UA
Invitee Invite
Figure 7 below gives an example of a service involving more that two entity types. MpConfConfig
Figure 8. Service goal diagram for Call
goal : Boolean
UserAgent
MpConfCtrl 0..1
MpConfOwner 1..m MeetingPlace participants : String[*]
0..1 0..1 mp_conf Conf
status : {None, Open, Closed}
1..c conferee
conf 1..2
state : {Idle, Active, Floating} participants : String [*]
{context MpConfConfig inv MpConfConfigGoal : self.mpConfOwner.participants-> exist(n|n=self.mpConfCtrl.name) and self.mpConfOwner.mp_conf.participants-> exist(n|n=self.mpConfOwner.mp_conf.conferee.name) and self.mpConfOwner.mp_conf.state Idle and self.mpConfOwner.mp_conf.conferee.status = Open implies self.goal}
Figure 7. N-ary service as a set of associations Here the service is still defined by an association class, but uses solely binary associations to model relationships between the entities involved in the service. The associations used in Figure 7 express more general relationships between the entity classes; for instance that conferences may or may not be contained by a Meeting Place, that a conference has at least one conferee, and
Figure 8 expresses that, in the context of the Call service, the goal of the Setup service can be obtained after the Invite service has reached its goal. The semantics of node connections are that a partial order exists between the goals referenced, placing a partial ordering on goal success, and thereby on the actual events involved in reaching the goal. Formally, service goal diagrams express that there is some way of reaching the “states” (goals) mentioned, and in that order, by some sequence of events. We do not specify which events these are, but focus on the relationships between the services and the entities involved. This does not mean that protocol events related to Setup cannot occur prior to Invite reaching its goal in some other context; we simply state that there is a way to reach the Invite goal before any events related to the Setup goal occur. In particular, events may occur in the service protocol after the goal has been reached.
EUNICE 2004
Tampere, Finland
To define how preceding services relate to each other, we allow the inclusion of previously referenced service goal elements (classes, associations, association classes and roles) in grey. In Figure 8 we for instance state that the A role of the Setup service is played by the same UserAgent instance that played the Inviter role in the Invite service. Only preceding service elements can be referenced. This feature points to role composition [8], which we shall not treat in this article. See [3] for more details concerning Service goal diagrams. D. Determining Service Opportunities Our approach lends itself to the challenging task of determining what Service Opportunities exist between distributed communicating peers. The concept is that each entity type will have descriptions of its Service Goals of the type exemplified above. By making these public between potential communicating peers, it is possible to compare them and determine possible matches. Figure 9 illustrates the principle. someEntity
callee caller
callee
User Agent
User Agent
host
Meeting Place
User Agent
IV. ROLE VALIDATION
caller
participant
host
thirdEntity
Messaging sender receiver
receiver sender
User Agent
Figure 9: Comparing Service Goals Here two potentially communicating peers are depicted, each with their respective Service Goal descriptions. In each case the various services they provide and require are identified by the association classes and the role names. The comparison procedure is outlined as follows: 1. 2. 3.
While the latter are typically taken care of by signalling and transport networks, the signalling protocol details can be addressed by the role validation mechanisms that we presented in the following. In a subsequent section we shall indicate how the Service Goal concepts and the role validation mechanisms relate to each other.
callee MpSession
MpSession participant
caller callee
The Service Opportunities that are determined by the above approach constitute exactly that: opportunities. They do not guarantee that Service Goals will actually be achieved at service invocation time. There may be signalling protocol discrepancies at a more detailed level that are not captured by the domain level Service Goal expressions, and/or there may be lacking resources, user actions or other events or conditions that hinder the reaching of the Service Goal.
otherEntity
Call
Call caller
not mean that this service can never be initiated towards other peers; it only precludes them between these particular types of peers. In this example, it means that no Messaging is possible between someEntity and otherEntity, which addresses the GSM messaging incompatibility issue we mentioned in the Introduction.
Identical association class names are searched for. If found, complementary role names are paired (e.g. caller and callee). Identical role names are not paired. For each found pair, any additional constraints expressed e.g. in OCL are evaluated.5
By performing such comparisons, the resulting Service Opportunities can be discovered. In the example of Figure 9 we find two Service Opportunities between the entity types presented: the Call service between someEntity and otherEntity6; and the MpSession service between someEntity and otherEntity. We note that someEntity initiates and provides another service, Messaging, that does not match in relationship to the peers shown here. This does
It has been shown how validation of functional roles (service roles or s-roles) between collaborating actors can be obtained by using role projections and validation [9]. Role validation exploits the validation of service association roles (a-roles). An a-role is the visible interaction behaviour of an s-role projected on an association. Each collaboration association involves exactly two s-roles. An s-role that interacts with other sroles provides distinct a-roles on the associations defined towards each other s-role. See Figure 10 below. collaboration A-B A’s service role
B’s service role Role projection
user A
user B
collaboration A-B'
Association validated
object1
B
Hidden Hidden interactions interactions legend:
A Role A: Projection of object1 to object2 service role (s-role)
object2
Role B: Projection of object2 to object1
Hidden interactions
association role (a-role)
Figure 10: Validation using projection 5
A constraint may express conditions that hinder Service Goal fulfilment. E.g. they may state that the peer must use a specific service provider, or be of a particular entity type (in the example: a UserAgent or a subtype of it), or have particular service quality demands, e.g. on price. 6 Note that in the example, calls may be initiated in both directions; a short-hand notation has been used: someEntity can play both the caller and callee roles of the Call service.
The benefit of projection is obtaining a simplified system description that emphasizes some of the system properties, while hiding internal actions and interactions not relevant to the validation of an association. Design rules have been formulated that, when followed, ensure that the a-roles are projected faithfully, meaning that they maintain the “observable behaviour” of the service roles over the association. Subsequent validation determines if
Discovering Service Opportunities by Evaluating Service Goals they behave well. Behaving badly results in deadlocks, improper termination or unspecified message reception, thereby constituting a violation of safety properties [9]. While Service Goals are compared “offline” in a background process, role validation can take place at service invocation time, for instance in what is called Role Negotiation in the experimental service development framework ServiceFrame [10]. A simplified version of how Role Negotiation works is illustrated in Figure 11. This kind of negotiation technique is similar in nature to resource allocation techniques for telecom systems, and the usual technique of solving one request at a time is applied. If several entities perform role requests towards each other, resolution will take place one at a time, possibly causing alternative roles to be played if for instance a “Busy” situation results. requesting:actor
object
A
requested:actor Performs role negotiation 1. Request (A)
ActorStateMachine
Now we turn to the issue of linking the Service Goals to liveness properties. We have previously shown that containment and obligation requirements do not guarantee any useful progress [12]. This is illustrated in Figure 12, where the validation of two a-roles determines that the containment and obligation requirements are satisfied, but the end result does not provide any useful progress in terms of achieving the Service Goals (the Call and Messaging service will never be successfully completed in this case). We have previously shown how so-called progress labels can be added to the s-roles, and subsequently propagated to the a-roles, in order to distinguish "useful" behaviour from simply "safe" [12]. Such labels can be used in the role validation to differentiate between role combinations with more or less progress. idle
state type A
2. Play (B)
B
object2
Figure 11: Role Negotiation in ServiceFrame [10] The validation techniques evaluate if so-called containment and obligation relationships are satisfied between the association endpoints being validated. A containment relation exists between two interacting aroles when, in each state reached during the interaction, any a-role is able to at least consume whatever signal can be received from its complementary a-role in that state. An obligation relation exists between two interacting aroles when, at each interaction step where the input queues of the a-role processes are empty, at least one of the interacting a-roles will eventually send a signal. These are complementary techniques; containment focuses on avoiding unspecified messages and improper termination, while obligation deals with deadlock [11]. In our Service Discovery approach, role validation must be performed between the candidate role players after a Service Opportunity has been detected. This is due to the rudimentary description of the service at the Service Goal level. As we mentioned above, a match of Service Goals and the identification of complementary service roles does not guarantee that safety or liveness properties are fulfilled. Performing Role Validation will ascertain these issues, and will avoid useless Service Opportunities being presented to the peers.
free
msg
call calling
as so cia ti o n
3. Confirm (B)
V. ASSOCIATING SERVICE GOALS TO PROGRESS LABELS
Validate
msging
call
state type B msg
called
msged
answer
reject
received
reject
reject
reject
connect
idle
idle
idle
free
free
discA
discB
pend_ack
discB
disc_ack
discA
idle
idle
Part of A’s behaviour that is not exercised when playing against B
Figure 12: A safe but "useless" role combination The state diagrams in these examples are expressed using an extension of SDL [9], where transitions can start with signal sending, which of course is not possible in without using spontaneous transition pure SDL [13]. idle
state type A
call calling answer
progress: Call
reject
connect
idle
discA
discB
pend_ack
discB
disc_ack
disc_ack
idle
idle
Figure 13: Service-specific progress label In Figure 13 we see an example of an a-role with a progress label added to an event that the designer of the service role considers constituting progress. The service referred to is the Call service identified in the Service Goal modelled in Figure 4. This event brings the state
EUNICE 2004
Tampere, Finland
machine into the connect state, which indeed was the condition formulated in the constraint of the Call service. Implicitly the connected attribute of Figure 4 is set to True during the transition into the connect state marked by the progress label. In Figure 14 we show an example of a progress label in the initiating side of the Messaging service. This describes the sender role depicted in Figure 5. state type A
idle msg waitack
progress: reject Messaging
received
idle
idle
Figure 14: Progress labels for messaging service Figure 15 shows how the Service Goals at the Enterprise View level are related with the progress labels at the design level. In our approach, progress labels match service names, and terms used in the OCL goal expressions can be found in the state diagrams. idle call
state type A connected = False
calling answer connect
progress: Call connected connected = True
reject idle
discA
discB
pend_ack
discB disc_ack
disc_ack idle
connected = False
idle
UserAgent connected: caller Boolean 0..2
0..2 callee
Call goal : Boolean
context Call inv CallGoal : self.caller.connected and self.callee.connected implies self.goal
Figure 15. Linking Service Goals and progress labels We see from these examples how the Service Goal comparisons and the role validation mechanisms relate to each other, while addressing service arbitration at different levels. In addition to Service Goal comparisons and Role Validation, the actual service logic caters for service execution, taking actual behaviour into consideration, as well as the transport networks providing the media transport, if needed. This was illustrated at the outset, in Figure 2.
models used to discover Service Opportunities and their use in a role validation scheme has been described. A. Discussion The service arbitration mechanisms suggested in our approach come as an addition to service signalling mechanisms existing in current systems. They come at the expense of additional signalling and context data. This addition is not deemed necessary for single system solutions. "Single system" could for instance be the ISDN network, even though these services can span several countries and service providers. The potential benefit of these mechanisms is to ease the establishment of Service Opportunities between distributed entities connected to heterogeneous networks and using different service providers. By comparing Service Goal descriptions it is possible to determine what services are available between which peers. This will become increasingly important with a growing number and diversity of terminal types, signalling and transport networks, and service providers. Such mechanisms do not exist in the telecoms service domain at present. The benefits of the additional mechanisms are related to situations with heterogeneous networks (e.g. ISDN, GSM and IP networks) and multiple service providers. It is also worth noting that validation between peers is and will be used to solve other issues, e.g. "traditional" QoS like authenticity, secrecy, and media stream capabilities. The "QoS" we are talking about addresses the “Quality of Telecommunication Services”. For such mechanisms to be possible, it is necessary that an ontology spanning the telecom service domain is established and standardised. Concepts that need to be included in such an ontology are the service names, the role types, and the elements used in the constraints expressions. This should not be an impossible task, since the domain of telecoms services is in many ways mature, with decades of standardisation of telecoms services e.g. by the ITU-T. Advanced telecoms services that converge with information services, such as in location-based mobile services, will pose a greater challenge, since this is likely to be an evolving area with a higher rate of innovation. On the other hand the need for ontologies for information services is maturing rapidly, and standardisation work is likely to start with information services in mind.
VI. CONCLUSION
An ontology should also define synonyms. Consider for instance the callee role in Figure 4 and the conferee role Figure 6. We know that many conference system implementations present the terminating conference call as an ordinary terminating call; hence the conferee role should be defined to be a synonym for the callee role, in the sense that the roles are interchangeable.
An approach to discovering and maintaining Service Opportunities between distributed communicating peers has been presented. The link between Service Goal
In terms of our contribution to role validation, it has been argued that the projection technique brings the task of formal validation closer to the mental framework of the
Discovering Service Opportunities by Evaluating Service Goals designer [9]. The same argument applies to the progress labels that we suggest; they become an integral part of the service logic, instead of being expressed in separately constructed model-checking models. This should lower the threshold for applying formal techniques to detect and remove some of most intricate errors that humans build into systems. We expect this to lead to more widespread use of formal validation techniques by engineers, rather than solely those with a mathematical background.
services? Subtyping of association classes can go some ways, but we shall also investigate other ways of evaluating "closeness", such as explicitly identifying role synonyms in a service ontology. VII. ACKNOWLEDGEMENTS The work presented here extends that of Jacqueline Floch and Rolv Bræk [8], [9],[11].
B. Related work The work here complements other service discovery mechanisms that are currently being specified in e.g. ODP [14] and implemented in JAIN [15]. Our work is also related to ongoing standardization work for harmonization between networks. The so-called “meta-protocols” in TIPHON constitute an attempt to abstract services from particular networks [16]. We view that TIPHON, like Intelligent Networks, is networkcentric; we instead advocate that a service-centric approach should be followed [17]. To the best of our knowledge we are not aware of similar approaches to arbitrating service logic, although there are attempts at modelling services at an abstract level that somewhat resemble our approach [18]. Implementing the approach presented here requires that an ontology is standardised for the telecommunication service domain. While service discovery protocols7 have terminology to identify services, they have not yet developed fully fledged ontologies. Such an endeavour would naturally draw on work being carried out within the Semantic Web [19], although we have not yet seen any such work being carried out. In our approach to negotiation, we assume that a fixed negotiation protocol suffices, rather than dynamically selecting a suitable protocol for the interaction, as proposed within the Intelligent Agents domain [20]. C. Further work In order to assess the merits of the concepts presented here, prototyping is being carried out in the context of a service development and deployment lab [21]. Validation tool development is taking place in the context of this lab, both to implement the safety properties of Role Validation [22], and to implement progress calculation [23]. Student assignments for prototyping Ontologies and Service Discovery tools have also been formulated. The comparison of Service Goals should be refined to compare services that are "similar enough" rather than be based on identical name matching. I.e. how different can complementary goals be and still provide complementary 7
Examples of such protocols include Jini, Bluetooth, and Parlay.
VIII. REFERENCES [1] [2] [3] [4] [5] [6]
[7] [8] [9] [10]
[11] [12]
[13] [14] [15] [16] [17]
[18]
[19] [20] [21] [22] [23]
ISO/IEC IS 10746-1, Open Distributed Processing: Reference Model. ISO (1998) UML 2.0 Superstructure Specification, OMG Adopted Specification, ptc/03-08-02 (2003) Richard Torbjørn Sanders, Rolv Bræk: Modeling Peer-to-peer Service Goals in UML, submitted to SEFM 2004 UML 2.0 OCL, OMG Document ad/2003-01-07 AMIGOS – Advanced Multimedia In Group Organised Services, http://www.pats.no/projects/AVANTEL/AMIGOS.html [accessed April 2004] G. Gonzalo, J. Llorens and P. Martínes: “The meaning of multiplicity of n-ary associations in UML”, Systems and Software Modeling, Vol 1(2) pp. 86 – 97, Springer-Verlag, Heidelberg, Germany, December 2002 Message Sequence Chart (MSC). ITU-T Recommendation Z.120 (11/99) Jacqueline Floch, Rolv Bræk: Using SDL for Modelling Behaviour Composition, Proceedings of the 11th SDL Forum (2003) Jacqueline Floch: Towards Plug-and-Play Services: Design and Validation using Roles, Ph.D. thesis 2003:47 NTNU (2003) Rolv Bræk, Knut Eilif Husa, Geir Melby: ServiceFrame Whitepaper, Ericsson NorARC, May 2002. Available at http://www.item.ntnu.no/lab/nettint1/ServiceFrame/ServiceFrame. html [Accessed April 2004] Jacqueline Floch, Rolv Bræk: Using Projections for the Detection of Anomalous Behaviours, Proceedings of the 11th SDL Forum (2003) Richard Torbjørn Sanders, Jacqueline Floch, Rolv Bræk: Dynamic Behaviour Arbitration using Role Negotiation, Proceedings of the 9th EUNICE and IFIP Workshop on Next Generation Networks, Balatonfüred, Hungary, 8-10 Sept 2003 ITU-T: Specification and Description Language (SDL), Z.100, Geneva (2002) ISO/IEC IS 10746-4, Open Distributed Processing, Trading Function: Specification. ISO (1998) JAIN Technology, http://java.sun.com/products/jain/ [accessed April 2004] TIPHON Protocol Framework Definition; Part 1: Metaprotocol design rules, development method and mapping guidelines, ETSI TS 101 882-1 V4.1.1 (2003-09) R. T. Sanders, “Service-Centred Approach to Telecom Service Development”, Proceedings of the 8th EUNICE and IFIP Workshop on Adaptable Networks and Teleservices, Trondheim, Norway, Sept 2-4 2002 P. Sties and W. Kellerer: “A Generic and Implementation Independent Service Description Model”, Proc. of the 21st International Conference on Distributed Computing Systems Workshops (ICDCSW ‘01), Mesa, Arizona, USA, April 2001 The Semantic Web http://www.w3.org/2001/sw/ [accessed April 2004] V. Tamma, M. Wooldridge, and I. Dickinson. An Ontology for Automated Negotiation. In Proceedings of the Workshop on Ontologies in Agent Systems, Bologna, Italy, July 2002 Teleservice Lab at the Department of Telematics, http://www.item.ntnu.no/lab/nettint1/ [accessed April 2004] Dragana Korda, Role Validation algorithms, M.Sc. thesis, NTNU, to be submitted June 2004 Rune Alsnes, Role Validation tool, M.Sc. thesis, NTNU, to be submitted June 2004
