Peer-to-Peer-based Web Services for Collaborative Engineering ...

Peer-to-Peer-based Web Services for Collaborative Engineering Environments Tim Schattkowsky1, Christoph Loeser2, Wolfgang Mueller2 1 Paderborn

University, Department of Computer Science, D-33095 Paderborn, Germany [email protected] 2 C-LAB, D-33102 Paderborn, Germany [email protected],[email protected]

Abstract. The Internet connects different enterprises to allow collaborative work, sharing of resources or just the integration of remotely supplied and possibly commercial services. However, different enterprises usually have different heterogeneous network infrastructure and different security policies, e.g., different firewalls with different configurations. The latter often imposes severe challenges to establish a real collaborative engineering infrastructure with distributed tool environments as well as secure exchange of design data and documents over different Intranets. We introduce ANTS (Advanced Network Transport Service) as a peer-to-peer based infrastructure, which can be applied to seamlessly integrate tools and interconnect them as Web Services in order to overcome connectivity problems between highly protected intranets. ANTS is supports relay and routing as well as different underlying transport protocols like TCP, HTTP(R) to transmit data across heterogeneous networks. The transport mechanism itself can be accessed as a Web Service using SOAP calls to the same server. This enables us to have a unified security solution for both the transport service and all other services hosted by the server. We currently apply in industrial projects to interconnect distributed design teams for secure exchange of design data and documents between different Intranets.

I. INTRODUCTION Engineering collaboration gets its new global dimension with the omnipotent access to Internet. When establishing complex collaborative engineering environments for distributed design teams, resource management, integration and their efficient and secure interconnection still remain as major problems though several projects investigated different solutions [11]. Tool management and integration were identified as one of the main challenges when establishing complex collaborative engineering environments connecting distributed design teams with distributed software and hardware resources. Several approaches have been proposed to deal with those issues like the definition of standard languages for Tool integration like TES [1] and tool integration frameworks with workflow management like ASTAI® [14].

Most recently, more advanced platforms for Web-based tool registration and management like TRMS [3][6] were introduced. Dynamic tool management in TRMS is about the dynamic discovery and transparent invocation of a tool based on a semantic description of the desired tool behavior. Figure 1 gives an example of a TRMS architecture to enable dynamic tool management based on the basic principles of UDDI and JINI. In that architecture, tools have to be registered using a centralized lookup service that can late be used to discover the tool. After discovery, the tool invocation may take place in some way.

Figure 1: Dynamic Tool Management in a collaborative Environment The core of the collaborative infrastructure is a set of Web Services enabling the dynamic management of distributed tools. Dynamic tool management means, that engineers are enabled to transparently use remote tools (i.e., costly simulation software that is used to test and verify their design) without being tied to a certain tool instance. Instead, the tool to be actually involved will be dynamically allocated using a centralized lookup service (see Figure 1). Tools are registered at the lookup service. Once a client calls the Lookup Service to discover a particular type of tool, the Lookup Service will locate an appropriate available tool and return a reference to that tool. The client uses this reference to directly invoke on the tool and to transfer the corresponding design data for tool input- and output. When transmitting design data over the Internet (and also even over Intranets) they have to be encrypted and

decrypted in order to preserve a high confidentiality of intellectual property. However, one main problem is mostly ignored and raises during the installation of distributed engineering environment when trying to interconnect applications and teams via different highly protected Intranets, e.g., connecting suppliers to enterprise internal workflows. The main problem, which comes up in industrial environments, is that different enterprises usually have different infrastructures and security policies by means of different firewalls with different configurations. Individual security policies often do not permit arbitrary data exchange and intentionally close communication ports for non-secure communication. In order to overcome those problems, we introduce ANTS (Advanced Network Transport Service). ANTS complements the previously discussed frameworks by providing secure transport services, which integrate tools and interconnect them as Web Services. It establishes a peer-to-peer network interconnecting nodes in different physical networks using different transport protocols. It includes support for features like routing, relay, polling, tunneling to overcome connectivity problems between these networks like those caused by firewalls and network address translations. The ANTS service interface is kept very simple and can be accessed as a SOAP service. It is designed with the goal to allow the reliable transmission of a data packet from one node in the ANTS network to another while dealing transparently with the subservices like routing through immediate nodes or relay. The remainder of this paper is structured as follows. The next section discusses related works in the field of peer-to-peer based systems. Section III introduces ANTS, its basic concepts, routing, interfaces, and architecture. ANTS integration as a web service is given in Section IV. Section V finally closes with some conclusions. II. RELATED WORK Peer-to-peer technologies widely emerged through the last years. Several per-to-peer approaches such as for distributed storage (e.g., CFS, Oceanstore, PAST) and distributed content (e.g., CAN, Pastry, Chord, Tapestry), which were all based on high level routing, have been developed. Several other projects concern the combination of web services and peer-to-peer networks where [4] gives a general overview and a classification of P2P based web services. Peermetrics [9] is a Java-based peer-to-peer development platform for implementation of distributed services with dynamic protocol binding (modular), resource identification, peer identification. Several projects have been announced to incorporate peer-to-peer technology. An example is Redfoot [10], a Python-based framework for distributed Resource Description Framework to implement semantic web based services. Other products like Gaia [7] are announced, but not available. However, Sun’s JXTA [13] toolkit for Java enables the of certain creation peer-to-

