|
Introducing Lutris EAS 4
and the Services Architecture
Lutris EASÔ
is an extensible Java/XML Internet application server that supports J2EE,
Web, and Wireless Services. Lutris EAS and its Services Architecture gives
ISVs, VARs, SIs, and OEMs a new level of flexibility, extensibility and
scalability for successful enterprise Java applications that are created
using any combination of these platform services.
Lutris EAS offers a Web of Services, built upon
the modular Services Architecture pictured at right. The Services Architecture
supports a broad range of technologies that enterprise applications require,
from J2EE services (JNDI, EJB, etc.) to Web Services (using SOAP, ebXML,
etc.) to Wireless Services (J2ME, WAP, Location, etc.). Each of these
collections of services are implemented as plugable platform services
within the Services Architecture, enabling ISVs, VARs, SIs, and OEMs the
ability to tailor the application server to their application, rather
than attempting to transform their application to meet the constraints
of application server. Further, ISVs, SIs, and VARs have the freedom
to innovate new platform services such as Schedulers, Workflow, Listeners,
and Alerter services to easily enable business processes that are not
easily expressible in the EJB/J2EE programming model yet still share in
the transaction, security, and management services of J2EE.
At JavaOne 2001, Lutris demonstrated the ease with which ISVs, VARs,
and SIs can take any existing code, such as SOAP, and quickly import that
code into the Lutris EAS application server as a platform service. The
benefits to offering this plug-able architecture is that code that behaves
as a horizontal facility to other applications, such as SOAP, needn’t
be replicated within every application that makes use of it. Rather,
horizontal facilities may be integrated as part of the application server
itself, alongside the other platform services of Lutris EAS, such as EJB,
JMS, etc. This approach is dramatically different from other commercial
approaches, in that rather than forcing ISVs, SIs and VARs to write applications,
Web Services or Web Service-enablers like SOAP on top of J2EE APIs, Lutris
EAS makes it easy to extend the platform to offer these services alongside
J2EE. This approach results in three key benefits:
1.
A far more manageable
platform, since the SOAP platform service (indeed any custom service)
is instantly manageable by Lutris’ JMX-based Management Console
2.
A far more dynamic platform, since developers
aren’t limited to the capabilities of the request/response programming
model of J2EE
3.
A more efficient platform, since every platform
service within the Lutris Services Architecture can run within a single
JVM, and thus benefits from shared common resources and from intra-VM
calls rather than expensive inter-VM calls using RMI 1
The
Lutris EAS Services Architecture in Action – A Stock Ticker Web Service
Web Services are intended to provide an easily accessible means of
assembling and extending Internet applications. As such, they provide
a specific functionality, and are increasingly expected to expose that
functionality using a standard protocol, SOAP. SOAP serves the Web Service
not unlike an XML-specified Remote Procedure Call (RPC), and allows for
disparate applications potentially using different programming languages
on different operating systems the ability to easily interoperate. The
canonical Web Service sample used by many companies is a simple Stock
Quote Web Service, which takes as an input a stock symbol, MSFT and returns as an output the current
price of that stock, 3.25 [each wrapped in a SOAP envelop]. Lutris
engineers used this canonical Web Service example to demonstrate a superior
approach to Web Service development and add a wireless flavor with Java
2 Micro Edition (J2ME).
The first step to superior Web Service development was to decouple
from the Stock Quote Web Service its function [receiving a ticker and
returning a value] versus its communication protocol [SOAP]. As mentioned
above, the reason for componentizing in this fashion was to allow many
different Web Services to share a single SOAP platform service, and as
a result of this componentization have superior time to market of new
Web Services, superior lifecycle management of the Web Service [so that
as new versions of SOAP are standardized, the Web Services that depend
upon SOAP for communication remain unaltered], and superior performance
[since redundant resources such as the SOAP code are not repeatedly loaded
with every new Web Service that is deployed]. The net results of this
modification in the demonstration were the independently manageable SOAP
platform service and Stock Quote Web Service that you see in the demo.
The second step of the development was to create a meaningful client
to access the Stock Quote Web Service. Lutris engineers decided to create
a cell phone client, using J2ME/MIDp and kSOAP, a J2ME/MIDp implementation
of SOAP included with Lutris EAS. The cell phone client, a MIDlet, allows
the end user to key in a stock ticker symbol, and have returned to them
the current price of the stock. Using kSOAP on the J2ME-enabled cell
phone allows for the phone to contact any number of different Web Services
providing a Stock Quote function, and thus empowers the user to choose
whatever Quality of Service they desire [for example, a Real-Time Quote
service that would be very expensive, or a 20 minute delayed Quote service
that might be free]. Indeed, both of these independent Stock Quote services
may be running side by side as Web Services on the Lutris EAS server,
sharing the exact same SOAP platform service as described above.
Conclusion
Thus, Lutris EAS offers the fastest path to authoring sophisticated
J2EE, Web, and Wireless Services and applications. Lutris’ Services Architecture
gives developers the freedom to innovate, and to transform the platform
to meet the needs of their business application, rather than restrict
their application to conform to a fixed platform. In this manner, Lutris
EAS enables an ISV, VAR, SI, or OEM to easily create either a customized
server for embedding in network appliances, for example, or a full J2EE
implementation extended with SOAP, ebXML, or other eBusiness enabling
Web Services.
1Any combination of services may be split across any number
of JVMs as desired by the developer
|