Collaboration in Design and Manufacturing Using Web Services

Collaboration in Design and Manufacturing
using Web Services

Thesis submitted in partial fulfillment of the requirements
for the degree of
Master of Technology
(Manufacturing Systems Engineering)
in
Mechanical Engineering
2003- 2005
by
Shoukat Ali (03ME6402)
Under the Guidance of

Prof. M. A. Faruqi
Department of Mechanical Engineering,

Indian Institute of Technology, Kharagpur,
India.
April, 2005.
.
Department of Mechanical Engineering,
Indian Institute of Technology,
Kharagpur-721302.
Certificate
This is to certify that the project entitled “Collaboration in

Design and Manufacturing using Web Services” is bonafide record
work carried by Mr. Shoukat Ali, Roll No. 03ME6402, under my
supervision and guidance for partial fulfillment of the requirements
for the degree of Master of Technology in Manufacturing Systems
Engineering during the academic session 2004–2005 in the
Department of Mechanical Engineering, Indian Institute of
Technology, Kharagpur.
Date: Prof. M A Faruqi

Place: Kharagpur Deptt. of Mech. Engg.,
IIT Kharagpur.
Department of Mechanical Engineering
Indian Institute of Technology
Kharagpur-721302
Certificate of Examination
This is to certify that we have examined the thesis entitled

“Collaboration in Design and Manufacturing using Web
Services” submitted by Mr. Shoukat Ali (Roll no. 03ME6402), a
postgraduate student of Mechanical Engineering with
specialization in Manufacturing Systems Engineering (ME-4).We
hereby accord our approval of it as a study carried out and
presented in manner required for its acceptance in partial
fulfillment for the Post Graduate Degree for which it has been
submitted. This approval does not necessarily endorse or
accept every statement made, opinion expressed or
conclusion drawn as recorded in this thesis. It only signifies the
acceptance of the thesis for the purpose for which it is
submitted.
Examiner Supervisor
Department of Mechanical Engineering
Indian Institute of Technology
Kharagpur-721302
Acknowledgement
With great pleasure and great sense of gratitude, I take this opportunity to
express my sense of indebtedness to Prof. M A. Faruqi, for his invaluable
guidance and constant encouragement at each and every step of my
thesis work. He has introduced me to new and exciting domain of
technology. He has been a constant source of ideas and enthusiasm
during the course of this work.
I would like to express sincere thanks to my teaching faculties for providing
sound knowledge base and positive co-operation during the course of my
M.Tech program.
I would also like to thank Mr. Masood Faruqui for his expert guidance in the
field of Web Services.
Finally, may I offer a special thank-you to those who have been with me
every step of the way? Without them this work would not exist and I would
be much the poorer for their absence.
Date: (Shoukat Ali)

Place: Kharagpur 03ME6402
Table of Contents
Abstract
1. INTRODUCTION…………………………………………...…………………….1
1.1 Introduction……………………………………………………………..1
1.2 Motivation………………………………………………………………2
1.3 Organization of the Thesis………………………………………………3
2. LITERATURE SURVEY…………………………………………………..4
2.1 Enterprise Integration…………………………………………………...4
2.2 Internet based Distributed Design and Manufacturing………………….5
2.3 Service Oriented Architecture (SOA) for Collaborative services………9
2.4 Orchestration and Choreography in Web Services…………………….11
3. ORCHESTRATION AND CHOREOGRAPHY OF

WEB SERVICES EMPLOYED IN DESIGN
AND MANUFACTURING……………………………………………….16
3.1 Objective of the present work…………………………………………16
3.2 Statement of the problem…..………………………………………….17
3.3 Software tools used in the study……………………………………….18
3.4 Methodology of the study……………………………………………..20
3.5 Conclusion……………………………………………………………..31
4. RESULTS AND CONCLUSIONS………………………………………..32
4.1 Results and Discussion………………………………………………...32
4.2 Conclusions……………………………………………………………32
4.3 Scope for future work………………………………………………….33
5. REFERENCES…………………………………………………………….34
6. APPENDICES……………………………………………………………..37
A-1 Overview of Web Services…………………………………………...37
_____________________________________________________________________ i
Collaboration in Design and Manufacturing using Web Services
A-2 Java source code of CastingBuyer Web Service……………………...47
A-3 WSDL Description of CastingBuyer Web Service……….…………..52
A-4 BPEL code for the process……………………………………………53
List of Figures
Fig.2.1 Architectures for Enterprise Integration………………………………….11

Fig.2.2 Web services orchestration and choreography…………………………...14
Fig.2.3 Standards for Orchestration and Choreography…………………………..15
Fig.3.1 Overview of Die Casting Design and Manufacturing process……………18
Fig.3.2 Conceptual model of the orchestration process…………………...……...19
Fig.3.3 Main page of Apache AXIS………………………………………………21
Fig.3.4 List of deployed Web Services…………………………………………...23
Fig.3.5 WSDL description of service CastingBuyer……………………………...25
Fig.3.6 SOAP Message sent to the CastingBuyer service from the system……....26
Fig.3.7 Process flow of die Design and Manufacturing process in
BPEL Maestro orchestration engine…………………………………...…27
Fig.3.8 SOAP message overview exchanged among the services in the process...28
_____________________________________________________________________ ii
Abstract
Efforts from diverse domains are made to use the Web as a platform of integration for all
service components. Design and Manufacturing (D&M) process area being no exception.
Leading manufacturing companies recently have announced plans for web-based systems
to coordinate transactions with their suppliers. If the design, production and delivery of
products have to be done in collaboration with corporate departments, suppliers, resellers
and customers, potential manufacturing partners should be identified, and design
activities and production plan should be carried out concurrently based on the design
requirements and manufacturing constraints. Such process involves many complex tasks,
and each task can be either performed in the same organization, of be outsourced. The
recent developments in IT technology, specifically e-business are useful to coordinate
these activities.
However, current e-business tools tend to focus on transactions involving standard parts
and products among network of suppliers. Therefore, e-business tools require research
focusing on creating business processes from composite Web services, and executing
processes that can interact with both internal and external Web services.
This study looks into creation of a service from composite Web services using
Orchestration and Choreography offered by Web services. Business Process Execution
Language for Web Services (BPEL4WS) or BPEL (for short) was used to orchestrate and
choreograph a Die Design and Manufacturing process, in which four Web Services were
involved (viz. Die Casting Buyer, Die Manufacturer, Die Design Analyzer, and Casting
Manufacturer). The combined process can also be used as a Web Service for further use.
Collaboration was achieved in the above said Design and Manufacturing process using
Java based, open domain software tools such as Apache Tomcat, Apache AXIS, and
Parasoft BPEL Maestro.
_____________________________________________________________________ iii
CHAPTER-1
INTRODUCTION
1.1 Introduction
Efforts from diverse domains are made to use the Web as a platform of integration for all
service components. Design and manufacturing (D&M) process area being no exception.
Leading manufacturing companies recently have announced plans for web-based systems
to coordinate transactions with their suppliers.
Potential manufacturing partners should be identified, and design activities and
production plan should be carried out concurrently based on the design requirements and
manufacturing constraints. Such a process involves many complex tasks, and each task
can be either performed in the same organization, or be outsourced. The recent
developments in IT technology, specifically e- business are useful to coordinate these
activities.
However, current e-business tools tend to focus on transactions involving standard parts
and products among network of suppliers. Therefore, e-business tools require research
focusing on creating business processes from composite Web services, and executing
processes that can interact with both internal and external Web services. Web services are
generally accepted as applications that interact with each other using web standard
interfaces, which include three major functionalities: description, discovery, and
communication. They offer high interoperability between cross-organizational
components in a loosely-coupled way.
The coordination of collaborating low level service is often mentioned as next step in the
development of Web service. Web Service choreography working groups in World Wide
Web Consortium (W3C) visualized that a framework for creating business process should
be able to compose and describe the relationship between lower-level services. Several
Web Service choreography languages inspired by industry have been proposed, such as
BPEL4WS, BPML, BPSS, and WSFL and OWL-S. These efforts focus on defining the
orchestration and choreography between Web Services to create business processes and
organizing services into a workflow.
_____________________________________________________________________ 1
This study looks into possible organization of Web Services into workflow using
Orchestration and Choreography offered by Web Services. Business Process Execution
Language for Web Services (BPEL4WS) or BPEL (for short) was used to orchestrate and
choreograph a Die Design and Manufacturing process, in which four Web Services were
involved (viz. Die Casting Buyer, Die Manufacturer, Die Design Analyzer, and Casting
Manufacturer). The combined process can also be used as a Web Service for further use.
1.2 Motivation
The practice of geographically distributed design and manufacturing is ever increasing,

yet is often inefficient. The problems with collocated design and manufacturing such as
insufficient information, support tools with inappropriate functionality and people
conflicts are exacerbated by distribution, while a whole new problem set specifically
related to distribution adds to the significant challenges. Put simply, an increase in
distributed space and time between members of a design team results in problems that
traditional approaches have failed to address adequately.
The growth of distributed design teams and distributed work in general in the past few
years has been facilitated due to advances made in the computing world and particularly
the creation and growth of the Internet. The present industrial climate also results in the
growth of distributed work. Continual technological advancement is set against a
backdrop of international mergers, takeovers and partnerships which invariably lead to
more distributed collaboration of formal and informal work. Further, recent movements
and concepts within the academic and industrial world such as Supply Chain
Management, Collaborative Product Commerce, Change Management, the increase in
outsourcing and the concept of the extended enterprise, promote the growth of distributed
work. The realization that collaborators external to the organization or at least at different
locations have higher levels of expertise continues to drive this increase. Although
distributed design and manufacturing practice is forced upon many organizations due to
the current industrial climate, the potential benefits of leveraging resources from different
locations often pre-empts a decision to design and manufacture in a distributed fashion.
The motivation for conducting research into Web services based design and
manufacturing is summarized in three ways:
_____________________________________________________________________ 2
•Value: the benefits of distributing the design and manufacturing processes and teams are
potentially great;
•Incidence: the level of distributed design and manufacturing is increasing dramatically;
•Problems: current problems with distributed design and manufacturing are rarely
realized.
1.3 Organization of the Thesis
The survey of relevant literature on Distributed Design and Manufacturing, Enterprise

