An Inter-Working Petri Net Model between SIMPLE and IMPS for XDM Service

1. Introduction

The XDM (XML Document Management) (Open Mobile Alliance, 2006a ; Open Mobile Alliance, 2006c; Open Mobile Alliance, 2006h ; Open Mobile Alliance, 2006l) service is more and more attractive in the age of regarding the user as the communication center. XDM which was ever named GM (Group Management) comes out with the Instant Messaging (IM) service, and manages the personal information, such as contact list, which is the necessary information that IM service needs (Rosenberg, 2005). With the development of XDM service, the information which the XDM server stores will be richer and richer, for example, the personal profile and group information are added to the XDM service. Then the XDM service turns into one of the supporting services from a simple service which just provides the contact for the user. As one of the supporting services, the XDM provides the personal information for the other services which need them, for example, providing the user’s personal information for the IM service or Presence service. At present, there are many different appellations of XDM in different standards. Many research institutes and companies have presented their implementations for the XDM service, but the implementations are different and incompatible, so it is hard to inter-work between them. However the inter-working for the services based on XDM service is desired intensively, such as IM, Presence service. There are three main international standards for the XDM service and its relative services: SIMPLE (Session Initiation Protocol for Instant Message and Presence Leveraging Extensions) {1}, IMPS (Instant Messaging and Presence Services) {2} and XMPP (Extensible Messaging and Presence Protocol) (P. Saint-Andre, 2004a; P. Saint-Andre, 2004b). IMPS has been deployed in many systems for its better maturity, but SIMPLE is more suitable for being deployed in IMS (Internet Protocol Multimedia Subsystem) network, so inter-working between them is becoming a research hotspot in the value-added service field, but recently the research on the topic is just in the initial stage. OMA (Open Mobile Alliance) just proposed a simple Architectural Model (Open Mobile Alliance, 2005a; Open Mobile Alliance, 2005b) for the inter-working between SIMPLE and IMPS, but the architecture can not perform the inter-working for the XDM service. Based on the research on the difference between SIMPLE and IMPS and the OMA’s inter-working Architectural Model, we (with the State Key Lab of Networking and Switching Technology of Beijing University of Posts and Telecommunications, and Research Institute of China Mobile) have proposed a bi-directional protocol mapping for use to enable the exchange of XDM information and an Enhanced Architectural Model to perform the inter-working functions which can not be completed by the current OMA Architectural Model. On the other hand, there is no any other research institute studying the XDM inter-working with the Protocol Conversion Methodology (Green, 1988; Zhu, 2006b; Zhu, 2007). In this chapter, according to the method proposed by the Protocol Conversion Methodology, the XDM inter-working model based on Petri Nets {3} is set up to verify the mapping and the Enhanced Architectural Model by a new coupling criteria of Petri net model. After the strict mathematical analysis and verification for the model, which prove that the model meets all properties of a correct Petri net model, the mapping and the Enhanced Architectural Model are proved to be reasonable and viable, and the probable exceptions in the inter-working can be found and excluded. During the modeling experiences of the inter-working with Petri Nets, some methods for solving the conflict of a Petri Net are proposed, which enriches the application of Petri Nets for the protocol conversion. As the concept of XDM is almost same among different standards, the inter-working Petri net model can provide an applicable reference for the inter-working between other standards.

2. SIMPLE and IMPS

2.1. SIMPLE

IETF (the Internet Engineering Task Force) first set up the basic models (Day, 2000a; Day 2000b) for Presence and Instant Messaging, then a working group called SIMPLE was founded to focus on the application of the SIP (Session Initiation Protocol) (Rosenberg, 2002) to the suite of services collectively known as Instant Messaging and Presence (IMP) {1}. 3GPP and 3GPP2 adopt SIMPLE as their basic standard and specify the practical implementations of SIMPE specifications for the Presence, Group and IM service in IMS and MMD (MultiMedia Domain) respectively (3GPP, 2002-2005f; 3GPP2, 2002-2006). With the expanding of the influence of SIMPLE standards, OMA also adopts it as its basic standard and has set up workgroups to create application level specifications for this standard. SIMPLE was divided into three services in OMA: Presence service, XDM (XML Document Management) service and IM service, and these three services would be in progress independently.

2.2. IMPS

IMPS, which is also based on the basic models set up by IETF, was designed for exchanging instant messages and Presence Information not only between mobile devices but also between mobile and fixed devices, which includes four primary features {2} (Open Mobile Alliance, 2007a-2007m) : Presence, Instant Messaging, Groups and Shared Content.

