We propose an inexpensive combination of UN/PW with operational security design. Figure 2 displays one of the possible solutions where messages that are sent to the JMS Topic are directed to particular JMS Queues for approved receivers, e.g., Audit Service Providers.

The Message Bridges shown in the diagram have been known since the WebLogic 7.0 release and play the role of an intermediary. They subscribe to the JMS Topic and transmit messages in the transaction to the JMS Queues. Both Topic and Queues are configured with assured delivery and the Message Bridges have a durable subscription to the Topic. Each Audit Service Provider uses Message-Driven Beans (MDB) for message retrieval from the JMS Queue. The MDB starts a transaction and manages the message transition into the database in the scope of the same transaction.

If a Message Bridge is down, the message stays with JMS Topic. If a JMS Queue is down, the Message Bridge rolls back its transaction and the message still stays with the JMS Topic. If Audit Service Provider or database experiences problems, the MDB transaction rolls back and the message stays with the Queue. When problems are fixed, it is guaranteed that the message is processed and stored in the database.

The trick here is not in the technical solution, but in the operational data processing. The matter is that the information owner controls Message Bridges and approves receivers. Upon approval, the receiver is granted the Message Bridge and JMS Queue, and the operation team configures them (in addition to UN/PW). Thus, the solution gets relatively secured and is still flexible and scalable.

Design for Reliability
There are several steps to be performed to achieve reliability and guaranteed delivery via the JMS model described before. The overall system is shown in the Figure 3.

Step 1:    All JMS destinations used in the system have to be configured with assured delivery. All JMS listeners - Bridges and MDB - have to use durable subscriptions.

Step 2:    It is clear that the JMS Topic is the heart of the system. That is why we have to minimize the risk of its failure. We place the JMS Topic on a physically separated server with an automated failover feature. If a working instance of the Topic gets down, the failover instance immediately starts to work. If the sender or receiver's application server goes down, the Topic is still capable of operating.

Step 3:    Since JMS Topic becomes a remote destination, the Worker Component endures a risk of loosing audit data if the JMS Topic is not reachable. To protect audit data at this point, we add a distributed (clustered) JMS Queue, which is situated on the same cluster as the Worker Component.

Step 4:    We add Message Bridges to connect each of the instances of the distributed Queue with the JMS Topic. All Message Bridges are situated in the same cluster as the sender's distributed Queue.

Step 5:    For every receiver, create a distributed Queue that serves the receiver (e.g., Audit Service Provider). A receiver's Queue may be isolated from or collocated with the sender component.

Step 6:    Connect the JMS Topic with the receiver's distributed Queue by a Message Bridge. The latter transmits messages in the transaction to the receiver's distributed Queue. This Message Bridge is collocated with the receiver's distributed Queue.

Step 7:    Receivers, such as Audit Service Providers, use MDB to subscribe to the receiver's distributed Queue. MDB operates in the same way as described above.

Now, let's look at how it works together. The sender forms an audit message and sends it to the sender's distributed Queue where it is persisted. The Message Bridge, which connects a particular JMS Queue instance with the JMS Topic, starts a transaction, retrieves the message from the Queue, and sends it to the Topic. If Message Bridge is down or JMS Topic is unavailable, the message stays with the sender's distributed Queue until next attempt. If the message is delivered to the JMS Topic successfully, the acknowledgement is sent to the sender's distributed Queue and the message leaves from the sender's distributed Queue persistent storage. In Figure 3, four images of the Message Bridge represent a case of a cluster with four nodes where the distributed Queue is situated.

In the JMS Topic, the message is persisted again and broadcasted to durable subscribers. We have only one subscriber in the system - the Message Bridge. The latter starts transaction, retrieves message from the JMS Topic, and sends it to the receiver's distributed Queue. If Message Bridge is down or receiver's distributed Queue is unavailable, the message stays with the JMS Topic until next attempt. When the message is successfully delivered to the receiver's distributed Queue, the acknowledgement is sent and message leaves from the JMS Topic persistent storage.

If more than one receiver is permitted to get the message, a new Message Bridge and receiver's distributed Queue are configured in the system. In this case, the JMS Topic sends the message to as many durable subscribers (Message Bridges) as permitted and configured in the system. Figure 3 does not reflect if a receiver is deployed in a cluster, though it is highly recommended.

Finally, a receiver - Audit Service Provider - deploys a pool of MDB to get the messages from the receiver's distributed Queue. Each MDB starts is own transaction and Audit Service Provider persists an audit message into the Audit database in the context of this transaction. If transmission to the database results in an exception, the transaction is rolled back and the message stays with the receiver's distributed Queue until the next MDB processes it. It is important to notice that MDB uses Bean-Managed Transaction (BMT). The BMT allows Audit Service Provider to roll back the transaction if Provider experiences any problems with, for example, data transformation and throws an application exception.

The discussed system looks relatively complex. One can ask - what is the big deal here? Any Enterprise Service Bus (ESB) can solve this problem and hide all details! Of course, you are right. However, even if an ESB provides guaranteed delivery, what do you do if your organization cannot afford ESB, or it takes too long to buy the product?

Conclusion
We have described two solutions for transmitting audit or any sensitive data from the application to the database with guaranteed delivery. Both solutions are scalable and can effectively work in a distributed environment. Both solutions may be easily converted into services to be used in the service-oriented architecture. The most important aspect of the solutions is that they do not require expensive products and can be implemented on a regular WebLogic platform.

Acknowledgements
Many thanks go to Bruce Horner and Manmeet Ahluwalia for their significant contributions into the reliability design.

References

• OASIS Web Services Reliable Messaging specification: http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf
• OASIS Committees by Category Web Services: www.oasis-open.org/committees/tc_cat.php?cat=ws
• Orchard, D. " Making Sense of Web Services Standards": http://dev2dev.bea.com/pub/a/2004/01/ws_orchard.html
• BEA AquaLogic Service Bus: www.bea.com/framework.jsp?CNT=index.htm&FP=/ content/products/aqualogic/service_bus/
• National Security Institute's Information, Security Resource: http://nsi.org/NSIProducts/SECURITYsense/SECURITYsense.html
• Poulin, M. "How to Deal with Security When Building Application Architecture." JDJ. SYS-CON Publications, Inc. Vol.10, issue 9: http://java.sys-con.com/author/poulin.htm