Jdk11 Examples Jdk14 Examples Midp10 Examples

tcp-producer-consumer jms-producer-consumer http-requestor

tcp-requestor-replyer jms-requestor-replyer

tcp-requestor-slowserver email-sender

udp-producer-consumer email-receiver

mpi-producer-consumer

Jdk11 Examples	Jdk14 Examples	Midp10 Examples
tcp-producer-consumer	jms-producer-consumer	http-requestor
tcp-requestor-replyer	jms-requestor-replyer
tcp-requestor-slowserver	email-sender
udp-producer-consumer	email-receiver
mpi-producer-consumer

Jdk11 Examples

Several examples are provided which are run within a single VM using an ExampleRunner . The ExampleRunner starts one or more Jumpi client applications which run in their own JumpiClientApplicationRunner . The JumpiClientApplicationRunner is an independent Thread which bootstraps a Jumpi instance with the configuration required by it's JumpiClientApplication . The ExampleRunner requires a single parameter which determines which example to run. The ExampleRunner can be started with the ExampleLauncher.bat script for Windows, or the corresponding shell script for Unix. The MpiLauncher.bat Is a launcher script for the MPI examples running MPICH's MPIRun.

tcp-producer-consumer

Overview Demonstrates the most simple asynchronous, reliable sending and receiving mechanism. A single Producer and a single Consumer client are started. The OrderingController and TcpConnector are used by both clients. The OrderingController allows a client to perform any number of asynchronous send or receive operations, which will be ordered and performed one at a time per Destination at the TcpConnector. Both clients' TcpConnector is configured to serialize and deserialize messages being sent and received.

Client Description

Producer Sends a single message reliably to the Consumer. The Producer has apriori knowledge of the Destination of the Consumer.

Consumer Receives a single message from the Producer. The Consumer has no apriori knowledge of the Producer's Destination.

Overview	Demonstrates the most simple asynchronous, reliable sending and receiving mechanism. A single Producer and a single Consumer client are started. The OrderingController and TcpConnector are used by both clients. The OrderingController allows a client to perform any number of asynchronous send or receive operations, which will be ordered and performed one at a time per Destination at the TcpConnector. Both clients' TcpConnector is configured to serialize and deserialize messages being sent and received.
Client	Description
Producer	Sends a single message reliably to the Consumer. The Producer has apriori knowledge of the Destination of the Consumer.
Consumer	Receives a single message from the Producer. The Consumer has no apriori knowledge of the Producer's Destination.

tcp-requestor-replyer

Overview Demonstrates a simple synchronous, reliable, request, reply mechanism using Jumpi's asynchronous send and receive operations. A single Requestor and a single Replyer client are started. The OrderingController and TcpConnector are used by both clients, providing ordered, reliable messaging guarrantees over TCP. Both clients' TcpConnector is configured to serialize and deserialize messages being sent and received.

Client Description

Requestor The Requestor sends messages to the Replyer and waits for a response to each message sent. The Requestor has apriori knowledge of the Replyer's Destination.

Replyer The Replyer receives messages from a single Requestor and sends a response back to it for each message received. The Replyer has no apriori knowledge of the Requestor's Destination. The Replyer can manage only one Requestor at a time.

Overview	Demonstrates a simple synchronous, reliable, request, reply mechanism using Jumpi's asynchronous send and receive operations. A single Requestor and a single Replyer client are started. The OrderingController and TcpConnector are used by both clients, providing ordered, reliable messaging guarrantees over TCP. Both clients' TcpConnector is configured to serialize and deserialize messages being sent and received.
Client	Description
Requestor	The Requestor sends messages to the Replyer and waits for a response to each message sent. The Requestor has apriori knowledge of the Replyer's Destination.
Replyer	The Replyer receives messages from a single Requestor and sends a response back to it for each message received. The Replyer has no apriori knowledge of the Requestor's Destination. The Replyer can manage only one Requestor at a time.

tcp-requestor-slowserver

Overview Demonstrates a more generalized, reliable, Requestor, Replyer scenario more commonly known as Client-Server model, where the Server can manage an arbitrary number of Requestors concurrently. Naturally resource issues limit the number of effectively handled Requestors. The TcpConnector's default connection limits are used for this example. Four Requestor clients and a SlowServer are started. The Selector functionality is illustrated, allowing the SlowServer to manage all Requestors with a single Thread in an overlapping fashion.