2.3. XDM service

In SIMPLE, XDM service provides the Personal Information (Shared Profile), Shared List and Shared Group for the users and the other services (Open Mobile Alliance, 2006a-2006l). There is almost the same information in IMPS. The Personal Information belongs to the common features in IMPS, which includes two parts: Private Profile and Public Profile. The Contact List (i.e. Shared List) belongs to the Presence features in IMPS. Group is a set of users, which is the same feature in SIMPLE and IMPS, and the participant can see the other participants in the same Group. The Group participant can have a group conversation (Instant Message conversation or voice conversation) through the Group information. Besides the conversation between the participants, the communication request initiated by one of the participants can be received by the other participants. Why there is a “Shared” in front of the “List” and “Group” in SIMPLE is just because the List and Group in SIMPLE can be referenced by the other service, but the List and Group in IMPS can’t, which are only used for Instant Messaging.

As there is almost the same information within SIMPLE and IMPS, it is possible for them to inter-work, a bi-directional protocol mapping for use to enable the exchange of XDM information is proposed to perform the inter-working functions (Zhang, 2007) (also see the mapping described in general in Section 3). Here we also use the XDM service to describe the corresponding service in IMPS.

2.4. Inter-working between SIMPLE and IMPS

At present, only OMA had made some contributions which just focused on a simple Architectural Model on the inter-working subject (Open Mobile Alliance, 2005a; Open Mobile Alliance, 2005b). State Key Laboratory of Networking and Switching Technology of Beijing University of Posts and Telecommunications and Research Institute of China Mobile have paid much attention to the inter-working issues and spent a lot of care on researching them. On the study of OMA’s inter-working Architectural Model and the gaps between SIMPLE and IMPS standards, we found the OMA’s Architectural Model can only realize the inter-working of Presence and Instant Messaging, and the inter-working for the other important service named XDM service can not be completed by the current OMA Architectural Model. Because the XDM service is going to be more and more important as it has become one of the basic supporting service, if the inter-working for XDM service has been realized, the XDM service and the services supported by XDM service would be more attractive to the user. We proposed an Enhanced Architectural Model for the inter-working (Zhang, 2007), as shown in Figure 1.

Figure 1.

The Enhanced IWF Architectural Model.

In this Model, we set up a new reference point IWF-4 to support the communication between the Shared XDMS and IWF, set up a new reference point IWF-5 to support the searching inter-working between IWF and Search Proxy which has been defined to search XML documents stored in any XDM Servers in OMA SIMPLE XDM 2.0. The IWF-4 reference point based on XCAP (Extensible Markup Language Configuration Access Protocol) (Rosenberg, 2006) performs the inter-working functions for the Group and Shared Profile features:

Retrieve the Public Profile and Group information from the Shared XDMS to the IWF Server;

Retrieve the Shared Profile and Shared Group information from the IWF Server to the Shared XDMS.

Add/Remove Group member from the Shared XDMS to the IWF Server;

Add/Remove Group member from the IWF Server to the Shared XDMS;

Leave/Join a Group from the Shared XDMS to the IWF Server;

Leave/Join a Group from the IWF Server to the Shared XDMS.

The IWF-5 reference point based on XCAP performs the inter-working functions for searching:

1. Search for users/groups from the Search Proxy to the IWF Server;

2. Search for users/groups from the IWF Server to the Search Proxy.

Besides, the functions of the IWF-1 reference point should be enhanced:

1. Subscription of changes in state of Group from the Shared XDMS to the IWF;

2. Notification of changes in state of Group from the IWF to the Shared XDMS.

The functions of the IWF-3 reference point should also be enhanced:

1. Retrieve the Public Profile and Group information from the IWF Server to the IMPS Server;

2. Retrieve the Shared Profile and Shared Group information from the IMPS Server to the IWF Server;

3. Subscription of changes in properties of group in the IMPS Server;

4. Notification of changes in group properties;

5. Add/Remove Group member from the IMPS Server to the IWF Server;

6. Add/Remove Group member from the IWF Server to the IMPS Server;

7. Leave/Join a Group from the IMPS Server to the IWF Server;

8. Leave/Join a Group from the IWF Server to the IMPS Server;

9. Search for users/groups from the IWF Server to the IMPS Server;

10. Search for users/groups from the IMPS Server to the IWF Server.

