When is a POJO no longer a POJO

When is a Plain Old Java Object no longer a Plain Old Java Object?

My take on POJOs is that they are no longer POJOs when there is an import statement for something not conforming to the expression "java*.*".

I see quite a lot of frameworks and toolkits claiming benefits around POJO oriented development. However either through annotations, extension, implementation etc. they require dependencies on non JRE artifacts.

This situation is quite OK of course; I just think that it is useful to distinguish a POJO from its dependent form. For example if you're looking for Object Relational Mapping then you might want to consider the Java Persistence API instead of being directly dependent on an implementation; such as Hibernate. Maintaining this distinction allows you to consider migration strategies to other implementations if required.

Sometimes you need to be dependent on a toolkit or framework and that is of course perfectly acceptable. Being aware is the significant point.

Who is Palm trying to attract for WebOS development?

I must say that my first impressions of what Palm is offering in terms of the WebOS leaves me curious.

I wrote for the Palm OS over a long period of time. I started my Palm OS development when Palm were US Robotics and programmed the original PalmPilot. The PalmPilot was an amazing achievement for the time.

There were a few things that attracted me to the original Palm OS platform, but a major one was that I could use my C++ skills to create robust and high-performance deliverables. The Metrowerks Codewarrior environment was a joy and I could use the same IDE for Mac OS (then Mac OS 8!) and Palm OS development.

I think that it is reasonable to state that the original Palm OS attracted seasoned software developers; a lot of them were also Mac developers that understood things like usability.

I am little surprised to learn that the WebOS is a Javascript world for the developer. To me Javascript is a language that evolved i.e. it does not appear to have been well thought out from the start. I am not attempting to criticise Javascript here - in fact I think that it is amazing what has been enabled via Javascript in the context of a web browser. I also understand why it has evolved the way it has. The thing is I am just surprised that Palm have chosen Javascript as their primary programming environment for WebOS. Who exactly is it that Palm are trying to attract to their platform?

I suppose what I am saying here is that while Javascript can be written in a disciplined manner, I do not often see this to be the case. I am therefore curious about the quality of applications that will be delivered to the WebOS.

I think that Apple have things almost right with the iPhone SDK and that Google have it completely right with Andriod. Where Apple need to improve is simply to provide a notification mechanism for an application. The notification handler should be able to operate in the background. The original Palm OS provided such a mechanism for handling alarm and other events. The benefit was that you could get an application to do things as a result of various device stimuli. This capability is very important and the iPhone falls short in this regard; so much so that I cannot consider porting my Palm OS based Titan Class Vision software.

In the case of Google I think that the choice of Java is correct. Java is a great way to deliver robust software and rich in its tooling. However Google have to solve the battery life implications of their environment which presently make their phone unusable in many quarters.

I digress slightly. The question remains though, who is Palm trying to attract for WebOS development?

Using Camel ProducerTemplate in a POJO

I am enjoying Apache Camel immensely. My productivity in terms of delivering enterprise grade services has increased dramatically. No doubt that the quality of my deliverables has also increased. All of this with no compromise to performance...

In the case of having deployed about 3 Camel based applications (containers for services) and a couple of non-Camel ESB applications, I think that one of the major ESB benefits is the de-coupling the service implementation from the transport. This of course allows the service code to be written as a POJO and with dependency injection, DAOs and a few other patterns, the resulting service has a clean focus on the business logic.

I recently had to implement a service that initialised a biometric device. Initialisation comprised of communicating several messages over a TCP connection to each biometric device. In the first instance I used Camel's ProducerTemplate to send my messages. This all worked fine and of course meets that goal of separating out the transport delivery from the business logic. However I now had a Camel dependency in my otherwise pure POJO service. This did not satisfy my design goal of ensuring that the service remained a POJO so that I could be free with my ESB choice (not that I see myself moving from Camel for any reason!).

To avoid this Camel dependency I created and used my own ProducerTemplate interface. This is merely a proxy to Camel's and only has the methods I need from my service. It looks like this:

public interface ProducerTemplate {
 Object sendBody(String endpoint, Object body);
}

I then pass a ProducerTemplate instance and its endpoint details to the invocation of my service along with any other parameters the service needs:

void process(ProducerTemplate producerTemplate, String deviceEndpoint,
 Collection fingerprints)

Note that the ProducerTemplate is passed in on each invocation of the service. This is because the template can potentially change between service invocations.

My Camel container project includes the project housing the above POJO. The container defines and instantiates its ProducerTemplate that forwards calls on to Camel's ProducerTemplate. The result is that I now have a POJO based service that interacts with other services in a non-Camel dependent manner.

Anatomy of a service/Apache anyone?

