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 that the next release of their flagship product will be hosted upon a J2EE server. J2EE is becoming important to their customers, their ability to compete, and their plans for offering interoperability through Web Services.

A representation of their product is illustrated to the right in Figure 1. The application is going to push the limits of J2EE due to the fact that a number of features, such as polling, do not easily fit within a J2EE request-response programming model.

Working With and "Around" J2EE

The ISV chose to migrate to J2EE for good reason.  First and foremost, their customers believed that a J2EE hosted solution was superior to a non-J2EE hosted solution, and thus they were addressing customers’ demands for standards.  Second, they wanted to avoid ‘re-inventing the wheel’ for security [JAAS], logging, naming [JNDI], messaging [JMS], and easy publishing of reports [Servlets/EJBs].  Figure 2 shows how the ISV was able to re-architect their application to make use of these J2EE provided services. Certain application behaviors, however, such as the time-oriented, long-duration, and asynchronous capabilities required the use of additional servers alongside their J2EE server, because there was no easy means of representing this application behavior in Servlets or EJBs. The resulting architecture in Figure 2 shows that the adoption of J2EE as a foundation resulted in two new servers in order to work around J2EE's capabilities:

  1. The main server (original base server)
  2. A Polling Server
  3. A Scheduling Engine

The main server manages the administration of users, reporting, logging, and other behaviors of the original system.  The Polling Server performs constant checking of networked devices in order to ensure their availability and response times.  When the Polling Server detects errors, it passes these errors via RMI to the main server for entry into the database.  The Scheduling Engine performs a number of tasks like cron based upon certain conditions, and it schedules administration jobs such as running reports from the main server during off-peak hours.  Each server requires support for security, logging, and management, and communicates with the other servers via RMI.  Additionally, each server must pass security contexts to the other servers at runtime due to the unknown deployment environment at the customer site, and thus the ISV needs to enforce Role based security at the Web and EJB container levels of the main server (and consequently the Polling and Scheduling servers as well).

Certain NSM 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. Table 1 below lists some of the services not present in J2EE but required for NSM applications. 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

CIMOM

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 NSM Services act like daemon processes, and daemon processes don't fit into the Servlet/EJB programming model of J2EE.

Implications Resulting from a non-Services Architecture J2EE-based solution

Just by visual inspection, it's clear that the original, relatively simple product architecture has experienced both efficiencies as well as difficulties due to working within a J2EE architecture.  Specifically:

·         Scheduling challenges:  Since Scheduling can’t be run on a J2EE server, the ISV had to author a Scheduler, write a security and management API for it, an installation program for it, and a failover system for it. What’s worse, the ISV must propagate security and transactional context back to the main J2EE server if they want to use its JavaMail system [otherwise its un-secure], or just give up and use a replicated copy of the JavaMail classes as part of their Scheduling Engine.

·         Productization challenges:  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 Same Management Server Functionality on Lutris EAS 4

As shown in Figure 3 below, the Lutris EAS Services Architecture allows for the easy hosting/import of new and existing code such as the Polling Service and Scheduler. As a result the NSM management application is implemented as an integrated suite of services on one server within one JVM, resulting in dramatic engineering, time to market, and quality benefits.  Specifically, thanks to the Services Architecture of Lutris EAS 4, the following goals are achieved:

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!