JLense Focuses on Web Services

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 implementations.

  • 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.

Specifics

Specifically, this is the outline of JLense development goals over the next few months.

  1. 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 Jakarta Tomcat.
  2. 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.

  3. 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.

  4. 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 permission.
    This step should take about a month.

    A future enahancement will be to support HTTPS.

  5. 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.