The functions of the IWF should be enhanced too:

1. Protocol conversions between XCAP and SSP;

2. Information Mappings and information format conversions between XDM information and IMPS corresponding information, such as Group information, Public Profile;

3. Operation mappings between XDM service and IMPS corresponding service in the new references.

After the IWF-4 reference point is added, the IMPS users can use the SIMPLE Group for communication and can retrieve the information of the Group participant who is the SIMPLE user whenever they want, as long as the information has been authorized by the SIMPLE user. Also, the SIMPLE users can do the same thing. After the IWF-5 reference point is added, the users can search for the users/groups not only in their service system, but also outside of their service system.

3. Petri net modeling

In order to verify the mapping and the Enhanced Architectural Model, and exclude the probable exceptions in the inter-working, we should set up some means to verify and analyze it.

The inter-working between SIMPLE and IMPS is mainly involved in the conversion between the protocols, and how to realize the inter-working is involved in the Protocol Conversion Methodology. As the Petri Nets, which is based on a set of strict mathematical theories, is very useful for the verification and analysis of the inter-working model (Zhu, 2007), this chapter adopts Petri Nets theory to set up inter-working model to analyze and verify the Enhanced Architectural Model and the related inter-working mapping.

We adopt the protocol conversion methodology of the Petri net model which is proposed by (Green, 1988; Zhu, 2006b) to build the Petri net model for XDM Service in the following section.

3.1. Atomic protocol functions of different reference points

The inter-working of the XDM service is mainly involved in the reference points IWF-1, IWF-3, IWF-4 and IWF-5. As described in (Zhang, 2007), IWF-1 includes the following SIP methods and their corresponding atomic protocol functions, as shown in Table 1.

Atomic Protocol Functions	SIP Request Methods
Subscribe Group Change	SUBSCRIBE (expires>0)
Notify Group Change	NOTIFY
Unsubscribe Group Change	SUBSCRIBE (expires=0)

Table 1.

The atomic protocol functions in IWF-1 for XDM service.

The methods and their atomic protocol functions in IWF-3 are shown in Table 2.

Atomic Protocol Functions	SSP Methods
Retrieve users profile	Get Public Profile Request Get Public Profile Response
Retrieve the Group Information	Get Group Props Request Get Group Props Response
Retrieve the joined member list of a group	Get Joined Member Request Get Joined Member Response
Retrieve the member list of a group	Get Group Member Request Get Group Member Response
Join Group	Join Group Request Join Group Response
Leave Group	Leave Group Request Leave Group Indication
Server Initiated Leave Group	Leave GroupIndication Status
Add Group Member	Add Group Member Request Status
Remove Group Member	Remove Group Member Request Status
Subscribe Group Change	Subscribe Group Change Request Status
Notify Group Change	Group Change Notice Status
Unsubscribe Group Change	Unsubscribe Group Change Request Status
Search for Users or Groups	Search Request Search Response

Table 2.

The atomic protocol functions in IWF-3 for XDM service.

The methods and their atomic protocol functions in IWF-4 are shown in Table 3.

Atomic Protocol Functions	XCAP Request Methods
Retrieve users profile	XCAP GET
Retrieve the Group Information	XCAP GET
Retrieve the member list of a group	XCAP GET
Join Group	XCAP PUT
Leave Group	XCAP DELETE
Add Group Member	XCAP PUT
Remove Group Member	XCAP DELETE

Table 3.

The atomic protocol functions in IWF-4 for XDM service.

Although Table 3 has many request methods of XCAP GET, XCAP PUT and XCAP DELETE, the URI (Uniform Resource Identifier) of every XCAP request method is different, so the request methods listed in the table indicates different concrete requests.

The methods and their atomic protocol functions in IWF-5 are shown in Table 4.

Atomic Protocol Functions	XCAP Request Methods
Search for Users or Groups	XCAP GET

Table 4.

The atomic protocol functions in IWF-5 for XDM service.

Although the methods of XDM service involved in different reference points only include the methods listed from Table 1 to Table 4, in the process of real service execution, the other XDM service methods may invoke some methods described above, for example, the change of the attributes of Group Information will cause the notification of the Group Information in SIMPLE, so will it in IMPS.

3.2. Common subset of atomic protocol functions

