![]() |
![]() |
||||||||||||||
![]() |
|||||||||||||||
[BACK] | |||||||||||||||
Migrating an ISV Application
|
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.
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 wouldnt 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 cant 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. Whats 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:
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!