peer based services. Currently, it seems to have the widest acceptance among all mentioned technologies. Thus, it may evolve to a pseudo-standard for Java-based peer-to-peer solutions in the near future. There are several JXTA based projects like the “network services” which are aiming at the implementation and integration of additional web services and languages (SOAP, WSDL, UDDI, WSEL, WSML, XMLP). Unfortunately the state of these developments is rather unclear and the platform itself is still evolving. Finally, none of the aforementioned works is currently available, widely elaborated and allows adaptation of the network layer to the necessary extend while being generic enough to be employed in the given context. Thus, we had to come up with a trustworthy that can be immediately deployed in a secured industry environment that dealing with highly sensitive intellectual property. III. THE ANTS PEER-TO-PEER NETWORK FOR WEB SERVICES We present ANTS (Advanced Network Transport Service) as a framework for peer-to-peer-based Web Services based on the integration of a peer-to-peer transport mechanism with a SOAP application server. In our approach, the ANTS transport mechanism itself is a web service hosted on the SOAP server. ANTS can be used to seamlessly integrate tools and interconnect them as Web Services in order to overcome connectivity problems between highly protected Intranets. ANTS provides access to a peer-to-peer network interconnecting nodes in different physical networks using different transport protocols. ANTS includes support for features like routing, relay, polling, tunneling to overcome connectivity problems between these networks like those caused by firewalls and network address translation (NAT). The ANTS service is designed with the goal to allow the reliable and secure transmission of a data packet from one node in the ANTS network to another while dealing transparently with all the hassles involved like the need for routing through immediate nodes or relay. A. Network Model Figure 2 shows the basic network model we will use to reflect the real world problems we identified. In our model, a machine in the network is a Node. A Node supports several Endpoints. Such an Endpoint is the end of a connection in the peer-to-peer network. Endpoints are for peer-to-peer networks what ports are for the Internet Protocol (IP). A real-world network enabling direct communication between the nodes in that network is a Network in our model.1 In our notion, the Internet is a Network among many others, as all Nodes in the Internet are expected to be capable of communicating directly with each other. We aim 1

Note here, that we use the capitalized ‘Network’ when we refer to this model.

between the two nodes is possible. As a Node may have no receiving connector, it is not possible to send data directly to this node. Thus, the node has to actively poll for the data. It is obviously not desirable to poll all potential senders (all nodes in the network). Thus, such a node will use a RelayNode that acts as a surrogate for the sender. That RelayNode should be capable of receiving data directly. However, this is not mandatory, as the RelayNode may itself use another RelayNode to actually retrieve the data for the PickupNode. There exist scenarios where this is the only possible solution although it is not desirable.

at creating an overlay peer-to-peer network that contains Nodes from several different Networks. The communication in a Network takes place using a certain set of protocols. For the Internet, these protocols are derived from the IP. The ability to use these protocols may differ from Node to Node. Thus, each Node is connected to a Network using a Connector. This Connector uses a specific Protocol (i.e., TCP for the Internet) to connect to other network nodes. Furthermore, a Connector may have limitations in receiving and transmitting. A connector connecting a Node behind a firewall to the Internet cannot receive data, as the firewall will block this. Nodes connected to the Internet which apply Network Address Translation (NAT) cannot be addressed from outside, thus they also cannot receive data. These properties are related to the connector in our model as well. Though Connectors which are unable to receive and transmit are useless, we keep them as valid. Multiple Connectors with different properties may exist that connect a Node to a Network. eg is te

