Information Technology Reference
In-Depth Information
In this chapter we validate these claims by:
• Evaluating protocol extendibility by providing a case study of the addition
of a publish/subscribe event-driven protocol to RemoteJ.
• Comparing the development of a number of simple distributed applications,
developed using the RMI, REST and JMS protocols, with the RemoteJ ap-
proach. We compare this in terms of reusability, testability and lines of code.
• Evaluating RemoteJ's recovery approach in terms of extendibility, flexibility
and the ability to add the recovery concern to existing applications.
6.2 Adding a Protocol - a Case Study
All three of RemoteJ's protocols described thus far use the request/response syn-
chronous model where a message is sent and the system suspends awaiting a re-
sponse, a model that is used by most RPC type distributed systems. While this
may be adequate and suitable for many scenarios, there is a class of application
that is more suited to the asynchronous event-driven model, as described in Sec-
tion 2.6.1.
To fully evaluate RemoteJ and to support our claim that the DDL can easily
be extended to support additional protocols by the implementation of protocol
plugins without changes needing to be made to the RemoteJ parser, we extended
RemoteJ by adding an asynchronous event-driven protocol based on the JMS
publish/subscribe model.
An additional motivation for the choice of an asynchronous event-driven pro-
tocol was to evaluate if the DDL concept could support both the synchronous and
asynchronous models.
6.2.1
The Event-Driven Model
As described in Section 2.6.2, publish/subscribe systems provide a loosely-coupled
interaction style where publishers publish events and subscribers subscribe to those
events and are subsequently asynchronously notified when an event occurs. Pub-
lish/subscribe systems therefore implement a loosely-coupled event-driven style of
communication [78].
For our evaluation we implemented an event-driven system based on JMS
topics as the JMS API [47] provides an asynchronous event-driven topic abstrac-
tion.
In contrast to the request/response synchronous model as exemplified by our
RMI, REST and JMS implementations, our event-driven implementation defines
two protocols, pub for the publish protocol and sub for the subscriber protocol.
The reason for this is that publish/subscribe systems are asynchronous and loosely-
coupled and therefore there is no notion of a client and a server as there is for
RPC type systems. Rather publishers and subscribers are distinct entities that
Search WWH ::




Custom Search