The corresponding relation of above atomic protocol functions: the atomic protocol functions in Table 1, Table 3 and Table 4 are corresponding to the atomic protocol functions in Table 2 respectively. We can see that there are some atomic protocol functions in Table 2 which can not be mapped to the other atomic protocol functions in the other tables. That is to say, some atomic protocol functions in IWF-3 can not be corresponding to the atomic protocol functions in the other reference points, i.e. “Retrieve the joined member list of a group” and “Server Initiated Leave Group” can not find their corresponding atomic protocol functions in Table 3. Except the two atomic protocol functions, the other atomic protocol functions can find their corresponding atomic protocol functions very well.

3.3. Decide whether the common subset is satisfied with the inter-working requirement

From the common subset of the atomic protocol functions, it is basically satisfied with the inter-working requirement, but not completely satisfied, so it is soft mismatch (Green, 1988) in the protocol conversion, and we should carry out the protocol complementing for the requirement.

3.4. Protocol complementing

As the common subset is not completely satisfied with the inter-working requirement, we should complement some atomic protocol functions in IWF-4, as shown in Table 5. The XCAP request methods added are based on the existed XCAP request methods. These XCAP request methods have different request URIs.

Atomic Protocol Functions	XCAP Request Methods
Retrieve the joined member list of a group	XCAP GET
Server Initiated Leave Group	XCAP DELETE

Table 5.

The complemented atomic protocol functions in IWF-4 for XDM service.

3.5. The common subset of atomic protocol functions after protocol complementing

After the protocol complementing, we get the whole common subset of atomic protocol functions which the service implementation needs. Table 6 shows mappings of atomic protocol functions between the IWF-1 and IWF-3.

Atomic protocol functions on IWF-1	Atomic protocol functions on IWF-3
Subscribe Group Change	Subscribe Group Change
Notify Group Change	Notify Group Change
Unsubscribe Group Change	Unsubscribe Group Change

Table 6.

Semantic Mapping Relationship of Atomic Protocol Functions between IWF-1 and IWF-3.

The mapping relationship of atomic protocol functions between IWF-4 and IWF-3 is shown in Table 7.

Atomic protocol functions on IWF-4	Atomic protocol functions on IWF-3
Retrieve users profile	Retrieve users profile
Retrieve the Group Information	Retrieve the Group Information
Retrieve the joined member list of a group	Retrieve the joined member list of a group
Retrieve the member list of a group	Retrieve the member list of a group
Join Group	Join Group
Leave Group	Leave Group
Server Initiated Leave Group	Server Initiated Leave Group
Add Group Member	Add Group Member
Remove Group Member	Remove Group Member

Table 7.

Semantic Mapping Relationship of Atomic Protocol Functions between IWF-4 and IWF-3.

The mapping relationship of atomic protocol functions between IWF-5 and IWF-3 is shown in Table 8.

Atomic protocol functions on IWF-5	Atomic protocol functions on IWF-3
Search for Users or Groups	Search for Users or Groups

Table 8.

Semantic Mapping Relationship of Atomic Protocol Functions between IWF-5 and IWF-3.

It should be based on the mapping relationship of XDM information and corresponding methods described in (Zhang, 2007) to realize the conversion of the XDM information and methods, when we implement the inter-working for the information and methods in the common subset.

3.6. Confirmation of the conversion way

Because it involves the SIP, XCAP and SSP protocols in the process of the protocol conversion in the IWF, and it needn’t carry out the conversions between multiple protocols, we decide to convert the protocols directly. Based on the description above, now we can set up a Petri net model to verify the mapping and the Enhanced Architectural Model with strict mathematical analysis and verification in order to find and exclude the probable exceptions in the inter-working.

3.7. Petri net model

Only the atomic protocol functions listed in Table 6 are totally related. Some atomic protocol functions listed in Table 7 often indicate the separate service methods, and always have nothing to do with the other atomic protocol functions listed in the same table, for example, “Retrieve user’s profile” has distant relationship to the “Retrieve the Group Information”, “Retrieve the Group Information” has distant relationship to the “Retrieve the member list of a group”. Someone joining a Group or adding a group member is the precondition for the atomic protocol functions listed in Table 6 to be effective, and it can also make the group to be changed. In the modeling procedure described in this section, we first model the atomic protocol functions listed in Table 6, then model the representative atomic protocol functions listed in Table 7 and Table 8, at last we couple the related Petri net models for the different reference points to an integrated Petri net model by a new coupling criteria.

Comparing multiple computer-aided Petri nets tools, we decide to adopt Visual Object Net++ {4} to construct the Petri net model for the XDM service.

