Ontology-based Dynamic Process Collaboration in Service-Oriented Architecture

Abstract

Service collaboration is important in service- oriented architecture (SOA). While service collaboration protocols for data exchange are well explored, the dynamic process collaboration (DPC) is still a challenge. DPC requires not only exchanging meaningful information between collaboration parties, but also performing collaboration workflow matching based on collaboration ontology. To do this, DPC needs service collaboration ontology modeling, service collaboration discovery and establishment based on collaboration ontology and runtime recomposition capability. This paper presents an ontology-based dynamic process collaboration (ODPC) framework with these features to facilitate DPC.

Full text

Ontology-based Dynamic Process Collaboration in Service-Oriented
Architecture 1
W.T. Tsai, Qian Huang, Jingj ing Xu, Yinong Chen, Ray Paul*
Arizona State University, Tempe, AZ 85287-8809, USA
{wtsai, qhuang, jingjing.xu, yinong}@asu.edu
*Department of Defense, Washington D.C. USA
Ray.Paul@osd.pentagon.mil
1 The contents of this paper were developed under a grant from US Department of Defense and the Fund for the Improvement
of Postsecondary Education (FIPSE), U.S. Department of Education. However, these contents do not necessarily represent the
policy of the Department of Education, and you should not assume endorsement by the Federal Government.
Abstract
Service collaboration is important in Service-
Oriented Architecture (SOA). While service
collaboration protocols for data exchange are well
explored, the Dynamic Process Collaboration (DPC)
is still a challenge. DPC requires not only exchanging
meaningful information between collaboration parties,
but also performing collaboration workflow matching
based on collaboration ontology. To do this, DPC
needs service collaboration ontology modeling, service
collaboration discovery and establishment based on
collaboration ontology and runtime recomposition
capability. This paper presents an Ontology-based
Dynamic Process Collaboration (ODPC) framework
with these features to facilitate DPC.
1 Introduction
Current Service-Oriented Architecture (SOA)
allows services to be published in a service registry
and exchange data through the SOAP protocol. It is the
user’s responsibility to discover and select service
from a broker’s registry and compose the SOA
application. In this approach, the application developer
needs to select and compose applications using
services discovered. Also the current UDDI [6] service
registry does not contain enough information for
service selection. Thus it is difficult to compose
applications automatically and to establish dynamic
service collaboration.
Dynamic Process Collaboration (DPC) addresses
these issues by introducing additional ontology [5]
information to the service profile, including formal or
semi-formal collaboration specification, into the
service specifications. Standard ontology systems are
used to exchange messages between services. DPC
allows an SOA application to commit process
collaboration at runtime with new services not known
before. OASIS CPP/CPA (Collaboration Protocol
Profile and Agreement) [4] defines the dynamic
message exchange capability for participating services,
while in DPC, not only the message exchange
agreements can be dynamically negotiated, but also the
way the participating services interact with each other
can be dynamically established [2] [8].
A shopping example can illustrate the DPC process:
two parties, one buyer and one seller, and they do not
know each other before. The buyer (A) starts to search
the seller (B) (dynamic discovery). Once A founds B,
they start a conversation:
The above conversation may look simple, but it
illustrates key iss ues in DPC:
- Communication from scratch: Both A and B do not
know each other. Not only they do not know each
other (including the kinds of services needed or
requested), they do not know how to interact with
each other in the first place as conversation top ics
can be changed dynamically (such as changing
Coke from Pepsi). Thus, all the participants need to
know each other via dynamic discovery protoco ls,
and they need to discover not only services
provided, but also how services will be provided.
- Ontology-based communication: The data
exchanged need to carry semantic information, and
A: Do you have Coke?
B: Sorry no Coke, how about Pepsi?
A: Pepsi is fine.
B: I take no cash, credit card only, do you have one?
A: Yes, I do.
B: Good, please give me the card number. .
A: Ok.
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