Here is a pattern that I have implemented a few times now.

I have had requirements to provide a web service, typically SOAP based, that persists something in a database (or whatever). Here's a general flow of events that I'm finding works particularly well:

1. Web browser to web service
A web application (typically Javascript executing in a web browser) sends a SOAP request. Given that my web service is written using Apache CXF it can generate the required Javascript for the browser's invocation by appending a ?js parameter to the web service. Check out the CXF doco to see how.

My CXF based web service is developed on a contract-first basis i.e. the SOAP interface is defined using Java. The reason I like that (as opposed to a WSDL-first approach), is because WSDL appears overly complex to me. It is much easier, in my most humble opinion, to create the Java interface and have CXF generate the WSDL. I reckon that CXF does a pretty good job of this too.

My web service has the responsibility of marshaling the SOAP XML into a Java object that is representative of my information model. Here's a critical point: you must have an information model to work with aka domain model. If you don't have that nutted out very well then you tend to spin wheels.

The classes of the information model are used as a normalised object for messaging and also for persistence. The web service marshals the XML into model objects, performs various integrity checks and then forwards the model objects on to a JMS queue.

I'm using Spring's JMS template classes to forward on my JMS messages; when it comes to sending messages, lots of code is taken care of using these classes (I've also programmed JMS without them so I can make a direct comparison as to what Spring offers in this respect).

In summary my web browser invokes a SOAP web service using some nice Javascript code that CXF can generate. My CXF based service has a relatively simple roll of marshaling the SOAP XML input into a domain object of my information model and sending it to a queue.

Oh, by the way, I'm using Apache Tomcat to host my CXF based web application.

2. Sending to ActiveMQ
I'm typically sending to queues dedicated to specific functions e.g. "queue to persist the biometric fingerprint of a person". These queues are persistent (a JMS default) so that messages are stored until they can be guaranteed delivery.

I like ActiveMQ. Apart from the price tag being very attractive (free), the Apache products are built to a very high standard. ActiveMQ is fast and reliable.

3. ActiveMQ replies
Once ActiveMQ replies back to my web service guaranteeing delivery, my web service replies to my browser application.

4. Browser processes the reply & Camel service consumes queue
These are concurrent activities. Of course the browser delivered the SOAP request in (1) asynchronously and registered call backs for processing any errors and successful responses. This way the user's browser remains responsive.

The design of my browser application is very much around the store-and-forward paradigm. Depending on how critical it is to feed back the results of an operation, it is generally adequate to inform the user that their requested has been posted. In the case where the request is involved in retrieving, say, customer details, receiving a response is important so I would use a request-reply enterprise integration pattern. However in many scenarios, store and forward is perfectly adequate and really suites a browser style application.

Almost as soon as ActiveMQ makes a message available to the queue (2) my Apache Camel based service is able to consume it.

I like Apache Camel. It really helps me assemble services very loosely given the strong promotion of enterprise integration patterns. You can build content based routers, aggregators, request-reply mechanisms and so forth - Camel provides the framework for you to build your services on. Camel almost forces you to think about the correct separation of concerns given its abstractions.

I typically deploy my Camel based services using jsvc - Apache's daemon toolkit (part of the Apache Commons project). jsvc is a very simple wrapper so that you can make your application run as a service on Unix and Windows based platforms. From a programming perspective, you implement a lifecycle interface (init, destroy, start, stop) and that's about it. I want to move toward using OSGi, and I have played with it. However I have not found a OSGi based container that I'm totally happy with yet (they don't appear to have totally satisfied use-cases associated with administrators - just programmers at this point).

I have many services do many things but a common task is persisting and retrieving data from a relational database. For that I program to JPA and use Hibernate as my JPA implementation. I prefer JPA over Hibernate directly so that I have the ultimate freedom of using other ORM implementations should I need to - I don't think I will be needing to at this point though as Hibernate is great.

Performance
I get great performance. The slowest parts tend to be associated with persisting data in an RDBMS (nothing to do with Hibernate etc - normal RDBMS stuff) and network latency. CXF and Camel fly along - you're mostly counting small units of milliseconds with these technologies.

Scalability
I've not had to do much in the way of scaling yet, but I know I have the correct separation of concerns to cope with most of what the world can throw at these services. In the performance testing that I have done I tend to exceed my customer's expectations. As stated above, it is network latency that appears to be the bottleneck given that the internet often sits between the browser and the web service.

Apache, Apache
It may appear that I work for Apache or something, but I don't. I do value the Apache Projects though. In summary here's what I'm presently using:

* Active/MQ
* Camel
* CXF
* Maven
* MINA
* Tomcat

Software Development and the Global Economic Downturn