3.7.1. Subscribing group change

According to the service flow and the mapping described in (Zhang, 2007), we construct the MSC (Message Sequence Chart) of Subscribing Group Change, then we educe the corresponding Petri net model, as shown in Figure 2.

Figure 2 is composed of two Sub-Figures and several places and transitions that couple the two Sub-Figures. The symbol “+” before every transition means that the corresponding transition has received a message from the related arc, while the symbol “-” means that the corresponding transition has sent out a message.

Sub-Figure 2(a) shows the Petri net model for Subscribing Group Change in IWF-1. The transitions and their possible occurring sequences, which are within three round-corner rectangles in Sub-Figure 2(a) represent the following atomic protocol functions: Subscribe Group Change, Notify Group Change and Unsubscribe Group Change. The six places (P6, P7, P8, P10, P11, P12) in Sub-Figure 2(a) represent the state elements in external channel between Shared XDMS and IWF. Sub-Figure 2(b) shows the Petri net model for Subscribing Group Change in IWF-3. The transitions and their possible occurring sequences, which are within three round-corner rectangles in Sub-Figure 2(b) represent the following atomic protocol functions: Subscribe Group Change, Notify Group Change and Unsubscribe Group Change. The six places (P29, P30, P31, P32, P33, P34) in Sub-Figure 2(b) represent the state elements in external channel between IWF and IMPS server.

According to Table 6 and the coupling criteria proposed in (Zhu, 2007), we couple the Petri net model in Sub-Figure 2(a) and the Petri net model in Sub-Figure 2(b) into an integrated Petri net model for Subscribing Group Change, as shown in Figure 2. The six places (P18, P19, P20, P21, P22, P23) represent the state elements in internal channel in IWF.

Figure 2.

The Petri net model of Subscribing Group Change.

This model describes the case of Subscribing Group State on the condition that the subscribing request is initiated from IMPS server. The case which indicates the subscribing request initiated from Shared XDMS is not in the same session with the case showed in Figure 2, and the groups which the two cases represent are different, so the Petri net model which describes the case on the condition that the subscribing request is initiated from Shared XDMS should be set up in another model. In the construction process, the corresponding places, transitions and related arcs should be constructed in a reverse direction from the model described in Figure 2, according to real condition of the service implementation, not simply constructed directly from the above model in the reverse direction. The two models are symmetrical in some degree.

Because the model shown in Figure 2 has unexpected conflicts and deadlocks (see the analysis of the model in the Section 4), it represents that the existing mapping may have some exceptions or unconsidered issues. In order to make the conflicts and deadlocks free, we construct the modified Petri net models, as shown in Sub-Figure 4(b) and Sub-Figure 4(e).

Based on the model shown in Figure 2, we add a series of places and transitions to build the model shown in Sub-Figure 4(b) and Sub-Figure 4(e), for example, add P9 in the external channel between Shared XDMS and IWF, add T11 and T12 in the IWF. Some places and transitions added represent the new mappings, such as T5, P9 and T12 represent a new mapping, i.e. the 487 Response of SIP sent from IWF to Shared XDMS, while some represent the new state, such as P39 represents the state in which the system only receives the notification of group state change (i.e. it doesn’t receive the notification of unsubscribing group change).

3.7.2. Join group

Join Group is one of the representative atomic protocol functions listed in Table 7, and its completion is the precondition of the cases listed in Table 6. The implementation of Add Group Member is similar to that of Join Group. Leave Group, Server Initiated Leave Group and Remove Group Member are almost the reverse operation of Join Group (or Add Group Member). Except those atomic protocol functions, the other atomic protocol functions are all independent. The cases described by the atomic protocol functions listed in Table 8 are also independent, so this section takes an example of Join Group to construct the corresponding Petri net model, as shown in Figure 3.

Figure 3.

The Petri net model of Join Group.

Figure 3 is composed of two Sub-Figures and several places and transitions that couple the two Sub-Figures. Sub-Figure 3(a) shows the Petri net model for Join Group in IWF-4. The transitions and their possible occurring sequences, which are within the round-corner rectangle in Sub-Figure 3(a) represent the atomic protocol function: Join Group. The two places (P43, P44) in Sub-Figure 3(a) represent the state elements in external channel between Shared XDMS and IWF. Sub-Figure 3(b) shows the Petri net model for Join Group in IWF-3. The transitions and their possible occurring sequences, which are within the round-corner rectangle in Sub-Figure 3(b) represent the atomic protocol function: Join Group. The two places (P51, P52) in Sub-Figure 3(b) represent the state elements in external channel between IWF and IMPS server.

