When this bundle is started it checks to see if an MQeQueueManager is
already running in the JVM, if so it assumes it is running in the same runtime
as the server and so uses that queue manager. If no queue manager is
detected then a new one is defined and started in memory and a connection
definition and remote queue definition are setup to the server. Client
application code is then run in a new thread which sends a single message to
the server. No checks are made to ensure the message is
received. If we created a new QueueManager for the Client, it is
stopped and deleted when the bundle is stopped.
The source for the classes included in the bundles can be seen in the
MQe\Java\examples\osgi directory. More details are given in the java
doc for these classes.
Some points to note when running the applications:
- Each application was written with two parts in mind. The first is
setup of the underlying WebSphere MQ Everyplace messaging infrastructure and
the second is the main application. This is why each one has a separate
class providing function for each part.
- The MQeClientBundle.class and MQeServerBundle.class are both
started in their own threads by the bundle activator start method. This
way the start method is not delayed in completing as the tasks of sending and
receiving messages can take some time. This ensures a smooth transition
of the bundles state from resolved to started.
- Note:
- The Client and Server share the same MQeAdmin class in their bundles.
This class could have been placed in its own bundle to avoid the duplication
but for simplicities sake we have not done this.
- The Server must always be started before any Clients. Each Server
must run in its own runtime. A single client can share the
server's runtime or can reside in its own.
© IBM Corporation 2002. All Rights Reserved