February 1, 2003
JLense is adopting a new focus on web services. This new focus will mean that
JLense will be focused on creating plugins that make it easy to create GUIs for
web services and on creating plugins that make it easy to create web services.
This new focus will not effect
the JLense Workbench or related UI plugins since these parts of JLense are independent
of thier underlying data sources and services.
This new focus is a response to many outstanding architecture issues:
Interoperability. The current JLedger General Ledger(GL) is an EJB Session Bean. Clients that want
to use the JLedger General Ledger must be able to talk RMI or IIOP to the
JLense Object Integration Framework EJB Session Bean.
By embracing web services JLense hopes to become a framework for easily
developing full-featured enterprise services that are interoperable across a
wide variety of technologies and platforms.
Standard Modeling. By adopting XSD and WSDL as the standard
method of modeling data and services JLense will be able to automate
much of the tedium of mapping data and services to their underlying JLense
Authentication, Security, and Transaction Management.
One item that's been on the
JLense Road Map for a while is to define how JLense will provide support for
Authorization and Authentication. Currently this aspect of J2EE is not plainly
and thoroughly addressed for client applications by the J2EE platform (actually, I
just found out that there is a CORBA standard for adding security assertions to
IIOP that J2EE supports. That covers the wire protocol, but how is a
client application supposed to propagate authentication info to the underlying connection?).
There is no standard way for J2EE client applications to propagate thier security context to J2EE services.
On the other hand, the JAX-RPC specification, JSR-101, requires support
for HTTP Basic Authentication and also provides a standard Handler mechanism for
integrating other interoperable security support such as SSL Mutual Authentication,
SOAP Security Extensions, and SAML - Security Attribute Markup Language, into the
client-side and server-side message processing stack. Thus, the JSR-101 specification
provides an implementation independent way for JLense to integrate all the
authentication, security, and transaction management mechanisms it wants to.
Support for interoperable transaction mechanisms such as BTP - Business Transaction
Protocol, may be integrated in a similar fashion as security mechanisms.
Specifically, this is the outline of JLense development goals over the next few months.
Create a WSDL definition of a General Ledger service (based on the OMG
General Ledger specification). Use Apache Axis to create Java stubs that
translate SOAP calls into calls to an EJB Session bean that JLense will create.
Create plugins for Apache Axis and
Create the GL EJB Session Bean. This bean will use the current JLense GL
code to implement the General Ledger. At this point JLense will have a functional
GL web service. It should only take a couple of weeks to get to this point.
Refactor the current JLedger GUI to use the new GL web service. This
will probably take a week.
Note that JLedger currently uses the Object Integration Framework to access the
General Ledger. JLedger uses the JLense Object Integration Framework to get objects
from the Gemral Ledger as well as to make changes to the system (create Accounts, insert
Transaction, etc). Going forward the JLense Object Integration Framework will be refactored
to only provide an ability to query a system for objects and to receive notification of data
changes in a system. Actually making changes to a system is more appropriately performed
through a well defined system interface. JLedger will use the new General Ledger web service
to create and delete Accounts, insert Transactions, etc.
The initial implementation of the GL web service will use HTTP Basic Authentication
over HTTP to authenticate users. JLense client applications will use JAAS to
authenticate users and get authorization info. Must put facilty into JLedger UI to get
username and password from user. Must also add a perspective (available only to
administrators) for adding Users and Groups/Roles, and for defining permissions.
Username and password will be set on JAX-RPC stubs.
Create a Tomcat security realm that uses authentication and authorization information
from JLense database.
Define simple role to grant or deny users the ability to post transactions.
At this point JLedger will require users to log in and will be
able to deny users the ability to post tranactions if they don't have
This step should take about a month.
A future enahancement will be to support HTTPS.
Integrate support for BTP - Business Transaction Protocol, a standard XML/SOAP based
mechanism for managing distributed transactions.
Must create Apache Axis message 'handler's' that will use BTP
assertions in SOAP requests coming into the server to set up transaction context
for call to GL EJB Session Bean. These handlers will use
the JBOSS J2EE JCA interface to setup security context.
This will probably take 1 month.
So, in less than 3 months I expect JLedger to have an interoperable,
web-based, secure, transactional General Ledger.