Chapter 19. Server Side

OSGi has been around for over a decade in the embedded and then the desktop environments. Recently its value and use in the server community have practically exploded. All of a sudden all of the major Java application servers are OSGi-based. WebSphere, GlassFish, Spring DM, and NetWeaver are all adopting or using OSGi.

Why is this happening? Server software is often large and complex and composed of many parts from a variety of sources. Desktop tools are similarly complex. Modularity has brought great value to desktop tools in the form of the Eclipse tooling platform. Now those benefits are being sought in the server world.

OSGi can be used under the covers simply as an implementation mechanism to improve flexibility in server offerings, or it can be exposed to the server application developer. Today we see both approaches. In this chapter we focus on the latter—the full use of OSGi in server environments.

Complete coverage of the server-side software topic is well beyond the scope of this book. Instead, in this chapter we build on previous chapters and look in more detail at how OSGi on the server works. In particular we talk about

• Embedding OSGi in existing web applications

• Running the Toast back end in a WAR on an application server

• Building WARs composed of bundles

• Remote Services

To work with the examples here, start with the sample code from Chapter 14, “System Deployment with p2,” and make the changes described in the following sections.

19.1 Servers and OSGi

In Chapter 7, “Client/Server Interaction,” we saw how to set up a simple client and server system using HTTP, servlets, and OSGi. Subsequent chapters added a pluggable web interface and provisioning support to the server. These server setups were based on an HTTP server embedded in an OSGi framework with servlets as the execution model. This was simple and clean but does not suit all use cases. Enterprise applications, for example, require scalability, performance, high-availability characteristics, and integration with existing infrastructure. Other server programming models operate at a level above servlets and are more like distributed systems with inter-object communication. Fortunately, these requirements are not at odds with OSGi.

Broadly speaking, there are three configurations for using OSGi on a server:

Native—One or more OSGi frameworks are run on a server machine. The frameworks interact with one another using remote messaging and mechanisms such as OSGi Remote Services and the Eclipse Communications Framework (ECF), HTTP, web applications, and other conventional server-side technologies.

Solo—One or more OSGi frameworks are run and include HTTP service implementations such as Jetty. As shown in Figure 19-1, server function is exposed as servlets and JSPs and supplied by bundles hooked together by the HTTP service running directly on an OSGi framework. This is the configuration we have been using in Toast.

Figure 19-1 Solo server-side configuration

Bridged—In the Bridged approach, the coding and exposure model is the same as in Solo, but here the OSGi framework is embedded into a web application and run inside a traditional web application server such as Tomcat or WebSphere. This is shown in Figure 19-2.

Figure 19-2 Bridged server-side configuration

In this chapter we focus on the Native and Bridged scenarios for server-side OSGi. First we change the Toast Back End from using the Solo configuration with Jetty running in Equinox to having Equinox and Toast running inside a web application on Tomcat—the Bridged approach. Details of how this infrastructure works are also covered. Finally, we convert Toast to use OSGi Remote Services and the ECF to manage the communication between the client and back end emergency monitor components without the use of HTTP servers—a Native server-side architecture.

19.2 Embedding the Back End in a Web Application

Many organizations have existing Java web application servers such as Tomcat, Jetty, or WebSphere. These systems are typically run by the IT team and serve business-critical or customer-facing applications. They are secure and managed. With good reason, the IT teams are loath to change from this known infrastructure to running an OSGi framework directly on their servers. They have years of experience with application servers and considerable support infrastructure, load balancing, fail-over, and other technology supporting their needs. Fortunately, the Bridged OSGi server-side story is not “rip and replace” but more of a “co-opt” model.

Rather than having Equinox operate as the overall execution container, the Bridged approach has Equinox running inside a standard web application. As with Solo configurations, server function writers craft bundles and contribute their servlets, resources, and JSPs to an HTTP service, either directly or via the Extension Registry. The Bridged configuration differs in the HttpService implementation. Here the HTTP infrastructure is supplied by the web application server in which the OSGi framework is running. That infrastructure is simply bridged into OSGi and surfaced as an HttpService to Toast. Because of the design practices of modularity and separation of concerns that we have followed, Toast doesn’t even notice.

The net effect for the system is that the Toast Back End changes from being a stand-alone OSGi-based application to being a standard web application that happens to be implemented with OSGi inside. The application programming model stays the same—bundles, services, and extensions: OSGi. On disk the system changes from being a launcher and set of bundles in a directory structure to being a standard WAR file. Through careful structuring we can use all the same tooling to produce both structures.

