Net Traveler: A Framework for Autonomic Web Services Collaboration, Orchestration and Choreography in E-Government Information Systems

Hillary Caituiro-Monge (hcaituiro@ieee.org), Manuel Rodrguez-Martinez (manuel@ece.uprm.edu) Department of Electrical and Computer Engineering University of Puerto Rico at Mayagez Abstract
Next-generation Government Information Systems will integrate large amounts of heterogeneous data sources located on distributed networks like the Internet. We present Net Traveler which is a framework for web services collaboration, orchestration and choreography in peer-to-peer autonomic environments. The main feature of our new approach is the elimination of a central coordination site running the queries and the autonomic query execution. Moreover, control information is embedded with the request for data, and also with the partial results in an XML document. This XML document indicates the next service to be requested, the target site (if known) and how should it process any partial results. We present the architecture, the ideas behind it, a prototype, and a performance study to validate this framework. This study shows this framework to be flexible, scalable and efficient for the web services collaboration in electronic government applications. Next-generation Information Systems (NIS) of organizations (e.g. Governments) will incorporate large amounts of heterogeneous distributed information sources accessible through web services (Figure 1). Each entity (e.g. government agency) will have its own set of NISs and policies to access them. The information sources might be located on servers, desktop computers, mobile devices, or embedded computer systems. Orchestration and choreography among NIS will be critical to collect vast amounts of valuable information. The main feature of our new approach is the decentralized coordination through lightweight web services that can be run from a client or information source site. Notice that a central coordination site simply cannot serve well to all the different kinds of applications and information sources that will be found in a NIS. Therefore, the control for coordination should be given back to the local sites, so they can use domain-specific knowledge to run the coordinating services. Thus, we can have multiple kinds of small, custom-tailored web services that are optimized to carry out the control of a specific computation process. Our approach is to include control data in an XML document that is attached with a request for a service, or with partial results. This XML document indicates the next service to be requested, the possible target site(s) and how should it process any partial results. This feature is necessary to avoid imposing a connection-oriented type of system, were a site has to be in continuous contact with the sites providing services it needs. Notice that this would be unfeasible for mobile devices.

1. Introduction
The emergence of wide-area networks such as the Internet has provided users with access to vast amounts of rich data sets that are located on data sources distributed over these networks. For the past twenty years, researchers in the area of Distributed Database Systems have concentrated on the problems of heterogeneous data integration [3] [6] [7] [8], distributed query processing, and distributed transaction processing. Database Middleware Systems were developed to integrate heterogeneous data sources distributed over networks. Web services play a critical role in the integration of distributed systems over wide-are networks. They need to collaborate in order to execute complex requests. Thus, web services are statically linked for performance, scalability and reliability. Also, the execution of requests triggers dynamic relationships among them. In web services static relationship are called orchestration. [9] And, dynamic relationship among web services is called choreography. [5]

Personal computer

DBMS

Satellite

Cell phone Tablet computer

Mobile Information Server

Mainframe

Radio tower

Wireless access point

PDA

XML

Web servers

Super computer

Laptop computers

Figure 1: Wide-Area Environments

1.1. Contributions of this paper

In this paper we present a new middleware architecture by unchaining the execution of control software from the coordinating sites. Our target environment is an E-government application in which various sites need to exchange data in order to complete a particular task, controlled not only by computational resources but also by statutes and regulations. This framework is implemented on an open source prototype called Net Traveler written in Java. We have a decentralized Peer-to-Peer software framework in which user-defined code and control is released to the local executing sites (client or data sources), which will decide which are the sites that will supply data, computational services, and the aggregation of results. Government-to-government interaction occurs naturally as cooperating sites interoperate the access to the required documents. The receiving site may partially execute its code on its local environment, and pass it along with partial results to next peer site, or coalition of peer sites that will continue with the computational process. This framework is based on a model for composition of distributed data services, where one site performs a given task and ships its results, plus some control information, to another site that will continue with the computational process. The goal is to provide a set of well-defined services that can be combined to create a larger government service. Thus, independent operations administered by distinct government agencies can be pipelined to complete a specific procedure (e.g. registering a home and paying state taxes). Any site asked to provide a service can obtain required user-defined capabilities by simply asking for the code to be shipped to it. Thus, control data, control software and software used to compute some government operation can be moved on demand anywhere in the system. The remainder of this paper is organized as follows. Section 2 motivates the need of Net Traveler. Section 3 describes the architecture. Section 4 presents the query execution model. Section 5 describes the benefits of our approach. Performance evaluation is presented in section 6. Section 7 presents the discussion of the results. Section 8 covers the related work. Section 9 covers the future work. Finally, we conclude in section 9.