-U

r

nr te

-U

r

n

te

-U

r

n

51

eg

3.

Ve

T

51

eg

d

nr

L

re

EA

io

IA

is

51

eg

3.

rs

TR

Ve

d

nr

L

re te

3.

nr

EA

-U

is

51

eg

3.

nr

EA

io

is

51

eg

3.

rs

IA

te

-U

is

TR

Ve

d

eg

51 EA

1

Protocol

r eg

51

n

L

re

EA

io

IA

te

*

nr

3.

1

te

-U

EA

n

*

rs

TR

Ve

d

can T ran sm i t: bo ol e an can Re ce i ve : bo o le an

is

Netw ork

io

L

re

+ +

51

rs

Conne ctor

IA

te

nr

3.

* E ndpoint

+Rel ayNo d e *

-U

EA 1

*

is

51

eg

3.

nr

+Pi cku pNod e *

Ve

is

-U

EA

1

TR

eg

51

Node

B. Routing

Figure 2: Network Model To directly send data between Nodes, these nodes have to have connectors using the same Protocol to in the Same Network. Furthermore, the sending Connector must be capable of transmitting and the receiving Connector must be capable of receiving. Otherwise, no direct connection

Routing in the ANTS network takes place locally on each hop. The router on the corresponding node chooses a directly reachable node and either sends the ANTS message directly to that node or returns a failure. Thus, the actual routing algorithm has to determine only the next hop and not the complete route. To perform that, a graph of the network will be constructed. ANTS searches for the shortest path between the current node and the target node in that graph. The shortest paths to all nodes will be determined using breadth-first-search and cached. To construct the actual routing graph, the ANTS network Nodes (see Figure 2) will be inserted as vertices into the graph. Furthermore, for each combination of Network and Protocol present in the network, a vertex is created. Direct edges between a node vertex and all network/protocol vertices equaling configurations of connectors present on the node are inserted into the graph. For tunneling connectors, it is necessary to create a separate network/protocol vertex corresponding to the individual connector. This yields a directed bipartite graph reflecting the basic network infrastructure.

1

1

51 3. 51 3.

51 3. 51 3. EA 3

3

is is is is is eg eg eg eg eg eg nr nr nr nr nr nr -U -U -U -U -U -U

51 3. EA

51 3. EA

5

Figure 3: Network Configuration Example

EA

51 3.

SOAPHTTP :Protocol

:Connector canTransmit = true canReceive = true

EA

51 3.

EA

Internet :Netw ork

EA

51 3.

:Connector canTransmit = true canReceive = true

EA

n n n io io io r rs rs rs Ve Ve Ve Ve L L L L IA IA IA IA T TR TR TR TR d d d d d re re re re re te te te te te is is is is is eg eg eg eg eg eg nr nr nr nr nr nr -U -U -U -U -U -U 5

C :Node

51 3. EA

TCP :Protocol

:Connector canTransmit = true canReceive = true

EA

:Connector canReceive = false canTransmit = true

B :Node

EA

n n n io io io rs rs r rs Ve Ve Ve Ve L L L L IA IA IA IA T TR TR TR TR d d d d d re re re re re te te te te te is is is is is eg eg eg eg eg eg nr nr nr nr nr nr U U U U U U

+RelayNode

EA

A :Node

The graph construction has to account for the relay mechanism. The edge between a PickupNode and RelayNode has to be distinguished from the other edges, as we should prefer a direct connection over using relay here. For that, we introduce a weight of 2 for these edges, which makes the normal edges having a weight of 1 causing a shorter path. However, since this does not truly reflect the penalty of using relay, a path using relay nodes may be preferred over a slightly longer path using no relay nodes in out scenario, which is a drawback of the current solution. Anyway, as it is necessary to have a certain number of nodes for this scenario, it is not likely to appear in most real life configurations.

Figure 4: Routing Graph for the Example

TR d re te is is eg eg nr nr -U -U 51 51 51 3. 3. 3. A EA EA n n io io rs rs rs Ve Ve L L IA IA TR TR TR