Client Description

Requestor1..N The Requestors send messages to the SlowServer and waits for a response to each message sent. The Requestors have apriori knowledge of the SlowServer's Destination.

SlowServer The SlowServer receives messages from any number of Requestors, processes the messages and sends replies back. The SlowServer is single-threaded and requires 1s to process each message. Since the Requestors are sending 2msg/s each, the SlowServer becomes unreliable when the flowcontroltimeout configured is < 1s*Num Requestors.

Overview	Demonstrates a more generalized, reliable, Requestor, Replyer scenario more commonly known as Client-Server model, where the Server can manage an arbitrary number of Requestors concurrently. Naturally resource issues limit the number of effectively handled Requestors. The TcpConnector's default connection limits are used for this example. Four Requestor clients and a SlowServer are started. The Selector functionality is illustrated, allowing the SlowServer to manage all Requestors with a single Thread in an overlapping fashion.
Client	Description
Requestor1..N	The Requestors send messages to the SlowServer and waits for a response to each message sent. The Requestors have apriori knowledge of the SlowServer's Destination.
SlowServer	The SlowServer receives messages from any number of Requestors, processes the messages and sends replies back. The SlowServer is single-threaded and requires 1s to process each message. Since the Requestors are sending 2msg/s each, the SlowServer becomes unreliable when the flowcontroltimeout configured is < 1s*Num Requestors.

udp-producer-consumer

Overview Demonstrates the most simple, unreliable, asynchronous sending and receiving mechanism. A single Producer and a single Consumer client are started. The OrderingController and UdpConnector are used by both clients. The OrderingController allows a client to perform any number of asynchronous send or receive operations, which will be ordered and performed one at a time per Destination at the UdpConnector. Both clients' UdpConnector is configured to serialize and deserialize messages being sent and received. The clients must make sure the size of the message sent does not exceed UDP limits which can additionally be enforced by UdpConnector configuration. Producer and Consumer are configured to establish their UdpConnector's on separate local ports.

Client Description

Producer Sends a single message unreliably to the Consumer. The Producer has apriori knowledge of the Destination of the Consumer.

Consumer Receives a single message from the Producer. The Consumer has no apriori knowledge of the Producer's Destination.

Overview	Demonstrates the most simple, unreliable, asynchronous sending and receiving mechanism. A single Producer and a single Consumer client are started. The OrderingController and UdpConnector are used by both clients. The OrderingController allows a client to perform any number of asynchronous send or receive operations, which will be ordered and performed one at a time per Destination at the UdpConnector. Both clients' UdpConnector is configured to serialize and deserialize messages being sent and received. The clients must make sure the size of the message sent does not exceed UDP limits which can additionally be enforced by UdpConnector configuration. Producer and Consumer are configured to establish their UdpConnector's on separate local ports.
Client	Description
Producer	Sends a single message unreliably to the Consumer. The Producer has apriori knowledge of the Destination of the Consumer.
Consumer	Receives a single message from the Producer. The Consumer has no apriori knowledge of the Producer's Destination.

mpi-producer-consumer

Overview Processor[0] acts as a message producer and sends 10 messages to each of the other Processors which are in the COMM_WORLD Group. The Processor[1..N] each receive 10 messages. The number of Processors in the Group is determined by the MPI runtime environment. The MpiConnector performs synchronous send and receive operations, driven by the calling Thread. The StatelessController maps client send and receive calls directly to the Connector layer without any additional synchronization or delay. Therefore Thread context switches are not required and minimize operation latency. MpiConnector uses standard serialization and deserialization for the messages sent and received. The default fixed maximum data sizes of 8Kb are used.

Client Description

ProducerConsumer Processor[0] acts as Producer of messages. Processor[1..N] act as Consumer.