2. Motivation and example scenario

NIS of organizations (e.g. Government) poses a great number of challenges to computer community that is working to build transparent, scalable, and reliable Information Systems (IS) to allow end-users to execute queries that need access to heterogeneous and geographically distributed databases.

Current IS are heterogeneous in several dimensions. First, in the logical dimension, ISs have several and critical differences among the entities (eg. government agencies), since each of them has its own and different logical model due to its functions and modus operands. Second, the database schemas are definitely heterogeneous, since they are designed independently by different teams of people with different backgrounds and preferences. Third, the database engines installed in the local area networks of entities are diverse even though at the same site. Finally, due to the nature of each entity, ISs are treated with non homogeneous security levels, while some of them could require encryption and high security standards; others could need only minimal protection such as anti-virus software. End-users usually request information that includes several entities. ISs are independently designed and implemented, so it is so difficult to get them together to work. In this context, it is necessary to gather the information from several ISs among different entities. Thus, the orchestration and choreography of the ISs will allow an efficient and effective result. Moreover, ISs need to be accesses through a standard and universal middleware. Web services fulfill such requirements, since they are broadly used in wide-area networks (e.g Internet). Information requests across entities are dynamic and usually include several ISs. Maintaining permanent relationships among such ISs are neither efficient nor effective. Predicting, designing and implementing all the possible occurrences of ISs interconnections for satisfying the requests are both impossible and expensive. Although, there could be some well known cases where is possible to make permanent federations of ISs, most of the time the federations will be ad-hoc. In several scenarios, it is predictable in advance which ISs will be needed to complete a task. However, due to the wide-area environment and nature of requests, in many scenarios, is not possible to determine in advance which ISs will be contacted in order to collect information, because is impractical that each IS maintains a complete addresses of ISs across the world. A Peer-toPeer [2] approach will allow completing tasks without previous knowledge of the complete list of ISs. Each IS represented by a Web Service will be a peer. An example to use through this paper is an EGovernment process for auctions. It consists of many government entities and government officials which work following a sequence of steps to complete the auction process. An official starts the process making a request of some products (e.g. computers). Such requirement falls under the hands of an official in charge of coordinating the complete auction process. This last builds an auction plan and sends pertinent communications and instructions to several non-government and government entities. The

non-government entities which receive the communication are the providers which have the requested product. They gather information from its own registers and send a proposal to an evaluation office in charge of collect and evaluate the proposals. Finally, an entity that is in charge of making orders and notifying about the result sends a final message to the winner and to the original requester.

3. System Architecture
Figure 2 depicts the different elements contained in the architecture of the proposed framework. Each rectangle represents a local execution environment. As Figure 2 depicts, the big rectangle is duplicated as small rectangles. Each rectangle can be composed by the mentioned components such as one or more QSBs. Thus, QSBs can be found in each rectangle, so they could have relationships among them. We consider such QSBs as peers that could be joined in federations.
Query Services Broker Registration Server

technology will be used to enable this operation over wide-area environments. Information Processing Server (IPS). Provides a commodity service for query execution. This is an optional element that will be most likely used in environments that require parallel processing capabilities, or which have many low powered devices. The Data Processing Server should be implemented on a multi-processor server or a cluster of workstations. Registration Server (RS). This server is used to coordinate access to a federation and to the resources that it provides. In addition the Registration Server handles all bookkeeping necessary to log events such as departure of a federation member, or reappearance of a member at a different network. Register Servers located at cooperative local execution environments will work together to keep track of moving data sources and route data requests as appropriate.

3.1. Message structure

Net Traveler has a Message eXchange Common Format (MXCF) as a general purpose envelope which contains static and dynamic information for control, data, and code exchange.

LAN
Information Gateway Information Gateway Information Gateway Information Processing Server

Query Services Broker

Registration Server
Information Source Information Source Information Source

Query Services Broker

Registration Server

Information Gateway

Information Gateway

Information Gateway Information Processing Server

Information Information Information Gateway Gateway Gateway

