JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 90

Introducing a New Model for Web Services

Composition Using Deputy Servers
A. Andalib, S. Mohammadi, and M. Mahdavi

Abstract—The latest presented technology for web is “Web Services”. The web services are the applicable programs that are
accessible via web, by human being and other programs, independent from programming language. Moreover, they can be
located and invoked through web. Nowadays, the main usage of World Wide Web is to have an interactive access to the
documents and applicable programs. Web services (also called simply services) are self-describing, platform-agnostic
computational elements that support rapid, lowcost and easy composition of loosely coupled distributed applications. From a
technical standpoint, Web services are modular applications that can be described, published, located, invoked and composed
over a variety of networks (including the Internet): any piece of code and any application component deployed on a system can
be wrapped and transformed into a network-available service, by using standard (XML-based) languages and protocols (e.g.,
WSDL, SOAP, etc.). The promise of Web services is to enable the composition of new distributed applications/solutions: when
no available service can satisfy a client request, (parts of) available services can. If the web develops in order to support the
links between Web Services, it will considerably improve in terms of range and power.Our research is concerned with
developing an efficient model for composing web services.Our goal is to enhance the potential of web services by focusing on
new aspects of their composition by using of deputy servers.

Index Terms— SOA, Web Service, Xml, SOAP, WSDL, HTTP, UDDI, XML-RPC, Orchestration, Choreography, Deputy Server

——————————  ——————————

1 INTRODUCTION

U ndoubtedly, Web is one of the most significant tech-

nologies in the last decade that provides a wide in-
formation publication and has made it possible to
present services via computers in the whole world. Also,
it is considered as one of the main factors of entering
computers to the daily life of humans [1].
The World Wide Web was proposed by Tim Berners-
Lee in 1989 in order to publish the web pages and make
links between them and it has unbelievably expanded
during these years [2]. Development of providing services
by institutions and organizations via internet has in-
creased the demand for commercial interactions and links
(especially Business to Business-B2B interactions) and the
new technologies like web services are presented to make
these links. Web services, are web based applicable pro-
grams that could be established or invoked independent-
ly by software or other services [4]. Service Oriented Ar-
chitecture (SOA), has facilitated the procedure of flexible
and loosely coupled programming, hence this architec-
ture as a fundamental factor for interoperability will be
discussed. Major organizations recently tend to utilize the
service oriented applications instead of simple applica-
tions, also portals for agencies and organizations provid-
ing their services in the form of Web services, allows us-
ers to experience quick and easy to use services provided
by organizations, through the Internet. Infact the main
————————————————
 A.Andalib – Department of Information Technology, International Cam- one. This style of architecture can be applied for making
pus, University of Guilan, Rasht, Guilan, Iran.
 S.Mohammadi–K.N.Toosi University of Technology,Tehran, Iran.
 M.Mahdavi– Departmant of Computer Science and Engineering. Universi-