The ANTS Web Service interface contains two core operations and two supplemental operations (see Figure 5).

+ + + +

d re te

C. ANTS Web Service Interface

d re te

As an example, we consider the network configuration shown in Figure 3. Node A can only transmit to the Internet, but cannot be contacted from outside (i.e., because it is behind a firewall). To receive data from outside, the node polls at Node B. This Node B is connected directly to the Internet, just like Node C. All nodes support the TCP protocol on the Internet. Node C additionally supports SOAP/HTTP. The corresponding routing graph is shown in Figure 4. The graph contains a vertex for every Node. Each combination of Network and Protocol used by the Connectors in the example is represented by a Vertex. The edge between a Node vertex and a Network/Protocol vertex exists, provided that a corresponding Connector exists for that Node. The edge is directed, just like the connector. For example, the Connector of Node can only transmit, but not read. Therefore, the corresponding edge is drawn from the Node vertex to the Network/Protocol vertex. Furthermore, Node A uses Node B as RelayNode. By examining the Connectors of both nodes, we find that there exists a match between these connectors as described above, where Node A is the Sender and Node B the receiver. For each of such mappings, an exclusive copy of the Network/Protocol vertex is created and integrated into a directed path from the RelayNode to the PickupNode. In our example, this is the path from B to A over the [Relayed]Internet(TCP) vertex. As already pointed out, this path has an edge weighted 2 to avoid routing over a RelayNode. Finally, it is worth noting that the network graph must only contain complete information about nodes one hop away. Information for other nodes could be simplified.

The doRequestResponse() operation sends an ANTS message (data packet) to the target node (as stated in the message) and returns either the response message from the target node or information about the message being relayed. In the case of a relayed message, the Node that relayed the message is returned. This node can be polled for the result message by using the pickupRelayedResponse() operation by the means of an identifier returned in the ANTS response message. Since response messages to relayed messages have to be sent to the Node that relayed the request message in order to allow pickup by the original request sender, the same sending mechanism is used to transmit responses in this scenario. However, since there is no response from the target Node of these messages expected, as they do in fact receive a response to their request, such messages are marked as OneWay to indicate that no response is expected. Anyway, the client application does not have to deal with this, as that is handled inside ANTS. The getNodes() operation returns a list of available network nodes. This enables client applications to present the use a selection of such nodes (i.e., for display in a connection dialog). Finally, the getInfo() operation returns an XML document describing several properties of the node including hosted services, system configuration and performance data. «interface» ANTS

doRequestResponse(ANTSMessage) : ANTSResponse pickupRelayedResponse(long) : ANTSResponse getNodes() : String[] getInfo() : String

ANTSMessage

+ + + + +

URI: String Origin: String ID: long OneWay: boolean data: byte[]

ANTSResponse

+ + +

ResultCode: long Response: byte[] RelayNode: String

Figure 5: ANTS Web Service Interface D. Internal Architecture Figure 6 shows the architecture of the ANTS service. ANTS consists of a set of subcomponents that provide essential functionality to the service. The TransmissionManager is responsible for transmitting an ANTS message directly to a remote node. This transmission does not involve routing or relay and is the basis for more complicated transmissions involving intermediate nodes and possibly routing and relay. The TransmissionManager is responsible for a set of Connectors. A Connector implements a transport protocol like TCP and is capable of transmitting an ANTS message to the same Connector on a remote ANTS node. Our implementation currently includes Connectors for TCP, HTTP, HTTP/SOAP and email (POP/SMTP). Other

connectors implementing more protocols could be easily integrated. Such a protocol could even be a human carrying the data on a floppy disk from one node to another, which is another potentially interesting scenario when considering the use of mobile devices like cellular phones, PDAs or just USB memory sticks.