Overview	Processor[0] acts as a message producer and sends 10 messages to each of the other Processors which are in the COMM_WORLD Group. The Processor[1..N] each receive 10 messages. The number of Processors in the Group is determined by the MPI runtime environment. The MpiConnector performs synchronous send and receive operations, driven by the calling Thread. The StatelessController maps client send and receive calls directly to the Connector layer without any additional synchronization or delay. Therefore Thread context switches are not required and minimize operation latency. MpiConnector uses standard serialization and deserialization for the messages sent and received. The default fixed maximum data sizes of 8Kb are used.
Client	Description
ProducerConsumer	Processor[0] acts as Producer of messages. Processor[1..N] act as Consumer.

Jdk14 Examples

jms-producer-consumer

Overview Demonstrates the most simple synchronous sending and receiving mechanism over JMS. A single Producer and a single Consumer client are started. The StatelessController and JmsConnector are used by both clients. The StatelessController passes send and receive operations down to the JmsConnector without any synchronization. The JmsConnector is configured to use the Somnifugi-JMS implementation which is an in-memory JMS provider. Hence it is not necessary to configure or setup an external JMS. Other third-party JMS providers could also be used by changing the JmsConnector's JNDI configuration.

Client Description

Producer Sends a single JMS ObjectMessage to a JMS Queue. The Producer must perform the send with a Serializable message. The send returns synchronously either with success or failure, it is the JMS Provider which is then responsible for the reliable, guarranteed delivery of the message to any QueueReceivers.

Consumer Receives a single JMS ObjectMessage from the JMS Queue. The Consumer does not specify a receive timeout, so if there are no messages in the Queue, then it will block indefinitely.

Overview	Demonstrates the most simple synchronous sending and receiving mechanism over JMS. A single Producer and a single Consumer client are started. The StatelessController and JmsConnector are used by both clients. The StatelessController passes send and receive operations down to the JmsConnector without any synchronization. The JmsConnector is configured to use the Somnifugi-JMS implementation which is an in-memory JMS provider. Hence it is not necessary to configure or setup an external JMS. Other third-party JMS providers could also be used by changing the JmsConnector's JNDI configuration.
Client	Description
Producer	Sends a single JMS ObjectMessage to a JMS Queue. The Producer must perform the send with a Serializable message. The send returns synchronously either with success or failure, it is the JMS Provider which is then responsible for the reliable, guarranteed delivery of the message to any QueueReceivers.
Consumer	Receives a single JMS ObjectMessage from the JMS Queue. The Consumer does not specify a receive timeout, so if there are no messages in the Queue, then it will block indefinitely.

jms-requestor-replyer

Overview Demonstrates synchronous requesting and replying mechanism over JMS. Multiple Requestors and a single Replyer client are started. The StatelessController and JmsConnector are used by both clients. The StatelessController passes send and receive operations down to the JmsConnector without any synchronization. The JmsConnector is configured to use the Somnifugi-JMS implementation which is an in-memory JMS provider. Hence it is not necessary to configure or setup an external JMS. Other third-party JMS providers could also be used by changing the JmsConnector's JNDI configuration.

Client Description

Requestor The Requestor sends messages to the Replyer and waits for a response to each message sent. The Requestor has sends the message to the JMS Destination that the Replyer receives from. The Requestor indicates on sending that it expects a response for the request. The JmsConnector automatically creates a temporary JMS Destination and sets the JMSReplyTo property of the JMS Message accordingly. The Requestor also provides a correlation id which can be used to uniquely identify the response to the request. The correlation id is required to find the correct response since the temporary reply Destination is used for all replies to requests sent on the Destination. The sending uses the JMS MessageProducer's default delivery mode and priority. The Requestor receives the response indicating a maximum timeout to wait for the message.

Replyer The Replyer receives messages from any number of Requestors and sends a response back to the Requestor for each message received. The Replyer sends the reply message back to the sender. This is a temporary JMS Destination of the Requestor, when the Requestor requested a reply. The Replyer must preserve any correlation id from the request and put it on the response so that the Requestor can tell which response belongs to the request. The reply is sent using the JMS MessageProducer's default delivery mode and priority.

