composition of mismatched web services in distributed service oriented design activities
TRANSCRIPT
Composition of mismatched web services
in distributed service oriented design activities
Muhammad Younasa, Kuo-Ming Chaob,*, Christopher Laingc
aDepartment of Computing, Oxford Brookes University, Oxford, UKbDistributed Systems and Modelling Research Group, School of MIS, Coventry University, Coventry, UK
cSchool of Informatics, Northumbria University, Newcastle upon Tyne, UK
Abstract
The composition of heterogeneous web services is a key aspect of usability and applicability of web services in different application
domains such as business applications, healthcare, and e-government. Current research has developed different techniques to achieve
effective composition of web services. Unfortunately, they fail to ensure a perfect match in the composition of web services. This paper
investigates the composition of web services and how to effectively employ web services in the design activities. Objectives of this work are
twofold. Firstly, to proposes a new technique that assists users to resolve a mismatch in the composition of web services. Secondly, to
implement, validate, and evaluate the proposed technique within the context of design activities thus establishing a workbench called Service
Oriented Design Activities (SODA). SODA provides a web-based design infrastructure that allows loosely coupled design teams to
collaborate on different services, and to enable them to resolve any mismatch between heterogeneous design services. Other anticipated
advantages include interoperability of design services, improving designer capabilities, and the reduction of product development time.
q 2005 Elsevier Ltd. All rights reserved.
Keywords: Web service; Semantic web; Engineering design; Web service matchmaking; Ontology
1. Introduction
Web services enable the development of diverse
applications using standard technologies and protocols
such as extensible markup language (XML), simple object
access protocol (SOAP), web services description language
(WSDL) and universal description, discovery and
integration (UDDI) [1]. Web services are used in different
applications such as business, scientific, education, and
engineering design [2–4]. Semantic web technologies [5]
are used to enhance the utility of web services. Semantic
web provides web services with more expressive power,
such that software programs can understand the meaning
and usage of those services.
Generally, if no single web service can provide the
required functionality there should be an option to
compose existing web services to satisfy a user’s
1474-0346/$ - see front matter q 2005 Elsevier Ltd. All rights reserved.
doi:10.1016/j.aei.2005.05.009
* Corresponding author. Tel.: C44 24 7688 8908.
E-mail addresses: [email protected] (M. Younas), k.chao@
coventry.ac.uk (K.-M. Chao), [email protected] (C. Laing).
requirements. The issue of composition has drawn a
significant attention both from the industry and academic
research communities. A considerable amount of research
has been invested in developing methods for the
automatic composition of web services. These include,
service discovery, match making, and the use of
workflow languages to coordinate web services. A survey
in [7] highlights various methods developed for the
automatic composition of web services. The work in [8]
develops a LARKS language that enables service
matchmaking among agents in the Internet environment.
While research in [9] applies Case-Based Reasoning to
automatically discovering and composing different web
services.
Recently, the academic and industrial community have
begun to consider the use of Semantic web in engineering
design. For instance, WIDE [6], a European funded project
has been investigating the application of Semantic web
technology in the engineering design activities for
information management and knowledge sharing. This
project does not consider the composition of heterogeneous
and autonomous web services in order to enable
collaboration or form composite services.
Advanced Engineering Informatics 19 (2005) 143–153
www.elsevier.com/locate/aei
Fig. 1. Web services architecture.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153144
Current approaches have developed different techniques
to achieve effective composition of web services. However,
they are unable to ensure a perfect match in the composition
of web services. In this paper, the authors have provided an
in-depth analysis of the possible mismatch between web
services. This analysis is used to define a new approach that
aims to assist users in resolving mismatch between web
services. This approach develops a virtual web service
(VSW) that helps developers to bridge their differences
when composing different web services. The proposed
approach complies with standard technologies of web
services and semantic web. It establishes a workbench
called Service Oriented Design Activities (SODA) [2], and
is implemented, validated, and evaluated using a case study
of ship design [10,11]. A SODA workbench is applied to the
domain of a large and complex engineering design. The
challenge of engineering design is that it involves numerous
design activities, requiring collaborative work among
diverse design disciplines and autonomous organisations
each providing specialised services. The proposed system,
therefore, provides a web-based design infrastructure that
allows loosely coupled design teams to collaborate on
different services. This is motivated by the fact that modern
design infrastructure involves many designers,
manufactures, financial analysts, and so on. Such
infrastructure consists of autonomous and heterogeneous
design systems, which are used to provide different services
required by the design activities. Effective service delivery
capabilities are critical to a viable design infrastructure
wherein design systems can cooperate with each other in
order to provide and receive desired services. For example,
in a ship design process, a Hydrostatic Consultancy will
provide services such as vessel’s buoyancy, stability, and
cargo capacity [10,11]. In order to provide such services the
hydrostatic consultancy generates the required block
coefficient (Cb), midship coefficient (Cm), longitudinal
centre of buoyancy (LCB), and length/breadth ratio (L/B).
It also needs services from the design consultancy such as
hull dimensions: length (L), breadth (B), and draft (T).
The contributions that this work makes are twofold:
On the web services side: it enables an effective
composition process thereby ensuring a higher degree of
matchmaking between heterogeneous web services.
On the application side: engineering design teams can
benefit from the proposed system as it facilitates the process
of system integration and knowledge sharing.
The remainder of the paper is structured as follows:
Section 2 provides background information through the
description of related technologies. Section 3 critically
reviews current solutions and defines the nature of the
problem. Section 4 presents the proposed SODA
Workbench. Section 5 illustrates the case study of ship
design within which the proposed system is tested. Section 6
describes the application and testing of the proposed system
using the case study. Section 7 concludes the paper.
2. Background
This section establishes the background of the related
technologies and the composition process. Firstly it
illustrates the web services and their underlying standards
and protocols. Secondly, it describes the semantic web and
its associated technologies. Finally, it explains the
composition process of web services.
2.1. Web services
Web services enable the development of Internet-based
applications using standard technologies and protocols such
as extensible markup language (XML), simple object access
protocol (SOAP), web services description language
(WSDL) and universal description, discovery and
integration (UDDI) [1]. As shown in Fig. 1, these
technologies and protocols are organized into different
layers comprising: network, messaging, service description,
service publication and service discovery layer. Web
services use commonly deployed network protocols such
as TCP/IP, HTTP, and IIOP. Web Services provide a
standard means of integration and communication among
different distributed systems and applications running on a
variety of platforms. For example, different design systems
can be integrated through web services in order to provide
design teams with different services.
WSDL facilitates the process of service description.
Each service provider (e.g. Hydrostatic Consultancy) uses
WSDL in order to define the details of the services it
provides. Through WSDL services are defined as
collections of network endpoints, or ports. In order to
define services WSDL document uses different elements
such as types (used for data type definition); message (typed
definition of the data); operation (describes an action which
is supported by the respective service); binding (defines a
protocol and data format specification for a particular port
type); port (specifies an address for a binding); service
(aggregates a set of related ports).
In web services, messages are communicated between
participating systems (e.g. hydrostatic consultancy and
design consultancy) using XML-based SOAP protocol.
SOAP provides an enveloping mechanism so as to
communicate document-based messages. A SOAP message
is an XML document. It comprises different parts such as
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153 145
SOAP envelope, a SOAP header, and a SOAP body. SOAP
envelope is the top element of the XML document, which
represents the message. Header is used to add features to a
SOAP message. Features are added to the message in a
decentralized manner without prior agreement between the
participating systems concerning the message. SOAP body
is a container for the information, which is sent from the
sender to the receiver of the message. SOAP messages are
extensible thus they can be customised according to the
application needs.
UDDI is used by the service requester (e.g. Hydrostatic
Consultancy) and service provider (e.g. Design Consul-
tancy) in order to publish and search for services. UDDI
uses WSDL documents to publish details of the services and
also facilitates the searching of services. In this respect
UDDI may be considered to be the Yellow Pages of the
system.
2.2. Semantic web technology
The utility of the web services can be enhanced using
semantic web technology [12]. Semantic web provides web
services with more expressive power, such that software
programs can understand the meaning and usage of those
services. It uses an ontology language, called OWL to
represent knowledge about web services [13]. OWL
provides a rich set of constructs with which to create
ontologies and to markup web information so that it is
computer readable and understandable. The definitions of
terms in vocabularies and the relationships between the
terms can be represented explicitly in OWL thereby
avoiding the ambigity. An ontology is the representation
of terms and their interrelationships.
OWL is built upon XML, RDF, and RDF-S, but it
supports more powerful expressive langauges allowing
users to model meaning and semantics of the terminologeis
which are machine interpretable web documents. It provides
the contructs for defining classes, the relation between
classes, their properties, RDF schema, cardinality, etc. The
ontologies represented in OWL can be reasoned with some
ontology tool such as OWLJessKB [14]. OWL is a
specification without provision of a run-time environment.
The ontology tool OWLJessKB (an implementation of
OWL) provides a run-rime environment and reasoning
mechanism to meet users’ needs. OWLJessKB is built upon
Java Expert System Shell (Jess) incorporating a descriptive
logic reasoning for performing the inference with OWL
ontologies. The syntax of OWLJessKB is production rules
like other expert system shells, but supports a rich set of
XML schema data types.
2.3. JWSDL and JAXRPC
JWSDL [15] contains a set of APIs for reading, writing,
creating, and modifying WSDL definitions and extensibility
elements. Developers can use JWSDL to represent
and retrieve WSDL documents dynamically. It can serialise
and/or de-serialise the extensibility elements in order to
maintain their persistence. In addition, a factory mechanism
supported by JWSDL allows a client code to be written
independent of any particular JWSDL implementation. It
provides an infrastructure for building WSDL at runtime.
JAX-RPC is a Java based web service technology that
enables Java technology developers to build web
applications and web services incorporating XML based
RPC functionality according to the SOAP (simple object
access protocol) 1.1 specification. JAX-RPC uses remote
method invocation (RMI) and Java beans technologies to
facilitate the implementation of the web services. The main
advantage of this mechanism is to allow Java developers to
construct web services under their familiar environment.
2.4. Composition of web services
Web service is a function that is well defined, self-
contained, and does not depend on the context or state of
other services [1,9]. However, if no single web service can
satisfy the functionality required by the user there should be
an option to compose existing web services so as to fulfil the
user’s requirements. Composition of services is defined as a
process that enables the creation of composite services.
Such services should be dynamically discovered, integrated,
and executed such that they can fulfil the users’
requirements [9].
Composition of services enhances the functionality of
web services, automate the service development process,
and enable dynamic interactions between services. In order
to fully benefit from the composition of web services, it is
important to develop an effective matchmaking mechanism.
The authors in [8] define matchmaking as a process of
discovering appropriate service providers that meet the
requirements of the service requester through a third party
(or middle agent). Current research considers various
factors in order to ensure matchmaking in the service
composition. However, it fails to ensure perfect match in the
web services composition, as described in the preceding
sections.
3. Related work
Analysis of the related work is classified into two parts:
Composition of Web services, and the application of
semantic Web and services in engineering design activities.
3.1. Composition of web services
The issue of composition has drawn a significant
attention both from the industry and academic research
communities. Different techniques are proposed for the
composition of Web services including manual and
automated composition techniques. Work undertaken in
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153146
[7] provides a survey of methods developed for the
automatic composition of Web services. These methods
are classified as workflow composition and AI planning
methods. Analysis of these methods is presented using a
generalized framework of the Web service composition.
The framework provides a high level abstraction, which is
independent of the underlying language or platform used in
the Web service composition. The authors also illustrate the
process of automatic Web service composition in terms of
(i) Web services presentation/advertisement (ii) translation
of Web services languages (iii) the main composition
process (iv) evaluation of the composite Web services, and
(v) the execution of the composite Web services. This
survey arrives at the observation that a fully automated and
precise composition of Web services may not be achieved
through the existing techniques.
Our own review of the literature supports the above
claim. For instance, [8] develops a LARKS language that
enables service matchmaking among agents in the Internet
environment. LARKS supports both syntactic and semantic
matchmaking of the services. LARKS matchmaking process
is based on different parameters (or filters) including context
matching, profile comparison, similarity matching and
constraint matching. LARKS resolves services’ mismatch
to some extent but is unable to ensure a fuller matchmaking
of heterogeneous services. In [9] a case-based reasoning
technique is used to discover and compose different Web
services. It provides proactive and reactive composition of
Web services. Advantages claimed of this approach are the
reduction in composition cost, service collaboration
and client satisfaction, and efficient service discovery and
composition. Despite these advantages this approach fails to
achieve precise composition of Web services. Work
undertaken in [18] proposes a semantic Web technologies
framework in order to automatically discover and compose
grid services. It is suggested that this approach is able to
support a dynamic workflow composition, and enable users
to share workflows, which may have different level of
granularities.
The above discussion reveals that current approaches
assume that Web services can be integrated seamlessly
without any needed modification. However, the issue of
mismatch between Web services may still exist, as these
approaches do not provide a perfect match in the Web
services composition. In this paper, the authors intend to
address this issue by developing a system that integrates
Web services and assists users in resolving the mismatch
between Web services, which is otherwise not possible
through the existing techniques.
3.2. Semantic Web and Web services in design activities
Research on the use of Web services and semantic Web
in the engineering design activities is still in its infancy.
WIDE [6], a European funded project, has begun an
investigation into the application of semantic Web
technology in the engineering design activities for
information management and knowledge sharing. The aim
is to provide multi-disciplinary design teams with improved
information management and knowledge sharing in their
workspace. This project appears to be in the early stages and
there are no details available on the approaches taken when
using the semantic Web in engineering design activities.
The approach in [16] employs description logics and
semantic Web in design repositories in order to develop
the representation and reasoning mechanisms. This work
develops an ontology for the representation, classification,
and comparison of electromechanical devices. The work in
[17] develops a conceptual design system in order to
provide collaborative and secure engineering design
environment for geographically distributed design teams.
This consists of the development of a conceptual design
interface, representation of design semantics, and reasoning
mechanism. This representation incorporates OWL
language of the semantic Web technology in order to
share design knowledge between different users involved in
the design process.
The above approaches apply semantic Web technologies
to engineering design activities but they do not give
attention to the composition of Web services, which is the
focus of this paper.
4. The SODA workbench
This section presents the proposed SODA Workbench.
Section 4.1 describes rationale for this research. In
Section 4.2, there is an illustration of the mismatch
identification model and its associated rules. Architectural
aspects of the SODA workbench are detailed in Section 4.3.
4.1. Rationale
The proposed approach aims at resolving mismatch in
the process of composition of Web services. Mismatches
could result from semantic and/or syntactic signature
differences between Web services. When a mismatch
occurs between two Web services, a function is required
to enable them to possess coherent interfaces and semantics
prior to their interaction or composition. Additional Web
services may also be used to bridge the gap between
heterogeneous web services. For example, a mediating web
service, called virtual web service (VWS), could be
introduced to resolve the differences. A web service can
use a single VWS, which includes essential functions for
resolving the differences and to facilitate the
communication with other Web services. Alternatively,
multiple VWSs can be designed for composing different
web services. A single VWS option can bring the advantage
of less communication. However, it may suffer from the
disadvantage of a single point failure. Multiple VWSs have
advantages of averting a single point failure. However, it
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153 147
may result in the communication overhead. Comparison
between single or multiple VWS is out of the scope of this
research. The emphasis is that VWS is a significant tool
towards resolving the incompatibility of web services.
Designing a system to assist users in identifying possible
mismatches and to allow users for facilitating the design of a
VWS in order to resolve the differences between composed
web services is an important research issue. However, what
steps should be taken by users to alleviate the differences? It
is important to have a system in hand that supports users
with analysis and illustration of possible or potential
mismatches between web services prior to composition. A
user-friendly graphical user interface should be designed to
reduce users’ burdens and to prevent manual errors. The
proposed SODA Workbench aims at addressing the
aforementioned issues. It does not automate the design
process, but assist the users in composing web services and
resolving their mismatches in terms of semantics and
syntactic signatures.
In the design activities, the rationale behind the compo-
sition of web services is twofold: meeting long-term or short-
term design requirements. If it is a long-term requirement, the
participating web services need to make changes for firm
integration. If it is a short-term requirement or there are other
requirements, it means the web service can be used for
different scenarios. The web services should be kept intact.
4.2. The mismatch identification model
This section presents the proposed mismatch identifi-
cation model. This model assumes that web services are
annotated with OWL-S and other match making mechan-
isms are used so as to identify a list of possible web services
for composition. It also assumes that there is no perfect
match among the identified web services. This model is
knowledge-based which includes rules and facts. Rules
identify the relationship between concepts. The derivation
of rules is built upon basic definitions of the problems and
related concepts. First we illustrate possible relationships
between concepts. These are then used in the formulation of
mismatch identification rules.
4.2.1. Concept relationships:
Definition 1: AtB
represents a gap between A and B. e.g. A provides width and
length of an entity, but B requires area for the computation.
Definition 2: AzB
A and B have same data types, but have different concepts.
e.g. A and B have float data types associated with a
measurement, but A uses inch and B means centimetre.
Definition 3: AsB
represents same concept, but different data types. e.g. A uses
integer data type to define a measurement, but B uses float
data type to define the measurement.
Definition 4: AIB
A is superclass of B. e.g. ferry is a type of ship.
Definition 5 A3B
A is subclass of B. e.g. Children are a subclass of passenger.
Definition 6: A2B
A is a part of B. e.g. Machinery cost is part of vessel cost.
Definition 7: AhBZC and Cs0
represent an overlap between two objects, e.g. A shares
attributes with B.
Definition 8: A!B
B has more attributes than A.
Definition 9: B!A
B has less attributes than A.
Definition 10: CZAgB and AhBZ0
C can be split into A and B. z denoted as split function. So z
(C)Z{A,B}.
Definition 11: CZACB
C consists of A and B, z(C)Z{A,B}. j denoted as
composition function and j(A,B)ZC.
Definition 12: CZAjB
C is either A or B. F denoted as option and F(A,B)ZA or B.
Definition 13: {A$B$C}
A, B and C must be executed, but without specific order.
Definition 14: {A/B/C}
A must be executed, before B and C cannot be executed
before B.
The production rules for mismatch identification can be
formulated based on the above defined relationship between
concepts.
4.2.2. Production rules
R1. If DZj(A,B) then A2D & B2D & AhBZ0;
composition rule for composing two concepts.
R2. If DZj((A),D 0) and AZACD 0 then DOA; Recursive
rule for identifying additional required concepts.
R3. If D!A and Dhz(A)s0 then DZz(A); Extracting
rule to extract extra attributes.
R4. If A3C then A3B & B3C; Superclass rule to
determine relationship between two concepts.
R5. If AIC then AIB & BIC; Subclass rule to determine
relationship between two concepts.
R6. If F(z(A)hz(B)) then AhBs0; overlapping rule to
find the overlaps between two concepts and identify the
overlapping concept.
R7. If A3B & B<C then AtC; Gap rule to determine
there is a gap between two concepts.
R8. If T1(A)ZB then AzB; A and B have same data types,
but have different concepts.
R9. If T2(A)ZB then AsB; A and B have same or similar
concept, but have different data types.
T1 and T2 are elements in set T, which contains a set of
transformation functions such as data type and date
transformation.
The above rules are examples, but not an exhaustive list.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153148
4.3. Architecture of SODA workbench
This section illustrates the architecture of the SODA
Workbench within which it is implemented. The architec-
ture, presented in Fig. 2, encompasses the above rules and
concept relationships. Those rules combining with the facts
and semantics given by ontologies and web services can
form a knowledge base for reasoning. SODA Workbench
contains a reasoning mechanism, which is built upon a close
world reasoning mechanism and a distiller mechanism. The
reasoning mechanism can reason on the knowledge or facts
given by semantic web and pre-defined rules to identify the
mismatches. One of the main functions for the distiller
mechanism is to extract related WSDL files and translate
them as facts for reasoning. These functions are main
contributors to the mismatch identification model. Thus a
list of WSDL files and profiles in OWL-S representing
different web services have to be loaded on to the SODA
Workbench. In addition, any other, related ontologies
represented in OWL need to be included in the Workbench.
The mismatch identification model can be triggered
when two port names from different web services are
selected for composition or collaboration. The input
message of a port name will be mapped to the output
message of the other port, which resides in a
different WSDL. The reasoning mechanism is provided by
OWL-Jess KB, semantic mismatches are identified by
considering their precondition effects; additional semantics
presented by the ontologies may also be taken into account
in this identification process semantic mismatches by taking
their precondition and effect and additional semantic
presented by the ontologies into account. The facts that
cannot be found are assumed to be false due to the close
world reasoning adopted in the system. Input and
output messages associated with the operations will be
retrieved by a distiller mechanism, which is built upon
Fig. 2. Architecture of S
JWSDL. As a result, the messages to be composed, the parts
and their associated port types can be loaded into Work-
bench for carrying out syntactic signature mismatch
identification.
The key purpose of the proposed system is to identify the
mismatches for users’ references. So it is important to
display a list of potential mismatches in terms of semantics
and syntactic signatures if there is any. Once the mismatches
have been identified, an editor should be provided to aid the
users when adding extra code in order to eliminate the
mismatches. As a result, Workbench generates a skeleton of
VWS which includes both WSDL URI and related message
types, port and input and output messages. An additional
port is generated which includes an input and an output
messages. The input message corresponds to one output
message in one WSDL. The output message matches up the
input message of the other WSDL.
Since SODA Workbench employs JAXRPC for
supporting web services, the corresponding Java beans
class is generated. The user can fill the class with
necessary code to bridge the differences. Once the users
have completed the addition of extra code, the system is
ready to generate the VWS. Target name space, binding to
communication protocol and a default partner like type
are added for generating a workable WSDL for VWS. The
Java beans are compiled into executable files. The user
can add to the OWL-S, but not necessarily. The system is
to provide a method to eliminate mismatches between
web services, so the process of composition is left to the
user to decide.
The user can use either a Java client or BPWS4J engine
to execute the composite web services. The Workbench is
implemented in Java and it utilises a number of related
technologies to support prescribed functions. The system is
applied and tested on the case study, which is presented in
the Section 5.
ODA workbench.
Fig. 3. A distributed design environment.
Table 1
Conceptual design requirements and revisions
Crew 15 15 VTrial (VT) 40 Knots
Passengers 600 750 VService (VS) 37 Knots
Lane length 685 m 856m VCruising (VC) 25 Knots
Cars 136 170 EnduranceMiles 400 Nautical
miles
Coaches 6 6 EnduranceDays 1 Day
Articulated
vehicles
5 5
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153 149
5. Case study: fast ferry concept design
This section describes a case study of fast ferry concept
design from Armstrong technology associates [10] in order
to test the proposed approach. A ship design process [11]
demonstrating the interoperability of different design
services is presented, and the data flow between design
teams in a distributed design environment is described.
Naval Architecture consists of differing ship design
activities/services, each with differing and competing
design priorities. These design services represents a design
environment [11]. The design of a ship is complex process;
a constrained by technical and economic issues. This design
process may be undertaken concurrently, in which design
teams can be part of a distributed design environment [19].
Each of these design teams will manage their own input and
output data. This interaction is shown in Fig. 3, which
represents a distributed design environment.
Fig. 3 shows the data flows between different teams in the
distributed design environment. In this case study the Prime
Contractor issues a specification to the Design Consultancy.
The Design Consultancy performs some preliminary
analysis, and identifies appropriate hull dimension; Length
(L), Breadth (B), and Draft (T), which are sent concurrently to
the Hydrostatic Consultancy, the Hydrodynamic
Consultancy, and the Shipyard [11]. In this case study,
three performance criteria will apply; service speed (VS),
cargo (passengers and cars) capacity of the vessel (CC), and
transverse stability (GMT). The Hydrostatic Consultancy is
responsible for the vessel’s buoyancy, stability, and cargo
capacity. The Hydrostatic Consultancy uses preliminary data
from the Design Consultancy to generate Block Coefficient
(Cb), Midship Coefficient (Cm), Longitudinal Centre of
Buoyancy (LCB), Length/Breadth ratio (L/B), vertical
Centre of Gravity (KGM), transverse stability (GMT), and
cargo capacity (CC).
The Hydrodynamic Consultancy is responsible for the
vessel’s sea keeping, manoeuvrability and resistance/
propulsion. This Consultancy takes data from the Design
Consultancy, and data from the Hydrostatic Consultancy to
generate a design with the necessary service speed (VS). The
Shipyard uses data from the Design Consultancy to generate
estimates of machinery cost (CM), steel cost (CS) and outfit
cost (CO). The final data flow is back to the Prime
Contractor for analysis and evaluation [11].
The basis ship will operate in competition with an
existing ferry service; but will use the faster service to
attract non-freight (passengers and cars) away from this
existing service [2]. The Prime Contractor uses this
rationale to define the conceptual design requirements
(Table 1); the distributed design process as described above
is initiated, and an initial design will eventually be returned.
However during the design process, revisions to the
conceptual design requirements are often undertaken. In this
case study, it is assumed that the Prime Contactor has
experience of operating a similar service, and that the
introduction of a fast ferry service will generate a demand
not accommodated by the initial conceptual design
requirements [2]. Furthermore this demand will be
experienced throughout the day, and an extra sailing
Fig. 4. User interface of the SODA workbench.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153150
would not ease the problem. The Prime Contractor estimates
that the cargo (passengers and cars) capacity will need to be
increased by 25% [2]. The design revisions are shown in
Table 1 in a shaded column.
The above case study illustrates the complexity of the
design process, involving frequent interactions between
different design teams/disciplines. This case study high-
lights the need for a new system that ensures the seamless
composition of mismatched design services. The mismatch
between design services may occur in terms of input/output,
data types, functionality, information context, and so on. For
example, design consultancy generates Block Coefficient
(Cb), midship coefficient (Cm), longitudinal centre of
buoyancy (LCB), length/breadth ratio (L/B), and vertical
centre of gravity (KGM). These are required as input by
Hydrodynamic Consultancy which then generates a design
with the necessary service speed (VS). However, the output
generated by the design consultancy may not fully comply
with the input requirements of hydrodynamic consultancy.
Each entity shown in Fig. 3 is a system that employs
different off-the-shelf tools such as CAD systems, decision
support systems and knowledge-based systems as well as
other in-house systems to perform the desired tasks. These
tools are implemented in different programming languages
and support a set of APIs as interfaces for the interoper-
ability with different programming languages (e.g. C,
CCC, Java, etc.). So, the web service technologies are
adopted to wrap the systems for the interaction with the
supported APIs that could alleviate the communication
among these heterogeneous systems. However, each system
requires different input parameters and produces different
outputs. It is difficult to standardise the interfaces to meet
different requirements. The flow of the interactions among
these systems is dynamic. It means that the design flow
cannot be predefined in a static way and a number of iterated
design processes could occur at same time.
This is especially the case in distributed web-based
design environment where the requirements of design
services are pre-determined. As discussed above, current
solutions partially resolve the mismatch between different
services. However, these techniques still need user
involvement to enforce a perfect match in the composition
of services. The Section 6 presents the proposed approach
that addresses these issues.
6. SODA workbench in the ship design
This section describes the application of SODA Work-
bench to the case study presented in Section 5. The aim is to
demonstrate the validity of the proposed workbench within
complex engineering design.
The application of SODA Workbench to the ship design
process is illustrated through the diagram presented in
Fig. 4. Consider that a user needs to create a new project or
open an existing project, before web services can be loaded
into the system. The user selects web services via UDDI or
other means and inputs WSDL web addresses.
The system can start to load the WSDL files. As shown in
Fig. 4, the panel in the left side window contains a list of
potential collaborating web services. These include,
Hydrostatic_WS, Hydrodynamic_WS, Shipyard_WS,
Design_WS and Prime_Contractor_WS. Each web service,
shown as a root, has a list of port types, which are shown as
leaves in a tree. The right side of the panel shows a list of
port types, which could possibly interact with each other.
For example, Hydrodynamic_WS includes 5 ports and each
port type is associated with an operation.
Before the matching process can be carried out, the
related ontologies must be imported into workspace. To
define the relationship between port types, simply drag a
line between them. Once the relationship between port types
has been defined, the mismatch identification model can be
activated. Fig. 5 shows that 4 different port types need to
interact with each other, so therefore 5 VWS are generated
to enable them to communicate seamlessly.
The system shows the possible mismatches between two
port types as shown in Fig. 5. The mismatch identification
message box contains a list of possible mismatches between
two port types by employing OWL JESS KB and Distiller.
In this example, machinery cost is part of vessel tool. The
machinery cost is float data type and vessel cost is complex
data type. The ontology provides the related concepts of
machinery cost and vessel cost. The Distiller identifies the
data type mismatch between these two.
When the mismatches have been identified, an editing
tool, shown in Fig. 6, is used to edit the VWS. In the
diagram a solid box (see Fig. 4) is added automatically and
represented as a VWS sitting between two web services.
The VWS contains a list of message types used by the port
types in web services. In this case, a complex data type and a
float data type are involved. An additional port type, which
Fig. 5. Mismatch identification message box.
Fig. 7. Integrated web services.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153 151
connects to two selected port types, is created in the VWS.
The target URIs (http://www.shipdesign.org/ferry-
shipWS743) and (http://www.shipdesign.org/ferryship/
Hydrodynamic_WS/ http://www.shipdesign.org/ferryship/
Prime_Contractor_WS) corresponding to imported web
services are inserted. An Interface class, Vessel_Cost_Ma-
chineary_CostIF, and a Java bean related to the created port
type are generated. An implementation class needs to be
defined by the users in order to alleviate the mismatches
between the port types. After the Java bean is implemented,
the VWS generator is invoked to complete the process. As a
result, and if there is no error in the implemented Java code,
the WSDL file and the required Java classes are generated.
Following the same steps, the mismatches between web
services are removed by including VWS. The interactions
among web services can be modelled in BPEL4WS or a
Java Client program to control the flow (see Fig. 7). In this
exercise, we used a Java Client program to integrate their
activities.
In order to evaluate the effectiveness of the generated
system, we obtain the parameters produced by the system
Fig. 6. Editing tool for bridgine mismatches.
and give them to the CAD system in order to test the output
as shown in Fig. 8. Key parameters such as vessel speed and
passenger numbers are produced as expected. A second test,
using the changed requirement specifications (as noted in
the above case study) is undertaken to examine the system’s
behaviour. The system responds to the change in a
predicable way by producing reasonable parameter values.
Fig. 9 shows the output of the composite web services as
plotted in CAD design tool. The capacity of accommodating
passengers and cars is reflected to the changes consistently.
The lane length is increased from 685 to 856 m.
Before the experiment was carried out, a number of tests
were undertaken to identify the shortcomings of the system.
The mismatching rules in general are sufficient to detect
most conflicted interfaces and semantics. Since the design
flow is dynamic, the order of the executing services and port
types cannot be determined by the system entirely.
Hardwired code and a fixed design flow were introduced
in some places to ensure that the system was carried out in a
desired order. In this problem domain, identifying the
mismatched data types and their associated semantics
within these collaborative services is the key focus.
Therefore, a number of additional functions, implemented
as a set of Java beans have been added to the
Prime_contractor web Service and others in order to
alleviate large functional gaps that exist between them. It
should be noted that the system is unable to deal with the
types of mismatches that are not modelled in the knowledge
base as the system cannot classify them. The system relies
heavily on the knowledge represented in OWL-S for the
web services to carry out the reasoning. Consequently,
Fig. 8. Fast ferry ship.
Fig. 9. Increased capacities for cars and passengers.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153152
the appropriate representation of the services interfaces and
their associated semantics are important for the system to
derive right conclusions. A number of mistakes in the
representation and missing semantics were identified in the
early rounds of the tests. These caused the system to behave
unexpectedly. OWLJessKB, a prototype system, is a useful
tool, but its reliability and some essential functions need to
be improved. These problems are either fixed or resolved by
hardwired solutions in order to demonstrate the system.
7. Conclusions
Web service technology, playing a similar role to
CORBA, provides a way of integrating heterogeneous
distributed systems, allowing them to work together
seamlessly. However, issues of semantic and syntactic
mismatches cannot be waived as web service only supports
location transparency and alleviating barriers when using
different languages. The common assumption in existing
match making methods and workflow language approaches
is that composite web services are based on the existence of
a perfect match. The issue of providing against a mismatch
among web services has been neglected.
In this paper, the authors have proposed a SODA
Workbench that includes a set of rules, knowledge (facts),
and a reasoning mechanism to identify mismatches. The
workbench contains a Distiller mechanism to extract WSDL
and form a skeleton of VWS. The VWS plays an important
role in bridging the gap and transforming the mismatches.
The focus of the proposed system is to firstly, provide a
mismatch identification mechanism for facilitating
the elimination of mismatches and secondly, provide a
user-friendly environment to design VWS. A prototype
system is implemented and tested in a ship design process.
The experiment was carried out within a closed environ-
ment; that is prior to the experiment, the number of systems
and their identity have been pre-defined. In addition, the
system is unable to provide support for choosing alternative
services. It is suggested that in order to identify its full
potential and limitations, future work will look at testing the
system in an open environment. In addition further
expansion of the mismatch rules is required to make the
system more flexible.
Acknowledgements
Thanks to Keith Hutchinson for providing the case study
from Armstrong Technology, Centre for Advanced
Industry, Royal Quays, North Shields Tyne and Wear,
UK. We also would like to express our great appreciation to
the valuable comments made by anonymous reviewers.
References
[1] Web Services Activity Working Group. Web services activity. W3C:
http://www.w3.org/2002/ws/.
[2] Younas M, Chao K-M, Laing C. SODA: service oriented design
activities. In: Proceeding of the eighth international conference on
computer supported cooperative work in design (CSCWD 2004).
IEEE Press; 2004 p. 419–24.
[3] Huhns MN. Agents as web services. IEEE Internet Comput
2002;93–5.
[4] Li Y, Ghenniwa H, Shen W. Agent-based web services framework
and development environment. J Comput Intell; 2004;20(4):78–92.
[5] DAML-S Coalition. OWL-S specifications. http://www.daml.org/
services/owl-s/.
[6] Stork A, Smithers T, Koch B. WIDE-semantic web-based information
management and knowledge sharing for innovative design and
engineering. http://www.ist-wide.info/.
[7] Rao J, Su X. A survey of automated web service composition
methods. In: Proceedings of first international workshop on semantic
web services and web process composition, 2004.
[8] Sycara K, Widoff S. LARKS: dynamic matchmaking among
heterogeneous software agents in cyberspace. J Auton Multi-Agent
Syst 2002;(5):173–203.
[9] Limthanmaphon B, Zhang Y. Web service composition with case-
based reasoning. In: Proceedings of 14th australasian database
conference (ADC 2003) p. 201–8.
[10] Hutchinson K, Todd D, Sen P. An evolutionary multiple objective
strategy for the optimisation of made-to-order products with special
reference to the conceptual design of high speed mono hull roll-
on/roll-off passenger ferries. In: Proceedings of international
conference of royal institution of naval architects, 1998.
[11] Laing C, Florida-James B, Chao K-M. In: Life-cycle knowledge
management in the design of large made-to-order (MTO) products
industrial knowledge management—a micro level approach. Berlin:
Springer; 2001 p. 429–48.
[12] Hendler J, Berners-Lee T, Miller E. Integrating applications on the
semantic web. J Inst Elec Eng Jpn 2002;122(10):676–80.
M. Younas et al. / Advanced Engineering Informatics 19 (2005) 143–153 153
[13] McGuinness DL, Harmelen F. OWL: web ontology language
overview. http://www.w3.org/TR/2004/REC-owl-features-
20040210/.
[14] Kopena JB, Regli WC, OWLJessKB: a semantic web reasoning tool.
http://edge.cs.drexel.edu/assemblies/software/owljesskb/.
[15] IBM DeveloperWroks. JWSDL, ftp://www-126.ibm.com/pub/wsdl4j/
JWSDLFinalReleas/1.0/.
[16] Kopena J, Regli WC. Functional modelling of engineering designs for
the semantic web. Bull IEEE Comput Soc Tech Committee Data Eng
2003.
[17] Kopena JB, Cera CD, Regli WC. Engineering design knowledge
management for conceptual design. In: Proceedings of the sixteenth
innovative applications of artificial intelligence conference (IAAI-04),
2004.
[18] Majithia S, Walker DW, Gray WA. Automated composition of
semantic grid services. In: Proceedings of the UK e-science all hands
meeting (AHM), 2004.
[19] Parsons MG, Singer DJ, Sauter JA. A hybrid agent approach for set-
based conceptual ship design. In: International conference on
computer applications in shipbuilding, 1999.