Figure 6: ANTS Architecture Among the implemented connectors, the SOAP/HTTP Connector is actually the simplest one. It is using HTTP to send a SOAP message directly to the ANTS web service on the remote node. Since the necessary code comes down to a transparent remote invocation of the remote ANTS service using a machine-generated proxy class representing the remote ANTS interface, the implementation consists just of the direct invocation of the ANTS interface through the transparent proxy code. Besides the simple implementation, there are other interesting advantages when using the connector. Using SOAP enables easy inspection of the transmitted data (i.e., on specialized firewalls at the enterprise border). The use of XML encryption and signature allows protecting the actual payload while providing signed meta information to the firewall for inspection. By using HTTP, possibly on port 80, messages from this connector are even likely to pass common firewalls without configuration changes. This also applies to the HTTP Connector, although the transported data here is the binary ANTS message, which hinders easy inspection of things like the desired destination of the message. However, the major advantage of using the HTTP Connector instead of the SOAP/HTTP Connection is the small size of the transported message as the ANTS message is not wrapped into a SOAP message. Here it is important to recall, that when using SOAP, the ANTS message has to be either base64-encoded, which will result in an 33% increase in size, or included as a binary attachment [15]. Furthermore, less runtime processing is required, because no SOAP message unwrapping is necessary to restore the transported ANTS message. This also holds for the TCPConnector, which is using the most straightforward way of transporting an ANTS message to a remote node by sending it as raw binary data using a TCP connection, which may be blocked by a firewall. However, if TCP connections are possible this connector provides the best performance, which is enhanced by a keep-alive feature for connections that allows the reuse of a single TCP connection to transfer multiple ANTS messages. The POP/SMTP Connector for using email messages to transport the ANTS messages offers worst performance among the implemented connects, but can be

used to establish connections to and between web services even in scenarios, where no TCP or HTTP connections are possible. The SOAP/SMTP binding is intended to provide a similar feature directly, but by using SOAP/SMTP instead of SOAP/ANTS with the POP/SMTP Connector all advanced ANTS capabilities like routing and relay are lost at first hand and have to be provided additionally if needed. Once an ANTS message has to be transmitted directly to the next (intermediate) node, the TransmissionManager retrieves information about this node from the NetworkManager. This information includes a description of the Connectors present at the remote node. This is compared to the locally available connectors to find valid connection options. It is possible and likely to have different connectors that could be used to directly contact a specific remote node. In that case, the TransmissionManager has to choose the most efficient Connector available. This Connector will then be used to contact the remote node. If a Connector fails, the other possible Connectors applied. Currently, the Connectors available on an ANTS node have user customizable priorities that by default prefer TCP over HTTP, HTTP over SOAP/ HTTP and SOAP/ HTTP over email. The NetworkManager keeps a view of the ANTS network as it is currently known to the local ANTS service. This view consists of the network nodes, the sub-networks these nodes are in and the properties of the supported connections to these sub-networks. All this is constructed from a description of the set of available nodes. The view of the ANTS network is used for routing between nodes in the ANTS network. It is important to note, that the network manager is just a passive component. The DiscoveryManager detects changes to the network configuration. It is responsible for updating the NetworkManager according to discovered changes. This allows the flexible employment of multiple different discovery mechanisms. Updates to the ANTS network view stored in the NetworkManager occur on a per-node basis. The node information records are generated by the individual ANTS nodes and contain an original time stamp. Once the DiscoveryManager gathers a node information record, it will pass this record to the NetworkManager. The NetworkManager can then compare the time stamp of the new record with the latest record stored for the respective node to determine whether or not the new record is indeed an updated version of the information already known. Thus, it is not important for the NetworkManager, how the DiscoveryManager implementation gathers this information. This enables us to employ different discovery mechanisms, as long as these are capable of retrieving node information records. Currently, there are two independent discovery mechanisms implemented, that can be employed concurrently or alternatively. The first discovery mechanism is based on selective messages to directly contactable ANTS nodes attempts to gather updated information from these nodes. Only nodes are contacted, where no updated information has been available for a certain period of time, usually a few minutes. These nodes do not only provide updated information about them, but also provide a limited set of recently gathered

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

Discov eryManager

+Router

*

0..1

+T ransmitter

+

transmit(ANT SNodeDescriptor, ANT SMessage) : ANT SResponse

+NodeID

+Connectors

+ + + + Connector

+* transmit(ANTSConnectorDescriptor, ANTSMessage) : ANTSResponse

TCPConnector

E A 3. 51

E A 3. 51

E A 3. 51

E A

HTTPConnector

3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

ANTSEndpointID

Netw orkManager

0..1

+NameManager

SOAPHTTPConnector

E A

Figure 7: ANTS Implementation Overview (UML Class Diagram) 3. 51

E A 3. 51

E A 3. 51

E A 3. 51