19.2.1 Updating the Product

Since the programming model is the same and the function is the same, the only thing in Toast that needs to be changed is the packaging. The version of Toast from Chapter 14, “System Deployment with p2,” is described using Eclipse product definitions. These detail the bundles, features, and launcher used for the back end and client. To run the back end code in Bridged mode, we need a product definition that includes the Servlet Bridge launcher rather than the conventional launcher.

The Equinox Servlet Bridge is a mechanism for linking the underlying servlet support in a web application server with an OSGi framework running inside a web application. It does this by hooking a set of URLs in the web application URL space and launching an Equinox framework to support the processing of HTTP requests to those URLs. In this way it is both a framework launcher and an HTTP request router. The Servlet Bridge is made up of the following bundles:

org.eclipse.equinox.servletbridge—The bridge itself. While packaged as a bundle, the code in this component is the launcher that instantiates and runs an Equinox framework inside a web application; that is, it runs under the framework rather than in it. It is packaged as a bundle for consistency and to ease workflows.

org.eclipse.equinox.http.servletbridge—This bundle creates and installs an instance of the HttpServiceServlet to act as a servlet delegate within the application server and capture servlet requests.

org.eclipse.equinox.http.servlet—This bundle provides the upper layer of the bridge and defines and registers an HttpService instance. The registered HttpService behaves like any other HTTP service and supports the registration of servlets, resources, and JSPs.

org.eclipse.equinox.servletbridge.extensionbundle—A somewhat magic fragment of the OSGi System Bundle used to export the packages javax.servlet, javax.servlet.http, and javax.servlet.resources as supplied by the underlying application server. The magic comes in that despite being specified and supplied here, the real bundle used at runtime is generated on the fly. We list it here to ensure that all the configuration and dependency information is specified correctly and to smooth workflows.

As of this writing, the bundle needed for the Solo and Bridged configurations is not captured in features shipped by the Equinox project. Let’s make the server infrastructure pluggable by refactoring the back end feature to split out the server bundles. You can load this from the Samples Manager or carry out the following steps:

• Create a feature for the bundles being moved out of the back end. Call it org.equinoxosgi.toast.server.solo.jetty.feature.

• Open the org.equinoxosgi.toast.backend.feature and look for bits related to the server. Remove all of the bundles listed here from the back end feature and add them to the Solo Jetty feature. Save both features.

• Open backend.product. Now that we have factored out the server code, add the Solo Jetty feature to the list of dependencies.

• Save the product and run it to ensure that it still works as before.

As with some of the other refactorings we have done, you are now back where you started, but the base structure is more flexible. The next step is to exploit that and make a WAR-based configuration of the back end:

• Create a feature to capture the Bridged scenario bundles. Call it org.equinoxosgi.toast.server.bridged.feature.

• Add the bundles related to the Servlet Bridge discussed at the beginning of this section and listed here. Notice that we are also including javax.servlet. Technically at runtime this bundle is ignored in favor of the servlet classes coming from the application server. We include it here to satisfy the build tools and help you validate your configuration.

• Copy backend.product to backend-war.product and open the new product file.

• On the Overview page, update the product ID to be org.equinoxosgi.toast.backend.war and uncheck the box beside The product includes native launcher artifacts—the framework will be launched by the application server, so native launchers are not needed.

• Flip over to the Dependencies page and swap the Solo Jetty feature for our new Bridged server feature.

• On the Launching page, clear out the VM Arguments section. In the Bridged scenario the JVM is already up and running. We’ll have to set up the configuration another way.

Now we have to set up the file structure for the web application. The following sections detail the steps required.

19.2.2 The Web Application Root Files

Standard web applications have a particular structure in their artifacts, the WAR files. Figure 19-3 illustrates the layout of a WAR with Equinox inside. This is a conventional structure with a few extra files. Standard are the WEB-INF folder that contains a web.xml file and the lib directory. These are the keys.

Figure 19-3 WAR file structure

The lib directory contains JARs of code that are added to the classpath of the web application as it executes in the application server. The web.xml file is somewhat analogous to the config.ini file in Equinox—it tells the container, the application server, how to install and run the web application.

Here we show the Servlet Bridge base code, servletbridge.jar, in the lib directory, and a web.xml that launches the Servlet Bridge, initializes it, and hooks it into the right spot in the server’s URL space:

• Use the Samples Manager to load the content of the rootfiles folder for the org.equinoxosgi.toast.server.bridged.feature project.