Integration, and Orchestration and Choreography in Web Services has been presented in
Chapter 2. Description of Die Design and Manufacturing process and its orchestration is
presented in Chapter 3. Finally, Chapter 4 includes results and conclusions.
_____________________________________________________________________ 3
CHAPTER-2
Literature Survey
2.1 Enterprise Integration
Nickerson et al. [1] established that enterprise integration needs to occur at many
technical and organizational levels. They further commented that integrated enterprise of
the future will tie together all existing applications, so that data from one application can
be easily used in another. Business Processes, which may stretch across different
applications, will be combinable, so the output from one will be input to another. The
integration mechanisms will not create performance bottlenecks. And the integrated
enterprise will be easy to change. Further they identified four current trends in the quest
for the ideal integrated enterprise system as: overall frameworks are preferred to point
solutions, loose coupling is more popular than tight coupling, XML is driving out
customized file formats, and industry-wide efforts are driving internal efforts. They
pointed out the de facto mechanisms of integration as: integration using files, Remote
Procedure Calls (RPC), ERP integration, and integration using consolidated databases.
They also described some newer mechanisms as: publish/subscribe on a broker,
Enterprise Application Integration (EAI), web services, agent-based methods, and
workflow.
One of the newer mechanisms (Web services) is used in the present work.
Johannesson et al. [2] compared three architectures for enterprise application integration
viz. point-to-point, message broker, and process broker. In point-to-point solution every
application is directly connected to every other application, (see Fig. 2.1). This solution
could work for a small number of applications, but as the number of applications
increases, the number of connections quickly becomes overwhelming. The Message
(a) (b) (c)

Fig.2.1 (a) Point-to-point architecture, (b) Message Broker architecture, and (c) Process Broker architecture.
_____________________________________________________________________ 4
Collaboration in Distributed Design and Manufacturing using Web Services
Broker architecture reduces this complexity, (see Fig. 2.1). The main idea is to reduce the
number of interfaces by introducing a central Message Broker and thereby make it easier
to support the interfaces. The Process Broker, (see Fig. 2.1), is an extension of the
Message Broker. In addition to handling format conversions, the Process Broker also
encapsulates the process logic for connecting applications.
They also identified problems in modeling application integration as: Unstructured and
complex process models, Complex data models, Redundancy, Incomplete models, and
Communication among stakeholders. These problems were addressed by a number of
instruments: speech act theory, process classification, design guidelines, and a
communication oriented language, BML. Business Model Language (BML) focuses on
describing interactions between systems. It can be used in different phases of a system’s
life cycle: in feasibility analysis, in requirement specification, in the design and
implementation phase, and even in the operation phase. It can describe the structure as
well as the behavior of a system as it uses a timer component.
BML was successful in modeling business processes, but it is not machine interpretable.
2.2 Internet based Design and Manufacturing (D&M)
Chung et al. [3] proposed a system called MIDAS (Manufacturing Integration and Design
Automation System) which can be viewed as an extension of agent-based approach. Each
task behaves as an agent that carries out a specified task by selecting an appropriate tool
based on constraints, input data and assigned resources. If the result of the task does not
meet the requirements, the agent must select other alternative or input data. Modules of
MIDAS, written in Java, communicate with each other using RMI. Process databases,
servers, and external applications that are distributed over various companies can be
integrated into the system transparently to users. XML is utilized to represent task
knowledge and execution status. The core of MIDAS is the process grammar, which
provides the theoretical foundation to represent, manipulate and execute D&M processes.
Presence of process grammar supports the iterative nature of engineering process and
provides a layered approach to information modeling.
This system is very close to the web services architecture as it uses RMI. It uses a number
of servers viz. communication server, site proxy server, and user info server.
_____________________________________________________________________ 5
Qureshi et al. [4] introduced a methodology called ‘Design for Facility over Internet
(DFF)’. This methodology provides an Internet-based environment for designers to
perform manufacturability analysis of product designs with respect to the capabilities of
existing manufacturing facilities, upfront into the design process. The DFF system
analyzes the parametric design with respect to the fixturing (machine datums) capabilities
and generates suggestions for a designer, to modify his design if required, to fit the
capabilities of specified facilities. DFF system is implemented using the Java
programming language and the main GUI (graphical interface) is eventually converted
into Java servlet, for actual application over the internet.
As this system uses only Java and no XML Java class has to be written for each and every
specific operation (e.g. to retrieve critical design parameters from the input design file, to
create a feasible region for each machining datum, to enlist capability databases etc.).
Leitão et al. [5] proposed architecture for the development of distributed manufacturing
applications based in the Holonic Manufacturing Systems (HMS) and Bionic
Manufacturing Systems (BMS) concepts and which uses an agent based approach to
implement those concepts. The proposed agent-based architecture has modules viz.
Decision making module, Co-operation module, Communication module, Local control
and Monitoring module, Physical communication and operational control modules, and
Operational control module. These all modules work in synchrony with a Knowledge
Base module in the middle. The implementation of this agent-based architecture uses new
and powerful technologies, such as JAVA and CORBA environments, network
capabilities, Internet and web-based interfaces, communication standards, such as
KQML, etc.
Sequin et al. [6] proposed a Java based, Internet-based paradigm for design and
fabrication in a global, networked CAD/CAM environment. They established an “Internet
based Mechanical MOSIS service”. Some specific results and achievements include:
1. SIF_DSG, a Solids Interchange Format for Destructive Solids Geometry, for the
transmittal of feature-based descriptions of mechanical parts that can be fabricated on a
three-axis milling machine, has been defined and implemented.
_____________________________________________________________________ 6
2. A Web-based computer-aided design front-end, called WebCAD, has been developed
in Java, with a user interface that should cater to novice designers who are neither
familiar with milling machines nor with industrial-strength CAD packages.
3. A rudimentary Manufacturing Advisory Service (MAS) program has been
implemented, which assists the novice designer in selecting an appropriate manufacturing
technology for a desired part, based on the size of the part, some of its key geometrical
features, strength requirements, material preferences, anticipated fabrication volume, and
other data entered into a query form.
4. A back-end processing chain consisting of a macro-planner, a micro-planner, and a
tool-path generator has been developed. It can handle most of the part designs coming
from the WebCAD tool automatically.
Muammer et al. [7] introduced an e-Manufacturing architecture, and outlined its

fundamental requirements and elements as well as expected impact to achieve high-
velocity and high-impact manufacturing performance. Web- enabled and infotronics
technologies play indispensable roles in supporting and enabling the complex practices of
design and manufacturing by providing the mechanisms to facilitate and manage the
integrated system discipline with the higher system levels such as SCM and ERP. For
future work they pointed out research needs in the fields as: data mining, reduction and
data-to-information-to-knowledge conversion tools, distributed and web-based computing
and optimization and synchronization systems for dynamic decision making.
For the future work they indicated web services fulfill their needs.
Wright et al. [8] proposed a networked manufacturing service named CyberCut. They
said CyberCut will be "an experimental fabrication testbed" for an Internet-accessible,
computerized machining service. Client-designers will be able to create mechanical
components, beginning with a CAD system of their choice, and submit appropriate files
to the server at Berkeley for process planning. CyberCut will utilize an existing open-
architecture, computerized machine tool for fabrication. Rapid tool-path planning, novel
fixturing techniques, and sensor-based precision machining techniques will allow the
client- designer to take delivery, in a short time, of a component with a high-strength and
tight- tolerance {e.g. +/- 0.002 inch (0.05mm)}. As the testbed grows, other services such
_____________________________________________________________________ 7
as laser-cutting and precision machining will be included. There will also be some
instances where the design has a complex shape that cannot be prototyped by machining.
Then there will be need to evaluate other Solid Free Form (SFF) technologies for the
downstream proto type realization. To facilitate this step, we will develop a bureaux
called a "Manufacturing Analysis Service" that will evaluate the design for fabrication by
Stereolithography or Selective Laser Sintering, and pass it on to our industrial
collaborators for fabrication.
Shyamsundar et al. [9] developed a collaborative Product Assembly Design (cPAD) tool
that utilizes a compact and comprehensive representation of product assembly, and serves
as an integrated interface through which product assembly modeling can be performed.
The cPAD system proposed has the following key features:
• Any designer connected to the Internet has ubiquitous access to the product model
and can interact with the product design through the client interface. A Java based
client interface is used, since Java code is platform independent.
• This design introduces a new paradigm for collaborative assembly design. For
example, instead of installing the CAD software on every machine, the designer
uses the CAD software which is packaged into a CAD server. The designer
accesses CAD and other design related computer tolls through the client. This
establishes a central point of control for product design and is therefore ideal for
collaboration. Hence, data security and integrity can be maintained easily. The
mapping between the primary and secondary representations of the AREP allows
for transfer of data without loss of functionality. This enables real time editing of
the product models.
• This system is an integrated tool that facilitates not only visualization of product
model, but also other activities like modification of the product model, reuse of
existing models and specification of assembly features. In general, visualization is
an activity performed by a much larger part of a company, when compared to
editing or modification of the CAD models. The cPAD technology proves that
existing bandwidth can support collaborative design.
• The system architecture is extensible. Due to the open architecture of the system,
additional design services can be added to the system. Technology proposed in
_____________________________________________________________________ 8
this research has adequately proved the ability to provide an open architecture for
collaboration.
However, this system uses too much servers i.e. an Intelligent Server as broker and five
application servers viz. Web server, Solid Modeling server, Database server,
Visualization server, and Catalog Database server.
2.3 Service Oriented Architecture (SOA) for Collaborative services
Jørstad et al. [10] proposed and investigated the use of SOA in the construction of
collaborative services. Introducing SOA they defined it as:
A Service Oriented Architecture (SOA) is a form of distributed systems architecture that
is typically characterized by the following properties:
• Logical view: The service is an abstracted, logical view of actual programs,
databases, business processes, etc., defined in terms of what it does, typically
carrying out a business-level operation.
• Message orientation: The service is formally defined in terms of the messages
exchanged between provider agents and requester agents, and not the properties of
the agents themselves. The internal structure of an agent, including features such
as its implementation language, process structure and even database structure, are
deliberately abstracted away in the SOA: using the SOA discipline one does not
and should not need to know how an agent implementing a service is constructed.
A key benefit of this concerns so-called legacy systems. By avoiding any
knowledge of the internal structure of an agent, one can incorporate any software
component or application that can be "wrapped" in message handling code that
allows it to adhere to the formal service definition.
• Description orientation: A service is described by machine-processable meta data.
The description supports the public nature of the SOA: only those details that are
exposed to the public and important for the use of the service should be included
in the description. The semantics of a service should be documented, either
directly or indirectly, by its description.
• Granularity: Services tend to use a small number of operations with relatively
large and complex messages.
_____________________________________________________________________ 9
• Network orientation: Services tend to be oriented toward use over a network,
though this is not an absolute requirement.
• Platform neutral: Messages are sent in a platform neutral, standardized format
delivered through the interfaces. XML is the most obvious format that meets this
constraint.
A service in SOA is an exposed piece of functionality with three properties:
1. The interface contract to the service is platform independent.
2. The service can be dynamically located and invoked.
3. The service is self-contained. That is, the service maintains its own state.
They classified the collaborative services as follows:
• Knowledge and resource sharing: In collaboration it is crucial to share knowledge
and resource together. By share it is meant several things:
o Presentation: the same knowledge or resource is presented such that all
the collaborators can view, experience and interpret it in the same way.
o Generation and modification: All the collaborators should be enabled to
generate and modify knowledge and resources in such way that
consistency and integrity are preserved
o Storage: the knowledge or resource must be stored safely without affecting
the availability.
• Communication and personal interaction: In collaboration, communication and
interaction between collaborator are crucial to avoid misunderstand and mismatch.
Communications can be classified in several ways:
o Synchronous (e.g. telephony, chat, sms, etc.) versus asynchronous (mail,
newsgroup, forum, etc.)
o Channels: Voice, text, multimedia
• Virtual rooms: All the collaborators shall share the same context in the same
manner as they are located in the same room. Examples are Team room,
Electronic Classroom.
• Organization management: It is also necessary to manage dynamically the
collaboration team itself and to distribute information about the team to all the
members in an efficient manner. The services include:
o Project/ team management
o Calendar, time scheduling, milestones, mail exploder.
_____________________________________________________________________ 10
They further mentioned that a collaborative service can be represented by four
components: ServiceLogic, ServiceData, ServiceContent and ServiceProfile
Further, ServiceLogic must be equipped with specific collaborative functions as follows:
1. Locking mechanism
Several types of locks are intent, shared, update, and exclusive.
2. Presentation control
3. User Presence management
4. Organization management
5. Communication control
The generic model of collaborative service is mapped to the Service Oriented
Architecture. To alleviate the tasks of the developers, the basic collaborative services,
Locking, Presentation Control, User Presence Management, Organization Management
and Communication Control are gathered into a Collaborative Service Layer and made
available to the applications. A collaborative service can be built by composing or by
orchestrating the collaborative services together with other services.
2.4 Orchestration and Choreography in Web Services
Peltz Chris [11] investigated the present scenario of Orchestration and Choreography in
Web Services. Collaboration in Web services is achieved through Orchestration and
Choreography which are described below:
Orchestration: Refers to an executable business process that may interact with both
internal and external Web services. Orchestration describes how Web services can
interact at the message level, including the business logic and execution order of the
interactions. These interactions may span applications and/or organizations, and result in
a long-lived, transactional process. With orchestration, the process is always controlled
from the perspective of one of the business parties.
Choreography: More collaborative in nature, where each party involved in the process
describes the part they play in the interaction. Choreography tracks the sequence of
messages that may involve multiple parties and multiple sources. It is associated with the
public message exchanges that occur between multiple Web services.
_____________________________________________________________________ 11
Orchestration differs from choreography in that it describes a process flow between
services, controlled by a single party. More collaborative in nature (see Figure 2.2),
choreography tracks the sequence of messages involving multiple parties, where no one
party truly "owns" the conversation. This article highlights key technical requirements for
Web services orchestration and choreography, and point out key standards used to meet
these needs.
Fig.2.2 web services orchestration and choreography
Technical Requirements for Orchestration and Choreography