E A

E A

getFriendlyName(ANT SNodeID) : String

3. 51

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A

E A

3. 51

RelayManager

relay(ANT SNodeID[], ANTSMessage) : boolean pickupRelayedResponse(long) : ANTSResponse

3. 51

E A

3. 51

E A

3. 51

E A

3. 51

E A

ANTSEndpoint

+* process(byte[]) : byte[] + ANT SEndpoint(ANTSEndpointID) + getID() : ANTSEndpointID

1

-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr n nr nr eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg gi is is is is is is is is is is is is is is is is is is is is st te te te te te te te te te te te te te te te te te te te te er r r r r r r r r r r r r r r r r r re r r ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed

E A

+EndpointID

51

POPSMTPConnector

3. 51

ANTS

E A

doRequestResponse(ANTSMessage) : ANTSResponse pickupRelayedResponse(long) : ANTSResponse getNodes() : String[] getInfo() : String

3. 51

«interface»

E A

NameManager

3. 51

ANTSNode

E A

+Remote + + + + 0..1

3. 51

1 +

0..1

E A

+ +

3. 51

ANTSGUID

E A

-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U nr nr nr nr nr nr nr nr nr nr nr nr nr nr nr n nr nr nr nr nr eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg gi is is is is is is is is is is is is is is is is is is is is st te te te te te te te te te te te te te te te te te te te te er re re re re re re re re re re re re re re re re re re re re ed d d d d d d d d d d d d d d d d d d d TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA L L L L L L L L L L L L L L L L L L L L L V V V V V V V V V V V V V V V V V V V V er er er er er er er er er er er er er er er er er er er er er si si si si si si si si si si si si si si si si si si si si si on on on on on on on on on on on on on on on on on on on on on

E A

1

51

URI: String Protocol: String canT ransmit: boolean canReceive: boolean

3. 51

*

E A

*

3. 51

ANTSGUID

E A

ANTSNodeID

3. 51

1

E A

*

1

3. 51

TransmissionManager

E A

+TunnelEnd

*

3. 51

+Transmitter

0..1

E A

1

+Router

3. 51

0..1

E A

-U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U -U nr nr nr nr nr nr nr n nr nr nr nr nr nr nr nr nr nr nr nr nr eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg eg gi i i i i i i i i i i i i i i i i i i i i st st st st st st st st st st st st st st st st st st st st st er er er er er er er er er er er er er er er er er er er er er ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed ed e ed ed ed ed TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR TR IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA IA L L L L L L L L L L L L L L L L L L L L L V V V V V V V V V V V V V V V V V V V V er er er er er er er er er er er er er er er er er er er er er si si si si si si si si si si si si si si si si si si si si si on on on on on on on on on on on on on on on on on on on on on

51

E A

updated information about other nodes. Thus, node information updates are propagated through the ANTS network over time. The nodes that reside in multiple subnetworks are very important, as they gather und supply information in all these sub-networks. Thus, they propagate this information across sub-network borders. That discovery approach is very convenient for the ad-hoc discovery of small networks, which makes it applicable in many scenarios including those involving mobile devices. However, it does not scale very well for larger networks.

*

The second discovery mechanism is based on hosting complete node lists on a set of centralized ANTS nodes. This scales well, but has the usual limitations of centralized approaches. All ANTS nodes must be able to contact at least one of these centralized nodes. Therefore, each ANTS node keeps a list of these centralized nodes that are updated when the node is connected to the ANTS network. This simple and straightforward approach is very effective and scales well, but depends on the reliability of the centralized nodes. Furthermore, the (intermediate) nodes needed to enable communication between a particular ANTS node and one of the centralized nodes have to keep their configuration (i.e., IP address) between the disconnection and reconnection of the ANTS node, because new nodes joining the network will have stored this information and rely on in to join the network. This is suitable in many scenarios, but it is worth noting that the combined application of both discovery mechanisms in the ANTS networks allows the integration of sub-networks containing very different devices, as those devices can employ discovery mechanisms that fit to their needs. The major requirement here is only, that any such discovery mechanism is capable of retrieving the complete network configuration from a single other network node. The RelayManager is responsible for relaying data that is to be picked up by other ANTS nodes. Furthermore, the RelayManager is an active component that polls a predefined (possibly empty) set of relay nodes for relayed packets targeted to the node hosting the RelayManager. E. Implementation ANTS has been implemented using Sun Java 2 Standard Edition Version 1.4. Figure 7 shows a UML class diagram illustrating major aspects of the implementation. The ANTS Web Service interface is implemented as a

