[BACK]

Migrating an ISV Application
to the Services Architecture

There's no better way to describe the implications of a new technology than to use a real world scenario. Based on a true customer scenario, this article will walk you through the possible design impact of moving an ISV's (Independent Software Vendor) application to the Lutris EAS platform, featuring the Services Architecture.

A Network and Systems Management software company decides to take the J2EE plunge. J2EE is becoming important to both their customers, the ability to compete and their plans for offering features through Web Services.

A representation of their product is illustrated to the right. Clearly, their application is going to push the limits of J2EE. In fact, there are a number of features, such as polling that will require some clever re-architecture. A potentially very expensive proposition.

Working "Around" J2EE

The figure to the right shows how the ISV chose to re-architect their application around J2EE. It was possible to re-write the application using servlets and EJBs, but there were certain, time-oriented, long-duration, asynchronous, capabilities that required the use of stand-aside servers. The result is that there are two new servers are introduced in order to work around J2EE's capabilities:

  1. The main server (original base server)
  2. A polling server
  3. A scheduling engine

All three servers are linked by RMI (Remote Method Invocation). Why is this necessary?

Certain behaviors simply don’t map to the Request/Response programming model of J2EE. Application behaviors that have long-running state or are driven by events other than user input cannot be expressed in the J2EE model. The table below lists some of the services that you won't find in J2EE. Each of these Services may have very complex state that would be difficult or inefficient to persist in a database between invocations. Invocations may be frequent and may require complex state analysis or transitions, and they are likely multithreaded. Additionally, these Services may be time-driven, driven by remote network-connected applications, or driven by other local applications. This is not possible or practical using the Servlet/EJB request-response model.

polling
logging
scheduling
calendaring
rules engine
workflow
alerts
event mgmt
monitoring
JTAPI
IRAPI
TSAPI
CIM
SMS
WEBM

Finally, these Services may need to do things like write to sockets or files, manage threads, or open a GUI, which EJBs are not allowed to do. In short Services act more as daemon processes which don't fit into the Servlet/EJB programming model of J2EE.

Some Implications

Just by visual inspection, it's clear that a relatively simple product architecture has now been made more difficult due to working around the constraints of J2EE.

  • Desktop client cannot easily manage polling server and scheduling engine without custom, highly specialized implementation
  • Inter-server communication make difficult and inefficient by virtue of having too many application contexts dealing with security, for example.
  • Wanting to use JavaMail, but not running on J2EE server so must duplicate functionality
  • Scheduling engine cannot be run as a J2EE server
  • Polling engine cannot be run as a J2EE server

The desktop GUI client was created to manage the application. However, now the application is on 3 different servers, so the ISV must replicate all of the management code to fetch management data from each server for presentation in the GUI. However, the servers must be secure, so they have to pass security context from the GUI to the servers, which means that they have to replicate security three times across each server. Ouch!

Polling

The polling server, which had to be disseced out of the ISV's existing app because it wouldn’t run on J2EE, has to receive requests from the J2EE server via RMI. But to be secure, of course they have to replicate the security infrastructure to this server as well. Worse, if one of the servers go down, there is no failover between the servers unless they hand code this for each of their supplemental servers. Another ouch!

Scheduling

Since Scheduling can’t be run on a J2EE server, they had to write one, write a security and management API for it, an installation program for it, and of course a failover system for it. What’s worse, they have to propagate security and transactional context back to the J2EE server if they want to use its JavaMail system [otherwise its un-secure], so they just give up and use a replicated copy of the JavaMail classes as part of their Scheduling Engine. Move to the next slide.

Productization

This architecture makes a unified installation virtually impossible. Configuration management is made more complex and there's no single, unified view of management. For instance, there's a log file for each of the three servers, each of which must be analyzed independently when diagnosis of issues is required. Reliability is significantly threatened if failover support is required.

The Management Server on Lutris EAS 4

Thanks to the Services Architecture of Lutris EAS 4, the following goals are achieved:

  • Unified management and installation of server
  • Can now use JavaMail from J2EE platform
  • Legacy code can be easily imported and run as a peer. J2EE contexts can be shared with legacy code.
  • A single, unified log file

The Services Architecture allows for the easy hosting/import of existing code. As a result the same application can be hosted on one server within one JVM, shown in the "Lutris 4 Services Architecture" figure below.

The ISV's application is implemented as pluggable "Java Services" that function as peer services right alongside the J2EE services, also implemented as individual pluggable services. All of these services have access to the underlying JVM operating environment and the operating system environment, making requests for threads, time, sockets, security and other resources made available through the Lutris EAS Kernel.

Furthermore, the JMX management API intercepts all plugged in services and represents the J2EE services as well as the services that represent the implementation of your application, providing a single, consistent management context and management view.

The Value

There are clearly a number of ways you can measure the value of what you've just read. Time to market is definitely one of the more significant values brought by the Services Architecture. Take your existing application, wrap it as a Java Service, plug it into the Services Architecture and you have your application and a J2EE platform all under one management view. Ship product!

 

[TOP]
 
Legal Notices ---- Privacy Policy