Information Processing Server

Query Services Broker

Information Source

Information Source

Information Source

<SOAP-ENV:Envelope xmlns:SOAP-ENV=""> <SOAP-ENV:Header ID="" OP_TYPE="" <NetT:To>URL</NetT:To> <NetT:From>URL</NetT:From> <NetT:Ack>BOOLEAN</NetT: Ack> <NetT:ForwardTO>URLs</NetT:ForwardTO> <NetT:ResponseTO>URLs</NetT:ResponseTO> </SOAP-ENV:Header></SOAP-ENV:Header> <SOAP-ENV:Body> <NetT:PLAN>...</NetT:PLAN> <NetT:CONTAINER TYPE> <NetT:Dataset1 SOURCE=""> <NetT:Operation id=sum></NetT:Operation> <NetT:Data></NetT:Data> <NetT:Result></NetT:Result> </NetT:Dataset1> <NetT:Dataset2 SOURCE=""></NetT:Dataset2> ... </NetT:CONTAINER> <NetT:HISTORY>...</NetT:HISTORY> <SOAP-ENV:Fault>...</SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Registration Server

Information Gateway

Information Gateway

Information Gateway Information Processing Server

Information Information Information Source Source Source

Information Source

Information Source

Information Source

Figure 2: Architecture The local execution environment represents the confines of a government agency. The purpose of each of the components is as follows: Information Gateway (IG). Provides access to other members of the system to the data sets maintained by a given source site. This element has a role equivalent to a database gateway or wrapper. This element will be run at the device hosting the data source, or at another computing unit that is physically close to it. Query Services Broker (QSB). Works on behalf of a client site (which can be a data source site that become a client) to find the data and query processing capabilities necessary to solve a given query. This element has responsibilities such as query plan generation, query coordination, and final resource acquisition. The Data Broker can access data sources that lay outside its local execution environment. VPN

Figure 3: Message exchange common format Figure 3 depicts an instance of MXCF, implemented as an SOAP message having static parts such as header, body, fault, plan, container, history. It also has dynamic parts such as dataset1, plan contents, history contents and others. It is special feature in Net Traveler, embedding control and code within data. Header contains information about the main operation that will be applied to the data in the message. Also, it has information about the message destination (NetT:To), if there will be an acknowledge (NetT:Ack), a forward

destination (NetT:ForwardTO), and a response address to send the result of the main operation (NetT:ResultTO). The body has fields to hold the execution plan (NetT:Plan). A container has datasets in which data is contained, the operation to be applied to the data, and the results from the operations. The history zone holds old information or previous messages that shows the progress of processing the data (NetT:History). Finally, if there is an error as a result of the execution of the main operation it is stored in the fault zone (NetT:Fault).

3.2. Federation model

The fundamental organizational unit in the system is the ad-hoc federation (Figure 4) of peer government sites, which is a collection of computing devices that have agreed (or are configured) to work together as a group to exchange data, and share computational resources to complete a government-related task.

different outcomes. Also, each member is represented as group of replicated web services (NetT:provider1 in NetT:providers in Figure 5) which provides the same functionality and outcomes. Replicas are useful for scalability in NIS with high requests rates and replicas are useful for fault tolerance when web services crash. Additionally, the tag NetT:webserviceID holds an unique identification for the web service. Tag NetT: orchestra holds the addresses of statically linked web services. The tags NetT:providers, NetT:collectors, NetT:notificators, NetT:coordinators holds the addresses of web services which have operations implementing such tasks. For example the tag NetT:providers has the addresses of the web services of providers of some product.
<NetT:conf> <NetT:webserviceID> </NetT:webserviceID> <NetT:orchestra> <NetT:ca> <replica1>http://localhost:9999/CA</replica1> <replica2>http://foreinghost:9999/CA</replica1>
...

PERMANENT FEDERATION

</NetT:ca> <NetT:qsb>...</NetT:qsb> <NetT:ig>...</NetT:ig> <NetT:ips>...</NetT:ips> <NetT:rs>...</NetT:rs>

QBS
AD HOC FEDERATION

QBS

QBS
PERMANENT FEDERATION

</NetT: orchestra > <NetT:providers> <NetT:provider1> <NetT:replica1>http://host1:9999/QSB</replica1> <NetT:replica2>http://host2:9999/QSB</replica2>

...

QBS