JAVA interface that is exposed by the application server. The ANTSNode class aggregates all components the ANTS service has to rely on (see also Figure 6). Both the RelayManager and the DiscoveryManager are implemented as subclasses of ANTSEndPoint, as both have to receive data. Furthermore, both are active classes. The RelayManager has to periodically poll other ANTS nodes for relayed data. The DiscoveryManager will do active discovery of the network. Unique identifiers are used to form the addresses used when sending an ANTS message. An ANTS Unique Resource Identifier (URI) consists of a unique identifier for the Node and one for the desired Endpoint. When a client calls the ANTS interface doRequestResponse() operation providing an ANTSMessage, this message contains the ANTS URI describing the desired Node and Endpoint. Figure 8 shows the behaviour of the ANTSNode implementation when transmitting the message. The ANTSNode retrieves a Node description from the NetworkManager. This Node description contains information about the connectors available on the remote Node. When the TransmissionManager is invoked, it examines the description for a remote connector capable of receiving from a local connector. That local connector is invoked with a description of the corresponding remote connector. This description contains a protocol-dependant URI (i.e., an IP address and port number or a HTTP URI) that can be used by the connector to contact its remote counterpart and deliver the message. The remote connector delivers the message to the ANTS interface at the remote node for further processing by invoking the doRequestResponse() operation. Thus, several distributed synchronous invocations of the doRequestResponse() operation may be involved until either one of the nodes is the target node of the message, has to relay the message of fails to deliver the message.

:NetworkManager

:Connector

51 3. EA

EA

51 3.

51 3.

NextHop:= getNextHop(Msg.URI.NodeID)

EA

EA

51 3.

51 3.

transmit(NextHop,Msg)

EA

EA

51 3.

51 3.

Remote:= getRemoteConnector(NextHop)

EA

EA

51 3.

51 3.

Response:= transmit(Remote,Msg)

51 3.

51 3.

EA

EA

51 3.

51 3.

EA

EA

Figure 8: doRequestResponse() Behavior

EA

EA

re re re re re re r te te te te te te te is is is is is is is eg eg eg eg eg eg eg nr nr nr nr nr nr nr -U -U -U -U -U -U -U -U

EA

51 3.

n n n n n io io io io io rs rs rs rs rs Ve Ve Ve Ve Ve L L L L L L IA IA IA IA IA IA TR TR TR TR TR TR ed ed ed ed ed ed er er er er er er er st st st st st st st

Response:= doRequestResponse(Msg)

n n n n n io io io io io rs rs rs rs rs Ve Ve Ve Ve Ve L L L L L L IA IA IA IA IA IA TR TR TR TR TR TR d d d d d d re re re re r re re te te te te te te te is is is is is is is eg eg eg eg eg eg eg nr nr nr nr nr nr nr -U -U -U -U -U -U -U -U

EA

Client

:TransmissionManager

51 3.

51 3.

:ANTSNode

IV. ANTS INTEGRATION To enable peer-to-peer-based Web Services using ANTS, it is necessary to provide a SOAP binding definition to transport SOAP messages using ANTS. Furthermore, ANTS has to be integrated with a SOAP server to provide access to the services hosted on that server using ANTS/SOAP messages. While it is possible to create a proxy server that receives ANTS/SOAP messages and accesses a local HTTP server using HTTP/SOAP messages, this is less desirable because of the significant overhead introduced by this solution. Furthermore, the deployment is getting considerably more complicated, as an additional component has to be deployed by the user. We decided to integrate ANTS directly with the SOAP server. As ANTS itself is a Web Service, we have the SOAP server hosting the ANTS service. This ANTS service is capable of directly invoking the SOAP Processor, which is responsible for processing the SOAP messages and invoking the respective Web Service. The transport of SOAP message using ANTS does not require any extensions like the additional header element used for SOAP/HTPP. An ANTS Endpoint is connected (using some clue code) to the SOAP processor and delivers the SOAP message directly to the SOAP processor. The SOAP message itself is delivered as the binary payload of the ANTS message and needs no further preprocessing. Thus, all services hosted by the application server are available using normal SOAP/HTTP as well as using the SOAP/ANTS. On the client side, we provide an implementation of the SOAPConnection interface from the Java SAAJ API. Clients use this interface to access the Web Services through a machine generated service proxy. Thus, the clients can switch directly between SOAP/HTTP and SOAP/ANTS by using the different supplied implementations of the SOAPConnection interface. No further code changes are necessary to enable the clients to use the new peer-to-peer infrastructure to access web services. V. CONCLUSIONS We have presented ANTS as a transparent Advanced Network Transport Service to overcome connectivity problems between highly protected Intranets in distributed collaborative engineering environments. ANTS establishes a peer-to-peer network interconnecting nodes in different physical networks using different transport protocols and supports routing, relay, polling, and tunneling. Through this, ANTS provides a simple but yet powerful communication infrastructure to enable shared workflows and to share resources between globally distributed teams, possibly from different enterprises, while maintaining full security.

