Page 1 of 2   next page »

This article describes two techniques that may be used for assured delivery of important data, specifically, audit data, in distributed systems. We will review design that leads from assured to guaranteed delivery. This task gets more and more important in light of modern global operation risk regulations and related application risk management.

Business Task and Functional Requirements
Relatively recent operation risk management regulations like Sarbanes-Oxley (SOX), and in some cases Basel II, require collection of "material evidences" of user activities that can affect financial reporting of the company. This includes user activities in the software applications, especially in the financial industry.

In many cases an activity is interpreted not only as a fact of application access, but also as an access to a particular application function and even data. The user activities in the application are supposed to be stored in persistence storage for following audit (for this article we will use relational database for simplicity). Such databases are usually centralized and serve multiple applications; therefore, we are dealing with distributed systems. The aforementioned regulations assume that audit data may not be lost on its way to the database. In automated systems, this means assured delivery of data.

Assured delivery of data is not a new thing in the application landscape. For many years MOM (Message Oriented Middleware) and recently, ESB (Enterprise Service Bus) technologies provided such functionality. The "cons" here are the high product costs and expensive maintenance. Plus, they do not guarantee that sent data is stored in the targeted persistent storage - they only assure that data is reliably transmitted from the sender to the receiver components or rolled back. This is the basic difference between assured and guaranteed delivery. In the article we will discuss an assured delivery and design a guaranteed delivery feature utilizing widely available J2EE technologies that may be suitable for small companies or for departments of large corporations.

When talking about delivery data with assurance in a distributed system, the first thing that comes to my mind is reliable messaging (RM). If an item of audit data is interpreted as a message, we can concentrate on the delivery mechanisms - in particular, on Web services and Java Messaging Service (JMS). It is interesting to notice that if a task of delivery is slightly extended and includes the reuse of audit data for integration with other systems, e.g., security systems, the Web services-based design has to be reconstructed to become scalable, while the JMS-based design requires just an extension for reliability. Details of these designs will be discussed in the following sections.

Web Services-Based Solution
The reliable messaging implemented as Web services is based on several standards such as SOAP, Web Services Reliable Messaging (WS-RM), WS-Acknowledgement, WS-MessageData, WS-Callback, SOAP-Conversation, and others. WebLogic platform version 8.1 provides SOAP Reliable Messaging solution while version 9.0 offers WS-RM. In both cases, the concept of RM may be demonstrated as shown in Figure 1.

An audit message is created in the Worker Component or Business Application and sent to the Sender Run-Time Procedure. Before the message is sent further, it is persisted locally. This protects the message from being lost if the receiver side is unavailable at the moment. Then the message is sent to the Receiver Run-Time Procedure where it is persisted first of all.

Since message transition is performed in the transaction, the latter can be rolled back in case of any problems on the network or receiver side. If the transaction is rolled back, the sender is notified that the message was not delivered. Depending on configuration, the message may be re-sent by Sender Run-Time Procedure or by the sender.

The Receiver Run-Time Procedure invokes a business method in the Audit Service Provider before the acknowledgement of delivery is sent to the sender. If the receiver - the Audit Service Provider - operates in the Receiver Transaction Context, it has an ability to perform its own operations in the same transaction. For example, the receiver can store the message in the database. If storing fails and rolls back, the Receiver Transaction Context rolls back and in turn, the process does not remove the message from the persistent store of the Sender Run-Time Procedure. Thus, the audit data is not lost. The only problem with this mechanism is that the Receiver Transaction Context does not automatically roll back if the receiver throws an application-specific exception, i.e., the Audit Service Provider has to take care of such exceptions and explicitly roll back the Receiver Transaction Context if needed. As we can see now, if data is persisted using the same transaction as the Receiver Transaction Context, we get a reliable solution for transmitting audit data into persistent storage.

The RM in the WebLogic 8.1 implementation has one major limit - it works on the WebLogic platform only. WebLogic 9.0 overcomes that limit via support of WS-RM, which works across all platforms that support the same standard. However, if a message has to be sent to multiple storages or transmitted data should be used for integration with other systems (for example, integration between authorization systems built into ALES, Documentum, and Business Objects products), the described Web services-based solution is limited in "vertical" business scalability. In particular, every time a new audit data consumer (or destination endpoint) has to be added to the system, a new sender (or source endpoint) has to be implemented and deployed.

To improve "vertical" scalability, we probably need to change design and set the Worker Component as a Web service while setting the Audit Provider and other integrated data consumers as Service clients. An alternative design might include an intermediary service that is situated between client (again - Worker Component) and integrated services. The intermediary service distributes audit data to all interested services. In both cases, original Web services-based design requires significant modification.

JMS-Based Solution
While JMS is designed for assured delivery from the beginning, we have to use it in a special way to achieve guaranteed delivery. Moreover, since we are discussing practical solutions, we have to address security in the design, despite the fact that it does not contribute to the guaranteed delivery process itself. Information security has not been discussed with regard to Web services because it is a well-known issue and has accumulated a lot of attention already. At the came time, messaging is traditionally considered as internal infrastructure and therefore secured, while actually, it is not (the majority of recent research points out that 75-80 percent of security violations happened inside the company). Therefore, we will examine JMS-based design while keeping in mind "vertical" scalability, security, and reliability.

Design for Security and Scalability
Let's assume that we deal with two Audit Service Providers. Each one collects only audit data of a certain type. Instead of an Audit Service Provider, it may be another system that integrates with Worker Component via data exchange. If we use just two JMS Queues for message receivers, we will need to modify sender code when we add more receivers, - this solution is not scalable. Therefore, we need to broadcast the message to all interested parties/receivers via, for example, JMS Topic.

Since audit data is sensitive, we cannot just put a message into a JMS Topic and rely on message filtering on the receiver side to select only appropriate messages; instead, we have to direct the message to the approved receivers only. We can observe several security models for JMS. As we know, JMS Connection Factory access may be protected by user name and password (UN/PW). We believe that this protection is not enough especially if the Topic is used by multiple receivers for integration purposes. It is common practice that, for example, an operation team discloses user name and password to those projects that need integration urgently without notifying the information owner (sender) and without checking security compliance. In WebLogic Trusted Domain configuration (trust between WebLogic Server domains), the password is not required at all.

Sensitive data also may be encrypted; however, it requires dealing with additional encryption service and/or encryption key management infrastructure. Both of them may be not available or may be too expensive.

Page 1 of 2   next page »