The following text walks you through the root files starting with web.xml:

While this is a standard web.xml file, it is worth relating some of the more interesting XML elements to our scenario.

<servlet>—The id attribute defines the root of the web application.

<servlet-class>—Identifies the BridgeServlet class. This is a servlet that, upon initialization, starts the Equinox framework and ultimately causes an HttpService to be registered.

<init-param>—There can be any number of <init-param> elements. Each defines a key/value pair that is passed into the BridgeServlet. For a complete list of the parameters available, see Section 19.2.6, “<init-param>s.”

<servlet-mapping>—Defines the mapping of the given URL pattern in the web application’s URL space to the servlet handling requests. The first example in the snippet routes all requests to the equinoxbridgeservlet. The second entry is needed to ensure that JSPs are properly routed.

The lib directory holds the Servlet Bridge bootstrap code, a copy of org.eclipse.equinox.servletbridge. This looks and acts like a bundle, but in fact it is run by the application server as standard Java rather than by Equinox as a bundle. It is the code that will ultimately create and start the Equinox framework.

The other file in the rootfiles structure is launch.ini. This is the functional equivalent of the standard eclipse.ini. This file is used to initialize system properties as part of the framework boot process. It is similar to, but takes priority over, the config.ini that is discussed in Section 23.10.2, “The Executable.” In the Servlet Bridge case the file looks like this snippet:

The first three lines are used to clear all existing system properties that match the given pattern. Since we are about to start an Equinox framework nested in an application server, we need to ensure that no Equinox-related property settings leak into the new framework from the external context.

You can also set properties here. The two class-loader-related properties tell the new framework to consult the class loader provided to the web application by the application server when loading system classes. This ensures that classes provided by the application server itself are available to Equinox.

Finally, we have to set up the root files such that the build system copies them to the right spot in the WAR. In Section 20.5.7, “Identifying and Placing Root Files,” we detail the root files mechanism. Here it is enough to know that you need to update the build.properties file as follows:

• Open the build.properties file, switch to the Source page, and update the contents to look like this by adding the root property:

19.2.3 Building the Web Application

The setup for this structure was a little involved, but we were walking you through all the gory details. In practice, once you have the server features in place, they don’t need to be touched. Everything else is done at the product level. To actually create the WAR, you just export the backend-war.product as follows:

• Open backend-war.product and click the export link or button as in the other chapters. This opens the Export Product wizard, as shown in Figure 19-4.

Figure 19-4 Exporting the WAR product

• In the Root Directory field, enter WEB-INF. This tells the export to place all of the generated content in the named folder in the output. This is required for proper structuring of the web application.

• Uncheck the Synchronize before exporting box. We saw this in Section 9.2, “Exporting Toast.”

• Enter toast as the name for the output file in the Archive file field.

• Press Finish to export the WAR. When it is done, rename toast.zip to toast.war and install it in an application server as discussed in the next section.

19.2.4 Running the Web Application

Running the Toast Back End WAR is the same as running any WAR. Here we assume the use of Tomcat, but any web application server could be used.

• Install the WAR into Tomcat by copying toast.war into the webapps directory under the Tomcat install.

Start the web server and test that it is configured correctly by opening a web browser and entering the URL http://localhost:8080. The web server should respond with the Apache Tomcat welcome page containing, among other things, the text

If you do not see the welcome page, the web server is typically not running or is not listening on port 8080. The shell command netstat –anb can be used to list the ports that are in use and by which applications.

Assuming you called the WAR toast.war, accessing the URL http://localhost:8080/toast/sp_test should yield the following response:

Servlet delegate registered -
org.eclipse.equinox.http.servlet.HttpServiceServlet

By default the BridgeServlet provides the following service platform (sp_) commands for controlling the OSGi framework. These commands are executed via a URL, as we’ve just shown.

sp_deploy: Deploy Equinox—This command copies the contents of the web application’s WEB-INF folder to the web application’s install area, as described by the servlet context attribute javax.servlet.context.tempdir.

sp_undeploy: Undeploy Equinox—This command deletes the files that sp_deploy copied to the web application’s install area. Equinox must first be stopped using the command sp_stop.

sp_redeploy: Redeploy Equinox—This command calls sp_stop, sp_undeploy, sp_deploy, and sp_start.

sp_start: Start Equinox—Equinox must first be deployed using the command sp_deploy.

sp_stop: Stop Equinox—Equinox must first have been started using the command sp_start.