Before introducing the standards, it's important to define the technical requirements for
orchestrating Web services. The following requirements are important for both the
language and the underlying infrastructure that supports it:
● Flexibility: One of the most important considerations is the flexibility offered by the
language. Flexibility can be achieved by providing a clear separation between the process
logic and the Web services invoked. This separation can usually be achieved through an
orchestration engine that handles the overall process flow. With this flexibility, an
organization can easily swap out services as business needs change.
●Basic and structured activities: An orchestration language must support activities for
both communicating with other Web services and handling workflow semantics. One can
think of a basic activity as a component that interacts with something external to the
process itself. In contrast, structured activities manage the overall process flow,
specifying what activities should run and in what order.
_____________________________________________________________________ 12
●Recursive composition: A single business process can interact with multiple Web
services. However, a business process can itself be exposed as a Web service, enabling
business processes to be aggregated to form higher-level processes.
In addition, both Web services orchestration and choreography must support some basic
requirements for managing the overall integrity and consistency of the interactions. These
requirements include:
●Persistence and correlation: The ability to maintain state across Web services
requests is an important requirement, especially when dealing with asynchronous Web
services. The language and infrastructure should provide a mechanism to manage data
persistence and correlate requests in order to build higher-level conversations.
●Exception handling and transactions: Orchestrated Web services that are long-
running must also manage exceptions and transactional integrity. For example,
resources cannot be locked in a transaction that runs over a long period of time.
Standards for Collaboration in Web Services

The two standards discussed here - the Web Service Choreography Interface (WSCI) and
Business Process Execution Language for Web Services (BPEL4WS) - are designed to
reduce the inherent complexity of connecting Web services together. Without them, an
organization is left to build proprietary business protocols that shortchange true Web
services collaboration.
WSCI
WSCI defines an extension to WSDL for Web services collaboration. Initially authored
by Sun, SAP, BEA, and Intalio, it was recently published as a W3C note. WSCI is a
choreography language that describes the messages exchanged between Web services that
participate in a collaborative exchange. A key aspect of WSCI is that it describes only the
observable behavior between Web services. It does not address the definition of an
executable business process.
A single WSCI interface describes only one partner's participation in a message
exchange. As Figure 2.3 illustrates, WSCI choreography would include a set of WSCI
interfaces, one for each partner in the interaction. In WSCI, there is no single controlling
process managing the interaction.
WSCI can be viewed as a layer on top of the existing Web services stack. Each action in
WSCI represents a unit of work, which typically would map to a specific WSDL
_____________________________________________________________________ 13
operation. WSCI can be thought of as an extension to WSDL, describing how the
operations can be choreographed. In other words, WSDL describes the entry points for
each service, while WSCI would describe the interactions among these WSDL
operations.
WSCI defines an <action> tag for specifying a basic request or response message. Each
activity specifies the WSDL operation involved and the role being played by the
participant. External services can then be invoked through the <call> tag. A wide variety
of structured activities are supported, including sequential and parallel processing and
condition looping. WSCI also introduces an <all> activity, used to indicate that the
specific actions have to be performed, but not in any particular order.
BPEL4WS
The BPEL4WS standard represents a convergence of ideas originally proposed by two
early workflow languages, XLANG and WSFL. Microsoft, IBM, Siebel Systems, BEA,
and SAP authored the 1.1 release of the specification in May 2003. It provides an XML-
based grammar for describing the control logic required to coordinate Web services
participating in a process flow and is layered on top of WSDL, with BPEL4WS defining
how the WSDL operations should be sequenced.
BPEL4WS provides support for both abstract business protocols and executable business
processes. A BPEL4WS business protocol specifies the public message exchanges
between parties. Business protocols are not executable and do not convey the internal
details of a process flow, similar to WSCI. An executable process models the behavior of
participants in a specific business interaction, essentially modeling a private workflow.
Executable processes provide the orchestration support described earlier, while the
business protocols focus more on Web services choreography.
The BPEL4WS specification supports basic activities for communicating with Web
services. The typical scenario is that there is a message received into a BPEL4WS
executable process. The process may then invoke a series of external services to gather
additional data, and then respond back to the requestor. In Figure 2.3, the <receive>,
<reply>, and <invoke> messages all represent basic activities for connecting the services
together.
_____________________________________________________________________ 14
BPEL4WS also supports structured activities for constructing the business logic for a
process. These activities include sequential and parallel activities, as well support for
conditional looping and dynamic branching.
Variables and partners are two other important elements within BPEL4WS that satisfy the
requirements for persistence and correlation.
● Variable: Identifies the specific data exchanged in a message flow, which
typically maps to a WSDL message type or XML schema type. When a
BPEL4WS process receives a message, the appropriate variable is populated so
that subsequent requests can access the data.
● Partner: Defines the various parties that interact with the process.
WSCI BPEL4WS
Fig2.3 Standards for Orchestration and Choreography
_____________________________________________________________________ 15
CHAPTER-3
Orchestration and Choreography of Web Services

employed in Design and Manufacturing
3.1 Objective of the present work
After going through an extensive literature survey (presented in Chapter 2) it is evident

that the propositions made by various researchers lack in one or other way. Chung et al.
[3] proposed a system called MIDAS (Manufacturing Integration and Design Automation
System) which had different modules written in Java and which communicated with each
other using RMI (Remote Method Invocation), so it was very close to Web Services as
Web Services also use RMI to communicate sometimes. They used a process grammar
which supported the iterative nature of engineering processes and layered approach to
information modeling. However, they had to use many servers viz. communication
server, site proxy server, and user info server which added to the complexity of the
proposed system. The system was an extension of agent based client-server architecture
but Web Services are purely peer-to-peer. Similarly, Qureshi et al. [4] proposed Design
for Facility over Internet (DFF) methodology to provide an environment for designers to
perform manufacturability analysis of product designs. This system was distributed
through the Java servlets. The process can not be automated as it uses only Java classes
and not XML. Machine can understand data transferred through XML. Leitão et al. [5]
proposed architecture for distributed manufacturing which was a very complex system
based in the Holonic Manufacturing Systems and Bionic Manufacturing Systems
concepts. This agent based architecture had various modules and a Knowledge Base
module at the centre. This was again client-server architecture and was tightly coupled as
different modules were dependent on one another. Then Sequin et al. [6] proposed a Java
based networked CAD/CAM environment. This system requires CAD software to be
installed at all the participating machines. Wright et al. [8] proposed a networked
manufacturing service named CyberCut where a client-designer submits its design to a
particular server for process planning. Server then utilizes open-architecture,
computerized machine tool for fabrication. However, this is a one way flow where only
server does the manufacturing work. Shyamsundar et al. [9] developed a collaborative
_____________________________________________________________________ 16
Product Assembly Design (cPAD) tool. A Java based client interface was used. In the
system, instead of installing the CAD software on every machine, the designer uses the
CAD software which is packaged into a CAD server. However, this system uses too much
servers i.e. an Intelligent Server as broker and five application servers viz. Web server,
Solid Modeling server, Database server, Visualization server, and Catalog Database
server.
Objective of the present work is to look into possible use of Orchestration and
Choreography offered by Web Services into design and manufacturing process. Web
Services are platform independent, loosely coupled, and truly peer-to-peer architecture
which needs no website. The service is described in machine interpretable WSDL
language, which renders it to be discovered automatically. This is the main advantage of
Web Services as a machine can discover and invoke a service automatically. WSDL can
also be understood by humans who can control the process, if it is going in undesired
fashion. As machine can not understand the meanings of words, lots of work are going on
to introduce ontology which can provide semantic markup of Web Services. One such
effort is Semantic Web Ontology Language (OWL-S). For global, use Web Services are
registered on publicly available registries known as Universal Description Discovery and
Integration (UDDI). UDDI also describes the binding templates and interfaces to the
services.
3.2 Statement of the problem
A Die Casting Design and Manufacturing process involving four partners viz. Casting
Buyer, Die Design Analyzer, Die Manufacturer, and Casting Manufacturer is taken into
consideration, as this process consists of both design and manufacturing closely
associated with each other. If the number of castings to be cast, changes at any moment
then the die is designed afresh. And as the dies are made up of hard and thermal resistant
materials which require special machine tools, the dies are made by companies which
specialize in it. So, many companies are involved in this process. A company which
needs a casting may not be willing to bother about the die design and manufacturing
process, so the whole process should be seen as one service which can be done better
through Web Services. After building the die casting design and manufacturing process
which eventually contain four Web Services, the whole process can be presented as one
Web Service. Therefore, this process is taken into consideration in this study. In the
_____________________________________________________________________ 17
process Casting Buyer orders a casting by giving design requirements to Die Design
Analyzer and Die Manufacturer both. After analysis, Analyzer forwards information
about selected material for die to the Die Manufacturer, which prepares dies for both
casting and trimming. On getting dies and trim dies from Die Manufacturer, Casting
Manufacturer prepares casting and then trims it to give finished product. The process is
shown below in the figure:
Casting Design
Buyer requirements
Die design Analyzer

