JXTA Framework

JXTA is to create a framework by providing capabilities that most peer-to-peer applications require. Moreover JXTA is simple application that relies on JXTA platform and when application starts, it becomes a peer in the network. After that, it can be used to discover other peers and can communicate with each other while publishing own services among the peers in the network. When increasing the number of peers in the network it becomes more complex to manage an individual peer. To avoid this problem, it addresses the grouping concept where multiple peers could collectively fit in to a group and that group members are facilitated to add new members into the network, deleting members, finding members and communicate with each other in the network. JXTA specifications provide security, authentication, access control and pipe connection services and infrastructures also to form and manage peers as well as collection of groups for peer-to-peer networks.


JXTA Messaging

After created the JXTA based network and peers are put together to communicate each other, then it does the communication among the peers via pipes. When communicating among peers the messages are sent into a pipe and all peers endpoints that are listening to that pipe. The pipe binding protocol controls how peers are connected and disconnected to a pipe at runtime. Not all messages needs to be broadcast and JXTA recognizes that. It also offers a point-to-point pipe where oneway communication occurs between two peers. In the JXTA model, a message is an object which is sent among peers.

JXTA depends greatly on XML to accomplish its goals which are messaging services that are exchanged among the peers in the peer-to-peer network are in XML format, which makes JXTA platform independent. And based on XML those peers, pipes and services are represented through the advertisements. Each advertisement describes peer information such as name, peer id, properties and services. The main advertisement categories are in JXTA peer, peer group, pipe, service, content, endpoint and user-defined advertisements.

WS-AtomicTransaction


Mainly, WS-Transaction is defined how web services coordinate their activities each other and having the underlying database operations. Under the WS-Transaction,it defines two transactions models over the web services. Those are atomic transactions and business activity transactions. An Atomic transaction of web services is considered as short-lived an activity which is executed within a short duration time. And WS-AtomicTransactions are made up of services that all enforce to a common outcome[Web Services Transactions Specifications].

In this case, an atomic transaction follows ACID properties and either commit or abort entire transaction which is all or nothing property. Likewise, there is a coordinator to coordinate the transactions and has responsibility to give instructions to participants either commit or abort the transaction. This process is known as two-phase commit. Normally, the two-phase commit protocol is a coordination protocol and that defines how multiple participants to reach on the final outcome of WS-AtomicTransaction. As well as, each participant locks the transaction that is involved to prevent any changes being made to the data while the transaction is being processing. This is because ACID implies resources must be locked until the transaction terminated by each other participants, so that it preserves isolation and consistency of each transaction.

WS-BusinessActivity

There is another transaction activity called WS-BusinessActivity. Normally, business activity is a long running business transaction that consumes many resources over a long duration. And there may be a significant number of atomic transactions involved. Therefore, this may be violating ACID properties since it is not suitable to lock the resources by each participant while the transaction is being processing for a long time. WS-Coordination protocols provide the specification to handle the distributed web transactions[Web Services Transactions Specifications].

Query Dissemination and Routing

This process will start after the query optimization phase. It means the optimized queries must be propagated throughout the network. So this can be started from the root node of the network with a broadcast of the query. In this case, the query must notice to each sensor in the network based on the query applied method. If the query applies locally then it must be broadcast to its child nodes also in the network routing tree. This is because in Aquisitional query processing technique it is important to identify the path of query where to be disseminated. According to this concern, it will help to reduce the costs of queries incorrect initiating in Acquisitional query processing environments such as in TinyDB application.

When doing query dissemination process in the network that there are two important concerns should be taken into account. Those are, if a query does not affect at an exacting node, and the node that is query applied doesn’t have any child nodes, then there can be removed the whole sub tree from that query. In doing so, it is much more conserve battery power of the sensor nodes reducing the costs of query dissemination, executing and results forwarding across the network. As well as, it will concern about nodes of the network with extending the life time of them. In this case, the process is to determine the node that need not participate in a particular query is a difficult task. But there are two situations have been considered to be taken into account to make this task in better way.

One usual situation is having constant valued attributes with a selection predicate that is nodeid or location. It shows that those nodes do not need participate for the query. Likewise, if a node knows that none of its child nodes will ever satisfy the value of some selection predicates then it does not also need to forward the query to its sub tree. It seems to be an energy efficient way in query dissemination process this is because, before a particular query disseminates it searches the query path that should be queried upon conditions earlier mentioned. In this way, making the routing information of the network in a better way and that will benefit for sensors to extend their lifetime much more.

Semantic Routing Tree

The primary goal in here is to determine whether it needs to participate or not below child nodes in a given query over some constant attribute value. In generally says, an SRT is a distributed index to locate relevant nodes in the network. Usually, each node stores value interval of itself and its children also in the network. Therefore this will help for SRT to determine a particular node that is needed to participate or not in a given query. In this mechanism, it may be important task when making the selection for the parent node to implement the SRT routing tree algorithm. Traditionally, when doing the routing tree algorithm construction is done by having nodes pick a parent with the most reliable connection to the root in sensor networks. But in this case it is differ with respect to the SRT. Therefore, in making the selection the parent in an SRT is considered such that several parents of comparable link quality. This process is known as link-quality-based parent selection algorithm in the SRT. It will give more details about link-quality-based algorithm on [Woo A. and Culler D. July 2001].

In this case, theoretically the SRT can take as an index over constant attribute value of a sensor node. That is used to locate nodes that have relevant data with respect to the query. The important thing is in here that the SRT is an overlay on the network. This is because SRT keeps all indices of sensor nodes with regard to the constant attribute value. As well as each node in the network maintains a single one-dimensional interval showing the range with regard to the constant attribute values underneath every child nodes of the network tree. Usually, this will help to make efficient routing process throughout the network before particular query dissemination. The query processing task is proceeding in the network such that when a query q (as an example) with a predicate value say A (as an example) arrives at node n (as an example), then node n check whether if any child’s node attribute value of A overlaps the range of A attribute value in query q. If this happens, it receives result and forwards the query and also if it is not happened the query is not forwarded. As well as, if the query applies locally then node n begins to execute the query itself [Madden et al., 2003].