this needs an ontology system. For example, B does
not sell Coke, but B can immediately recognize that
A needs a drink (to be more specific soda). Based
on this understanding and stock availability, B
indicates Pepsi as a possible replacement. Similarly,
both participants understand that credit cards are
one kind of payment method, and they can replace
cash. If the participating parties use different
ontology systems, they must have a mapping
mechanism between concepts in these two ontology
systems so that two parties can understand each
other. Furthermore, with different ontology systems,
different solutions can be proposed at runtime. For
example, instead offering Pepsi, tea may be offered
if the parties are located in tea drinking countries.
Based on the data exchange agreement just reached,
they need to carry out the collaboration process, thus
they might have a conversation like below:
From the conversation, it is clear that both parties
need to match their collaboration workflow with each
other. In this example, they both support the “standard
credit card payment” collaboration pattern, thus the
collaboration can be established. The example above
can be shown in Figure 1:
Provide Credit Card Information
Provide Signature
Take Receipt and Product
Wait
Collect Credit Card Data
Collect Signature
Provide Receipt and Product
Initiate Charging Request
SCCP-A SCCP-B
Provide Product and Quantity Collect Product and Quantity
(SCCP = Abbr. of Standard Credit Card Payment)
Provide Credit Card Information
Provide Signature
Take Receipt and Product
Wait
Collect Credit Card Data
Collect Signature
Provide Receipt and Product
Initiate Charging Request
Provide Product and Quantity Collect Product and Quantity
Complete SCCP
Figure 1 Collaboration Matching
In the above process, the trading parties need only
to claim which process (collaboration pattern) they
support and what kind of roles they play in the
collaboration (seller or buyer). One can see that A
supports pattern “SCCP-A” and B supports pattern
“SCCP-B”, thus their collaboration profile can be
matched and form a complete “Standard Credit Card
Payment” process.
This paper proposes an ontology-based DPC
framework to support this ki nd of communication. In
the specification phase, a process modeling language
such as BPEL [3] or PSML-S [7] can be used to
specify the application template, and the OWL-S [2] or
PSML-O can be used to model the service
collaboration ontology system. The Collaboration
Control Service will perform the collaboration pattern
matching based on the collaboration ontology in the
application template and service profile, then the
automated code generation service is invoked to
generate executable code based on the target system’s
application model. The generated code can be
deployed to the environment using the automated
deployment service [9]. PSML-C [8] has a set of
service collaboration specification as listed in Table 1,
which helps to model the service collaboration profile:
Table 1: PSML-C Service Collaboration Specifications
Spec Information
ECPP Collaboration capabilities of the service.
ECPA Collaboration interactions among the
collaborative services.
USS Specifies how to carry out a specific
collaboration based on a given ECPP.
IPS Internal control logic of each service.
CIS Service Interfaces for collaboration.
• ECPP (Extended Collaboration Protocol Profile)
• ECPA (Extended Collaboration Protocol Agreement)
• USS (Use Scenario Specification)
• IPS (Internal Process Specification)
• CIS (Collaboration Interface Specification)
Figure 2 shows the relationships between major
blocks in the extended DPC.
Service
IPS
CIS
ECPP USS
ECPA
Figure 2 Dynamic Collaboration Protocol
In the entire process, only the process model of the
application template needs to be changed and the
required services are discovered at runtime. All the
remaining steps can be performed using automated
process. Once the system requirement changes, one
needs only to make minor modifications or use another
existing application template. The collaboration
control service will automatically re-match and re-
discover the services with compatible collaboration
B: I support standard credit card payment
process. My process is like below:
- Collect product and quantity information
- Collect credit card information
- Initiate charging request and wait for approval
- Collect signature
- Provide receipt and product
A: Yes I support standard credit card payment
process too. My process is like below:
- Provide product and quantity information
- Provide credit card information and wait
- Provide signature
- Receive receipt and product
B: Good, let start trading.
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