</NetT:provider1> <NetT:provider2>...</NetT:provider2>
...

QBS QBS QBS

AD HOC FEDERATION

QBS

</NetT:providers> <NetT:collectors>...</NetT:collectors> <NetT:notificators>...</NetT:notificatos> <NetT:coordinators>...</NetT:coordinators> </NetT:conf>

QBS

PERMANENT FEDERATION

Figure 5: XML structure for a fixed federation 3.2.2. Ad-hoc federations (AF) model Ad-hoc federations (AF) are composed for such NIS whose domain and relationships are loosely coupled and unpredictable. In Net Traveler an AF is a collection of web services related as described before (doted region in Figure 4). An AF is established for a temporal duration with a specific purposed as a result of an end-user request that need to be answered using heterogeneous web services. AF members belong to several and different entities which are not usually related neither physically nor logically. Net Traveler gives support to ad-hoc federation through a ad-hoc federation model whose configuration is established by means of a XML structure similar to the one in Figure 3.

Figure 4: Federation model 3.2.1. Permanent federations (PF) model. Permanent federations (PF) are composed for such NIS whose domain and relationships are highly coupled and are frequently used. In Net Traveler a PF is a collection of web services related as described before (circles in Figure 4). For example, they could potentially belong to the same physical entity that could be a government entity in the same building. Alternatively, they could be logical entity such as an association of related state universities. Net Traveler gives support to permanent federations through a permanent federation model whose configuration is established by means of a XML structure (Figure 5). The XML structure of a PF holds the necessary information for the operation of an entity web service and the information about the federation conformation. Members (web services) of the PF can be grouped by functionality (NetT:providers in Figure 5) which indicate that these members provide the same operations but with

3.3. Ad-hoc coordination model

Fixed (FC) and ad-hoc (AC) coordination models are incorporated in our approach. However, ad-hoc coordination (AC) across PFs and/or AFs gets our attention due to its several advantages to work in non

fixed web services arrangements. Web services organization, localization, and functionality are in advance full known information in FC. Thus, fixed and pre-fabricated plans are implemented in order to complete the different tasks. Moreover, such plans are embedded into web services code. Usually this kind of coordination is done by a centralized coordinator that executes several algorithms using its catalogs. In AC, knowledge about sites might be partially known or simply not known at all. Thus, AC starts with incomplete information that is subsequently completed by other peers or web services. Under these circumstances of uncertainty, centralized coordination does not work neither effectively nor efficiently, since it will need to gather information from far located peers several times in order to complete an execution plan. Even worse, it could not complete the plan due to the lack of information in its directory. Obviously, a better way to do coordination in those scenarios is one done in a decentralized style. Decentralized coordination requires that peers collaborate among them for purposes of completing an execution plan that could be started without full site information and subsequently be completed on the road.
1 1 0 Coordinator 1 1 1 P1 1

Client Application (CA) 3 Collector

P2 2 2 2 2 Pi

become in a initial coordinator (e.g. QSB labeled with Coordinator in Figure 6). At this steep, Q1 build an initial plan A1 based on its knowledge and send it to its nearest QSBs (e.g. QSBs labeled as Collector, Notificator, P1 Pn in Figure 6). A1 is stored in the XML format, similar to the structure presented in Figure 3, containing the control information with the sequence of web services to contact and the data that could be partial results. This plan is sent as a message to the other web services, which can re-send it to others web services or respond with the information requested. For example, in Figure 6, the Coordinator sends a message to P1 Pn, which re-send the results to the Collector. A plan can be viewed as a directed graph, where arcs with the same sequence number conduce to parallel executions and/or conduce to broadcast a message. For example in Figure 6 the web service Coordinator will broadcast a message to web services P1Pn. Therefore, these web services will run in parallel and subsequently send next messages activating other web services. As part of a dynamic and decentralized execution plan conformation, web services can add more information both as control and data. In this context some web services can request notifications at certain points of the plan execution (e.g. a message will be sent to web service Pi as a notification in Figure 6, since it included a request when send a message to Collector). In the implementation of the current prototypes we assumed a fixed plan to solve request which are similar to the auction example described above.

3.4. Orchestration and choreography model

Orchestration refers to an executable process and choreography refers to tracking the message sequences among peers. [5] Referring to web services, orchestration is the static and/or fixed relationship among them. Usually it is determined in the logic of the source code, or some times defined by a system administrator. Generally, such relations occur between different web services classes and/o between web services from different architectural layers.

