AMF3 for OSGi
AMF3 for OSGi is a collection of three bundles which ultimately allow Flex Remoting to be seamlessly integrated with your OSGi based applications. A sample application with source code is also available.
The bundles are made available from this website using the Lesser GPL license. This means you are allowed to use it, modify it and redistribute it for personal or commercial use, so long as you make the source code available.
The AMF implementation is based on the work of GraniteDS.
While this is a bundle, it can also be used directly as a jar by any Java application in order to provide object serialisation based on AMF3. All your application has to do is provide an implementation of the AMF3Factory and call the AMFProcessor with an input stream and output stream.
The AMF3Factory is responsible for loading classes, instantiating objects, custom externalisation and processing objects that have been read from the input stream, the response of which is serialised to the output stream as AMF3 objects.
This bundle has some dependencies on some OSGi services (ServiceTracker, LogService, EventAdmin and HttpService) and registers a HTTP servlet that is capable of reading and writing AMF3 objects using the uk.co.arum.osgi.amf3 bundle.
The servlet uses a compound AMF3Factory which consists of any AMF3Factory implementations that have been registered as services in the OSGi Service Registry. The compound implementation is passed to the servlet and allows AMF3Factory implementations to come and go dynamically, as is appropriate to the OSGi environment. The compound factory simply delegates to each registered factory in turn until one returns something it can use, e.g. until the loadClass(String) method returns a non-null Class.
When an AMF3 connection is made a HttpSessionCreatedEvent is dispatched via the EventAdmin service (if it is available). Likewise, when a session expires the HttpSessionExpiredEvent is dispatched. This is achieved by setting an HttpSessionBindingListener attribute on the HttpSession with the name "___OSGI_SESSION___".
Finally, the HttpRequestContext class has a static accessor to a thread local variable which can be accessed during the call to the AMF3Factory#process(Object) method. This allows object processors (implemented by an AMF3Factory) to access the HttpServletRequest and HttpServletResponse of the request directly.
Up to this point you have all you need to implement your own AMF3 remoting protocol over HTTP, though if you want to use FlexRemoting we can save you some time...
As the name suggests, this bundle implements FlexRemoting and does this over HTTP by providing an implementation of AMF3Factory that understands the FlexRemoting objects. Additionally this bundle provides support for channel based messaging.
This bundle tracks services and makes them automatically available to be called remotely by Flex clients. The developer registers their service in the usual way, but adds an additional property with the String key "AMF_SERVICE_NAME" and the destination name expected by the Flex client as the String value. Only methods available on the interface that has been registered as the service are able to be called on the implementation, thus maintaining the contract created with the OSGi Service Registry.
Channel based messaging also utilises the OSGi framework. A message that is received over a messaging channel from a Flex client (using the mx:Producer) is posted as a PublishedObjectEvent using the EventAdmin. EventHandlers can handle and reply to the PublishedObjectEvent. Likewise, processes running in the container can post PublishedObjectEvents and any clients listening to the specified channel will receive them.
This sample application demonstrates the capabilities of AMF3 for OSGi. Running multiple clients also demonstrates Flex client based publishing and consuming. Run the application and have a look at the code!
The application comes with a README.txt which gives more details about what is required to run the application, how to run it and what to expect. Here are the minimum requirements:
- An OSGi 4 compliant container, e.g. Eclipse Equinox
- OSGi LogService implementation
- OSGi HttpService implementation
- OSGi Util (ServiceTracker) implementation
- OSGi EventAdmin implementation
AMF3 for OSGi has been tested with Equinox 3.4 which provides all of the above requirements and more. During development and testing our container footprint was as follows:
id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230 1 ACTIVE org.mortbay.jetty_5.1.14.v200806031611 3 ACTIVE uk.co.arum.osgi.amf3_1.0.0 4 ACTIVE org.eclipse.equinox.log_1.1.0.v20080414 5 ACTIVE uk.co.arum.osgi.amf3.http_1.0.0 6 ACTIVE javax.servlet_2.4.0.v200806031604 7 ACTIVE org.eclipse.osgi.services_3.1.200.v20071203 8 ACTIVE org.eclipse.equinox.event_1.1.0.v20080225 10 ACTIVE org.eclipse.equinox.http.jetty_1.1.0.v20080425 11 ACTIVE org.eclipse.equinox.http.servlet_1.0.100.v20080427-0830 12 ACTIVE org.apache.commons.logging_1.0.4.v20080605-1930 15 ACTIVE uk.co.arum.osgi.amf3.flex.remoting_1.0.0 16 ACTIVE uk.co.arum.osgi.amf3.sample_1.0.0
We believe that AMF3 for OSGi could be the basis for building complex, modular, enterprise applications. As such, it will become the basis of Solstice 2, a complete platform for managing modular enterprise applications based on OSGi and Flex.
Future enhancements include:
- Allow remote services to be registered programatically, rather than through registering your service with the Service Registry. The main reason for this is that you might not want other bundles in your OSGi container to have access to your remote service.
|Bundles and Sample Application||2009-01-26||January 2009|
|Bundles and Sample Application||1.0.0||December 2008|
We're always keen to hear feedback, ideas and suggestions from the community. Please email firstname.lastname@example.org for more information or to discuss potential consultancy using Solstice (v1) or AMF3 for OSGi.