collaboration in design and manufacturing using web services

8/14/2019 Collaboration in Design and Manufacturing using Web Services

1/62

Collaboration in Design and Manufacturingusing Web Services

Thesis submitted in partial fulfillment of the requirementsfor the degree of

Master of Technology(Manufacturing Systems Engineering)inMechanical Engineering2003- 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.


2/62

.

Departme nt of Mec hanica l Engineering ,

Ind ian Institute of Tec hnolog y,

Kharagpur-721302.

Certificate

This is to certify tha t the p rojec t 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 Tec hnolog y in Manufacturing Systems

Engineering during the academic session 20042005 in the

Department of Mechanical Engineering, Indian Institute of

Tec hnolog y, Kha ragpur.

Date: Prof. M A Faruqi

Plac e: Kha ragpur Dep tt. of Mec h. Engg.,

IIT Kha ragpur.


3/62

Certificate of Examination

This is to c ertify that we ha ve examined the thesis entitled

Collaboration in Design and Manufacturing using Web

Services submitted by Mr. Shoukat Ali (Roll no. 03ME6402), a

postgraduate student of Mec hanic al Enginee ring with

spec ia liza tion in Manufac turing SystemsEngineering(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

sub mitted . This approva l does not nec essa rily endorse o r

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 issubmitted.

Examiner Supervisor

DDeeppaarrttmmeenntt ooffMMeecchhaanniiccaall EEnnggiinneeeerriinngg

IInnddiiaann IInnssttiittuuttee ooffTTeecchhnnoollooggyy

KKhhaarraa uurr--772211330022


4/62


5/62

_____________________________________________________________________Collaboration in Design and Manufacturing using Web Services

i

Table of Contents

Abstract

1. INTRODUCTION....11.1Introduction..11.2Motivation21.3Organization of the Thesis3

2.

LITERATURE SURVEY..42.1Enterprise Integration...42.2Internet based Distributed Design and Manufacturing.52.3Service Oriented Architecture (SOA) for Collaborative services92.4Orchestration and Choreography in Web Services.11

3. ORCHESTRATION AND CHOREOGRAPHY OFWEB SERVICES EMPLOYED IN DESIGN

AND MANUFACTURING.16

3.1 Objective of the present work16

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..324.1Results and Discussion...324.2Conclusions324.3Scope for future work.33

5. REFERENCES.346. APPENDICES..37

A-1 Overview of Web Services...37


6/62


ii

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 process53

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 process18

Fig.3.2 Conceptual model of the orchestration process......19

Fig.3.3 Main page of Apache AXIS21

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


7/62


iii

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.


8/62

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


9/62

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 particularlythe 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


10/62

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


11/62

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, andworkflow.

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.

_____________________________________________________________________Collaboration in Distributed Design and Manufacturing using Web Services

4


12/62

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 systems

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


13/62

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.).

Leito 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


14/62

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


15/62

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 servesas 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 modeland 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. Forexample, instead of installing the CAD software on every machine, the designeruses 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 productmodel, 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


16/62

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

Jrstad 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 messagesexchanged 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 relativelylarge and complex messages.


9


17/62

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 formatdelivered through the interfaces. XML is the most obvious format that meets thisconstraint.

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 knowledgeand resource together. By share it is meant several things:

o Presentation: the same knowledge or resource is presented such that allthe collaborators can view, experience and interpret it in the same way.

o Generation and modification: All the collaborators should be enabled togenerate 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 affectingthe availability.

Communication and personal interaction: In collaboration, communication andinteraction 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 thecollaboration team itself and to distribute information about the team to all the

members in an efficient manner. The services include:

o Project/ team managemento Calendar, time scheduling, milestones, mail exploder.


10


18/62

They further mentioned that a collaborative service can be represented by four

components: ServiceLogic, ServiceData, ServiceContentand ServiceProfile

Further, ServiceLogic must be equipped with specific collaborative functions as follows:

1. Locking mechanismSeveral types of locks are intent, shared, update, and exclusive.

2. Presentation control3. User Presence management4. Organization management5. 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


19/62

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


20/62

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 anexecutable 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


21/62

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 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 tag. A wide variety

of structured activities are supported, including sequential and parallel processing and

condition looping. WSCI also introduces an 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 ,

, and messages all represent basic activities for connecting the services

together.


14


22/62


23/62

CHAPTER-3

Orchestration and Choreography of Web Servicesemployed 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 Designfor 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. Leito 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


24/62

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


25/62

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

Buyer

Die design Analyzer

Die

Manufacturer

Casting

Manufacturer

Design

requirements

Part Analysis

Selected material

Design Dies