Notificator 4 Pn
Query Services Broker (QSB)

Figure 6: Choreography We now give an example about coordination. Figure 6 is composed of web services and their dynamic relationships. A CA is a client application from which a request is started. The remaining web services are QSBs. The QSB coordinator acts as the coordinator of a process like the auction process. The QSBs P1 Pn are providers of something that could be some products requested in the auction process. The QSB collector gathers the responses of providers. And, the QSB notificator notifies about the process result that will be the auction result. Ad-hoc coordination in Net Traveler begins when an end-user sends a request to a QSB through a CA or another interface (e.g. arrow labeled with 0 in Figure 6). As an immediate consequence of such action, this QSB

Choreography CA 1 2 3 4 QSB QSB 5 QSB QSB CA

IG IG Orchestration

IG IG Orchestration

Figure 7: Orchestration and Choreography

Choreography, is the dynamic relationship among web services, typically it occurs as a result of the execution of a given temporary plan to complete a task. Choreographs or plans define temporary relationships which leads to conform ad-hoc federations. Figure 7 shows a sketch of choreography through the arrows labeled as 15, where each arrow represents an interaction between two QSBs and numbers represent the sequence of such interactions. In our framework orchestration is defined by the fixed relationship among Client Application (CA), Query Services Broker (QSB) and Information Gateway (IG). Figure 7 shows an orchestration instance in Net Traveler, where CA is linked to two QSBs, and each QSB is linked to a different IG.

3.5. Message passing model

There are two main models to implement message passing: synchronous and asynchronous models. In synchronous models end-users are blocked waiting for a response, while in asynchronous models end-user send a request and they continue executing other tasks. In distributed systems, even more in distributed peer-topeer, systems synchronous message passing models are not efficient mainly due to that such models tend to be resource consuming. On the other hand asynchronous message passing fulfill better the requirements and nature of these kinds of systems, because this model allow maximize the availability of resources. NISs have large amount of distributed components (i.e. web services) related among them. Web services and its relationships can be represented as a directed graph G(V,E), where a vertex represent a web service and a edge represent a relation. Edges have a label that is a number indicating a sequence of dependence, where an edge with a lower numeric value occurs before an edge with a higher numeric value. In a synchronous message passing model when a relation triggers another relation, the first must wait until the last finish. Net Traveler follows an asynchronous message passing model where web services do not have to wait blocked to obtain responses. For example CAs send a message and continue executing its own tasks. The response can be obtained as a result of a second inquiry to the NIS or by means of a notification from the NIS. This scheme is followed by the web services at each step of the query execution. Our asynchronous approach allows redirect messages through different paths. Figure 6 shows the sequence of execution as a directed graph.

format to be parsed, optimized, and executed. This model is described as a combination of an orchestration and choreography of web services. Before all, the orchestra of web services is designed in such manner that the IS to be efficient. This happens when CAs, QSBs, and IGs are logically and geographically distributed in strategic locations for load balancing, availability, and performance. It remains as a static structure that will be rarely changed. Once established the orchestra of web services then several occurrences of choreographs are triggered when an end-users starts a request. This request is started through a CA which captures the information to start the operation and sent it to one or more of its linked QSBs. Many things could happen before and after this event. This CA can be linked only to one QSB and it could not have the functionality to give the requested information. Definitely, requests with operations not supported will be rejected. However, before this happen the contacted QSB will need to check if someone of its colleagues could have the functionality to reply the request. Also, when a QSB receives a message form a CA or another QSB, it creates an initial execution plan in its own domain and security context. A security context defines the boundaries where the data can be sent or viewed. This QSB could create several versions of a message following the security restrictions and for performance purposes. After that, this QSB sends the initial plans to the other peers. They, at their time, add information to complete the execution plan under the same condition before mentioned. A complete plan is sent only to the QSBs with the same security restrictions or to QSBs with higher security grants. An instance of the query execution model is in Figure 6, where CA sends a request labeled as 0 to the coordinator QSB. The coordinator structures three initial plans and it sends the firs plan to QSBs P1Pn. In the first plan it gives instructions to QSBs P1Pn to get some information and sent the results to the QSB collector. The second plan is sent to the QSB Collector giving instruction to him to wait for responses from QSBs P1 Pn and later sent a message to the QSB notificator. The third plan is sent to the QSB Notificator giving instruction to him to notify to some QSB Pi. The QSB Notificator notifies to the CA and QSB Pi with final information about the query results. Each one of them receives relevant information in their security domain.