sp_test—Test to see if the BridgeServlet is registered and is accepting requests.

Once you are satisfied that the web application is configured correctly, test the Toast Back End by launching the full Toast Client as normal but with the following tweak:

• Add the following to the Launching page’s VM Arguments section in the product editor:

-Dtoast.backend.servlet.container=/toast

This instructs the client that the back end URLs should be prefixed with toast as this is how the application server positions the application in URL space by default. See the sidebar “Disabling sp_ Commands” for information on changing this.

• Once the client is running, click on the emergency button to send an emergency message to the back end.

• Check the Tomcat console and look for the following message confirming that the emergency request was received by the back end:

[INFO] 2008-08-10 23:43:17.274 - EmergencyServlet:
Emergency: ABC123 (38.88746N, -77.02192E) 90deg 50kph

19.2.5 Troubleshooting

In the web.xml we start the OSGi console using the –console command-line argument. This gives you a standard OSGi console and allows you to inspect and control the system as normal. For example, you can use ss at the osgi> prompt to display the installed bundles and their statuses. You can also use diag to investigate any problems with bundle state and the DS console commands described in Chapter 15, “Declarative Services,” to introspect your service components.

If your setup is not working or if any bundles are missing, try the following:

• Open the backend-war.product and click the validate button at the top right. Resolve any issues reported and re-export and reinstall the WAR.

• Look at the exported WAR to ensure that all expected bundles are present.

• Look at the exported config.ini file and ensure that its osgi.bundles list has the expected entries. See Section 23.8.3, “osgi.bundles,” for more details.

• If Simple Configurator is being used, confirm that the right bundles are listed in the WAR’s bundles.info file.

• Check the timestamp and contents of the WAR file in Tomcat’s webapps directory. If needed, delete the back-end-related directories from webapps and the work/Catalina/localhost directory.

19.2.6 <init-param>s

The Servlet Bridge can be controlled using a number of parameters loaded during initialization. These are defined using the standard web.xml <init-param> markup. Here is a list of the most interesting parameters and what they control:

commandline—The command line that is passed into the Equinox framework launched inside the Servlet Bridge. Often the <init-param> is used to specify –console and open the interactive console.

enableFrameworkControls—Enables the sp_ controls for starting, stopping, and deploying the Equinox framework. The value is true or false.

extendedFrameworkExports—The org.eclipse.equinox.servletbridge package and the Servlet API are exported automatically by the Servlet Bridge bundles. The extendedFrameworkExports parameter allows the specification of additional Java package exports. The value is specified as a comma-separated list of exports as specified by the Export-Package bundle manifest header. For example:

com.mycompany.exports; version=1.0.0, com.mycompany.otherexports;
version=1.0.0

frameworkLauncherClass—Specifies the framework launcher class and defaults to org.eclipse.equinox.servletbridge.FrameworkLauncher, the launcher supplied by the Servlet Bridge.

19.3 Remote Services in OSGi

Building systems using HTTP and standard web server infrastructure is certainly powerful and widespread. It is not the only way, however. With the OSGi R4.2 Enterprise Expert Group (EEG) specification release, there is a new facility called Remote Services (RFC 119). An early draft of the RFC characterized the work as follows:

The solution is intended to allow a minimal set of distributed computing functionality to be used by OSGi developers without having to learn additional APIs and concepts. In other words, if developers are familiar with the OSGi programming model then they should be able to use . . . this solution very naturally and straight forwardly to configure a distribution software solution into an OSGi environment.

Put simply, Remote Services extends the normal service discovery and usage model across JVM boundaries.

The code for this section can be found in the Samples Manager as “Chapter 19.3.” It is based on the state of Toast at the end of Section 19.2, “Embedding the Back End in a Web Application.”

19.3.1 The Eclipse Communication Framework

The Eclipse Communication Framework (ECF) project at Eclipse is all about, well, communication. Whether you are looking for social networking protocols such as XMPP, Twitter, Jingle, and the like or core computing infrastructure such as HTTP, file transfer, ActiveMQ, or Remote Services, ECF is the place to go. As part of the Eclipse community, all ECF functionality is shipped as bundles with few, if any, ties to the specifics of Equinox—it should run on any framework that implements the required parts of the OSGi specification.

The core concept in the ECF API is container. A container represents a point to which or from which messages can be sent using a particular protocol. In other contexts these are called endpoints. How messages get from one place to another and what happens to them along the way are all details of the container.