patterns, thus make the reconfiguration and re-
composition of the system possible at runtime with the
support of DPC.
This paper is organized as follows. Section 2
presents a collaboration hierarchy and associated
ontology information to support SOA collaboration.
Section 3 presents the overall framework of the
Ontology-based Dynamic Process Collaboration
(ODPC). Section 4 uses an example to illustrate the
application. Section 5 concludes this paper.
2 SOA Collaboration and Ontology
Collaboration can be carried out at different layers
of services, as shown in the hierarchy in Figure 3 [8] .
Figure 3 Collaboration Hierarchy
There are five layers in the collaboration hierarchy:
- Protocol Interoperability Layer
- Static Data Interoperability Layer
- Static Process Collaboration Layer
- Dynamic Data Interoperability Layer
- Dynamic Process Collaboration (DPC) Layer
Under DPC, both data collaboration agreement and
the collaboration workflow are negotiated at runtime.
This is the most challenging case. However, it brings
great flexibility for the deployed SOA application to
meet the continuously changing environment.
2.1 Three-Tier Pattern Based Collaboration
The ODPC framework uses a 3-tier and pattern-
based collaboration architecture as shown in Figure 4.
At each layer, there is the corresponding ontology
which describes the concepts and relations in that layer.
The three ontology systems are Application Ontology
(AO), Collaboration Ontology (CO), and Service
Ontology (CO) respectively. In general, AO stores
information related to applications, CO collaboration
patterns, and SO services. These ontology systems are
related to and reference each other. For example, an
application in AO may reference several collaboration
patterns in CO and services in SO as candidate
solutions for the application. This is unique as this
breaks a traditional ontology system into three separate
systems according to the structure of SOA software.
This approach facilitates dynamic application
composition and service discovery.
Furthermore, all the ontology systems (AO, CO and
SO) use the same process modeling language to
address the interoperability issue. An application in
AO uses the language to specify the overall system
architecture and process flow, and it references
collaboration patterns modeled using the same
language. Both the application and its associated
collaboration patterns also reference to services
modeled using the same language.
These ontology systems also have the
corresponding extended UDDI/ebXML [4][6]
registries to support registration, query, and discovery.
Thus, common service brokers such as UDDI/ebXML
need to be extended because they support service
discovery only, but the OPDC needs discovery at three
layers: applications, collaborations, and services.
Figure 4 3-Tier Pattern-Based Framework
2.2 Application Ontology
AO defines the concepts and the relations related to
applications such as application types, classification,
and application templates. For example, e-business
may include online shopping, travel reservations and
service purchasing as shown in Figure 5. Each item in
the AO has attributes such as names and environments.
Items in AO also have relationships with each other.
For example, an online book shopping is a specific
kind of e-business applications. Via attributes, AO can
also specify various constraints on these applications.
AO also cross references to CO and SO.
Specifically, an application may reference specific
collaboration patterns in the CO that are applicable to
the application. For example, an online book shopping
application may reference the following collaboration
patterns: book browsing, payment system, and
shipment. Similarly, the same application may
reference related services in SO. In this way, an
application developer can identify the related
collaborations and services quickly for composition.
Furthermore, as collaboration patterns in CO also
reference to services in SO, thus via collaboration
patterns, an application can identify its related services.
Figure 5 shows a classification tree for e-business
applications, and an online travel reservation is one
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

such application, and a travel reservation system can
be further classified into hotel reservation, air ticket
reservation, and car rental reservation.
E-business
Application
Travel
Reserve
Service
Purchasing
Hotel Air
Ticket Car... ...
... Online
Shopping
Book CD Beauty...
SubclassOf
(Disjoint)
SubclassOf
(Disjoint) SubclassOf
(Disjoint)
SubclassOf
(Disjoint)
Browsing Payment Shipment
Online
CheckIn
ComponentOf ComponentOf
...
Figure 5 E-business Application Ontology
2.3 Collaboration Ontology
CO specifies the concepts and relations of
collaboration patterns. CO also contains a
classification scheme like AO and SO, but items in CO
are collaboration patterns. For example, in Figure 6,
there are several payment methods, such as wire
transfer, debit card, and credit card. Under each
category, they are divided into subclasses accord ing to
different collaboration routines, such as regular
transactions, refund transactions, and over-limit
transactions. When a collaboration pattern is registered
in a collaboration registry, it will be placed under the
corresponding concept. CO also references both AO
and CO, and essentially provides the linkage between
AO and CO. In this way, one can trace from an
application in the AO, to its associated collaboration
patterns in the CO, and then to the related services in
the SO.
Payment Method
Credit Card TransactionWire Transfer
CC Regular
Transaction
CC Refund
Transaction
SubclassOf
(Disjoint)
Regular
Transaction
Refund
Transaction
Over
Limited
Single
Account
SubclassOf
(Disjoint)
Distributed
Account
Debit Card Transaction
DC Refund
Transaction
DC Regular
Transaction
SubclassOf
(Disjoint)
Over
Limited
SubclassOf
(Disjoint)/Compose
SubclassOf
(Disjoint)
ComposedOf
Compose
DC Network
Provider
CC Network
Provider
Figure 6 Collaboration Ontology of Payment Methods
2.4 Service Ontology
SO stores concepts and relations of related services,
and also has classification trees with a reasoning
mechanism. In SO, both atomic and composite
services will be presented. As shown in Figure 7,
several payment methods, such as by check, debit card,
and credit card are available. In the example, when the
Visa-Card payment service is requested, the services
registered under the visa card payment will be returned.
If no such service is available, the system will return a
similar service. For example, the system may return
AMEX or Master-Card payment services by using the
information in the SO. Furthermore, one can apply
semantic distance to identify those related concepts [1].
SO also cross references to AO and CO for
application and service discovery. One can start from
AO to identify the needed services or collaboration
patterns, but one can also start from a given service,
and identify the related applications or collaboration
patterns that use the service.
One can wrap a collaboration pattern as a service,
and make the service available for discovery and
composition. However, once a service is wrapped, its
internal logic is supposedly hidden from the user; on
the other hand, as a collaboration pattern, the user can
still see the participating services as well as the
collaboration process. In this way, a software provider
has at least two choices in providing services, either as
a black-box service that exposes specifications only, or
as a collaboration template linking multiple services
for more flexible customization.
Figure 7 Payment Services Ontology
2.5 Symmetrical Collaboration Model
The collaboration patterns are specified in a
symmetrical manner. The runtime behavior between
the two collaborative services can be illustrated in
Figure 8:
Figure 8 Symmetrical Collaboration Model
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