Die Design Dies Part Analysis
Manufacturer
Designed trim dies Designed dies Selected material
Make trim dies Make dies
Trim dies Dies
Casting
Die casting
Manufacturer
Finished casting
Trim
Trimmed part
Outside processing
Finished product
Fig.3.1 Overview of Die Casting Design and Manufacturing process
3.3 Software tools used in the study
In this study Java programming language as it is publicly available and platform

independent and it is widely used in the networking domain due to availability of rich
libraries which supports networking, though the Web Services can be written in other
languages as it also platform and language independent. For deploying Web Services a
_____________________________________________________________________ 18
SOAP (Simple Object Access Protocol) server is needed for which Apache-AXIS is used
here as it is publicly available and widely used. Other technologies such as .NET from
Microsoft® are proprietary and they use C++ programming language which is not
platform independent. Apache-AXIS requires an application server which can support
web application, for which Apache Tomcat/4.1.12-LE-jdk14 is used here since it is
publicly available and AXIS works best with it and is widely used. Then for the
orchestration of Web Services PARASOFT® BPEL Maestro for Web Service
Orchestration, Version 1.6.0 is used which is a freely available Web Services
orchestration engine. Fig 3.2 shows how these softwares work in tandem to collaborate
Web Services. It can be seen from the figure that all the web services are described in
WSDL and can be located on disparate systems. They can use any technology to write
web services. All the web services can be accessed irrespective of the software used and
hardware on which it is employed. The messages which are being exchanged are in
SOAP format. The ovals used in the figure show the particular setup of software used in
this study. It is clear that Java is the core of the system, and that there is a layer of
softwares viz. Tomcat, AXIS, and BPEL maestro, which are described above.
Casting Buyer Die design Analyzer Die Manufacturer Casting Manufacturer

(WSDL) (WSDL) (WSDL) (WSDL)
SOAP
SOAP
SOAP SOAP
Internet
SOAP
BPEL Orchestration Engine
SOAP Web Application