System-level programmers extend ECF by plugging in protocol providers. A provider generally implements or adapts to a particular messaging protocol or implementation such as XMPP, ActiveMQ, or simple TCP messaging. This is the core of ECF’s SPI (System Programmer Interface).

ECF’s job, then, it is to marry and map the API-level requests to send a message to some destination to some underlying network location and message format. This all happens under the covers.

To use ECF, you have to add it to your target as follows:

• Open toast.target and Edit... the “Galileo” repository entry.

• In the resultant dialog, uncheck the Group by Category box and find and select the Eclipse Communication Framework SDK entry.

• Click Finish, Save the target definition, and click Set as Target Platform.

19.3.2 Remote Services

Remote Services is independent of ECF. It turns out, however, that ECF inherently implements almost all that is needed to do Remote Services. Roughly speaking, that is two separate elements: distribution and discovery. The RFC characterizes these as follows:

Distribution—The distribution software is responsible for the actual network communication between a remotely available service and its consumer, including the data format (i.e., serialization) and communication protocol.

Discovery—The Discovery service is an optional service that enables services running in a framework to be published for remote consumers and the discovery of services running outside a framework.

The RFC comprehensively sets the scene for Remote Services use cases and the interactions between frameworks and services. Here we look at using ECF’s Remote Services support to change the way the client and back end interact.

19.3.3 Distributed Toast

Toast became a distributed system in Chapter 7, “Client/Server Interaction,” when we introduced the Toast Client and Toast Back End. Since then client and back end interactions have been based on simple HTTP messages and independent servlets. This has been fine for a system of Toast’s scale. As the number of interacting parties and the complexity of their interactions increase, however, we need a more managed and centralized approach. That is what ECF does for you—all the marshaling, messaging, and management. Adopting ECF then makes sense, but what of distributed services?

Since our initial discussion of Declarative Services, we have found using services to be both easy and natural. Services give us the decoupling we need, and DS deals with many of the complexities around dynamic and unpredictable behavior. Allowing services from a remote framework to show up in a local framework blends these advantages. Let’s change Toast to use ECF and its implementation of the RFC 119 draft specification to do the tracking and emergency reporting communications.

19.3.4 Remote Service Host

In the back end, the tracking and emergency functions are implemented as servlets that process HTTP GET requests containing the relevant information. To switch to Remote Services, we need some services to remote. It turns out that we already have these: IEmergencyCenter and ITrackingCenter. All we need to do is signal that they should be made available to other frameworks.

The ControlCenter component provides both of these services. We need to annotate the component and mark the provided services as remotable:

• Open the component.xml file found in org.equinoxosgi.toast.backend.controlcenter.

• On the Overview page, click Add Property... and fill in the dialog as shown in Figure 19-5. In particular, note that the Values field lists each remote interface on a line by itself. This list should be the same as or a subset of the services provided by the component.

Figure 19-5 Remote interfaces property in DS

That’s all we need to do to the Toast Back End proper to enable remote service calls. To make it run, we do need to add the various ECF support bundles to the back end product. There are a great many combinations of ECF message transports and remote interaction mechanisms. For simplicity we have included a feature that groups together the bundles needed for ECF remote messaging using a generic TCP transport:

• Using the Samples Manager, load the org.equinoxosgi.toast.remoteservices.host.feature project into your workspace.

• Open backend.product and add the new remote services host feature to the list of Dependencies. Do the same on the backend-war.product.

At this point Toast has the remote services markup and the infrastructure. All that is missing is the initialization of the infrastructure. As ECF is very loosely coupled, we just have to create a container and let Toast and ECF find each other. For our purposes, it is easiest to create the container when the control center component is activated—that is the earliest it would be needed anyway.

• Modify the ControlCenter.startup method to add the container creation code as shown in the following snippet. The first argument is the type of container to use, and the second is a set of parameters to the container creation.

Now that IEmergencyCenter and ITrackingCenter are exposed directly as remote services, the servlet exposure of the services is no longer needed. In fact, the bundles hosting these servlets do nothing else, so they, too, can be removed:

• Delete both org.equinoxosgi.toast.backend.emergency and org.equinoxosgi.toast.backend.tracking from the workspace.

• Open the back end feature, org.equinoxosgi.toast.backend.feature, and delete the emergency and tracking bundles from the Plug-ins list. Note that the core emergency and tracking bundles are still needed, as they supply the service interfaces.

Now the back end is functionally equivalent to previous versions but implemented using remote services. Next is converting the client to use remote service calls.

