Migrating an ISV Application
to the Services Architecture
Keith Bigelow & David H. Young, Lutris
Technologies
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:
- The main
server (original base server)
- A Polling
Server
- 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.
Table 1 |
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:
- Desktop GUI challenges: Since the application is distributed
across 3 different servers, the ISV must replicate all management code
to set and get management data from each server. Further, the
ISV must pass security context from the GUI client to the each of the
servers, which means replicating JAAS support within each server.
- Polling Server challenges: The polling server, which
had to be dissected out of the ISV's existing app because it couldn’t
run on J2EE, has to receive requests from the J2EE server via RMI, or
some other inter-server communication protocol. But to be secure, the
ISV must replicate the security infrastructure to this server as well.
Worse, if one of the servers fails, there is no transaction failover
between the servers unless the ISV hand codes this for each of their
supplemental servers.
- 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:
- Unified installation, configuration, and logging
- Unified transaction, management, and security
contexts
- Unified architecture hosts both J2EE Services
as well as all non-J2EE Services [Logging, Management, Scheduler, Polling,
etc.]
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!
|