According to Table 7 and the coupling criteria proposed in (Zhu, 2007), we couple the Petri net model in Sub-Figure 3(a) and the Petri net model in Sub-Figure 3(b) into an integrated Petri net model for Join Group, as shown in Figure 3. The two places (P47, P48) represent the state elements in internal channel in IWF.

This model describes the case of Join Group on the condition that the joining request is initiated from IMPS server, just like the analysis described in Section 3.7.1, the Petri net model which describes the case on the condition that the joining request is initiated from Shared XDMS should be set up in another model.

3.7.3. The coupled model and the coupling criteria

The message flows between IWF-1 and IWF-3 need cooperation with the message flows between IWF-4 and IWF-3, so the Petri net models described above should be further coupled together. This chapter takes an example of coupling the Join Group, Subscribing Group Change and Leave Group into an integrated Petri net model to show how an integrated case of XDM service is completed. Other small cases represented by other atomic protocol functions can replace one of the small cases represented by Join Group, Subscribing Group Change or Leave Group in order to model other integrated case. For example, the case of Add Group Member can replace the case of Join Group, the case of Retrieve the Member List of a Group can replace the case of Subscribe Group Change, the difference between Retrieve the Member List of a Group and Subscribe Group Change is that the two atomic protocol functions are involved in different relationships between different reference points, so in order to simplify the coupled model, the service state will enter the case of Subscribe Group Change directly after the user has joined the group in the coupled model. When a user unsubscribe the change of a group, the user may leave the group, or be removed by the group manager, in this chapter, we only consider the case of user leaving group for the convenient modeling. The coupled model is shown in Figure 4. Compared to Figure 2 and Figure 3, the same part in Figure 4 is indicated as suspension points. The Petri net model of Leave Group is almost like the Petri net model of Join Group, so we don’t describe the Petri net model separately, but describe it in the coupled model, as shown in the last part of Figure 4.

The coupling criteria proposed in (Zhu, 2007), is referenced by us when we commence coupling. In the criteria, the coupling of service parallel execution is realized by adding new places and changing the direction of directed arc from the places. We don’t adopt the criteria completely, but create a new criteria:

• Adding new places and transitions, changing the direction of directed arc at the same time, such as P55, T40, P70, T49;

• Besides the above rule, the value of the token in the places connected with the coupling transitions in the original model should be set to zero, and the direction of the corresponding directed arc should be changed, in order to ensure the service is executed naturally, such that the values of the tokens in P35 and P68 are set to zero, the direction of T39 pointing to P53 is changed to point to P55.

The coupling of service serial execution is realized by the new criteria. In the criteria, the added places, transitions and the directed arcs connected with these places and transitions are the coupling points. These coupling points are those parts in which the messages in different reference points should be cooperated, which has special state and different events, so the coupling points should be paid more attention to when we implement the system. The Petri net model coupled by the new criteria meets all properties of a correct Petri net model, please see the analysis of the model in the Section 4.

Figure 4.

The coupled Petri net model for XDM service.

4. Analysis of the model

We analyze the properties of the Petri net model by combined analysis method of simulation analysis, reachability analysis, invariant analysis. The simulation analysis is completed by Visual Object NET++ and PIPE2 (Platform Independent Petri Net Editor 2) {5}, and the invariant analysis is completed by PIPE2. A correct Petri net model for protocol conversion should have the following attributes: Boundedness, Conflict freeness, Contact freeness, Deadlock freeness, Livelock freeness, Resetability, S-invariant (Zhu, 2007).

The coupled Petri net model has remained the properties of each original model, so we only analyze the properties of the coupled Petri net model from which the properties of each original model can be known, for reducing the length of this chapter.

We make the simulation analysis by Visual Object Net++ and PIPE2 for Figure 4. From the analysis of structural properties of the model, the model is not a pure net, not a simple net either. But from the analysis of state space of the model, the model is safe, i.e. 1-Boundedness, live, Contact freeness, Deadlock freeness and Livelock freeness.