From the diagram, one can see that:
- The collaboration pattern is divided into two parties,
say Party A and Party B, and each party supports
one side of collaboration.
- Collaboration patterns are stored in the
collaboration pattern repository with CO.
- Services are specified using SO with their
collaboration profile. If a service finds another
service that matching its collaboration profile, the
collaboration can be established. A sample
collaboration pattern is shown below:
In this symmetrical collaboration model, each service
can either serve as client” or “server” as long as they
can match their collaboration profiles with each other.
For multi-party collaboration, one may decompose the
collaboration into multiple bi-party collaboration
processes and fit it into the above process. This can be
done incrementally, e.g., for 3-party communication, A
and B first establish their collaboration, and then the
combined process (A&B) establishes a collaboration
with C with the same approach.
3 Overall Framework
Figure 9 shows the overall ODPC framework, and it
consists of application servers, application template
registry, collaboration pattern registry, extended
service registry, ontology system, and information
services. During the execution, the user can access the
application server via the interaction service provided
by the application server through the internet to control
the application composition process. A key component
on the application server is the Collaboration Control
Service, which retrieves application templates from the
application template registry, and then extracts the
collaboration profiles from templates and performs the
matching.
Figure 9 Overall ODPC Framework
Once all required services are found and the
application template is completed, the Code
Generation service will be invoked to generate the
system. Deployment Service can be used to deploy the
application to the specified environment if needed.
During the whole process, the user can access the
application server through the Interaction Service to
control and monitor the application composition
process.
3.1 Collaboration Control Service
Collaboration Control Service plays a key role on
application server for application composition. The
automated process is illustrated by Figure 10 and the
steps marked in the figure are described as follows:
<Collaboration Profile>
<Collaboration Pattern>
<UUID>3d5a9c32-c2d3-11db-8314-0800200c9a66</UUID>
<Name>Credit Card Payment</Name>
<Classification>w3c.webservice.collaboration.pattern.synchr
onized.financial.payment.credit</Classification>
<Actor>Bank</Actor>
<Actor>Seller</Actor>
<Process>
using ACTOR::Seller
using ACTOR::Bank
do ACTION Seller.SendInfo
if (! Bank.Confirmed)
{
do ACTION Seller.Reject
retu rn
}
do ACTION Bank.Approve
do ACTION Seller.Signature
</Process>
...
</Collaboration Pattern>
<Collaboration Pattern>
<UUID>3d5a9c32-c2d3-11db-8314-0800200c9a67</UUID>
<Name>Debit Card Payment</Name>
...
</Collaboration Pattern>
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