19.3.5 Remote Service Client

The pattern for converting the client to use remote messages is similarly straightforward. Here we look at updating the emergency monitor. Updating the tracking monitor is very much the same.

The EmergencyMonitor originally used the IChannel abstraction to explicitly send messages to the back end. Now the back end surfaces an IEmergencyCenter service for the client’s use. Let’s assume that that remote service is surfaced in the client’s service registry and update the emergency monitor component:

• Open the emergency monitor’s component.xml and change the reference to the IChannel service to reference IEmergencyCenter. Ensure that the name of the reference is set to emergencyCenter and the bind method is updated accordingly.

• Open EmergencyMonitor and use refactoring to rename the channel field to emergencyCenter and then change its type to IEmergencyCenter.

• Update the code for runEmergencyProcess to call the emergency center service directly rather than using the channel, as in the following snippet:

• Organize imports, do other cleanup, and save EmergencyMonitor.

• Clean up the emergency monitor’s MANIFEST.MF by removing the reference to the channel package.

• Finally, update the test cases to follow the new pattern.

Repeat these steps for the client tracking code to complete the conversion of the code. Once that is done, the coding work is finished. Now we need to initialize the ECF infrastructure as we saw with the back end and update the product definition.

Since multiple bundles need the ECF infrastructure, we chose to put its initialization in a separate bundle. We also created a client-side Remote Services feature to capture all the required ECF functionality.

• Use the Samples Manager to load the org.equinoxosgi.toast.remoteservices.client and org.equinoxosgi.toast.remoteservices.client.feature projects.

• Open the client.product and add the new feature to the list of Dependencies.

19.3.6 Service Discovery

Toast now has a remote service host and client and ECF infrastructure for communicating between them—if only they knew about each other. That’s where service discovery comes in. The RFC 119 draft defines a generalized mechanism for integrating the services published by one framework’s service registry into the registry of other frameworks. ECF includes several implementations of this protocol based on standard technologies such as Service Location Protocol (SLP) and Zeroconf. To keep things simple here, we will use the so-called local discovery mechanism.

As the name implies, local discovery reads a local file that describes the remote services available and publishes them in the local service registry. This is a way of externalizing and controlling the location and characteristics of the remote services.

• Use the Samples Manager to load the local discovery mechanisms. Fetch the org.eclipse.ecf.osgi.services.discovery.local and org.eclipse.ecf.provider.localdiscovery projects. As of this writing, these are not part of the official ECF release. With future versions of ECF you can likely skip this step.

• In each of the client’s emergency and tracking bundles, add a remote service definition file, remote-services.xml, in the OSGI-INF folder. The following snippet shows the file for the emergency monitor. Be sure to update the service interface type for the tracking monitor.

• Update the MANIFEST.MF for each bundle to point to the new Remote Services declarations by adding the following line:

Remote-Service: OSGI-INF/remote-services.xml

19.3.7 Running the Distributed System

Running Toast with remote service support is the same as running normally. Indeed this whole exercise of converting to Remote Services has been very painless and has left the business logic largely unaffected.

Note that in setting up Toast as a distributed system we have glossed over some key discussions and decisions, namely, how to handle synchronous and asynchronous messaging and whether or not remote method invocation should be implicit or explicit.

Synchronicity is largely a situational decision. In our case the monitors were already set up as stand-alone jobs with nothing to do but send the message, so waiting is OK. To help with asynchronous messaging, the Equinox org.eclipse.equinox.concurrent bundle has support for futures. This mechanism allows you to send a message and immediately get back an IFuture object. You can then pass the future around, and only when you need the result of the message send do you need to wait for the value. Equinox futures are quite similar to those found in more recent JREs, but they run on old versions of Java and have support for status values and cancellation.

Here we have used implicit messaging but structured the code with the expectation that the message send may take a long time. Sending remote messages introduces additional chances for failure, which we have not accounted for particularly here. In general, a RuntimeException will occur and need to be handled. Of course, explicit remote service calls are also supported. See the ECF project and OSGi specifications for more information.

19.4 Summary

Here we have taken our stand-alone Toast Back End and converted it both to run inside standard web application servers and to use draft Remote Services technology and ECF for remote messaging. Both of these move Toast into the enterprise space.

Shipping the back end as a web application means that it can be deployed without ripping and replacing existing infrastructure while still maintaining the benefits of OSGi and Equinox. Using ECF and Remote Services opens the door to the transparent adoption of enterprise messaging infrastructure such as ActiveMQ.