There are four possible conflict groups: {T26, T30} with the reachable marking M¹ (P4=P16=P27=P31=P37=1, the token values of the rest places are 0), {T18, T22} with the reachable marking M² (P4=P16=P20=P26=P33=P40=1, the token values of the rest places are 0), {T10, T14} with the reachable marking M³ (P4=P8=P15=P22=P28=P40=1, the token values of the rest places are 0), {T3, T6} with the reachable marking M⁴ (P3=P11=P17=P28=P40=1, the token values of the rest places are 0). This model is coupled with the modified Petri net model from the original model shown in Figure 2, after resolving the problems found from the original model. In the original model, there are four conflict groups described above, but in any of the markings of M² and M³, the happening of any of the transitions in the conflict group will cause the deadlock of the system, also, in the marking of M¹, the happening of T30 will cause the deadlock of the system, in the marking of M⁴, the happening of T3 will cause the deadlock of the system. In fact, it indicates that there are some exceptions in the original mapping, for example, in the marking M⁴, when Shared XDMS has just sent the NOTIFY, i.e. T3 has just happened, but at the same time, IWF has just received the UnsubscribeGroupChangeRequest from IMPS server and sent out SIP SUBSCRIBE converted from the request for unsubscribing, i.e. T14 has also happened, it means that IWF has stopped process the SIP NOTIFY when IWF has just received NOTIFY, because it has received the unsubscribing request from IMPS server, and at this time, it is not good for IWF to convert NOTIFY to GroupChangeNotice which will be sent to IMPS server in the next step, or throw away NOTIFY (if NOTIFY is thrown away, it betrays the principle of SIP), so the system is “dead”. In order to resolve the problem, we extend the message flow in the mapping. When IWF has received NOTIFY and unsubscribing request, IWF sends the 487 Response (Request Terminated) to Shared XDMS, so we add T5, T12 and P9 to mark this response. In order to distinguish the NOTIFY received normally from the NOTIFY received abnormally (i.e. IWF has received the unsubscribing request and sent it out when IWF has received NOTIFY), T11 is added to represent receiving NOTIFY abnormally. After the addition has been done, the deadlock brought from M4 will never happen, and the conflict brought from M4 will become the “untrue” conflict. When T3 has happened, it is sure for T6 to have a chance to happen after some transitions have happened in the Petri net model, so we deem the conflicts are not the actual conflicts. It meets the principles of a correct Petri net model, for the Petri net model can well guide the development of a real system and well simulate the possible exceptions in the real environment after the Petri net model has been modified by the above way, which is consistent with the real application environment (it is possible for the request to be delayed for some reasons). It shows the strong capability of strict mathematical analysis of Petri net in another way, which can expose the possible problems before system implementation by the properties of deadlock, conflict and so on, and can help us to resolve these possible problems and decrease the errors in system implementation, as the resolving way of Petri net. If we want to resolve these conflicts further, we can treat T6 and T3 as immediate transition and timed transition, or give every transition a different execution probability, which are not shown in this chapter for model simplicity reason. There are similar problems in the marking of M¹, M² and M³, but in these cases, we don’t add a message mapping indicating the exception, but use the Status of SSP, because the different status codes of Status can be used to represent different exceptions, such as T28 and T29 are all pointing to P32. The different status codes of Status are all mapped to SIP 200 OK, which is made in order to simplify the model, otherwise the model will be very complex. In fact, when NOTIFY is sent to IMPS server through IWF, the NOTIFY has been transmitted successfully from Shared XDMS point of view. In resolving the conflicts in the marking M¹, besides using the methods used to resolve the conflicts in the other markings, we add P39 to distinguish the difference of the tokens arrived at P38 and P39, in order to restrict the happening of different transitions, i.e. restrict the happening of T28 and T29, which is also a good way to resolving the conflict.

We make the invariant analysis for the model shown in Figure 4 by PIPE2. The five nonnegative T-Invariants exported from PIPE2 are shown by matrix J, the two nonnegative S-Invariants exported from PIPE2 are shown by matrix I, as shown in Figure 5.

From the nonnegative T-Invariants shown in Figure 5, the Petri net model is covered by nonnegative T-Invariants, so it is bounded, live and resetable.

The equation of S-Invariants got from the two nonnegative S-Invariants are:

$$\text{M}\left({\text{P}}_{\text{1}}\right)+\text{ M}\left({\text{P}}_{\text{2}}\right)+\text{ M}\left({\text{P}}_{\text{3}}\right)+\text{ M}\left({\text{P}}_{\text{4}}\right)+\text{ M}\left({\text{P}}_{\text{5}}\right)=\text{1}$$ E1