Figure 10 Collaboration Control Service
1) The developer contacts the application template
registry to obtain desired application template;
2) The registry returns the satisfied application
template. The collaboration points in the
application template are denoted by solid circles;
3) The collaboration control service extracts
collaboration points from the application template,
contacts the collaboration pattern registry to
retrieve the collaboration workflow and
collaboration profile information;
4) The collaboration pattern registry returns required
collaboration pattern information;
5) The collaboration control service contacts the
collaboration matching agent to find qualified
services for the collaboration profile;
6) The collaboration matching agent contacts the
service registry for service discovery;
7) The service registry returns the needed service
references to the collaboration matching agent;
8) The collaboration matching agent returns required
service references to the collaboration control
service;
9) The collaboration control service completes the
application composition based on the application
template and the information retrieved. It
dynamically binds service and generates the
collaboration workflow based on the collaboration
pattern, service interface and ontology information.
The completed application specification is sent to
the code generation service for automatic code
generation;
10) The code generation service returns the generated
code to the collaboration control service;
11) The collaboration control service invokes
deployment service to deploy the application;
12) The deployment service sends back feedback.
During the process above, the user can monitor and
control the entire process via the interaction service at
any time.
3.2 Service Profile Modeling
Figure 11 shows a service collaboration profile.
Collaboration Profile
Collaboration
Pattern
Ontology
Collaboration
Pattern
Matching
Interface Collaboration
Interface
Ontology
Collaboration
Data Ontology
Collaboration
Policy
Ontology
Service Implementation
Service Policy
Enforcement
Engine
Service
Interface
(E-CPP)
Interface
Parameter /
Results (CPP)
Matching
/Update PresentedBy Present
/Enforce
PresentedBy PresentedBy
Local Collaboration Pattern
Repository (WS-CDL, Use Scenario)
Figure 11 Service Collaboration Profile
In the diagram:
- The service owns a Local Collaboration Pattern
Repository which stores the detailed collaboration
patterns it currently supports
- The service provides a public collaboration pattern
matching interface. This interface receives inquiries
for collaboration. It answers yes if its local
repository already contains the requested
collaboration pattern. Or it will try to match its
collaboration capability with the requested
collaboration pattern. If it meets the collaboration
requirements, it will answer yes and store the new
pattern into the registry..
- The collaboration pattern ontology system stores
the existing and supported collaboration patterns
for fast matching.
- The collaboration interface ontology system stores
the semantic interface (functionality) information
that it supports. This information can include
description written by OWL-S [2] or Extended
CPP (E-CPP) [8].
- The collaboration data ontology system stores the
message exchanging capability for the service. This
can be modeled using current CPP specifications.
- The collaboration policy ontology system stores
the policy constraints the service must keep during
the collaboration. The policy constraints are
enforced by its internal policy enforcement engine,
or by a policy enforcement agent from outside.
Figure 12 shows the matching process based on
service collaboration profile. The service side
collaboration pattern ontology is like one piece of the
puzzle. Only certain puzzle pieces can match its
collaboration profile and establishes collaboration
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

Figure 12 Service Collaboration Pattern Matching
4 Case Study
This section presents a case study to show how a
composite application can be generated to illustrate the
ODPC framework. Figure 13 describes an online
shopping service. The application template is specified
as shown in the workflow. The application template is
initially incomplete and two collaboration points (the
shaded circle) are specified as “Payment” and
“Shipping”, each of which owns its collaboration
pattern ontology information.
Figure 13 Online Shopping Application Template
Figure 14 shows the collaboration pattern matching
process for the online shopping service. Several kinds
of “Payment” and “Shipping” collaboration patterns
are available in the pattern registry and the
collaboration profile of the collaboration points in the
online shopping example may reference to these
patterns. For example, the payment process supports at
least three different collaboration patterns: Debit Card
Payment Pattern, Credit Card Payment Pattern, and
Check Payment Pattern, each of which has different
workflow and service requirements. Similarly, the
shipping process in the pattern registry also has three
different collaboration patterns: Express Shipping
Pattern, Priority Shipping Pattern, and Economic
Shipping Pattern.
Furthermore, the service providers register their
services to the service registry declaring the kinds of
“Payment” and “Shipping” collaboration patterns
supported. The Debit Card Payment Service and Credit
Card Payment Service support the corresponding Debit
and Credit Card Payment collaboration pattern, which
are provided by all card companies: VISA, Master,
AMEX and one service can support multiple
collaboration patterns, as can be seen in the figure: the
Debit Card Payment Service can also support the
Credit Card Payment Pattern, because some banks
allow their debit cards to be used in the same way as
credit cards when certain constraints apply. The Check
Payment Service supports the Check Payment
collaboration pattern and is supported by virtually all
banks. The Express, Priority, and Economic shipping
services support the corresponding collaboration
patterns and are supported by all registered shipping
service providers: UPS, Fedex and USPS.
Figure 14 Online Shopping Collaboration Matching
Figure 15 shows the underlying ontology for the
payment part in the online shopping collaboration
framework. Part of corresponding axioms is listed as
following in which A, B denotes the nodes in the
ontology:
1. Disjoint(A, B) ÅÆ ¬Overlapping
2. (x∉B|∀x∈A)ÅÆDisjoint(A,B)
3. Issue(A, B) ÅÆ IssuedBy(B, A)
4. OwnedBy(A, B) ÅÆ OwnerOf(B, A)
5. ProvideService(A,B) Ù UsingServiceFrom(B, A)
According to the 2 nd axiom, any provider who
belongs to "DC (Debit Card) Network Provider"
should not belong to "CC (Credit Card) Network
Provider". However, according to Figure 15, the
company Master and Visa are defined under both
classes. Therefore, the conflict between the "Disjoint"
relation defined on the pair ("DC Network Provider",
"CC Network Provider") is detected by the consistency
analysis. Thus, the "Disjoint" relation between the "DC
Network Provider" and the "CC Network Provider" in
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007