Designed trim dies Designed dies

Make trim dies Make dies

Trim dies Dies

Die casting

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


26/62

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.

BPEL Orchestration Engine

SOAP

Server

(AXIS)

Web Application

Server

(Tomcat) JAVA

Internet

Casting Buyer Die design Analyzer Die Manufacturer Casting Manufacturer(WSDL) (WSDL) (WSDL) (WSDL)

SOAP

SOAPSOAP

SOAP

SOAP

Fig 3.2 Conceptual model of the orchestration process


19


27/62

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 ofaxis-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

installations configuration; view the list of deployed web service, Administer AXIS,

SOAPmonitor.


20
http://127.0.0.1:8080/axis/http://127.0.0.1:8080/axis/


28/62

Fig 3.3 Main page of Apache AXIS


21


29/62

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 linkview 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


30/62


31/62

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


32/62

Fig. 3.5 WSDL description of Web Service CastingBuyer


25


33/62

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:

uuid:005692

22-bf7c-4eca-9c7c-ae7f29c522ef

http://144.16.204.182:18585/axis/services/CallbackService

Fig.3.6 SOAP Message sent to the CastingBuyer service from the system.


26


34/62

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 tags against each

variable used in the process. The messages used in the study were of string type; however


27


35/62

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

_DesReq_req

uuid:00569222-bf7c-4eca-9c7c-ae7f29c522ef

http://144.16.204.182:18585/axis/services/CallbackService

_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.

_die_req


28
http://www.parasoft.com/


36/62

_die_res

_finProd_req

_finProd_res

Required_Casting

_getTrimDie_req

param2

_getDie_req

param1

_getDie_res

Designed and Manufactured Dies

_getTrimDie_res

Designed and Manufactured Trim Dies

_mdesDie_req

_mdesDie_res

Designed and Manufactured Dies


29


37/62

_mDesReq_req

param

_mDesReq_res




_mSelMat_req

paramtr

_mSelmat_res

die steel

_selMat_req

_selMat_res

die steel

_trimDie_req

_trimDie_res

Designed and Manufactured Trim Dies


30


38/62

a_DesReq_req

param

a_DesReq_res




sequencereceive 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_Designerinvoke 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


39/62

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


40/62

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


41/62

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 DETC01

ASME 2001 Design Engineering Technical Conference and Computers and

Information in Engineering Conference Pittsburgh, PA, September 9-12, 2001.

[5] Leito Paulo and Restivo Francisco, A Framework for Distributed Manufacturing

Applications, ICIMS-NoE 2000 Advanced Study Institute, Bordus, 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] Jrstad Ivar, Dustdar Schahram, and Thanh Do Van, A Service Oriented

Architecture for collaborative services, 3rd International Workshop onDistributed and Mobile collaboration (DMC), IEEE WETICE, Linkping,

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 Releasehttp://www.daml.org/services/owl-s/1.0/


34
http://www.daml.org/services/owl-s/1.0/http://www.daml.org/services/owl-s/1.0/http://www.daml.org/services/owl-s/1.0/


42/62

[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
http://www.w3.org/TR/soap12-af/http://server2.tecweb.inf.puc-rio.br/we-sw-2004/www-se.pdfhttp://server2.tecweb.inf.puc-rio.br/we-sw-2004/www-se.pdfhttp://www.ibm.com/developerworks/library/ws-bpel/http://www.ibm.com/developerworks/library/ws-bpel/http://server2.tecweb.inf.puc-rio.br/we-sw-2004/www-se.pdfhttp://server2.tecweb.inf.puc-rio.br/we-sw-2004/www-se.pdfhttp://www.w3.org/TR/soap12-af/


43/62

[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-East04)

[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 (ICWS04).

[33] Colan Mark, Dynamic e-business: Using Web services to transform business,

IBM e-business, June 2001.


36


44/62

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


45/62

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 usingplatform-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


46/62

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. WebServices communicate by passing messages to each other. The Web Serviceinterface 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 communicationsprotocol for Web Services.

Web Services Description Language (WSDL) defines a standard mechanism todescribe a Web Service.

Universal Description, Discovery and Integration (UDDI) provides a standardmechanism 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


47/62


48/62

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
http://www.wsi/http://www.wsi/


49/62

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 doesnt 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
http://www.w3.org/TR/SOAPattachmentshttp://www-/http://www-/http://www.w3.org/TR/SOAPattachments


50/62

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 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 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 element defines a set of operations. Each

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 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 element defines a collection of related ports. A 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


51/62

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 businessincluding 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 servicesoffered 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 ofbinding templates that prov

collaboration in design and manufacturing using web services

Documents