5. Benefits
The main goals that designers pursue in the design of DSs are transparency, scalability, reliability and performance. In the design of this framework we had in mind those all.

4. Query execution model

This model defines how the framework behaves when a query is executed. The query can be either an end-user or web service request that is translated to a XLM query

Transparency was addressed in several dimension of the proposed framework. Some of the most important were the fault tolerance transparency and availability transparency. However, the most important was the transparency that allows end-users through a single request execute a multiple multi-domain operations. Endusers do not have to worry about send a request to a given web service and gets the results to send a second request to another web services, and so on, in order to complete an entire process. Fault tolerance is one means of achieving reliability. In a DS, a processor, computer or component that fails is replaced by another that continues executing its activities. In Net Traveler fault tolerance and scalability are provided by means of the replication of the web services. It is supported using alternative addresses for the web services. If one of them fails, it is possible to use one of the remaining, thus the operation will continue normally. Also, if one of the work load is huge it could be divided between the replicas. Performance is a sensitive feature in Net Traveler. End-users want to get their job done opportunely and promptly. We designed and lightweight asynchronous approach with the mind in reduce waiting times and communication overheads.

In Figure 8, the workload is the number of messages occurred during the execution of the plan. And, the response time is the time that takes to interchange a given number of messages. The response time counter started when the Test Application send a message to the first QSB with an initial request. Immediately, this QSB selects a query plan containing the request and the control information and sends it as a SOAP message to the other twelve. After completing the tasks contained in the query plan, one of the web services sends the signal back to the Test Application, thus it stops the response time counter. The experiments were repeated ten times and averaged.
4000 3500 Response time (msecs) 3000 2500 2000 1500 1000 500 0 0 Async 100 Sync 200 300 Workload (m essages) Linear (Async) 400 Linear (Sync) 500

y = 6.3372x + 820.31 R2 = 0.9952

y = 3.5343x + 289.81 R2 = 0.9957

6. Performance Evaluation
This performance evaluation assesses the scalability of our solution, thus showing its feasibility. Also, it exhibits that a centralized approach is outperformed by our decentralized approach. We implemented two prototypes: centralized and decentralized. Each prototype was used to do a preliminary performance evaluation by measuring the response time for an increasing workload. It was executed using forty one computers. Thirteen computers were Pentium IV of 2.40GHz with 512MB of RAM (lab 1). Seventeen computers were Pentium III of 500Mhz with 128MB of RAM (lab 2). And, the last one was a Pentium III of 1GHz with 512MB of RAM (computer 0). All of them were networked by a 100 Mbps Ethernet and were running Linux RedHat and the Java Web Services Developer Pack. To describe the web services distribution we will use the schema of Figure 6. The QSBs Coordinator, Collector, Notificator and P1P10 were placed in the lab 2 using one computer for each. Several CAs were placed in the lab 1, from one to twenty seven. Finally, the Test Application (TA) was stored in computer 0. The query used was a request for an auction: buy some equipment whose cost was less than a constant X, This is because we were interested in measure the response time of the synchronous and asynchronous message passing rather than the performance of database access or the resolution of complex queries. Figure 8: Response time in a synchronous and asynchronous message passing model

7. Discussion
In Figure 8 the trend line of the response time curves fits a linear curve. This line grows at the same time that the workload increases. The workload was produced by the execution of one to twenty seven Client Applications. The results show that our asynchronous scheme for choreography is superior to a synchronous approach, as those used by centralized systems. Notice that has the number of messages as the number of messages increase, the response time of synchronous choreography is twice as large as that of our approach. This evidence shows the promise of Net Traveler as a system for E-Government collaboration. The decentralized approach outperforms to the centralized approach in the overall response time due to the inherent characteristics of each one. That is that while the query execution and coordination is distributed among peers in the first case. In the second case the coordination is done by only one peer. Thus, this centralized component become a bottleneck Additionally, the asynchrony of the query execution frees resources that can be quickly reused, so the performance improves. This is contrary in the synchronized execution of queries that is used in the centralized approach.