Overview	Demonstrates synchronous requesting and replying mechanism over JMS. Multiple Requestors and a single Replyer client are started. The StatelessController and JmsConnector are used by both clients. The StatelessController passes send and receive operations down to the JmsConnector without any synchronization. The JmsConnector is configured to use the Somnifugi-JMS implementation which is an in-memory JMS provider. Hence it is not necessary to configure or setup an external JMS. Other third-party JMS providers could also be used by changing the JmsConnector's JNDI configuration.
Client	Description
Requestor	The Requestor sends messages to the Replyer and waits for a response to each message sent. The Requestor has sends the message to the JMS Destination that the Replyer receives from. The Requestor indicates on sending that it expects a response for the request. The JmsConnector automatically creates a temporary JMS Destination and sets the JMSReplyTo property of the JMS Message accordingly. The Requestor also provides a correlation id which can be used to uniquely identify the response to the request. The correlation id is required to find the correct response since the temporary reply Destination is used for all replies to requests sent on the Destination. The sending uses the JMS MessageProducer's default delivery mode and priority. The Requestor receives the response indicating a maximum timeout to wait for the message.
Replyer	The Replyer receives messages from any number of Requestors and sends a response back to the Requestor for each message received. The Replyer sends the reply message back to the sender. This is a temporary JMS Destination of the Requestor, when the Requestor requested a reply. The Replyer must preserve any correlation id from the request and put it on the response so that the Requestor can tell which response belongs to the request. The reply is sent using the JMS MessageProducer's default delivery mode and priority.

email-sender

Overview Demonstrates sending of email messages.

Client Description

EmailSender Sends two email messages via SMTP to the same email recipient. The first send method requires no explicit references to javax.mail classes. It supports a simple text message with optional subject. The second send variant uses the javax.mail.MimeMessage and therefore more complex emails, with multiparts and multiple recipients etc. Sending and receiving can be performed in the same client if the receiving email account information is configured ( See below ).

Overview	Demonstrates sending of email messages.
Client	Description
EmailSender	Sends two email messages via SMTP to the same email recipient. The first send method requires no explicit references to javax.mail classes. It supports a simple text message with optional subject. The second send variant uses the javax.mail.MimeMessage and therefore more complex emails, with multiparts and multiple recipients etc. Sending and receiving can be performed in the same client if the receiving email account information is configured ( See below ).

email-receiver

Overview Demonstrates receiving of email messages.

Client Description

EmailReceiver Receives two email messages via POP3. Tip, use after the EmailSender example, which sends 2 mails, which can be received with this example. The MimeMessages received from an email account are displayed, assuming they are simply text messages. The EmailConnector logs into the email account and provides the client application with mails, so the client does not have to worry about account management. Note, you will need to change the configuration to point to a different POP3 or IMAP account, and give working login credentials. Compile the example sources before this will work properly.

Overview	Demonstrates receiving of email messages.
Client	Description
EmailReceiver	Receives two email messages via POP3. Tip, use after the EmailSender example, which sends 2 mails, which can be received with this example. The MimeMessages received from an email account are displayed, assuming they are simply text messages. The EmailConnector logs into the email account and provides the client application with mails, so the client does not have to worry about account management. Note, you will need to change the configuration to point to a different POP3 or IMAP account, and give working login credentials. Compile the example sources before this will work properly.

Midp10 Examples

The Midp10 examples are provided pre-packaged in the jumpi-midp10-examples.jad file. You can either load the jad onto a java enabled mobile device, or run it locally on a PC with Wireless Toolkit Emulator .

The Midp10 examples require the JmsHttpBridgeServlet to be running in a Servlet v2.3 compliant engine. For example Tomcat.

http-requestor

Overview Demonstrates synchronous requesting and replying mechanism over HTTP 1.0 for wireless devices. This example requires not only a Midp device or emulator which runs the HTTP client, but also there must be a Servlet or other HTTP server which provides responses to the client. The HttpJmsBridgeServlet provides an Echo application which echoes any request back to the Midlet requestor. The HttpJmsBridgeServlet is packaged in jumpi-jdk14-servlet.war . If Tomcat is configured to manage servlets, then this war file can be installed automatically. The context path used by default by the Midlet below is 'jumpi-jdk14-servlet'. The test HTML page HttpJmsBridgeServlet.html can be used to test the Servlet running. Posting the form to the Servlet using the default values should return a plain text reply with the values sent returned each on a separate line.

Client Description