ty of Guilan, Rasht, Guilan, Iran.
and basic services of organizations are available in the
form of Web services through their portal for their visit-
ing users. Ease of service combination and combined con-
struction of service applications is discussed as basic a
feature in service oriented architecture. With improve-
ment of web services and development of their usage, the
new concepts regarding the combination of simple servic-
es to make a complicated one, have been raised.
The purpose of this paper is to emphasis on the fun-
damental concepts of Service Oriented Architecture
(SOA), the requirements of applying the web services in
order to achieve a more valuable goal and description of
the structures and rules of these services. Then we explain
current solutions for compositing web services to achieve
this goal and finally we introduce a new model for im-
proving implicit methods.
2 SERVICE ORIENTED ARCHITECTURE
SOA is a style of architecture that supports Loose Coupl-
ing for more flexibility and interaction of commercial
processes, independent from the technology. It is estab-
lished from the combination of commercial services’ col-
lections that provide dynamic configuration with more
flexibility for the processes [5].
SOA has existed from 90 decades, so it is not a new
concept but the ability of implementation and perfor-
mance of it with related tools and protocols is the new
software that uses the published services in one network,
such as Web [6]. Thus, the Web services are the origin of
a fundamental technology that make the commercial
models capable of moving from B2C (Business to Cus-
tomer) to B2B (Business to Business) position that their
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
significance are palpable, especially for complicated
commercial transactions.
Usually, the SOA and Web services are used instead of
each other by mistake. Infact the Web services should be
considered as the one that makes the SOA happen [6].
The advantage of applying SOA by using Web services is
its capability of performing independently from the plat-
form and the ability of more cooperation with other ser-
vices. In general, SOA is a collection of rules, patterns and
criteria in production and development of softwares and
organization’s processes that cause to the product’s capa-
bilities like Reusing, Modularity, Loose Coupling and
independent from the platform [15].
TABLE 1
THE COMPARISON BETWEEN SOA AND FORMER APPROACH
2.1 SOA Principles
The ability of reuse: Essentially, services are designed for
reuse, whether this is operating under use in the present
or future. This is done by applying standards indepen-
dent of technology and separation of service implementa-
tion from interface [21]. There are different types of ser-
vices, some of them are combination of other services
having a lot of calls while other group of services, such as
basic services (primary services) have full autonomy and
do not call other services.
Formal contract for the engagement: Services that need
to interact with each other, should define and publish the
rules about how this relationship and coordination
should move on. The contract includes at least the name
and address definition of the service, operations, input
and output messages for each operation and type of data.
Since the only way of understanding a service requester is
defined in the contract, the server must pay attention to
defined instances, such as complete and accurate informa-
tion definition, data management, maintenance and dis-
semination.
Hiding the internal implementation: The only part of the
service, which is visible to participants and environments,
is the service interface under which the contract form is
published. The implementation of operations is hidden
for the environment and even it’s possible to change
without client notice or to use new technology without
defining or changing service interfaces. In fact, what the
environment of a service knows is "what" and not "how",
so that the services are as a black box that can hide its
internal details [21].
Combining Ability: Services use each other, thus differ-
ent services grain and reuse capabilities are created. This
is to some extent similar to reuse ability [22] with the dif-
ference that reuse emphasizes on equipment and pro-
91
vided standards while combining ability determine the
design services grain, and functionality, in a way that can
make a macro service combination from other established
services.
Services autonomy: Each service has its logic and busi-
ness data fields that determine its function, this area is
clear. Although service use each other’s functionalities
(otherwise reuse capability will not have meaning), but
do not have strong dependence on each other and each of
them has their specific functions and logic. This principle
issue emphasizes that a service should be able to change
its internal implementation or develop that without hav-
ing to get the required work permission or to change oth-
er services [21]. One of the benefits of service oriented
architecture is its flexibility in a way that a service can
change its implementation or call new provider of its
needed services, without permission or need to change
the environment or the participants.
Loose Coupling: Loose Coupling is a characteristic for
data systems that the interfaces between the parts (mod-
ules) are designed to have the minimum dependence be-
tween them. Therefore, it decreases the risk of affecting
the other parts by changing one part. In SOA, Loose
Coupling refers to the ability of interaction between the
services independent from the coding and place of servic-
es [9]; in a way that the services can change their place
while they are performing, they can change their internal
procedures or even can use a newer technology with no
negative impact on users [23]. There are some considera-
ble tips in the definition of Loose Coupling such as; this
coupling performs by system interface, the connection is
via sending message, all the parties in the connection area
should use a same module of data and finally, the connec-
tion should be independent from the platform and the
implementation technology of each part [6].
TABLE 2
THE COMPARISON BETWEEN FIRM COUPLING AND LOOSE
COUPLING
Without condition (state) services: Services should not
record any of current status or conditions, because they
are reusable unit that are used by different participants
and perform a specific operation. Control and recording
of mode and tasks sequence will be done elsewhere (Ex.
Centre Orchestration).
The ability to identification and detection: Interface con-
tract of service usage must have the potentiality to be
identified and detected by participants and all the factors
allowed to be used. One of the Advantages of Service
Oriented Architecture is capabilities of questing between
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
providers of a particular service and selecting the best
among them based on service quality and other criterions.
3 INTRODUCTION TO WEB SERVICES
Every service that is accessible via Internet, uses the mes-
sage transferring system based on the XML (Extensible
Markup Language) standards and does not depend on an
operating system or a programming language is a Web
service [7].
The World Wide Web Consortium which is the presti-
gious reference in Web, defines the Web services as fol-
lows: "a Web service is a software system that is designed
to protect machine to machine interactions on a network
and have a definition which is processed by a machine
called WSDL (Web Services Description Language). This
service has an interface that is presented as an unders-
tandable language for the machine. The other systems
make connection with this service by the method which is
defined in this interface, and through sending message"
[8]. In other words, a Web service is a software service
that is realized with a URL (Uniform Resource Locator)
and its public interfaces are described and identified by
using XML.
Generally speaking, using Web services can cause a
general advantage which is no need to coding again. Al-
though, this advantage is for using the classes too, but in
using the classes in every project they need to be added,
while in Web services the methods can be applied. By
working with classes in various applications with several
methods, it is possible to work with different classes. In
other words, the work that is done is different in every
time which reduces the legibility and also makes the de-
velopment difficult. But, by using Web service, every time
an especial Web service according to a specific Web ser-
vice’s method is used, regardless of being in any applica-
tion [7].
3.1 Two Additional and desirable Properties of a
Web Service, although they are not necessary
First property is that a Web service should be discovera-
ble. If we create a Web service, there should be a relative-
ly simple method for us to publish it. Also, there should
be some simple methods whereby interested parties can
find the service and locate its public interface. The exact
mechanism could be via a completely decentralized sys-
tem or a more logically centralized registry system.
Second property is that a Web service should be self-
describing. If we publish a new Web service, we should
also publish a public interface for it. At a minimum, your
service should include human-readable documentation,
so that other developers can easily integrate your service.
If we have generated a SOAP service, we should also
ideally include a public interface written in a common
XML grammar. This grammar can be used to identify all
public methods, method arguments, and return values.
92
4 ARCHITECTURE OF WEB SERVICES
There are two ways to view the Web service architecture.
The first is to peruse the roles of each Web service actor
and the second is to peruse the Web service protocol
stack.
4.1 Web Service Roles
Web services roles can be divided in three parts. The first
role is about Service provider who is the provider of the
Web service. The service provider implements the service
and makes it available on the Internet.The second role is
about Service requester. This is any consumer of the Web
service. The requestor utilizes an existing Web service by
opening a network connection and sending an XML re-
quest. Finally third role is about Service registry. It is a
logically centralized directory of services [7]. This registry
is a central place where developers can publish new ser-
vices or find existing services. It therefore serves as a cen-
tralized clearinghouse for companies and their services.
Fig.1. shows the major Web service roles and how they
interact with each other.
Fig. 1. Web Service Roles
The provider of service makes or proposes the service
and needs to describe the Web service in a standard for-
mat (usually XML). Then, issue it in a central storage. The
storage includes more information about the service pro-
vider, such as address, contact number of company (pro-
vider) and the technical details about the service. The user
of service detects the data from the storage and applies
the described service to connect and invoke.
When a service provider decides to issue its service, at
first a file for Web Services Describing Language (WSDL)
should be established [5] to be able to describe its Web
services with Simple Object Access Protocol (SOAP) in-
terpreter help [10]. Then, the service will be recorded in
Universal Description, Discovery and Integration (UDDI)
storage and remains to be invoked [5]. At this stage, the
UDDI storage contains all the essential information for
identifying a Web service by using the URL that refers to
the WSDL file corresponding with that service. Once a
service applicator searches the UDDI storage and realizes
that a certain Web service is the most suitable one for
his/her need, the WSDL file of the service can be down-
loaded and can be used to produce the required messages
to connect with the desired Web service by using the
SOAP interpreter [11].
4.2 Web Service Protocol Stack
A second option for viewing the web service architecture
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
is to peruse the Web service protocol stack. The protocol
stack is still evolving, but currently there are four main
layers. Following is a description of each layer.
5 SERVICE TRANSPORT LAYER
The bottom of the Web service protocol stack is service
transport layer. This layer is responsible for transporting
messages between different applications. Currently, this
layer includes hypertext transfer protocol (HTTP), Simple
Mail Transfer Protocol (SMTP), file transfer protocol
(FTP), and newer protocols, such as Blocks Extensible
Exchange Protocol (BEEP).we will explain the most im-
portant of them in following.
5.1 Hypertext Transfer Protocol (HTTP)
Currently, HTTP is the most popular option for service
transport layer. HTTP is stable, simple, and widely dep-
loyed. Forby, most firewalls allow HTTP traffic. This ca-
pability allows XML-RPC or SOAP messages to masque-
rade as HTTP messages. This is good if we want to easily
agglomerate remote applications, but it evinces to in-
crease a number of security concerns [7].
Nonetheless HTTP does get the job done, some critics
have argued that HTTP is not idealistic for Web services.
Especially, HTTP was originally designed for remote
document retrieval, and is now being reworked to sup-
port RPCs (remote procedure calls). RPCs appeal greater
efficiency and reliability than document retrieval does.
5.2 Blocks Extensible Exchange Protocol (BEEP)
The Blocks Extensible Exchange Protocol is one of prom-
ising alternatives to HTTP. It uses to exchange the devel-
oped blocks. BEEP is a new IETF (Internet Engineering
Task Force) framework of best practices for manufactur-
ing new protocols. Furthermore, BEEP is layered directly
on TCP and contains some built-in features, such as an
initial handshake protocol, authentication, security, and
error management. With BEEP, we can establish new pro-
tocols for different applications, including instant messag-
ing, content syndication, file transfer and network man-
agement [7]. SOAP dose not depend on any specific
transport protocol. So, we can use SOAP via HTTP,
SMTP, or FTP.
One of promising purposes is to use SOAP over BEEP.
It provides some performance premium over HTTP. The
important point is that BEEP does require an initial hand-
shake, but after the handshake, the protocol needs only 30
bytes of overhead for each message, so making it much
more effective than HTTP. Also, BEEP countenances mul-
tiple channels of data over the same connection, getting
surplus efficiency over HTTP. The overhead for each
HTTP message is dependent on numerous factors, like as
the type of client used, the requested URL and the type of
information of servers returned within the HTTP answer.
In typical browser and SOAP requests, Overhead for each
message can therefore vary from approximately 100 to
300 bytes.
93
5.3 Reliable HTTP (HTTP-R)
Reliable HTTP (HTTP-R) is another promising alternative
to HTTP. IBM has developed HTTP-R and plans to sub-
mit its proposal to the Internet Engineering Task Force
(IETF). HTTP-R helps HTTP to warrant message reliabili-
ty. For example, HTTP-R warrants that a message gets
reported as undeliverable or gets delivered only once.
This is chiefly important for e-commerce services, like as
inventory management and electronic ordering systems.
6 XML MESSAGING LAYER
The responsibility of this layer is to encode messages in a
common XML format. So easy understanding of messages
can occur at either end. Currently, this layer contains
XML-RPC and SOAP. In recent years XML has exploded
onto the computing domain. It has gained rapid accep-
tance because it enables diverse computer systems to easy
sharing of data, regardless of programming language or
operating system. There are several XML tools, including
parsers and editors that are available for almost every
operating system and every programming language.
When developers began to build a web service messaging
system, a natural choice for them was XML. There are
two major contenders for XML messaging: XML-RPC and
SOAP. The following sections provide descriptions of
both protocols.
6.1 XML-Remote Procedure Call (XML-RPC)
A simple protocol that uses XML messages to perform
RPCs is XML-RPC. Requests are encoded in XML and
sent via HTTP POST. XML responses are embedded in
the body of the HTTP responses. XML-RPC is indepen-
dent from platforms; therefore it allows communication
between diverse applications. For example, a Java client
can speak XML-RPC to a Perl server. The easiest way to
get started with web services is XML-RPC. In many ways,
it is easy to adopt and simpler than SOAP. Although, un-
like SOAP, XML-RPC hasnot any grammar for descrip-
tion of corresponding services. This prevents automatic
invocation of XML-RPC services which is a key ingre-
dient for integrating of just-in-time application.
6.2 Simple Object Access Protocol (SOAP)
A simple protocol based on XML, for exchanging data
between the computers is SOAP and it usually is used by
the transition protocols like HTTP, HTTPS and FTP [5].
However SOAP, can be used in several messaging sys-
tems, and it can be delivered via a variety of transport
protocols, the major focus of SOAP is RPCs transported
via HTTP. SOAP is platform-independent (Like XML-
RPC) and so enables diverse applications to communi-
cate. Moreover, SOAP is an important choice in Web ser-
vices to describe the architecture of transferable messages,
at the time of implementation and to invoke [16]. The
message of SOAP is a documented XML for describing an
operation that should be performed. The potency of
SOAP (as a code packer) is that the SOAP message is gen-
erally sent as a text file via HTTP and HTTPS protocols,
because it can traverse the firewalls. The methods such as
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
CORBA (Common Object Request Broker Architecture),
DCOM (Distributed Component Object Model) and RPC
donot have this advantage.
The complicacy of SOAP request is slightly more than
the XML-RPC request. Because it uses of both XML na-
mespaces and XML Schemas. However the body of the
SOAP request (as in XML-RPC), specifies both a method
name and a list of parameters.
7 SERVICE DESCRIPTION LAYER (WSDL)
Web Services Description Language (WSDL) demon-
strates the service description layer in the Web service
protocol stack. Currently, WSDL handles the Service de-
scription. WSDL is an XML grammar to introduce a pub-
lic interface for a Web service. This public interface can
contain information on all generic available functions,
data type information of all XML messages, binding in-
formation about the especial transport protocol to be
used, and the specified service location address. In a nut-
shell WSDL does not necessarily depend on a specific
XML messaging system, but it does include built-in ex-
tensions to describe SOAP services [12].
EveryWeb service which is placed on the Internet has a
WSDL file that explains the characteristics, place and the
usage method of that service. A WSDL file represents
type of messages that is received or sent by the Web ser-
vice. Briefly, it can be said that WSDL predicate the de-
scription of quiddity, quality and place of the Web servic-
es [7]. The components of WSDL are: “Type” determines
the received and sent parameters, “Message” determines
the input and output parameters and their types, “Opera-
tion” is the Web Services methods that have the input and
output messages, “Port Type” represents the collection of
operation and “Service” includes the collection of ending
points [12].
Using WSDL, a client can locate a Web service and in-
voke any of the publicly available functions. With WSDL-
aware tools, this process can be entirely automated,
enabling applications to easily integrate new services
with little or no manual code [17].
8 SERVICE DISCOVERY LAYER (UDDI)
This layer is responsible for centralizing services into an
exoteric registry within the Web service protocol stack. It
provides easy publish/find functionality. Currently, Uni-
versal Description, Discovery, and Integration (UDDI)
handles service discovery. Microsoft, IBM, and Ariba
have originally created UDDI. It represents a technical
specification for publishing and finding Web services.
Likewise, it is an instrument to propagate the details of
the service provider, saved service and is an opportunity
for user of service to recognize the service provider and
details of Web service. The other standards can well de-
velop beside UDDI [13].
UDDI consists of two parts, at its core. First part is a
technical specification to build a distributed directory of
businesses and web services. Data is stored within a par-
ticular XML format. The UDDI specification includes API
94
(Application Program Interface) elaboration for searching
existing data and propagating new data. Second part
within the UDDI Business Registry is a wholly operation-
al implementation of the UDDI specification. It Launched
by Microsoft and IBM in May 2001. The UDDI registry
now enables anyone to seek about existing UDDI data.
Furthermore, it enables any company to register itself and
its services.
UDDI captured data is divided into three main catego-
ries. "White page" that includes overt information about a
particular company, for example business name, business
description and address. "Yellow page" that includes en-
cyclical classification data for either the company or the
service offered. For example, this data may contain indus-
try product or geographic codes based on standard tax-
onomies. And "Green page" that contains technical infor-
mation about a web service (a pointer to an external spe-
cification and an address for invoking the Web service).
UDDI storage includes metadata that are used for ser-
vice searching according to their name, ID, series, type
etc, and usually is known as the Web services’ core.
Moreover, UDDI is designed in order to integrate with
SOAP messages and making the WSDL documents ac-
cessible. The UDDI storages can be public or private. This
storage is an organized data base of organizations, their
provided services, their technical description and the
WSDL documents for those services. UDDI can be consi-
dered as a type of DNS (Domain Name System) for Web
services.
Fig. 2. Web Service Protocol Stack
9 SECURITY CONSIDERATIONS
A critical sense for Web services is Security. However,
neither the XML-RPC nor SOAP specifications make any
vivid security or authentication requirements. Likewise,
the Web services community has proposed countless se-
curity frameworks and protocols, but has yet to reach
consensus on a universal security package.Very broadly,
there are three specific security subjects: confidentiality,
authentication, and network security.
9.1 Confidentiality
If a client sends an XML request to a server, we can not
certify that the communication remains confidential? Both
SOAP and XML-RPC run primarily on top of HTTP. So
XML communications can therefore be encrypted via the
Secure Sockets Layer (SSL). SSL is a corroborated tech-
nology, is widely deployed, and is therefore a very per-
manent choice to encrypt messages. Although, an impor-
tant element of Web services is that a single Web service
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
may consist of a curb of applications [7]. In this case, SSL
is not proper because the messages require to be en-
crypted at each node along the service path, and each
node exerts a potential weak link in the curb [18]. Cur-
rently, there is no concurrent solution to this subject, but
one of promising solutions is the World Wide Web XML
Encryption Standard. This standard provides a frame-
work to encrypt and decrypt XML documents perfectly
and it is likely to receive splay industry patronage.
9.2 Authentication
If a client connects to a Web service, it is necessary to
identify the user and authorize him/her to use services.
One promising solution is to use HTTP authentication.
HTTP includes built-in patronage for Basic and Digest
authentication. So services can be protected more than the
same manner as HTML documents are currently pro-
tected. However, security experts, agree that HTTP au-
thentication is a relatively weak but there are several
frameworks under consideration [18]. The first SOAP
Security Extensions is Digital Signature (SOAP-DSIG).
SOAP-DSIG leverages public key cryptography to digital-
ly sign messages. This enables the client or server to con-
firm the identity of the other parties.The second option is,
the Organization for the Advancement of Structured In-
formation Standards (OASIS). It works on the Security
Assertion Markup Language (SAML). The capability of
SAML is to facilitate the exchange of authentication and
authorization information between business partners [7].
In a related effort, some companies have put forth the
XML Key Management Services (XKMS). XKMS specifies
a collection of services for managing and distributing
public keys and certificates. The protocol itself is built on
SOAP and WSDL. So it is an excellent example of a web
service.
9.3 Network Security
Bruce Schneier, a famous computer expert In June 2000,
imparted that "SOAP is going to open up a whole new
avenue for security vulnerabilities" [14]. Schneier's basic
focus is that HTTP was made to retrieve documents. Ex-
tending HTTP via SOAP enables remote clients to invoke
procedures and commands, something that firewalls are
explicitly established to prevent. We can argue that CGI
(Common Geteway Interface) applications and servlets
give the same security vulnerabilities. After all, these
programs therefore enable remote applications to invoke
[7]. Currently there is no easy response to this problem,
and it has been the subject of much controversy. One
possible solution for filtering out SOAP or XML-RPC
messages, is to filter out all HTTP POST requests that set
their content type to text/xml (a requirement of both spe-
cifications). Another alternative solution is to filter for the
SOAPAction HTTP header. Currently, firewall vendors
are developing tools explicitly built to filter Web service
traffic.
10 ALL TOGETHER NOW
When you realize these layers in the Web service protocol
95
stack, the next important step is to gripe how all the parts
fit together. There are two ways for this target, either
from the service requestor landscape or the service pro-
vider landscape.
10.1 Service Request Landscape
Here we introduce a typical development plan for a ser-
vice requestor landscape:
First, we should identify and discover those services
that are appropriate to our application. So the main pur-
pose of this step is searching the UDDI Business Directory
for partners and services.
Once we have recognized the favorite service, in the
next step we should locate a service description. If this is
a SOAP service, we are likely to find WSDL documents. If
this is XML-RPC services, we are likely to find some hu-
man-readable injunctions for integrating.
In Third step, we should create a client application. For
example, we may create an XML-RPC or SOAP client in
the favorite language. If the service has a WSDL file, we
also have the option of creating client code via a WSDL
invocation instrument automatically.
In finally step, we run ourr client application to actual-
ly invoke the web service.
Fig. 3. The Service Requestor Landscape
10.2 Service Provider Landscape
Here we explain a typical development plan for a service
provider:
First, we must develop the main functionality of our
service. This is usually the most complicated part, as your
application may connect to databases, Enterprise Java-
Beans™ (EJBs), COM objects, or legacy applications.
In second step, we should develop a service wrapper
to our major functionality. This might be an XML-RPC or
a SOAP service wrapper. It is usually a relatively simple
step to wrap existing functionality into a larger frame-
work.
In the next step, we need to provide a service descrip-
tion. If we are creating a SOAP application, so we should
create a WSDL file. If we are creating an XML-RPC ser-
vice, we should create some human-readable instructions.
Fourth, we need to spread the service. According to
our requirments, it could mean installing and running an
alone server or integrating with an existing Web server
[7].
In the fifth step, we need to publish the existence and
specifications of our new designed service. It means pub-
lishing data to a universal UDDI directory or maybe a
private UDDI directory specific to our company.
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Fig. 4. The Service Provider Landscape
11 WEB SERVICES COMPOSITION METHODS
IT organizations need the versatility to reconcile to cus-
tomer requirements and changing market situation. But
existing solutions do not directly support Web services
standards and, as a result, IT organizations may be capti-
vated to take a short-term solution and create their own
proprietary protocols for composing services. Web servic-
es orchestration, decentralized orchestration and choreo-
graphy standards are efforts that can be long-term solu-
tions for business communications. By connecting servic-
es through open, standards-based methods, organizations
withhold themselves the burden of maintaining those
proprietary interfaces.we explain these standards and at
the end of this article we will introduce a new efficient
method for web services composition.
11.1 Orchestration Method
Orchestration method is an executable business process
that may communicate with both internal and external
Web services. Service orchestration is a centralized ap-
proach which insulates control and data flow. We need
Control flow to control/orchestrate the workflow, whe-
reas data flow relates to the the tasks that compose the
actual applications. It describes how Web services can
communicate at the message level, including the business
logic and execution order of the communications [18].
These interactions can span applications and/or organi-
zations, so they result in a long-lived, transactional
process. With orchestration, the process is always con-
trolled from the viewpoint of one of the business parties.
In this model, all communication is directed via a central
process (workflow engine) for both the control and data
flow.
Fig. 5. Orchestration Model
In the Web service world, Web Services Business
Process Execution Language (WS-BPEL) [19] has become
the de facto standard for orchestration. With WS-BPEL,
the workflow can be specified without the need to ac-
commodate any of the services, with help of the central
process providing the workflow logic.
96
11.2 Choreography Method
This method is more collaborative in nature. Each party
describes the part they play in the interaction. Choreo-
graphy tracks the sequence of messages that may involve
multiple parties and also multiple sources. It is done with
the public message exchanges that tide between multiple
Web services [19].
This decentralized solution does away with the centra-
lized process and instead each collaborating service is
aware of its portion in the workflow. In Service choreo-
graphy, the collaborating services exchange messages in
order to coordinate execution of the workflow. We should
notice that in order for this collaboration to take place, the
Web services need to be corrected so that they are aware
of the related workflows. The characteristics have been
put forth for Web service choreography in the Web Ser-
vices Choreography Description Language (WS-CDL)
[21]. This method has so far not been widely used, nor are
there many implementations of the specification.
Fig. 6. Choreography Model
Orchestration differs from choreography. it describes a
process flow between services, controlled by a single par-
ty but, choreography tracks the sequence of messages
involving multiple parties, where no one party truly
“owns” the conversation.
11.3 Decentralized Orchestration
Decentralized Orchestration is another solution for being
used by web services. In this model, a centralized
workflow is analyzed and divided into smaller
workflows [18]. Each workflow engine orchestrates its
own partition of the workflow.
Fig. 7. Decentralized Orchestration Model
We need multiple workflow engines to execute the
partitioned workflows (each executing its own partition).
In this method, potential bottlenecks that we could see in
the previous methods, will be removed. Decentralized
orchestration was found to minimize the amount of traffic
in the workflow but this approach increases the complexi-
ty of the workflow design and execution, while deadlock
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
can be built [20]. Furthermore this model needs parallel
programming that can cause to additional challenges.
12 AN EFFICIENT ALTERNATIVE MODEL WITH
DEPUTY SERVERS
In our model, the data flow is decentralized while the
control flow remains centralized. Applications with this
method have advantages compared to other centra-
lized/distributed control and data flow. To accomplish
this, deputy servers are used in the system. The contribu-
tion of this model is the introduction of the deputy server.
This server is participated with the workflow engine, but
strives to be a non-disruptive extension to the traditional
orchestration model.The workflow engine negotiates with
the deputy servers using the control flow. The servers
carry out Web service invocations instead of the
workflow engine.
Deputy servers will need to communicate with three
parts: the central workflow engine, other deputy servers
and the Web services. Interaction of deputy servers with
each other exposes the desired interface for them.
Fig. 8. A New Model with Deputy Servers
As mentioned earlier in our model, data flow is decen-
tralized. Instead of sending all data back to the workflow
engine, data can stay on the deputy servers. Because of
the workflow continues, the data on a deputy server,
should be sent to other deputy servers. Deputy servers
provide Web service requests and receive Web service
responses. Requests are either received from the
workflow engine or another deputy server or they may be
the response from a previous request. Responses will ei-
ther be stored, or forwarded to another deputy servers or
the workflow engine. So a full SOAP protocol stack is not
a necessity at the deputy server.
Wheras in the traditional systems, the workflow en-
gine communicates with the Web services, this is not re-
quired in our model. Instead, the workflow engine does
the same work by sending workflow Web service interac-
tion to the deputy servers (they would act as pass-
through services). The workflow engine, should coordi-
97
nate the execution of the workflow by using control mes-
sages. These messages may be sent to the deputy servers
that require them or perhaps forwarded by other deputy
servers.
The placement of the deputy servers can improve the
performance of our model as compared to the traditional
model. For example, in traditional model, all data have to
be sent to the workflow engine which can be at a remote
situation (compared to the Web services). In our model a
deputy server can be placed near the Web services (for
example in the same domain), so they cause to a lower
cost for data transfer.
13 CONCLUSION
This paper has fully reviewed the Service Oriented Archi-
tecture (SOA), its Web services’ domain and the essential
requirements of establishing a suitable Web service. It
also covers the introduced technologies in this area and
entirely explains four main layers for perception of the
protocol’s stack in Web services. Because without realiza-
tion of each layer in protocol’s stack of Web services it
will not be possible to specify how the different parts
should be compatible with each other in order to lead the
Web services to composite for getting the ultimate goals.
Furthermore, we maintioned security issues briefly. Al-
thoutgh Web services domain is growing quickly, but
there are many challenges for this sence yet.
It can be claimed that the next steps are the review of
the posed challenges in area of combining the services
and optimizing them. Applying the composite Web ser-
vices has many commercial benefits for organizations.
Firstly, it reduces the time of producing process that
cause to reduce the time for products to reach to the mar-
ket. Secondly, producing the applications with available
services decreases the business risks of software produc-
ing and avoids dealing with new software errors. Thirdly,
by using available Web services, organizations’ need for
several new skills will decrease which also cause to save
in cost of software production. Finally, by using available
Web services it is possible to choose the best service from
several options which leads to better softwares in terms of
quality. Therefore we explained the advantages of com-
bining Web services and existing methods and finally
discussed a model for Web services composition in order
to optimize former compound methods, based on the use
of deputy servers.
In the first methods, cost and data exchange, time re-
duction, response time improvement, and centralized
control of communication between different services to
provide appropriate services to the customer is aimed. In
the improved models main goal is, the cost and time re-
duction associated with large current data (especially re-
petitive data). One of our model considerable advantages,
is in a large volume data transaction where simultaneous
respond to many requests is needed, the result of tradi-
tional storage in this volume (Work Flow Engine) may be
impractical while in this case the optimized approach will
partition data into different deputy servers leading re-
cording volume decrement and makes it practical. Anoth-
JOURNAL OF COMPUTING, VOLUME 3, ISSUE 2, FEBRUARY 2011, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 98