Current industrial case studies and trials in well-defined testbeds with selected European system houses and chip manufacturers show promising results with respect to the stability of the implemented software and easy application and flexibility of the provided interfaces. In order to be applicable for such studies, ANTS has been used to interconnect components enabling XML-based tool integration and tool remote invocation component through which workflow automation for distributed tools environments can be easily implemented. VI. ACKNOWLEDGEMENTS The work described herein is partly funded by the IST project E-Colleg (IST-1999-11746). We gratefully acknowledge the fruitful discussions and valuable remarks of our E-Colleg partners. VII. REFERENCES [1] CFI: Tool Encapsulation Specification; Version 1.0.0. CAD Framework Initiative Inc., Austin, USA, 1992. [2] van Engelen, R., Gallivan, K.: The gSOAP Toolkit for Web Services and Peer-to-Peer computing Networks. In Proc. Of the 2nd IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGRID’02), 2002. [3] Kostienko, T., Müller, W., Pawlak, A., Schattkowsky, T.: An Advanced Infrastructure for Collaborative Engineering in Electronic Design Automation, CE’03, Madeira, July, 2003. [4] Maedche, A., Staab, A.: Services on the Move - Towards P2PEnabled Semantic Web Services. Proceedings of the Tenth International Conference on Information Technology and Travel & Tourism, ENTER 2003, Helsinki 2003. [5] Schattkowsky, T., Müller, W.: Distributed Engineering Environment for the Design of Electronic Systems. Challenges in Collaborative Engineering CCE’03, Poznan, Poland, April 2003. [6] Mueller, W., Schattkowsky, T., Eikerling, H.-J., Wegner, J.: Dynamic Tool Intergration in Heterogeneous Computer Networks. In Proc.Design Automation and Test in Europe DATE 2003, Munich, Germany, March 2003. [7] Mind Electric, http://www.themindelectric.com, 2003. [8] Object Management Group, The: UML Specification, Version 1.4. http://www.omg.org/technology/documents/modeling_spec_catalog.h tm#UML, 2001. [9] Peermetrics: Technical Overview. http://www.peermetrics.com/peer_system0.8/docs/guide/technical_overview.html, 2003. [10] Redfoot, http://redfoot.sourceforge.net, 2003. [11] Schefstroem, D.; van den Broek, G.: Tool Integration. Wiley Series in Software Based Systems, John Wiley & Sons, 1993. [12] Schlosser, M., Sintek, M., Decker, S., Nejdl, W.: A Scalable and Ontology-Based P2P Infrastructure for Semantic Web Services, In Proceedings of the Second IEEE International Conference on Peer-toPeer Computing (P2P2002), 2002. [13] Sun Microsystems Inc.: JXTA – Network Services Project htttp://networkservices.jxta.org, 2003. [14] Thronicke, W.; Fox, W.; et al.: From Tool Integration to Workflow Management - A Lean Integration Solution. In Proc. 2nd World Conference on Integrated Design and Process Technology, Austin, TX, Dec. 1996 [15] W3C: SOAP Version 1.2 Attachment Feature. http://www.w3.org/TR/2002/WD-soap12-af-20020924/. 2002. [16] W3C: SOAP Version 1.2 Part 0: Primer. http://www.w3c.org/TR/2003/PR-soap12-part0-20030507/, 2003.