HttpConnectorMidlet The Requestor sends messages to a Servlet and receives the response synchronously. The request is sent to the Servlet's URL as plain text, where each line represents a new key or new value. The key-value pairs make up a Hashtable of data being transferred between client and server. The Serlvet must provide also plain text requests where each line represents a new key or value of a response Hashtable. The Jumpi HttpConnector client does not handle general HTML responses or parse HTML. The Midlet starts by asking the user to enter the URL of the HttpJmsBridgeServlet. This is likely to be 'http://localhost:8080/jumpi-jdk14-servlet/HttpJmsBridge' if the servlet is configured as described above. Then the user is requested to enter the request key-value pairs. Each key and value is placed on a separate line. Once this is entered, then a HttpConnection is established to the Servlet at the URL provided, and the request is sent to the Servlet. The Midlet blocks until there is a response from the Servlet ( or it is unable to establish the Connection and fails ). The response is presented also as line separated text. The user can continue and the process starts again at the Url entering screen.

HttpJmsBridgeServlet The HttpJmsServletBridge is a Servlet which bridges between HTTP request/replies and synchronous JMS request/replies. The idea is that there does not need to be any 'business-logic' implemented in the Servlet itself, it just dispatches the requests from a HTTP client on to a backend service implemented as a JMS service. The HttpJmsServletBridge is pre-configured to use Somnifugi-JMS which is an in memory JMS service provider. The Servlet also runs any number of JMS services. Pre-configured is simply the Echo Application which receives messages on the JMS Queue 'Echo'. Any request sent from a Midlet to this Queue will cause the request to be echoed unchanged back unchanged. The HTTP request parameter 'jms.queue.name' is used to determine to which JMS queue the request will be forwarded.

Overview	Demonstrates synchronous requesting and replying mechanism over HTTP 1.0 for wireless devices. This example requires not only a Midp device or emulator which runs the HTTP client, but also there must be a Servlet or other HTTP server which provides responses to the client. The HttpJmsBridgeServlet provides an Echo application which echoes any request back to the Midlet requestor. The HttpJmsBridgeServlet is packaged in jumpi-jdk14-servlet.war . If Tomcat is configured to manage servlets, then this war file can be installed automatically. The context path used by default by the Midlet below is 'jumpi-jdk14-servlet'. The test HTML page HttpJmsBridgeServlet.html can be used to test the Servlet running. Posting the form to the Servlet using the default values should return a plain text reply with the values sent returned each on a separate line.
Client	Description
HttpConnectorMidlet	The Requestor sends messages to a Servlet and receives the response synchronously. The request is sent to the Servlet's URL as plain text, where each line represents a new key or new value. The key-value pairs make up a Hashtable of data being transferred between client and server. The Serlvet must provide also plain text requests where each line represents a new key or value of a response Hashtable. The Jumpi HttpConnector client does not handle general HTML responses or parse HTML. The Midlet starts by asking the user to enter the URL of the HttpJmsBridgeServlet. This is likely to be 'http://localhost:8080/jumpi-jdk14-servlet/HttpJmsBridge' if the servlet is configured as described above. Then the user is requested to enter the request key-value pairs. Each key and value is placed on a separate line. Once this is entered, then a HttpConnection is established to the Servlet at the URL provided, and the request is sent to the Servlet. The Midlet blocks until there is a response from the Servlet ( or it is unable to establish the Connection and fails ). The response is presented also as line separated text. The user can continue and the process starts again at the Url entering screen.
HttpJmsBridgeServlet	The HttpJmsServletBridge is a Servlet which bridges between HTTP request/replies and synchronous JMS request/replies. The idea is that there does not need to be any 'business-logic' implemented in the Servlet itself, it just dispatches the requests from a HTTP client on to a backend service implemented as a JMS service. The HttpJmsServletBridge is pre-configured to use Somnifugi-JMS which is an in memory JMS service provider. The Servlet also runs any number of JMS services. Pre-configured is simply the Echo Application which receives messages on the JMS Queue 'Echo'. Any request sent from a Midlet to this Queue will cause the request to be echoed unchanged back unchanged. The HTTP request parameter 'jms.queue.name' is used to determine to which JMS queue the request will be forwarded.

2003.12.29