There appears to be plenty of software development work around at the moment.

A manager at a large company that I have been doing some work for recently commented that when a business looks to contract, the demands on IT increase.

I agree.

The reason for this is automation; something that the business should always strive for of course. The point is that they don't. Large companies would rather throw multitudes of people at a problem than optimise operational tasks... until external pressures such as world economic downturns occur. I have friends that work for some other large companies that are typically regarded as being innovative. One of the common threads is how, from an operational perspective, they always automate the mundane tasks as much as possible.

So for me at least, as a small software developer, there appears to be plenty of work around and a great deal is focused on automation.

An Image Compositor Technique for a Planet

I had a need to develop a capability within Titan Class Vision to composite many images representing parts of our planet at different resolutions. In particular, these images could be quite large; perhaps 200MB each.

I decided to give memory mapped files a go using the low-level paging mechanisms available to modern operating systems. In a nutshell we’re looking at the use of mmap and munmap. Memory mapping files is very fast and highly optimised - it is by far the fasted way of reading bytes in to memory from disk.

My main image of the planet is about 200MB in size. What I do is have a Windows BMP file mapped saved in BGRAUnsignedInt8888Rev form (this is the optimal format for something to be textured on Mac OS X) and then use memory mapped file IO to page the BMP into memory. I then have an image compositor object that is able to composite many of these images e.g. I have a BMP for the entire planet, and one for just a given state of Australia (NSW). When it comes to client code making a request the compositor assembles a composited buffer of my layers as required and in the resolution required. This composited buffer is then sent to a texture using GL_STORAGE_SHARED_APPLE as an optimisation. I also keep some of these textures around for situations where I know in advance that I'm going to zoom in on something; it is then consequently very fast when it comes to rendering as no dynamic composition is required.

Oh, and I'm using the Mac OS X Accelerate Framework for high quality and high performance scaling given that Titan Class Vision targets this platform.

It all works pretty well and is fast, even on a tired old G4 Powerbook. Multiprocessors are utilised given the Accelerate Framework. One naturally has to be considerate of virtual memory usage with the compositor, but that is a resource management exercise.

Here’s the class structure that I came up with; feel free to use it in your own work but please be kind and include a reference to this page and some credits.

namespace WorldLayerCompositor {
    typedef unsigned long BGRA;
    
    inline unsigned short SwapInt16LittleToHost(
        unsigned short arg
        ) throw();

    inline unsigned long SwapInt32LittleToHost(
        unsigned long arg
        ) throw();

class Layer {
  public:
virtual ~Layer();

inline void GetCentreLatLong(
            double& outLat, double& outLong
            ) const throw();

inline double GetResolution() const throw();

inline void GetSizePx(
            unsigned& outWidthPx, 
            unsigned& outHeightPx
            ) const throw();

virtual BGRA* GetBuffer() const throw() = 0;
};

class MemoryMappedBMPFileLayer : public Layer {
  public:
MemoryMappedBMPFileLayer(
            const std::string& inFile
            ) throw();
virtual ~MemoryMappedBMPFileLayer();

virtual BGRA* GetBuffer() const throw();
};

class LayerCompositor {
  public:
LayerCompositor() throw();

typedef std::list<boost::shared_ptr<Layer> >
            LayerList;

LayerList::iterator AddLayer(
            boost::shared_ptr<Layer> inLayerP
            ) throw();

void RemoveLayer(
            const LayerList::iterator& inLayerIter
            ) throw();

bool GetNextSubBuffer(
            unsigned long** inBGRAUnsignedInt8888RevPP, 
            unsigned& outSubXPx, 
            unsigned& outSubXPy,
            unsigned& outSubWidthPx, 
            unsigned& outSubHeightPx
            ) const throw();

void GetEffectiveSizePx(
            unsigned& outWidthPx, 
            unsigned& outHeightPx
            ) const throw();

inline void SetSubRegion(
            double inLat, double inLong,
            double inResolution,
            unsigned inWidthPx, unsigned inHeightPx
            ) throw();
};
};

I intend to evolve this class much further and make it considerate of planet related things. For example if a request is presently made for a region that extends over the dateline then I move the region back either east or west. In the future I’ll be handling this so that the compositing considers the dateline.

Another thought is to be able to add layers described in vector terms using SVG and GML... I think that there are some interesting possibilities.

Using The GML’s Moving Object Status for presenting Flight Information

This is something that I’ve wanted to share for sometime now - how to use the Geography Mark-up Language (GML) for tracking things that move in the real world. GML can be a lot to get one’s head around so I hope that this real-world implementation will help you. We have been using GML for sometime now with our Titan Class Vision product.