the ontology in Figure 15 should be changed to
"Overlapping", as shown in Figure 16, which also
shows complete ontology with all relations between
the classes included.
Figure 15 Ontology for Payments
Figure 16 Revised Payment Ontology
Based on all the ontology information and
specification above, the collaboration control service
will match the collaboration profile ontology from both
the application template and the identified service to
compose a complete application specification. During
the application composite time, policy enforcement
engine will be invoked if there is any process policy is
specified for the application composition restriction. At
last the code generation service and deployment
service will be invoked to generate and deploy the
final application [9].
5 Conclusion
This paper presented the ODPC framework for
composing SOA applications with dynamic
collaboration. This framework supports modeling and
composition of complex SOA systems with automated
code generation and code deployment [9]. The
collaboration matching in ODPC framework is based
on collaboration patterns and ontology. A unique
feature is that ontology information is divided into
three separate but linked ontology systems AO, CO
and SO. A separate application template registry and
collaboration registry, in addition to the regular service
registry, are needed in this framework. The
collaboration pattern is a symmetrical workflow
specification and can be integrated in to the application
template to form a complete application. The ODPC
framework is a viable approach towards automated
service collaboration and application composition, it
can be used together with the dynamic collaboration
verification framework [10] to provide rapid SOA
application development.
References
[1] M. C. Cooper, “Semantic Distance Measures”,
Computational Intelligence, Vol. 16, No. 1, 2000
[2] DARPA: OWL-S: http://www.daml.org/services/owl-s/
[3] Matjaz B. Juric, et al., Business Process Execution
Language for Web Services BPEL and BPEL4WS,
Packt Publishing; 2nd edition Jan 30, 2006, ISBN: 1-
9048-1181-7.
[4] OASIS: ebXML: http://www.ebxml.org/
[5] A. Gomez-Perez, M. Fernandez-Lopez, O. Corcho,
Ontological Engineering, Springer, 2004
[6] D. Tidwell, “UDDI4J: Matchmaking for Web services”,
http://www-106.ibm.com /developerworks/library/ws-
uddi4j.html, Jan 2001.
[7] W.T. Tsai, Ray A. Paul, Bingnan Xiao, Zhibin Cao,
and Yinong Chen, "PSML-S: A Process Specification
and Modeling Language for Service-Oriented
Computing", the 9th IASTED International Conference
on Software Engineering and Applications (SEA),
Phoenix, November 2005, pp.160-167.
[8] W. T. Tsai, B. Xiao, Q. Huang, Y. Chen, and R. Paul,
"SOA Collaboration Modeling, Analysis, and
Simulation in PSML-C", Proc. of the Second IEEE
International Symposium on Service-Oriented
Applications, Integration and Collaboration
(SOAIC’06), October 2006.
[9] W. T. Tsai, C. Fan, Y. Chen, and R. Paul, “A Service-
Oriented Modeling and Simulation Framework for
Rapid Development of Distributed Applications”,
Simulation Modeling Practice and Theory, Elsevier, 14
(2006), pp. 725-739.
[10] W.T. Tsai, Qian Huang, Bingnan Xiao, Yinong Chen,
“Verification Framework for Dynamic Collaborative
Services in Service-Oriented Architecture”, QSIC 2006.
pp. 313-320.
IEEE International Conference on Service-Oriented Computing and Applications(SOCA'07)
0-7695-2861-9/07 $20.00 © 2007