8. Related Work
The Web Service Choreography Interface (WSCI) [1] is an XML-based interface description language. It describes the flow of messages exchanged describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. A difference we include orchestration. Peltz [5] published Web Services Orchestration and Choreography that is about combining Web services to create higher level, cross-organizational business processes. There, he remarked clear differences between Orchestration and Choreography. While the first refers to an executable process, the second tracks the message sequences between parties and sources. Peltzs work is almost the description of a model for orchestration and choreography. We gave a strategy, implement it, and conclude based on a performance evaluation. Pavilion [4] is an object-oriented middleware framework for developing collaborative web based applications. It enables a developer to construct new applications by inheriting and extending its default functionality. Pavilion components include interfaces to common web browsers and a reliable multicast protocol tailored for delivery of web resources. This approach is highly dependent of inherited components and does not provide support for autonomic web services orchestration and choreography. Benatallah et al. [2] describe the design and implementation of a System through the composition of Web Services using a declarative paradigm. Once the system is composed then it can be executed in a peer-topeer fashion without a central coordination. The difference is that in our approach we make a clear distinction between orchestration and choreography as an equivalent to static and dynamic composition. Moreover, we consider fixed and ad-hoc federations.

performance evaluation model is needed, in order to predict its behavior in wide area environments.

10. Summary and Conclusions

In this paper we presented a new middleware architecture by unchaining the execution of control software from the coordinating sites. We had a decentralized a peer-to-peer software framework in which user-defined code and control is released to the local executing sites (client or information sources), which will decide which are the sites that will supply data, computational services, and the aggregation of results. This framework was based on a model for composition of ad-hoc peer-to-peer web services, where one site performs a given task and ships its results, plus some control information, to another site that will continue with the computational process. The goal was to provide a set of well-defined services that can be combined to create a larger service.

Acknowledgments
This project has been funded in part by the UPRM EGovernment program under NSF Grant EIA-0306791.

References
[1] A. Arkin, S. Askary, S. Fordin, W. Jekeli, K. Kawaguchi, D. Orchard, S. Pogliani, K. Riemer, S. Struble, P. Takacsi-Nagy, I. Trickovic, S. Zimek, Web Service Choreography Interface (WSCI) 1.0, W3C, 2002. [2] B. Benatallah, M. Dumas, Q.Z. Sheng, and A.H.H. Ngu, Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Services. In Proc. of the International IEEE Conference on Data Engineering, San Jose, USA, February 2002. [3] S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J. Ullman, and J. Widom, The TSIMMIS Project: Integration of Heterogeneous Information Sources, In Proc. of IPSJ Conference , Tokyo, Japan, 1994. [4] P. K. McKinley, A. M. Malenfant, J. M. Arango, Pavilion: a middleware framework for collaborative Web-based applications, Proceedings of the international ACM SIGGROUP conference on Supporting group work, November 1999. [5] C. Peltz, Web services orchestration and choreography, Computer, Volume: 36, Issue: 10, Oct. 2003, pp. 46 52. [6] M. Rodriguez-Martinez, N. Roussopoulos, MOCHA: A Self-Extensible Database Middleware System for Distributed Data Sources, In Proceeding of the ACM SIGMOD International Conference on Management of Data, Dallas, Texas, USA, May 2000, pp. 213-224. [7] M.T. Roth and P. Schwarz, Dont Scrap It, Wrap It! A Wrapper Architecture for Legacy Data Sources, In 23rd VLDB Conference, Athens, Greece, 1997. [8] A. Tomasic, L. Rashid, and P. Valduriez, Scaling Heterogeneous Databases and the Design of DISCO, In Proc. 16th ICDCS Conference, Hong Kong, 1996. [9] J. Udell, Orchestrate services, InfoWorld, July, 02.

9. Future Work
The preliminary results form the prototype shows that this model is feasible for the depicted research problem. However, there are many outstanding challenges, which will be addressees in the next steps of this research. These are: (i) scalability through load balancing; (ii) fault tolerance through replication; (iii) availability through scalability and fault tolerance. For example this could prevent that a node become overloaded; (iv) support for the transactional processing to ensure the successfully termination of tasks; (v) a security framework to manage issues such as trusting of nodes; (vi) semantic integration will be definitely covered since the nodes are for nature heterogeneous; (vii) an algorithm to build plans on the fly; and (viii) designing a more complex and accurate