|
 | |
Jumpi is a simple low level, generic, protocol agnostic and extensible message passing communications API written in Java. The scope of the Jumpi project is a Jumpi API, and a reference implementation. The Jumpi API is the interface visible to client application code. Jumpi API is MIDP1.0, JDK1.1 and PersonalJava1.0 compatible. The reference implementation provides the Jumpi API to client applications and defines a Service Provider API for component based plug-ins. The reference implementation is continuously being extended within this project. Support for different communications protocols and quality of service mechanisms can be achieved by writing plug-ins. The following protocols and quality of service mechanisms are currently supported.
| Protocol | Description |
|---|---|
| UDP | Standard unreliable, unordered, limited-sized packet based Internet Protocol. Jumpi currently supports unicast communications, not multicast groups, and does not support fragmentation/defragmentation of larger messages ( yet ). |
| TCP | Standard unicast, reliable, ordered, unlimited-sized stream based Internet Protocol. |
| JMS | Standard point-to-point or publish-subscribe Messaging. Reliable, ordered, once-only guaranteed delivery. Jumpi supports synchronous send-receive and request-reply messaging for both domains. Jumpi bundles the Open-Source Somnifugi-JMS provider for in-memory JMS messaging. |
| Sending of email messages via SMTP and receiving of email messages via POP3 or IMAP. Jumpi supports multipart MimeMessages. | |
| MPI | Standard reliable, ordered, unlimited-sized message passing interface, implemented by numerous non-commercial organizations and commercial vendors. MPI is a low latency message passing standard for high performance computing. Jumpi uses mpijava which uses JNI to wrap a native MPI implementation. MpiJava supports Solaris using MPICH or SunHPC-MPI, Linux using MPICH, and Windows NT and 2000 using MPICH tested with MPICH Jumpi currently supports single group, point-to-point, not generalized group communications. |
| HTTP for Midlets | Jumpi provides synchronous message sending and receiving via MIDP1.0 HttpConnections. A Servlet is provided which bridges between HTTP and JMS. This can be used to provide arbitrary backend functionality to MIDP1.0 Midlets. |
Jumpi is intended to combat the complexity which programmers face currently due to the plethora of similar but different communication API's, protocols, and third-party communications products. Jumpi can bring together various technologies under one hat, transparently, reducing the learning curve for each technology. Jumpi is ultimately 'object-oriented' by encapsulating the lowest common denominator functionality needed to communicate between separate entities. The conceptual simplicity of MPI as a message passing paradigm was taken directly into Jumpi. Like MPI, Jumpi does not feature any explicit connections, and as a consequence, does not bother the application layer with the complexities of connection management. Although Jumpi borrows many ideas from MPI, is not a (crazy) attempt to position Java in the High Performance Computing space. Unix's file descriptor functionality, where file descriptors are used to encapsulate file, socket, named-pipe, pipe, shared memory and other operations was also a source of inspiration.
Jumpi is a complementary technology to JMS and RMI. In particular, JMS targets Enterprise computing specifically through the support for transactions. Jumpi does not inherently support transactions, which are at a higher abstraction level. Jumpi on the otherhand can be used in Mobile environments and would be better for integrating non transactional heterogeneous systems, like SMS Centers, FTP, SCP, E-mail transfers etc.
Jumpi does not foresee that all communicating parties be Jumpi client applications. Jumpi can be used in cross platform, cross technology, cross language environments. For example, a Jumpi client application could use standard HTTP to get content from a web server which is not a Jumpi client application. Since data representation 'over the wire' is implementation dependent, there is nothing preventing a C# client application communicating with a Java Jumpi client. The Jumpi reference implementation may eventually be ported to other platforms.
Jumpi project is 100% dedicated to quality - better than production quality ( because I've seen production quality and wasn't impressed ). Any contributions, bugs found, or improvement ideas are welcome!
A Jumpi client application uses the Jumpi API to perform message passing regardless of underlying protocols and networks. Jumpi API provides a means of addressing communicating parties using Destinations. Messages are sent to and received from Destinations. Connection management is fully handled by the API implementation, substantially reducing client application complexity. Messages are represented in Jumpi by the java.lang.Object. Jumpi does not prescribe message formats, these are implementation dependent.
Jumpi provides a send method. The client application is given a Handle which allows the application to be notified when an asynchronous sending operation has completed, to inquire the status, or cancel the operation before completion.
Jumpi provides a receive method. The client application is given an Handle which allows the application to be notified when an asynchronous receiving operation has received a message, to inquire the status, or cancel the operation before reception has completed. Jumpi does not provide a callback mechanism for message reception, like JMS's onMessage().
Additional information, which is implementation specific, can be provided by a Jumpi client application to the implementation via send and receive properties. This is API's extensibility mechanism. For example credentials can be passed to a send, receive or getDestination operation in order to provide information for the establishment of a secure connection.
Jumpi provides additional synchronization support for groups of Handles through the Selector. Polling to check for operation completion is not necessary in Jumpi. Whether the sending or receiving operation is synchronous or asynchronous is implementation dependent. The intention is that the operations should be implemented asynchronously so that they do not block the caller under normal conditions. Furthermore all synchronous primitives can always be emulated by using asynchronous primitives with a little extra synchronization.
The Jumpi Service Provider Interface provides a Component based extensible framework to provide various quality of service and transport layer adapters whilst keeping the same simple client side Jumpi API. The Jumpi SPI architecture is shown below:
 |
The Jumpi implementation provides Controllers and Connectors with runtime services required for efficient, timely functioning. A Timer provides any Component with an timer based interrupt service. A ThreadFactory provides a factory for Threads for any component which needs Threads. Typically Threads are only required by the TaskScheduler for long running Tasks. Components which require processing can schedule Tasks to be run by the TaskScheduler. For example cleanup tasks or processing queued send or receive operations. The TaskScheduler maintains a thread pool which can grow and shrink within configurable bounds, maintaining a good compromise between resource usage and latency. A SequenceGenerator provides any Components with unique sequence numbers. Tasks require unique names, and these can be provided by the SequenceGenerator. A Logger interface is availible through a Jumpi instance so that each Component can log messages in a standard way. It is possible to plug-in Logger implementations for any external logging framework, so Jumpi can seemlessly fit into the client application's logging scheme.
| |
|
|
2003.12.29
|