Server Server
(AXIS) (Tomcat) JAVA
Fig 3.2 Conceptual model of the orchestration process
_____________________________________________________________________ 19
3.4 Methodology of the study
In this study firstly, j2sdk1.4.2_04 version of Java was installed. Then Tomcat was
installed, and then a folder named axis in webapps folder of axis-1_1 was copied into the
webapps folder of Tomcat. In this way AXIS was installed. After installation
http://127.0.0.1:8080/axis/ was typed in the web browser. As 127.0.0.1 is used for the
localhost so the main page of AXIS installed at the local system is displayed. This page is
shown in fig.3.3. In this page various links can be seen e.g. Validate the local
installation’s configuration; view the list of deployed web service, Administer AXIS,
SOAPmonitor.
_____________________________________________________________________ 20
Fig 3.3 Main page of Apache AXIS
_____________________________________________________________________ 21
In this study four Web Services were written named CastingBuyer, DieDesignAnalyzer,
DieDesnManufr, and DieCastingManufr. All the Web Services and their interfaces, and
binding stubs, were written using Java. These Java codes are presented in appendix. The
deployment descriptor files for deployment of the Web Services were written in XML.
After compilation in Java these Web Services were deployed to AXIS using deployment
descriptor files from the command prompt through AXIS AdminClient command. On
clicking the link view the list of deployed web services in the main page of AXIS, a page
(shown in fig 3.4) is displayed which shows a list of deployed Web Services with the
interfaces each service provides to access it. There is a link which takes to the WSDL
description of the service. If the SOAP server is publicly available then any system can
automatically search for the desired service with the help of UDDI lookup. However, in
this study the wsdl files of the Web Services are available from the main page of AXIS
they can be searched in some UDDI registries over the internet.
_____________________________________________________________________ 22
Fig. 3.4 List of deployed Web Services
_____________________________________________________________________ 23
wsdl files of services can be obtained by clicking the wsdl link given beside the name of
service in the list of services page. The wsdl page (fig 3.5) contains the description of web
service. WSDL description mainly consists details of messages which can be exchanged,
SOAP binding of the service (i.e. how it is converted into SOAP messages), and details of
portType (portType is the entry point to a service. The interfaces which a web service
allows are converted into portType in wsdl. portType contains operation, input and output
message details).
On getting wsdl files, services can be accessed by sending SOAP messages. Axis
provides a way to generate SOAP binding stub which hides all the bindings and access
the services through Java program as if the services were in our system. In this way all the
required services can be called in a program and can be used in any desired sequence or
flow. In this study the problem of die design and manufacturing was also solved by this
method.
In fig 3.5 wsdl of only CastingBuyer web service is presented. Similarly, wsdl of all the
four web services can be obtained.
_____________________________________________________________________ 24
Fig. 3.5 WSDL description of Web Service CastingBuyer
_____________________________________________________________________ 25
Now coming to the orchestration part, a process flow was built in BPEL Maestro in which
all the wsdl files of the services were imported. The process flow was written using
Business Process Execution Language (BPEL), the code of which is presented in
appendix. A deployment.xml file was also written to render the deployment of the process
flow to the orchestration engine. When the process is built in Maestro it shows the
process in an UML (Unified Modeling Language) diagram, which is presented in fig 3.7.
In the figure, the process starts on receiving a message from service CastingBuyer. On
receiving message the process invokes two services i.e. DieDesignAnalyzer and
DieDesnManufr in parallel. After invoking these two services, the design requirements
are assigned from CastingBuyer service to both services. And the selected material after
analysis is passed to the DieDesnManufr from DieDesignAnalyzer service. These three
assign activities are done in parallel. Thereafter, the DieCastingManufr service is invoked
and designed dies and trim dies are assigned to it from DieDesnManufr service. Then the
process ends by sending required casting to the CastingBuyer service as reply to the first
message received in the process. The SOAP message sent to the process is shown below:
<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header
xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">uuid:005692
22-bf7c-4eca-9c7c-ae7f29c522ef</MessageID>
<ReplyTo
<wsa:Address>http://144.16.204.182:18585/axis/services/CallbackService</
wsa:Address>
</ReplyTo>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<design_requirement
xmlns="http://127.0.0.1:8080/axis/services/CastingBuyer"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Fig.3.6 SOAP Message sent to the CastingBuyer service from the system.
_____________________________________________________________________ 26
Fig. 3.7 Process flow of Die Design and Manufacturing process in BPEL Maestro orchestration engine
The messages exchanged among the services can be viewed by using browse option
available in BPEL Maestro, after the execution of the process. The result of which is
presented in fig 3.8. The messages can be seen between the <message> tags against each
variable used in the process. The messages used in the study were of string type; however
_____________________________________________________________________ 27
they can be in any format available in SOAP. Technical details like drawings can also be
passed using new format of SOAP known as SOAP with attachment (wSOAP), however
this facility was not available with the current tool. The messages passed in the process
were design requirements, selected material, designed dies and trim dies, and required
casting.
BPEL Maestro for Web Service Orchestration, Version 1.6.0
Process: _DieCasting 1
Debugger: (none)
Variable Values:
Variable Value
<message
xmlns:ns1="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<part name="MessageID"
message="ns1:MessageInformationHeader">
<MessageID
uuid:00569222-bf7c-4eca-9c7c-ae7f29c522ef
</MessageID>
</part>
_DesReq_req
<part name="ReplyTo" message="ns1:MessageInformationHeader">
<ReplyTo
<Address>
http://144.16.204.182:18585/axis/services/CallbackService
</Address>
</ReplyTo>
</part>
</message>
<message
xmlns:ns1="http://127.0.0.1:8080/axis/services/CastingBuyer">
<part name="design_requirementReturn"
message="ns1:design_requirementResponse">
_DesReq_res 1.Potential die casting application 2.Optimum die cast shapes,
forms and sizes 3.Structural considerations 4.Finish
machining factors 5.Surface treatment considerations.
</part>
</message>
_die_req <message>
_____________________________________________________________________ 28
</message>
<message xmlns:ns1="http://127.0.0.1:8080/axis/services/
DieDesnManufr ">
_die_res <part name="diesReturn" message="ns1:diesResponse">
</part>
</message>
<message>
_finProd_req
</message>
DieCastingManufr ">
<part name="FinishedProductReturn" message="ns1:
_finProd_res FinishedProductResponse">
Required_Casting
</part>
</message>
DieCastingManufr ">
<part name="param2" message="ns1:getTrimDiesRequest">
_getTrimDie_req
param2
</part>
</message>
DieCastingManufr ">
<part name="param1" message="ns1:getDiesRequest">
_getDie_req
param1
</part>
</message>
DieCastingManufr ">
<part name="getDiesReturn" message="ns1:getDiesResponse">
_getDie_res
Designed and Manufactured Dies
</part>
</message>
DieCastingManufr ">
<part name="getTrimDiesReturn"
_getTrimDie_res message="ns1:getTrimDiesResponse">
Designed and Manufactured Trim Dies
</part>
</message>
<message>
_mdesDie_req
</message>
DieDesnManufr ">
_mdesDie_res <part name="designDiesReturn"
message="ns1:designDiesResponse">
Designed and Manufactured Dies
_____________________________________________________________________ 29
</part>
</message>
<message
xmlns:ns1="http://127.0.0.1:8080/axis/services/DieDesnManufr">
<part name="param" message="ns1: getBuyerDesignReqRequest">
_mDesReq_req
param
</part>
</message>
<message
xmlns:ns1="http://127.0.0.1:8080/axis/services/DieDesnManufr">
<part name="getBuyerDesignReqReturn" message="ns1:
getBuyerDesignReqResponse">
_mDesReq_res 1.Potential die casting application 2.Optimum die cast shapes,
</part>
</message>
DieDesnManufr ">
<part name="paramtr" message="ns1:getselectedMaterialRequest">
_mSelMat_req
paramtr
</part>
</message>
DieDesnManufr ">
<part name="getselectedMaterialReturn"
_mSelmat_res message="ns1:getselectedMaterialResponse">
die steel
</part>
</message>
<message>
_selMat_req
</message>
<message
xmlns:ns1="http://127.0.0.1:8080/axis/services/DieDesignAnalyzer ">
<part name="selectedMaterialReturn"
_selMat_res message="ns1:selectedMaterialResponse">
die steel
</part>
</message>
<message>
_trimDie_req
</message>
DieDesnManufr ">
<part name="trimDiesReturn" message="ns1:trimDiesResponse">
_trimDie_res
Designed and Manufactured Trim Dies
</part>
</message>
_____________________________________________________________________ 30
DieDesignAnalyzer ">
<part name="param" message="ns1:getDesignReqRequest">
a_DesReq_req
param
</part>
</message>
DieDesignAnalyzer ">
<part name="getDesignReqReturn" message="ns1:
getDesignReqResponse">
a_DesReq_res 1.Potential die casting application 2.Optimum die cast shapes,
</part>
</message>
sequence
receive BuyerReq
flow
invoke Design_Analyzer
invoke Die_Designer
{http://www.parasoft.com/bpel}internalError - No such operation
'dies'
flow
assign pass_design_reuirement_to_Analyzer
assign pass_design_requirements_to_Designer
assign pass_selected_material_to_Designer
invoke Casting_Manufacturer
assign
assign
reply finished_product
Legend
Breakpoint
Completed Activity
Suspended Activity
Unhandled Fault
Fig.3.8 SOAP message overview exchanged among the services in the process.
3.5 Conclusion
As evident from the results obtained from the study presented in this chapter in detail,
collaboration is achieved in Design and Manufacturing of a Die Casting process through
the use of a web services orchestration engine named BPEL Maestro which works in
tandem with a SOAP server named AXIS and an web application server named Tomcat
which is a Java based software. All the softwares used in the study are available free.
_____________________________________________________________________ 31
CHAPTER-4
Results and Conclusions
4.1 Results and Discussion
As presented in chapter 3, in this study web services were written using Java
programming language and then deployed to a SOAP server using Tomcat and AXIS to
get wsdl files i.e. description file of the web services. Then the collaboration was done
using orchestration engine BPEL Maestro and the wsdl files obtained through AXIS. The
results obtained are encouraging. Orchestration and Choreography offered by Web
Services can be used in collaboration in Design and Manufacturing. For global use, the
most important part is the standardization of interfaces provided by the service. The name
of the service and that of interfaces should be self-explanatory and some standard practice
should be followed in order to render easy and accurate search of Web services. Ontology
powered semantic search could be used to improve the performance of Web services.
Then comes the security part, which is ubiquitous in every process which is implemented
via. Internet. So, it is not a big problem as security aspects are always looked on in a big
way by software developers.
4.2 Conclusions
In this thesis, the Collaboration in Design and Manufacturing using Web Services,
collaboration was achieved in a Design and Manufacturing process through orchestration
and choreography offered by Web Services. First a Design and Manufacturing process
was chosen in which collaboration is highly required. In this case it was a die casting
design and manufacturing process in which four companies were involved.
As reported in chapter 2 the architectures which are present currently are not enough for
real time, automatic collaboration because they use tightly coupled CAD/CAM
applications or client-server architecture with too many servers (one server each for a
specific application).
Then the Web Services were written and deployed using widely used public domain
software and then they were orchestrated using orchestration engine. The results obtained
_____________________________________________________________________ 32
were encouraging. Finally, the design and manufacturing process was presented as a Web
Services for further use.
4.3 Scope for future work
In the study, public UDDI registry was not used since all the Web Services were written
and deployed locally. Some publicly available services can be used in any process and
moreover it should be searched automatically by the machine. For the automatic search
semantic language should be used, e.g. Semantic Web Ontology Language (OWL-S)
[12]. The SOAP messages exchanged among the Web Services in this process were of
simple types (e.g. string, int, float etc.). Study can be carried out using wSOAP i.e. SOAP
with attachments. More technical details can be transferred using wSOAP.
_____________________________________________________________________ 33
CHAPTER-5
References
[1] Nickerson V. Jeffrey, and Stohr A. Edward, “Intra Enterprise Integration:

Methods and Direction”, Competing in the Information Age, Oct 2003.
[2] Johannesson Paul, and Perjons Erik, “Design principles for process modeling in
enterprise application integration”, Information Systems, 2001(26) pp.165-184.
[3] Chung Moon Jung, Kim Sangchul, Kim Hyun, and Ham Ho Sang, “A Java-Based,
Distributed Process Management System for Collaborative Design and
Manufacturing”, FIDJI 2002, LNCS 2604, 2003, pp. 61-72.
[4] Qureshi A. Khurshid and Saitou Kazuhiro, “Design for Facility over the Internet:
a case study with automotive connecting rod designs”, Proceedings of DETC’01
ASME 2001 Design Engineering Technical Conference and Computers and
Information in Engineering Conference Pittsburgh, PA, September 9-12, 2001.
[5] Leitão Paulo and Restivo Francisco, “A Framework for Distributed Manufacturing
Applications”, ICIMS-NoE 2000 Advanced Study Institute, Bordéus, September
2000.
[6] Sequin Carlo, Ahn Sung, and Wright Paul, “Internet-based Design and
Manufacturing”, Proceedings of the 1998 Japan-USA Symposium on Flexible
Automation, Ohtsu, Japan, July 13-15 1998, (1998).
[7] Muammer Koc and Jun Ni, “Introduction of e-Manufacturing”, NAMRC 2003 E-
Manufacturing Panel, McMaster University, May 2003.
[8] Wright Paul and Sequin Carlo, “CyberCut: A Networked Manufacturing Service”,
Transactions of NAMRC/SME, Vol. XXVI, 1998.
[9] Shyamsundar N. and Gadh R., “Collaborative virtual prototyping of product
assemblies over the Internet”, Computer-Aided Design 34 (2002), pp 755-768.
[10] Jørstad Ivar, Dustdar Schahram, and Thanh Do Van, “A Service Oriented
Architecture for collaborative services”, 3rd International Workshop on
Distributed and Mobile collaboration (DMC), IEEE WETICE, Linköping,
Sweden, IEEE Computer Society Press, 2005.
[11] Peltz, C. "Web Services Orchestration and Choreography," IEEE Computer
(October), pp 46-52, October 2003.
[12] OWL-S 1.0 Release http://www.daml.org/services/owl-s/1.0/
_____________________________________________________________________ 34
[13] W3C Working Group Note, SOAP 1.2 Attachment Feature,
http://www.w3.org/TR/soap12-af/
[14] Woongsup Kim et al., “Service Model for Collaborating Distributed Design and
Manufacturing,” WWW Workshop on Application Design, Development and
Implementation Issues in the Semantic Web 2004. http://server2.tecweb.inf.puc-
rio.br/we-sw-2004/www-se.pdf
[15] Chung, M.J., and Kwon, P. “A Web-based Framework for Design and
Manufacturing a Mechanical System,” DETC, Atlanta, Georgia. Sep. 1998.
[16] Frank Sommers, “A birds-eye view of Web Services”, Java World, January 2002.
[17] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, and D.
Orchard, “Web Services Architecture”, W3C Working Draft 8 August 2003.
[18] H Yang, D Xue, “Recent Research on developing Web-based manufacturing s
ystems: A review”, Int. J. Prod. Res., 2003, Vol.41, No.15, pp3601-3629
[19] IBM, “Patterns: Service-Oriented Architecture and Web Services”, Redbook,
April 2004.
[20] Robert Eisenberg, “Service-Oriented Architecture: The Future is Now”, Intelligent
Enterprise, April 2004.
[21] Francisco Curbera, Rania Khalaf, Nirmal Mukhi, Stefan Tai, Sanjiva
Weerawarana, “The Next Step in Web Services”, Communications of the ACM,
October 2003/Vol. 46, No. 10, pp29-34.
[22] Curbera, F., Khalaf, R., Leymann, F., and Weerawarana, S., “Business Processes:
Understanding BPEL4WS”, in Proceedings of the International Conference on
Business Process Management, BPM 2003 (Eindhoven, The Netherlands, June
2003).
[23] Business Process Execution Language for Web Services, version 1.1.;
www.ibm.com/developerworks/library/ws-bpel/.
[24] Curbera, F. et al., “Unraveling the Web services Web: An introduction to SOAP,
WSDL, and UDDI”, IEEE Internet Computing 6, 2 (Mar./Apr. 2002).
[25] Robert Wegener, “How Manufacturers Can leverage Web Services Today”, RCG
Information Technology White Paper.
[26] Heather Kreger, “Web Service Conceptual Architecture (WSCA 1.0)”, IBM
Software Group, May 2001.
_____________________________________________________________________ 35
[27] Zhao J. Leon, Cheng Hsing Kenneth, “Web services and process management: a
union of convenience or a new area of research?”, Decision Support Systems 40
(2005), pp1-8.
[28] Shacklett Mary, “Collaboration software plays pivotal role in manufacturing
organizations”, Unisys World, June 2003.
[29] Cui Juntao, Liu Jiamao, Wu Yujin, and Gu Ning, “An ontology Modeling Method
in Semantic Composition of Web Services”, Proceedings of the IEEE
International Conference on E-Commerce Technology for Dynamic E-Business
(CEC-East’04)
[30] Nahm Yoon-Eui, Ishikawa Haruo, “Integrated Product and Process Modeling for
Collaborative Design Environment”, CONCURRENT ENGINEERING: Research
and Applications, Vol.12, No.1, March 2004, pp5-23.
[31] Sherman Doron, “BPEL: Make Your Services Flow”, Web Services Journal, June
2003.
[32] Chung Moon Jung, Jung Hong Suk, Kim Woongsup, Gopalannalan Ravi, “A
Framework for Collaborative Product Commerce using Web Services”,
Proceedings of the IEEE International Conference on Web Services (ICWS’04).
[33] Colan Mark, “Dynamic e-business: Using Web services to transform business”,
IBM e-business, June 2001.
_____________________________________________________________________ 36
Appendices
A-1 Overview of Web Services
What are Web Services

A Web Service is programmable application logic accessible using standard
Internet protocols. Web Services combine the best aspects of component-based
development and the Web. Like components, Web Services represent functionality that
can be easily reused without knowing how the service is implemented. Unlike current
component technologies which are accessed via proprietary protocols, Web Services are
accessed via ubiquitous Web protocols (ex: HTTP) using universally-accepted data
formats (ex: XML).
In practical business terms, Web Services have emerged as a powerful mechanism
for integrating disparate IT systems and assets. They work using widely accepted
technologies and are governed by commonly adopted standards. Web Services can be
adopted incrementally with little risk and at low cost. Today, enterprises use Web
Services for point-to- point application integration, to reuse existing IT assets, and to
securely connect to business partners or customers. Independent Software Vendors (ISVs)
embed Web Services functionality in their software products so they are easier to deploy.
From a historical perspective, Web Services represent the convergence between
the service-oriented architecture (SOA) and the Web. SOAs have evolved over the last 10
years to support high performance, scalability, reliability, and availability. To achieve the
best performance, applications are designed as services that run on a cluster of centralized
application servers. A service is an application that can be accessed through a
programmable interface. In the past, clients accessed these services using a tightly
coupled, distributed computing protocol, such as DCOM, CORBA, or RMI. While these
protocols are very effective for building a specific application, they limit the flexibility of
the system. The tight coupling used in this architecture limits the reusability of individual
services. Each of the protocols is constrained by dependencies on vendor
implementations, platforms, languages, or data encoding schemes that severely limit
interoperability. And none of these protocols operates effectively over the Web.
_____________________________________________________________________ 37
The Web Services architecture takes all the best features of the service oriented
architecture and combines it with the Web. The Web supports universal communication
using loosely coupled connections. Web protocols are completely vendor-, platform-, and
language-independent. The resulting effect is an architecture that eliminates the usual
constraints of DCOM, CORBA, or RMI. Web Services support Web based access, easy
integration, and service reusability.
As stated earlier, a Web Service is an application or information resource that can
be accessed using standard Web protocols. Any type of application can be offered as a
Web service. Web Services are applicable to any type of Web environment: Internet,
intranet, or extranet. Web Services can support business-to-consumer, business-to-
business, department-to-department, or peer-to-peer interactions. A Web Service
consumer can be a human user accessing the service through a desktop or wireless
browser; it can be an application program; or it can be another Web Service. Web
Services support existing security frameworks.
Today, Web Services products like Systinet WASP will operate anywhere, in
almost any existing IT setting.
Service Assembly
A Web Service represents a discrete unit of business, application, or system
functionality. Each discrete Web Service can be deployed on and accessed from any node
on the Internet. Multiple services can be combined or assembled to deliver more valuable
services. This modular approach gives businesses great flexibility in system design. By
reassembling a few services into a new configuration, a business can create a new
business service to support a different business objective.
Definitive Characteristics
Web Service exhibits the following definitive characteristics:
• A Web Service is accessible over the Web. Web Services communicate using
platform-independent and language-neutral Web protocols. These Web protocols
ensure easy integration of heterogeneous environments.
• A Web Service provides an interface that can be called from another program.
This application-to-application programming interface can be invoked from any
type of application client or service. The Web Service interface acts as a liaison
between the Web and the actual application logic that implements the Service.
_____________________________________________________________________ 38
• A Web Service is registered and can be located through a Web Service Registry.
The registry enables service consumers to find services that match their needs.
• Web Services support loosely coupled connections between systems. Web
Services communicate by passing messages to each other. The Web Service
interface adds a layer of abstraction to the environment that makes the connections
flexible and adaptable.
Web Services Technologies

Web Services can be developed using any programming language and can be
deployed on any platform. Web Services can communicate because they all speak the
same language: the Extensible Markup Language (XML). Web Services use XML to
describe their interfaces and to encode their messages. XML-based Web Services
communicate over standard Web protocols using XML interfaces and XML messages,
which any application can interpret.
But XML by itself does not ensure effortless communication. The applications
need standard formats and protocols that allow them to properly interpret the XML.
Hence three XML-based technologies have emerged as the de facto standards for Web
Services:
• Simple Object Access Protocol (SOAP) defines a standard communications
protocol for Web Services.
• Web Services Description Language (WSDL) defines a standard mechanism to
describe a Web Service.
• Universal Description, Discovery and Integration (UDDI) provides a standard
mechanism to register and discover Web Services.
Figure 1 shows how these technologies relate to one another. When a service provider
wants to make the service available to service consumers, he describes the service using
WSDL and registers the service in a UDDI registry. The UDDI registry will then
maintain pointers to the WSDL description and to the service. When a service consumer
wants to use a service, he queries the UDDI registry to find a service that matches his
needs and obtains the WSDL description of the service, as well as the access point of the
service. The service consumer uses the WSDL description to construct a SOAP message
with which to communicate with the service.
_____________________________________________________________________ 39
Figure 1 Core Web services technologies are SOAP, WSDL and UDDI.
SOAP
SOAP is an extensible XML messaging protocol that forms the foundation for
Web Services. SOAP provides a simple and consistent mechanism that allows one
application to send an XML message to another application.
Fundamentally, SOAP supports peer-to-peer communications. A SOAP message
is a one-way transmission from a SOAP sender to a SOAP receiver, and any application
can participate in an exchange as either a SOAP sender or a SOAP receiver. SOAP
messages may be combined to support many communication behaviors, including
request/response, solicit response, and notification.
SOAP was first developed in late 1999 by DevelopMentor, Microsoft, and
UserLand as a Windows-specific XML-based remote procedure call (RPC) protocol. In
early 2000 Lotus and IBM joined the effort and helped produce an open, extensible
version of the specification that is both platform- and language-neutral. This version of
the specification, called SOAP 1.1 (see http://www.w3.org/TR/SOAP/), was submitted to
the World Wide Web Consortium (W3C). W3C subsequently initiated a standardization
effort. SOAP 1.2 is the latest, approved version of the standard. You can find out the
latest status of activities at http://www.w3.org/2000/ws/.
SOAP consists of four parts:
SOAP Envelope. The SOAP envelope provides a mechanism to identify the contents of a
message and to explain how the message should be processed. A SOAP envelope
includes a SOAP header and a SOAP body. The SOAP header provides an extensible
_____________________________________________________________________ 40
mechanism to supply directive or control information about the message. For example, a
SOAP header could be used to implement among other things:
• Transactions
• Security, for instance, using WS-Security
• Reliability, using the upcoming WS-ReliableMessaging standard
• Routing
• Payment mechanisms
SOAP Body. The SOAP body contains the payload that is being sent in the SOAP
message.
SOAP Transport Binding Framework. SOAP 1.1 defines bindings for HTTP and the
HTTP Extension Framework. SOAP 1.2 defines a default binding for HTTP (not the
extension framework) and provides for other bindings such as SMTP, JMS and others.
SOAP Serialization Framework. All data passed through SOAP messages are encoded
using XML. Data can be passed as a literal XML document that validates against some
XML Schema (http://www.w3.org/XML/Schema) document, or data can be passed using
the original SOAP encoding rules that are based on an early version of XML Schema but
diverge from it in several significant ways. The Web Services Interoperability
Organization (WS-I, http://www.wsi. org/) maintains what might be called a Web
Services ‘super-standard’ called the “Basic Profile 1.0.” This profile recommends against
the use of SOAP encoding in applications, though long usage means that a number of
services are already in existence using SOAP encoding.
Services may be designed to work on the raw XML payload, but it is more
common for the payload to be mapped or bound directly to data types in the host
language. This step is called serialization and is implemented by most Web service
implementations. Serialization is possible regardless of whether the payload is a literal
XML document or SOAP encoded as both support common features found in the type
systems of most programming languages and databases. This includes simple scalar types
such as strings, integers, and floats, and complex types, such as structures and arrays.
SOAP RPC Style Messaging
SOAP supports a tightly coupled communication scheme based on the SOAP RPC
representation. The SOAP RPC representation defines a programming convention that
represents RPC requests and responses. Using SOAP RPC, the developer formulates the
SOAP request as a method call with zero or more parameters. When the payload is
_____________________________________________________________________ 41
constructed into a single structure the outermost element represents the name of the
method or operation, and the innermost elements represent the parameters to the
operation. The SOAP response is similar with an outermost element named in relation to
the method name and the innermost parameters representing zero or more return
parameters.
SOAP Document Style Messaging
SOAP also supports very loosely coupled communications between two
applications. The SOAP sender sends a message and the SOAP receiver determines what
to do with it. The SOAP sender doesn’t really need to know anything about the
implementation of the service other than the format of the message and the access point
URI. It is entirely up to the SOAP receiver to determine, based on the contents of the
message, what the sender is requesting and how to process it. Note that even with
Document Style Messaging it is possible to emulate RPCs by putting the
method/operation name in the SOAPAction header of the HTTP request.
SOAP with Attachments
The SOAP with Attachments binding (http://www.w3.org/TR/SOAPattachments)
can be used to transport non-XML data, such as multimedia files, as attachments to a
SOAP message. This specification uses MIME to encode messages. Though MIME is
ubiquitous it is not necessarily the best mechanism for sending binary messages in a
SOAP envelope. An alternate mechanism is called DIME, and the WSAttachments
specification (http://www- 106.ibm.com/developerworks/webservices/library/ws-
attach.html) describes how to embed DIME in a SOAP Envelope.
WSDL
WSDL is an XML vocabulary for describing a Web Service. A WSDL document
describes what functionality a Web Service offers, how it communicates, and where it is
accessible. WSDL provides a structured mechanism to describe the operations a Web
Service can perform the formats of the messages that it can process, the protocols that it
supports, and the access point of an instance of the Web Service. SOAP development
tools can use a WSDL description to automatically generate a SOAP interface for use in
an application.
A WSDL description defines a service as a collection of network endpoints or
ports. Each port is defined abstractly as a port type, which supports a collection of
_____________________________________________________________________ 42
operations. Each operation processes a particular set of messages. A binding maps a port
type to a specific protocol and data format. A port instantiates a port type and binding at a
specific network address.
A WSDL description is an XML document that contains a set of definitions. There
are five major elements within a WSDL document:
1. Types. The <types> element defines the data types that are used within messages.
WSDL uses the data typing system defined in the W3C XML Schema Part 2: Data types
Recommendation (see http://www.w3.org/TR/xmlschema-2/) as its canonical type
system, although any data typing system may be used. The type system supports simple
scalar types and complex types. Schema types can be mapped to most programming
language type systems. SOAP tools use the type information to encode and decode the
data in SOAP messages.
2. Message. A <message> element defines the format of a message. Messages are used as
input or output structures for operations. A message can consist of one or more logical
parts, each of which is associated with a type. When using the SOAP RPC programming
model, each part represents a method parameter.
3. Port Type. A <portType> element defines a set of operations. Each <operation>
element defines an operation and the input and output messages associated with the
operation. When using the SOAP RPC programming model, each operation represents a
method.
4. Binding. A <binding> element maps the operations and messages defined in a port
type to a concrete protocol and data format specification. For example, a binding element
might map a port type to a specific SOAP RPC interface using the HTTP transport
protocol and the SOAP data encoding system.
5. Service. A <service> element defines a collection of related ports. A <port> element
maps a binding to the location (a URL) of an instance of the Web Service.
Services and Service Types

The type, message, and port type elements define a service in an abstract way. A
WSDL description that contains only these elements, in effect, describes a service type.
The binding element maps the service type to a specific protocol. The service element
maps the service type and the binding to a specific instance of the service. The binding
_____________________________________________________________________ 43
elements and service elements can be maintained in separate WSDL documents to
provide more reusability and flexibility.
UDDI
UDDI provides a mechanism to register and categorize Web Services that you
offer and to locate Web Services that you would like to consume. UDDI is itself a Web
Service. Users communicate with UDDI using SOAP messages.
A UDDI Registry contains information about businesses and the services they offer. The
information is organized as follows:
• Business Entity. A business entity contains information about a business
including its name, a short description, and some basic contact information. Each
business can also be associated with unique business identifiers, including a
Thomas Register identifier and a D-U-N-S number, and with a list of
categorizations that describe the business. UDDI V2 products allow businesses or
industry groups to create additional describing categories, a very powerful feature.
• Business Service. Associated with the business entity is a list of business services
offered by the business entity. Each business service entry contains a business
description of the service, a list of categories that describe the service, and a list of
binding templates that point to technical information about the service.
• Binding Templates. Associated with each business service entry is a list of
binding templates that provide information on where to find the service and how
to use the service. For example, a binding template may contain the access point
of the service implementation. The binding template also associates the business
service with a service type.
• Service Types. A service type, defined by a construct called a tModel, defines an
abstract service. Multiple businesses can offer the same type of service, all
supporting the same service interface. A tModel specifies information such as the
tModel name, the name of the organization that published the tModel, a list of
categories that describe the tModel, and pointers to technical specifications for the
tModel. For example, a tModel may point to a WSDL document that describes an
abstract service type.
_____________________________________________________________________ 44
When looking for a Web Service, a developer queries the UDDI Registry,
searching for a business that offers the type of service that he wants. From the tModel
entry for the service type, the developer can obtain the WSDL description describing the
service interface. From the Binding Template entry for the specific service, the developer
can obtain the service binding and access point. Using the WSDL description, the
developer can construct a SOAP client interface that can communicate with the Web
Service.
Similarly, running client code can use the UDDI Registry as a naming server. That
is, the client can ask UDDI to return the endpoints for a service of a particular name or
type, and bind to one of the returned URLs dynamically. This promotes both flexibility
and high-availability. In addition, since any amount of information can be associated with
a service, UDDI promotes a certain amount of polymorphism. That is, a client may chose
to bind with a service not just by its name, but by other meta information as well, such as
its version, or its applicable geography, and so on.
The UDDI standards process is managed by OASIS, with V3 being the latest
version. An important new feature of the UDDI V3 specification is Subscriptions and
Notifications, which allow clients to automatically receive notification of changes made
to the registered Web Services. Without this, subscribers would not be aware of Web
service changes until they attempted to use the service.
UDDI is a general-purpose registry. It can be used to register any type of service,
not just Web Services. UDDI doesn’t require that the services registered within it support
SOAP interfaces or that they be described using WSDL. In fact, there are no
dependencies among any of the three Web Services technologies. But the system works
best when the three technologies are used together.
Private Registries
Organizations can set up a private registry to support the requirements of an
enterprise or a private community. Indeed, this is the most common commercial
application of the registry. A private registry can impose additional security controls to
protect the integrity of the registry data and to prevent access by unauthorized users. At
design time, UDDI enables developers to easily locate a service and use that service
within an application. With a UDDI registry in place, disparate IT development teams can
easily discover and share programmable interfaces across groups and collaborate with one
another on complex projects.
_____________________________________________________________________ 45
UDDI is also an essential runtime component of any SOA infrastructure. UDDI
provides IT administrators the level of indirection required for dynamic binding. With
dynamic binding, an application queries the UDDI registry to determine the current
binding information for the services it needs, instead of having a hard-coded endpoint.
Using the binding information provided by UDDI, the application then connects to the
service. Should the location of the service change, the application will always be able to
find it.
B2B Registries
UDDI can be used to enable closer integration of companies, services and products.
While most organizations begin deploying UDDI to better manage services inside the
firewall, UDDI’s design makes it a natural fit as a shared registry between business
partners.
_____________________________________________________________________ 46
A-2 Java source code of CastingBuyer Web Service
Java source codes of all the Web Services are similar to the source code of one service.
Therefore, one source code is presented here.
/* CastingBuyer.java*/
package castbuy;
public interface CastingBuyer extends java.rmi.Remote {

public java.lang.String design_requirement() throws java.rmi.RemoteException;
}
______________________________________________________________________________________
/*CastingBuyerService.java */
package castbuy;
public interface CastingBuyerService extends javax.xml.rpc.Service {

public java.lang.String getCastingBuyerAddress();
public castbuy.CastingBuyer getCastingBuyer() throws javax.xml.rpc.ServiceException;
public castbuy.CastingBuyer getCastingBuyer(java.net.URL portAddress) throws

javax.xml.rpc.ServiceException;
}
______________________________________________________________________________________
/*CastingBuyerServiceLocator.java */
package castbuy;
public class CastingBuyerServiceLocator extends org.apache.axis.client.Service implements

castbuy.CastingBuyerService {
// Use to get a proxy class for CastingBuyer

private final java.lang.String CastingBuyer_address =
"http://127.0.0.1:8080/axis/services/CastingBuyer";
public java.lang.String getCastingBuyerAddress() {

return CastingBuyer_address;
}
// The WSDD service name defaults to the port name.

private java.lang.String CastingBuyerWSDDServiceName = "CastingBuyer";
public java.lang.String getCastingBuyerWSDDServiceName() {

return CastingBuyerWSDDServiceName;
}
public void setCastingBuyerWSDDServiceName(java.lang.String name) {

CastingBuyerWSDDServiceName = name;
}
public castbuy.CastingBuyer getCastingBuyer() throws javax.xml.rpc.ServiceException {

java.net.URL endpoint;
try {
endpoint = new java.net.URL(CastingBuyer_address);
}
catch (java.net.MalformedURLException e) {
_____________________________________________________________________ 47
throw new javax.xml.rpc.ServiceException(e);
}
return getCastingBuyer(endpoint);
}
public castbuy.CastingBuyer getCastingBuyer(java.net.URL portAddress) throws
javax.xml.rpc.ServiceException {
try {
castbuy.CastingBuyerSoapBindingStub _stub = new
castbuy.CastingBuyerSoapBindingStub(portAddress, this);
_stub.setPortName(getCastingBuyerWSDDServiceName());
return _stub;
}
catch (org.apache.axis.AxisFault e) {
return null;
}
}
/**
* For the given interface, get the stub implementation.
* If this service has no port for the given interface,
* then ServiceException is thrown.
*/
public java.rmi.Remote getPort(Class serviceEndpointInterface) throws javax.xml.rpc.ServiceException
{
try {
if (castbuy.CastingBuyer.class.isAssignableFrom(serviceEndpointInterface)) {
castbuy.CastingBuyerSoapBindingStub _stub = new castbuy.CastingBuyerSoapBindingStub(new
java.net.URL(CastingBuyer_address), this);
_stub.setPortName(getCastingBuyerWSDDServiceName());
return _stub;
}
}
catch (java.lang.Throwable t) {
throw new javax.xml.rpc.ServiceException(t);
}
throw new javax.xml.rpc.ServiceException("There is no stub implementation for the interface: " +
(serviceEndpointInterface == null ? "null" : serviceEndpointInterface.getName()));
}
/**
* For the given interface, get the stub implementation.
* If this service has no port for the given interface,
* then ServiceException is thrown.
*/
public java.rmi.Remote getPort(javax.xml.namespace.QName portName, Class
serviceEndpointInterface) throws javax.xml.rpc.ServiceException {
if (portName == null) {
return getPort(serviceEndpointInterface);
}
String inputPortName = portName.getLocalPart();
if ("CastingBuyer".equals(inputPortName)) {
return getCastingBuyer();
}
else {
java.rmi.Remote _stub = getPort(serviceEndpointInterface);
((org.apache.axis.client.Stub) _stub).setPortName(portName);
return _stub;
}
}
_____________________________________________________________________ 48
public javax.xml.namespace.QName getServiceName() {
return new javax.xml.namespace.QName("http://127.0.0.1:8080/axis/services/CastingBuyer",
"CastingBuyerService");
}
private java.util.HashSet ports = null;
public java.util.Iterator getPorts() {

if (ports == null) {
ports = new java.util.HashSet();
ports.add(new javax.xml.namespace.QName("CastingBuyer"));
}
return ports.iterator();
}
}
______________________________________________________________________________________
/* CastingBuyerSoapBindingStub.java */
package castbuy;
public class CastingBuyerSoapBindingStub extends org.apache.axis.client.Stub implements

castbuy.CastingBuyer {
private java.util.Vector cachedSerClasses = new java.util.Vector();
private java.util.Vector cachedSerQNames = new java.util.Vector();
private java.util.Vector cachedSerFactories = new java.util.Vector();
private java.util.Vector cachedDeserFactories = new java.util.Vector();
static org.apache.axis.description.OperationDesc [] _operations;
static {
_operations = new org.apache.axis.description.OperationDesc[1];
org.apache.axis.description.OperationDesc oper;
oper = new org.apache.axis.description.OperationDesc();
oper.setName("design_requirement");
oper.setReturnType(new javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema",
"string"));
oper.setReturnClass(java.lang.String.class);
oper.setReturnQName(new javax.xml.namespace.QName("", "design_requirementReturn"));
oper.setStyle(org.apache.axis.enum.Style.RPC);
oper.setUse(org.apache.axis.enum.Use.ENCODED);
_operations[0] = oper;
public CastingBuyerSoapBindingStub() throws org.apache.axis.AxisFault {

this(null);
}
public CastingBuyerSoapBindingStub(java.net.URL endpointURL, javax.xml.rpc.Service service) throws

org.apache.axis.AxisFault {
this(service);
super.cachedEndpoint = endpointURL;
}
public CastingBuyerSoapBindingStub(javax.xml.rpc.Service service) throws org.apache.axis.AxisFault {

if (service == null) {
super.service = new org.apache.axis.client.Service();
_____________________________________________________________________ 49
} else {
super.service = service;
}
}
private org.apache.axis.client.Call createCall() throws java.rmi.RemoteException {

try {
org.apache.axis.client.Call _call =
(org.apache.axis.client.Call) super.service.createCall();
if (super.maintainSessionSet) {
_call.setMaintainSession(super.maintainSession);
}
if (super.cachedUsername != null) {
_call.setUsername(super.cachedUsername);
}
if (super.cachedPassword != null) {
_call.setPassword(super.cachedPassword);
}
if (super.cachedEndpoint != null) {
_call.setTargetEndpointAddress(super.cachedEndpoint);
}
if (super.cachedTimeout != null) {
_call.setTimeout(super.cachedTimeout);
}
if (super.cachedPortName != null) {
_call.setPortName(super.cachedPortName);
}
java.util.Enumeration keys = super.cachedProperties.keys();
while (keys.hasMoreElements()) {
java.lang.String key = (java.lang.String) keys.nextElement();
_call.setProperty(key, super.cachedProperties.get(key));
}
return _call;
}
catch (java.lang.Throwable t) {
throw new org.apache.axis.AxisFault("Failure trying to get the Call object", t);
}
}
public java.lang.String design_requirement() throws java.rmi.RemoteException {

if (super.cachedEndpoint == null) {
throw new org.apache.axis.NoEndPointException();
}
org.apache.axis.client.Call _call = createCall();
_call.setOperation(_operations[0]);
_call.setUseSOAPAction(true);
_call.setSOAPActionURI("");
_call.setSOAPVersion(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS);
_call.setOperationName(new javax.xml.namespace.QName("http://DefaultNamespace",
"design_requirement"));
setRequestHeaders(_call);
setAttachments(_call);
java.lang.Object _resp = _call.invoke(new java.lang.Object[] {});
if (_resp instanceof java.rmi.RemoteException) {

throw (java.rmi.RemoteException)_resp;
}
else {
_____________________________________________________________________ 50
extractAttachments(_call);
try {
return (java.lang.String) _resp;
} catch (java.lang.Exception _exception) {
return (java.lang.String) org.apache.axis.utils.JavaUtils.convert(_resp, java.lang.String.class);
}
}
}
_____________________________________________________________________ 51
A-3 WSDL description of CastingBuyer Web service
<?xml version="1.0" encoding="UTF-8" ?>

- <wsdl:definitions
targetNamespace="http://127.0.0.1:8080/axis/CastingBuyer.jws"
xmlns:impl="http://127.0.0.1:8080/axis/CastingBuyer.jws"
xmlns:intf="http://127.0.0.1:8080/axis/CastingBuyer.jws"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<wsdl:message name="design_requirementRequest" />
- <wsdl:message name="design_requirementResponse">
<wsdl:part name="design_requirementReturn" type="xsd:string" />
</wsdl:message>
- <wsdl:portType name="CastingBuyer">
- <wsdl:operation name="design_requirement">
<wsdl:input name="design_requirementRequest"
message="impl:design_requirementRequest" />
<wsdl:output name="design_requirementResponse"
message="impl:design_requirementResponse" />
</wsdl:operation>
</wsdl:portType>
- <wsdl:binding name="CastingBuyerSoapBinding" type="impl:CastingBuyer">
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
- <wsdl:operation name="design_requirement">
<wsdlsoap:operation soapAction="" />
- <wsdl:input name="design_requirementRequest">
<wsdlsoap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://DefaultNamespace" />
</wsdl:input>
- <wsdl:output name="design_requirementResponse">
<wsdlsoap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://127.0.0.1:8080/axis/CastingBuyer.jws" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- <wsdl:service name="CastingBuyerService">
- <wsdl:port name="CastingBuyer" binding="impl:CastingBuyerSoapBinding">
<wsdlsoap:address location="http://127.0.0.1:8080/axis/CastingBuyer.jws" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
_____________________________________________________________________ 52
A-4 BPEL code for the process
<?xml version="1.0" encoding="UTF-8"?>

<process name="_DieCasting" targetNamespace="urn:_DieCasting" xml:ID="1"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:ana="http://127.0.0.1:8080/axis/services/DieDesignAnalyzer"
xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:cstb="http://127.0.0.1:8080/axis/services/CastingBuyer"
xmlns:cstm="http://127.0.0.1:8080/axis/services/DieCastingManufr"
xmlns:diem="http://127.0.0.1:8080/axis/services/DieDesnManufr"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<import importType="http://schemas.xmlsoap.org/wsdl/"
location="CastingBuyer.wsdl"
namespace="http://127.0.0.1:8080/axis/services/CastingBuyer"/>
location="DieDesnManufr.wsdl"
namespace="http://127.0.0.1:8080/axis/services/DieDesnManufr"/>
location="DieDesignAnalyzer.wsdl"
namespace="http://127.0.0.1:8080/axis/services/DieDesignAnalyzer"/>
location="DieCastingManufr.wsdl"
namespace="http://127.0.0.1:8080/axis/services/DieCastingManufr"/>
<partnerLinks>
<partnerLink myRole="Buyer_role" name="castingBuyer"
partnerLinkType="cstb:Cast_Buyer" partnerRole="Buyer_role"/>
<partnerLink name="designAnalyzer"
partnerLinkType="ana:Des_Analy" partnerRole="Analy_role"/>
<partnerLink name="dieDesignManufr"
partnerLinkType="diem:Die_Manu" partnerRole="DieManu_role"/>
<partnerLink name="castingManu" partnerLinkType="cstm:Cast_Manu"
partnerRole="Manu_role"/>
</partnerLinks>
<variables>
<variable messageType="cstb:design_requirementRequest"
name="_DesReq_req"/>
<variable messageType="ana:selectedMaterialRequest"
name="_selMat_req"/>
<variable messageType="cstb:design_requirementResponse"
name="_DesReq_res"/>
<variable messageType="ana:selectedMaterialResponse"
name="_selMat_res"/>
<variable messageType="diem:designDiesRequest"
name="_mdesDie_req"/>
<variable messageType="diem:designDiesResponse"
name="_mdesDie_res"/>
<variable messageType="diem:diesRequest" name="_die_req"/>
<variable messageType="diem:diesResponse" name="_die_res"/>
<variable messageType="diem:getBuyerDesignReqRequest"
name="_mDesReq_req"/>
<variable messageType="diem:getBuyerDesignReqResponse"
name="_mDesReq_res"/>
<variable messageType="diem:getSelectedMaterialRequest"
name="_mSelMat_req"/>
<variable messageType="diem:getSelectedMaterialResponse"
name="_mSelmat_res"/>
<variable messageType="diem:trimDiesRequest"
name="_trimDie_req"/>
_____________________________________________________________________ 53
<variable messageType="diem:trimDiesResponse"
name="_trimDie_res"/>
<variable messageType="cstm:getDiesRequest" name="_getDie_req"/>
<variable messageType="cstm:getDiesResponse"
name="_getDie_res"/>
<variable messageType="cstm:getTrimDiesRequest"
name="_gerTrimDie_req"/>
<variable messageType="cstm:getTrimDiesResponse"
name="_getTrimDie_res"/>
<variable messageType="cstm:FinishedProductRequest"
name="_finProd_req"/>
<variable messageType="cstm:FinishedProductResponse"
name="_finProd_res"/>
<variable messageType="ana:getDesignReqRequest"
name="a_DesReq_req"/>
<variable messageType="ana:getDesignReqResponse"
name="a_DesReq_res"/>
</variables>
<sequence xml:ID="2">
<receive createInstance="yes" name="BuyerReq"
operation="design_requirement" partnerLink="castingBuyer"
portType="cstb:CastingBuyer" variable="_DesReq_req"
xml:ID="3"/>
<flow xml:ID="8">
<invoke inputVariable="_selMat_req" name="Design_Analyzer"
operation="selectedMaterial"
outputVariable="_selMat_res"
partnerLink="designAnalyzer"
portType="ana:DieDesignAnalyzer" xml:ID="9"/>
<invoke inputVariable="_die_req" name="Die_Designer"
operation="dies" outputVariable="_die_res"
partnerLink="dieDesignManufr"
portType="diem:DieDesnManufr" xml:ID="10"/>
</flow>
<flow xml:ID="11">
<assign name="pass_design_reuirement_to_Analyzer"
xml:ID="12">
<copy>
<from part="design_requirementReturn"
variable="_DesReq_res"/>
<to part="param" variable="a_DesReq_req"/>
</copy>
</assign>
<assign name="pass_design_requirements_to_Designer"
xml:ID="13">
<copy>
<from part="design_requirementReturn"
variable="_DesReq_res"/>
<to part="param" variable="_mDesReq_req"/>
</copy>
</assign>
<assign name="pass_selected_material_to_Designer"
xml:ID="14">
<copy>
<from part="selectedMaterialReturn"
variable="_selMat_res"/>
<to part="paramtr" variable="_mSelMat_req"/>
</copy>
</assign>
</flow>
_____________________________________________________________________ 54
<invoke inputVariable="_finProd_req" name="Casting_Manufacturer"
operation="FinishedProduct" outputVariable="_finProd_res"
partnerLink="castingManu" portType="cstm:DieCastingManufr"
xml:ID="15"/>
<assign xml:ID="16">
<copy>
<from part="diesReturn" variable="_die_res"/>
<to part="param1" variable="_getDie_req"/>
</copy>
</assign>
<assign xml:ID="17">
<copy>
<from part="trimDiesReturn" variable="_trimDie_res"/>
<to part="param2" variable="_gerTrimDie_req"/>
</copy>
</assign>
<reply name="finished_product" operation="design_requirement"
partnerLink="castingBuyer" portType="cstb:CastingBuyer"
variable="_DesReq_res" xml:ID="18"/>
</sequence>
</process>
_____________________________________________________________________ 55

Collaboration in Design and Manufacturing Using Web Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Collaboration in Design and Manufacturing Using Web Services

Uploaded by

Copyright:

Available Formats

Collaboration in Design and Manufacturing

using Web Services

Under the Guidance of

Department of Mechanical Engineering,

This is to certify that the project entitled “Collaboration in

Date: Prof. M A Faruqi

Indian Institute of Technology

This is to certify that we have examined the thesis entitled

Indian Institute of Technology

Date: (Shoukat Ali)

3. ORCHESTRATION AND CHOREOGRAPHY OF

Fig.2.1 Architectures for Enterprise Integration………………………………….11

The practice of geographically distributed design and manufacturing is ever increasing,

1.3 Organization of the Thesis

The survey of relevant literature on Distributed Design and Manufacturing, Enterprise

(a) (b) (c)

2.2 Internet based Design and Manufacturing (D&M)

Muammer et al. [7] introduced an e-Manufacturing architecture, and outlined its

2.3 Service Oriented Architecture (SOA) for Collaborative services

2.4 Orchestration and Choreography in Web Services

Fig.2.2 web services orchestration and choreography

Technical Requirements for Orchestration and Choreography

Standards for Collaboration in Web Services

Orchestration and Choreography of Web Services

3.1 Objective of the present work

After going through an extensive literature survey (presented in Chapter 2) it is evident

3.2 Statement of the problem

Die design Analyzer

Make trim dies Make dies

Trim dies Dies

Fig.3.1 Overview of Die Casting Design and Manufacturing process

3.3 Software tools used in the study

In this study Java programming language as it is publicly available and platform

Casting Buyer Die design Analyzer Die Manufacturer Casting Manufacturer

BPEL Orchestration Engine

SOAP Web Application

Fig 3.2 Conceptual model of the orchestration process

<?xml version="1.0" encoding="UTF-8"?>

BPEL Maestro for Web Service Orchestration, Version 1.6.0

Results and Conclusions

4.1 Results and Discussion

4.3 Scope for future work

[1] Nickerson V. Jeffrey, and Stohr A. Edward, “Intra Enterprise Integration:

A-1 Overview of Web Services

What are Web Services

Web Services Technologies

Services and Service Types

public interface CastingBuyer extends java.rmi.Remote {

public interface CastingBuyerService extends javax.xml.rpc.Service {

public castbuy.CastingBuyer getCastingBuyer() throws javax.xml.rpc.ServiceException;

public castbuy.CastingBuyer getCastingBuyer(java.net.URL portAddress) throws

public class CastingBuyerServiceLocator extends org.apache.axis.client.Service implements

// Use to get a proxy class for CastingBuyer

public java.lang.String getCastingBuyerAddress() {

// The WSDD service name defaults to the port name.

public java.lang.String getCastingBuyerWSDDServiceName() {

public void setCastingBuyerWSDDServiceName(java.lang.String name) {

public castbuy.CastingBuyer getCastingBuyer() throws javax.xml.rpc.ServiceException {

private java.util.HashSet ports = null;

public java.util.Iterator getPorts() {

public class CastingBuyerSoapBindingStub extends org.apache.axis.client.Stub implements

static org.apache.axis.description.OperationDesc [] _operations;

public CastingBuyerSoapBindingStub() throws org.apache.axis.AxisFault {