I want to show you how GML can be used to describe flight data; the sort of data you’ll see presented in the arrival and departure halls of airports. I have a hope that the world can share a view on how airport flight information should be provided to many kinds of application.

GML provides a set of abstractions that are intended to be specialised by applications for their own purpose. Consequently we have defined a schema to describe journeys. This schema is represented by the class diagram above and is available in XSD form from our website.

Journeys describe a track between point A (departure port) and point B (arrival port). They have a scheduled departure and scheduled arrival time. A specific type of journey is a flight which has no other characteristic than its type for distinguishing itself.

A Journey is a specialisation of a GML DynamicFeature. Dynamic features are things that have a relationship to geography (as per a regular Feature) but can also change over time and record when they do so. Consequently snapshots of a dynamic feature can be expressed given the availability of a validTime element. Additionally, and importantly, dynamic features can also have a “track” element. Tracks define a set of objects that describe a feature’s status over a period of time. These objects are known as GML’s MovingObjectStatus and minimally describe the time that the status applies to (validTime) and the location of the dynamic feature. A location can also be “null” i.e. unknown; this is pertinent to us and I’ll come back to it. The other elements are also very useful when tracking the position of a dynamic feature. For example, given acceleration, speed, bearing (horizontal and vertical), elevation etc. one can reasonably predict where the feature will be next. For most flight information displays in airports though, these elements are less important (Titan Class Vision at the airport is attempting to change this situation!).

We have further specialised MovingObjectStatus as a JourneyStatus with the discriminating element being the Estimated Time of Arrival (ETA). Thus for a given validTime we can report what the ETA was.

Enough words! Let’s have an example based on our journey schema:

<j:FeatureCollection ...>
<name>Journeys</name>
<boundedBy>...</boundedBy>

<featureMembers>
<j:Flight>
<name>QF32</name>
<validTime>
<TimeInstant>
    <timePosition>
        2006-05-01T10:30:00Z
    </timePosition>
</TimeInstant>
</validTime>
<track>
<j:JourneyStatus>
<validTime><TimeInstant>
        <timePosition>
            2006-05-01T10:30:00Z
        </timePosition>
</TimeInstant></validTime>
<location><Null/></location>
<j:ETA>
    2006-05-02T00:05:00Z
</j:ETA>
</j:JourneyStatus>
</track>
<j:departPort xlink:href="..."/>
<j:departTime>
   2006-05-01T11:15:00Z
</j:departTime>
<j:arrivePort xlink:href="..."/>
<j:arriveTime>
    2006-05-02T00:00:00Z
</j:arriveTime>
</j:Flight>

</featureMembers>

<validTime><TimeInstant><timePosition>
    2006-05-01T10:30:00Z
</timePosition></TimeInstant></validTime>

</j:FeatureCollection>

Please note that the above is not valid XML i.e. I’ve removed the namespace declarations and the xlink:href contents so that I could fit everything on the page and just present what is relevant to this discussion. A valid version of the above can be found on our website.

The above document states, “here are the flights as at 1030 GMT. There is just one flight named QF32 which is scheduled to arrive at midnight GMT. However the current ETA is 0005 GMT.”. In the real world there would be a number of Flight elements for a given airport and a number of JourneyStatus elements if there have been a number of ETA revisions. The location is not important for most flight information displays at airports and hence we show that as having a null value.

ETA could have been included as a element of Journey. I chose to have it as an element of JourneyStatus (aka MovingObjectStatus) so that I could have a number of ETAs reported for historical reasons. Additionally the reporting of an ETA could be further analysed by location.

Plans are deemed other features (including other Journey features) that can further describe a given Journey feature. For example we have journeys that describe the frequently used flight paths between various destinations. These paths can include various way-points and record typical elevation and speed at those points.

Our schema can also be used to describe a schedule such as a flight schedule. The validTime element of a Journey feature has the potential to be used to distinguish different schedules depending on the day of the week. For example a scheduled flight might only occur on Mondays and Fridays.

I’m hoping that it is becoming apparent that more than just the ETA of a flight can be described. Firstly the structure of our schema permits the actual positions of flights at given time instances. We have embarked on consuming air radar data using our journey schema. This will enable us to render the real-time track of aircraft with our flight information display.

Secondly anything that has a journey should be able to be described. This includes trains, ships, cars and trucks - even people swiping their security cards.

In a future blog I shall describe various forms of accessing journey data using the Web Feature Service (WFS) and also how this data can be published and subscribed using an enterprise messaging bus such as IBM’s Websphere MQ and others that use the Java Messaging Service (JMS).

Meanwhile if you find that our journey schema is useful to you then please add a comment or do get in touch.