$$\text{M}\left({\text{P}}_{\text{1}}\right)+\text{ M}\left({\text{P}}_{\text{2}}\right)+\text{ M}\left({\text{P}}_{\text{3}}\right)+\text{ M}\left({\text{P}}_{\text{5}}\right)+\text{ M}\left({\text{P}}_{\text{8}}\right)+\text{ M}\left({\text{P}}_{\text{9}}\right)+\text{ M}\left({\text{P}}_{\text{1}0}\right)+\text{ M}\left({\text{P}}_{\text{16}}\right)=\text{1}$$ E2

The equation (1) describes the states of the places in IWF-1 within Shared XDMS, which is consistent with the assumed execution result of the mapping for Shared XDMS and meets the requirement of protocol conversion for S-Invariants. The equation (2) describes the inter-working part in IWF-1 between Shared XDMS and IWF, which is also consistent with the assumption and indicates that in the process of the inter-working there has sequence for Shared XDMS, the external channel and IWF to process NOTIFY and unsubscribing request after NOTIFY has been sent out, i.e. it ensures that the received NOTIFY can be processed after the unsubscribing request has been received, so as to ensure the service security of Shared XDMS and IWF in the inter-working. Because the S-Invariants above are just the bases of the S-Invariants, the other S-Invariants can be constructed by the linear combinations of the above S-Invariants. We make the test for the other S-Invariants, and the result of test indicates that two place sets for processing SIP and SSP protocols in IWF are corresponding to two S-Invariants, four place sets for processing XCAP and SSP protocols in IWF are corresponding to four S-Invariants, the place sets for processing the communications between Shared XDMS and IWF are corresponding to two S-Invariants, the place set for processing the communications between IMPS server and IWF is corresponding to one S-Invariants.

As shown in the above analysis, the Petri net model meets all properties of a correct Petri net model, it is reasonable and viable for the mapping proposed for the XDM service. The execution of the coupled Petri net model can prove that the model can find out and resolve the possible exception, the added IWF-4 and IWF-5 can completely work well with the existed reference points (IWF-1, IWF-2 and IWF-3), so it is reasonable and viable for the Enhanced Architectural Model proposed in (Zhang, 2007).

Figure 5.

The nonnegative T-Invariants and nonnegative S-Invariants in the coupled Petri net model.

5. Resolving of conflict

In the process of the Petri net modeling, we don’t use the methods proposed in (Zhu, 2007) for resolving the conflicts, but resolve the conflicts according to the real service execution. There are two concrete methods in this chapter: adding service mapping, adding place (i.e. adding the state of service execution) to restrict the happening of the transitions, such as P39. Besides the two methods, there are some other methods to resolve the conflicts, such as the methods proposed in (Lin, 2005): importing priority, giving different predications of implementation condition, giving different implementation time of the transition, giving different implementation possibility of a transition, and so on; the methods proposed in (Zhu, 2006a; Zhu, 2007): adding complementary place and side place, importing inhibitor arc and static testing arc, and so on.

6. Conclusions

In this chapter, with the procedure of Protocol Conversion Methodology, a Petri net model is constructed to verify the mapping and the Enhanced Architectural Model proposed in (Zhang, 2007), find and exclude the possible exceptions in the inter-working. After the strict mathematical analysis and verification for the model, which prove that the model meets all properties of a correct Petri net model, the mapping and the Enhanced Architectural Model are proved to be reasonable and viable, and the probable exceptions in the inter-working can be found and excluded. During the modeling experiences of the inter-working with Petri Nets, a new coupling criteria for Petri net and some new methods for solving the conflict of a Petri Net are proposed, and the methodology is summarized, which enriches the application of Petri Nets for the Protocol Conversion Methodology.

There are many standards or solutions for XDM, as the concept of XDM is almost same among different standards or solutions, the inter-working model proposed in this chapter has highly universal value and can provide an applicable reference for the inter-working between other standards, such as the inter-working between SIMPLE and XMPP.

Acknowledgments

This work was jointly supported by: (1) National Science Fund for Distinguished Young Scholars (No. 60525110); (2) National 973 Program (No. 2007CB307100, 2007CB307103); (3) Program for New Century Excellent Talents in University (No. NCET-04-0111); (4) Development Fund Project for Electronic and Information Industry (Mobile Service and Application System Based on 3G); (5) National Specific Project for Hi-tech Industrialization and Information Equipments (Mobile Intelligent Network Supporting Value-added Data Services).