er important advantage is that, in Web services without a dissertation, Dept. of Informatics., Edinburgh Univ., 2008.
deputy server, data exchange should only operate with [18] Y. Rao, B. Qin Feng, J. Cang Han, and Z. Chao Li “A Security
the Work Flow Engine that might be located in far dis- Integrated Model for Web Services,” Proc. IEEE Symp. Machine
tances. As a solution near domain deputy servers can be Learning and Cybernetics (ICLMC ’05), pp. 2953-2958, Aug 2004,
identified to transfer data through them in a lower time doi:10.1109/ICLMC.2004.1378538.
with less cost. In the optimized model entire data base [19] G. Chafle, S. Chandra, V. Mann, and M. GowriNanda “Decetra-
has been distributed on multiple servers so the processing lized Orchestration of Composite Web Services,” Proc. 13th. In-
power is increased and lateral services can be provided ternational World Wide Web Conf. Alternate Track Papers And Post-
without any traffic enhancement or work overflows. ers, pp. 8-16, 2004.
[20] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, and Y. Lafon
REFERENCES “Web Services Choreography Description Language Version
1.0,” W3C Technical Report, W3C Working Draft, Dec. 2004.
[1] N. Milanovic, and M. Malek, “Cuurent Solutions for Web Ser-
[21] M. Weski, Business Process Management: Concepts, Languages,
vice Composition,” Proc. IEEE Symp. Interner Computing, No-
Architectures. Springer, pp. 123-135, Sep. 2007.
vember-December 2004.
[22] B. Benatallah and Q. Sheng, "The Self-Serv Project Uses a P2P-
[2] T. Berners-Lee and J. Hendler, and O.Lassila “The Semantic
Web,” Scientific American, 501(5):pp. 28-37, May. 2001. based Orchestration Model to Support the Composition of Mul-
[3] A.Masri, and E.Mahmoud “Investigating Web Services on the tienterprise Web Services," IEEE Computer Society Trans. Internet
World Wide Web,” Proc. 17th International Conf. World Wide Web Computing, vol. 3, pp. 40-48, January 2003.
(www)-for QWS-WSDLs Dataset Version 1.0, pp. 795-804, April [23] M. Matsumura, “Generico SOA Adoption Bluprint,”
2008. http://www.oasis-
[4] R. Pessoa, “A survey of Service Composition Approaches,” open.org/committees/documents.php?wg_abbrev=soa-
Proc. Conf. Enterprise Distributed Object Computing Conference blueprints. 2006.
Workshops, pp. 238-251, 2008.
[5] Z. Mahmood, “Enterprise Application Integeration based on
Service Oriented Architecture,” International Journal of Comput-
ers, vol. 1, no. 3, pp. 135-139, 2007.
[6] E. Cerami, Web Services Essentials-Distributed Applications with
XML-RPC, SOAP, UDDI, and WSDL. Publisher: O'Reilly, pp. 1-
24, ISBN:0-596-00224-6, First Edition February 2002.
[7] H. Hass, and A. Brown, “Web Service Glossary,” Technical
Report, WWW Working Group Note, Feb. 2004.
[8] D. Booth, and C. Liu, “Web Services Description Language
(WSDL) Version 2.0,” W3C Technical Reports and Publications,
Primer W3C Working Draft, August 2005.
[9] A. Oussalah, and M. Lina, “Toward the Definition of the Loose
Coupling Notion in a Composite Service,” Proc. IEEE Symp.
Computer Engineering and Applications (ICCEA), pp. 339-343,
March 2010.
[10] A. Alamri, M. Eid, and A. Elsaddik, “Classification of the state-
of-the-art Dynamic Web Services Composition Techniques,” J.
Classification,University of Ottawa,Canada,Int.J Web and Grid
Services, vol. 2, no. 2, , Apr. 2006.
[11] J. Ge YuhUi Qiu Shiqun Yin, “Web Services Composition Me-
thod Based on OWL,” Proc. International Conf. Computer Science
and Software Engineering, pp. 74-77, 2008.
[12] B. Mathew, and P. Sarang, Business Process Execution Language for
Web Services. An Architect and Developers Guide to Orchestra-
tion Web Services Using BPEL4WS, pp. 92-104, 2006.
[13] S. Jones, “A Methodology for Service Oriented Architect,”
http://www.oasis-
open.org/committees/documents.php?wg_abbrev=soa-
blueprints. 2005.
[14] S. Dustdar, and W. Schreiner “A Survey on Web Services Com-
position,” Technical University of Vienna Systems-Information Sys-
tems Institute, http://www.infosys.tuwien.ac.at. 2004.
[15] L.J Zhang, “SOA and Web Services,” Proc. IEEE Symp. Service
Computing (SCC ’06), Sept 2006.
[16] B. Carminati, E. Ferrari, and P. Hung “Security Conscious Web
Service Composition,” Proc. International Conf. Web Services, pp.
8-16, 2006.
[17] N. Kyprianou, “Web Service Orchestration,” Master of Science