Jt - Java Pattern Oriented Framework

An application of the Messaging Design Pattern

Jt is a design pattern framework for the rapid implementation of Java applications. The framework architecture is based on a messaging design pattern which is utilized to implement many well-known design patterns, in addition to SOA and ESB capabilities.

Al Galvis (jtowner@dev.java.net), Consultant, IBM

Al Galvis have had several roles over a period of many years in the computer industry. Roles include Computer Science Professor, Computer Scientist at research facilities and roles as a technical consultant and architect for several major corporations.



27 May 2010

Also available in Japanese

Overview

Jt is a Design Pattern Framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. The framework addresses the following goals:

  1. The framework architecture is based on a messaging design pattern: framework components are able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides simplicity, strong encapsulation and loose coupling; framework components can be interchangeably plugged into complex framework applications using a "lego/messaging" architecture. Framework messages can be processed synchronously or asynchronously. The framework takes full advantage of the power and simplicity of the messaging design pattern/API.
  2. The design pattern framework uses messaging to implement and/or facilitate the implementation of well-known design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns. The framework itself is conceived and implemented, from the ground up, based on design patterns. The framework also facilitates and accelerates the implementation of applications based on design patterns.
  3. The framework lego/messaging architecture provides transparent and secure access to remote components: remote framework objects are treated as local objects. Design patterns implemented by the framework (messaging, adapters, remote proxies and facades) make this possible by hiding the complexities associated with remote APIs. Built-in components for message encryption and authentication are provided.
  4. The framework provides transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, Data Access Object implementations (DAO), Model View Controller implementations (MVC), EJBs, JSP, AJAX, ESB, JMS, XML, REST and Web Services.
  5. The framework is designed to be lightweight and fast (low overhead/small footprint).
  6. The framework messaging/lego architecture improves and simplifies design/development efforts. There is a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. The framework provides wizards and automated capabilities for generating framework applications. Framework components can be easily added to BPM/BPEL process diagrams. In future versions of the framework, it should be possible for application modules to be generated directly from the UML design diagrams. This goal is still work in progress.
  7. The framework messaging architecture facilitates testing and debugging efforts. The framework provides capabilities for testing components as independent units by sending messages to the component and verifying the expected reply messages.

Messaging Design Pattern (MDP)

Intent: The messaging design pattern allows the interchange of information (i.e. messages) between components and applications.

Motivations (forces): This design pattern can be applied to solve a great variety of problems in many diverse scenarios. A messaging paradigm is widely used in nature and the real world. Messages are interchanged all around us. Entities are constantly sending, receiving and processing messages. Human beings for instance: when we watch TV, listen to music, talk over the phone, or communicate via the internet. Right now, you are reading this written message. Since computer applications seek to model the real world, it is only natural to design and write applications using a messaging approach. We can argue that this approach provides a more complete and accurate representation (i.e. model) of the real world. As a consequence, software engineering processes are significantly improved by the use of the messaging design pattern.

Participants:

Message Sender: Component that sends the message.

Message Recipient (Receiver): Component that receives the input message and may produce a reply (output message) after processing it. The input message, general in nature, may contain any type of information. The component may be instructed to perform computations based on the input message.

Messenger: Intermediary that transfers the message from the sender to the recipient. The sender and the recipient don’t need to be concerned about how the message is transferred (communication protocol, message format, encryption/security mechanism, etc.) and the transformations performed on the message along the way. This is the messenger’s purpose and responsibility. Similar to the real world, it is often the case that the messenger is not required. The message can be sent directly to the message recipient. Several modes of communication are possible: synchronous, asynchronous and two-way messaging.

Message: any piece of information (i.e. data) that needs to be interchanged between sender and recipient. Two messages are usually involved: input message and output message (or reply message). The reply message is not required.

Figure 1. Messaging Interface
Messaging Interface
Figure 2. Messaging Design Pattern (synchronous mode)
Messaging Design Pattern (synchronous mode)
Figure 3. Messaging Design Pattern (synchronous mode without messenger involved)
Messaging Design Pattern (synchronous mode without messenger involved)

Consequences:

  • Encapsulation. The messaging design pattern maximizes encapsulation. Each component is a self-contained/independent unit. The only mechanism of communication with other components and applications is via messaging.
  • Decoupling. MDP minimizes coupling. Again each component is a self-contained unit that can perform independently from the rest of the system.
  • Reusability. MDP improves reusability. This is similar to the building blocks in a “Lego” set. Very complex models can be built based on simple pieces that share a simple way of interconnecting them (i.e. common interface). The power of the approach is derived from the number of combinations in which these toy pieces can be assembled. Components that use the messaging design pattern can be interchangeably plugged into complex applications. The components can be assembled in a limitless variety of configurations. The user of a component only needs to know the input/output messages that the component handles. Applications are also able to reuse components from other applications at the component level: a single component can be extracted from another application, provided that the messaging design pattern is being used.
  • QA/Testing process. MDP facilitates testing and debugging efforts. Components are tested as independent units by sending messages to the component and verifying the expected reply messages (black-box testing). In general, unit testing can be performed via a testing harness. No need to include testing code inside the component code which can be time consuming and lead to the unexpected introduction of software defects.
  • Design process. MDP improves and simplifies the design process. The bulk of the design work becomes defining the set of components needed to meet the system requirements and the input/output messages that each component needs to handle. There is a tight correspondence between UML design diagrams and the components needed for the implementation. Since all components share the same messaging interface, they can also be easily added to BPM/BPEL diagrams. As mentioned earlier, this is similar to building blocks that can be reused and connected in many different ways.
  • Development process. Since each component that relies on messaging is self-contained, a large team of people can cooperate in the development effort without stepping on each other's code/work. In the ideal situation, responsibility for one component/package can be given to an individual. The rest of the team only needs to know the input/output messages that someone else’s component is designed to handle. No need to change someone else’s code. The need for creating, maintaining and merging several versions of the code is also minimized or eliminated. Testing/QA engineers can do their testing independently via a testing harness. In general, there is no need to add testing code.
  • Logging and Debugging. Since all the components use the same messaging interface, messages can be logged automatically. This minimizes the need for print/logging statements inside the code which can be time consuming and error-prone. By taking a look at the messages being logged, the user is usually able to quickly track down the message/component that is causing the problem (with minimum or no extra effort).
  • Speed of development and cost. Because of all the reasons outlined above, the messaging design pattern is able to substantially improve the speed of development and reduce cost.
  • Quality and software maintenance. Quality and software maintenance efforts are also improved as a result of the all of the above.
  • In order to take full advantage of this design pattern, people need to think in terms of messaging when they model, design and build software applications: independent entities (i.e. components) interchanging messages among each other. This may require learning time and training. Although a messaging approach is natural, intuitive, and consistent with the real world, traditional approaches are based on libraries and method/procedure invocation (both local and remote).
  • MDP behaves like a state machine. Therefore it can be extended to provide fault-tolerant capabilities in a very natural and intuitive fashion by replicating components and coordinating their interaction via consensus algorithms. Adding fault-tolerant characteristics to a program that doesn’t use MDP is, in general, a difficult undertaking.

Implementation and Code Examples:

The messaging design pattern is implemented using the Jt messaging interface (JtInterface). This interface consists of a single method:

Listing 1. Messaging Interface
public interface JtInterface  {

/**
  * Jt messaging interface used for the implementation
  * of the messaging design pattern.
  * Process an input message and return a reply (output message). 
  */

  Object processMessage (Object message); 
}

The messaging interface (JtInterface) is simple but powerful. The simplicity of this interface can be deceiving. One method is all that is needed! It acts as a universal messaging interface that applies to remote and local framework components. This interface handles any type of message (Object class). Although a Java implementation is presented here, MDP and the associated framework can be implemented using any computer language or technology.


Design Pattern implementation

As stated earlier, MDP has been used to implement and/or facilitate the implementation of other well-known design patterns like Gang of Four design patterns (GoF), DAO, J2EE Design patterns, etc. A couple of patterns will be used to illustrate how this is accomplished. The same concepts apply to the implementation of many others. The Jt framework employs these patterns for the implementation of advanced capabilities.

Proxy

The messaging design pattern facilitates the implementation of Proxy. Under the messaging paradigm, Proxy is mainly responsible for forwarding the input message to the real subject.

Figure 4. MDP implementation of Proxy
MDP implementation of Proxy

Adapter

The messaging design pattern facilitates the implementation of Adapter. The main purpose of Adapter becomes the transformation of messages between Sender and Receiver so that these components can be interconnected.

Figure 5. MDP implementation of Adapter
MDP implementation of Adapter

Web Services and transparent access

Notice that MDP sender and receiver don't need to be running on the same host. Messages can be sent to remote components. MDP doesn't impose limitations in this regard. Using a real-world analogy, you can communicate with a friend across the room or thousands of miles away via a phone/internet conversation. MDP is able to handle all these scenarios. You and your friend don’t need to be concerned as to how your conversation is transmitted (technologies, communication protocols, security mechanisms, etc). As it should be, all of this is transparent to you.

As Figure 6 shows, the messaging design pattern and several of the other design patterns discussed earlier can be combined to implement access to remote components. MDP is able to provide transparent and secure access to remote components/services regardless of the protocol and communication technology being used: remote component are treated as local components. Messages can be transferred via web services, REST, EJBs, RMI, HTTP, Sockets, SSL or any similar communication interface. The design patterns discussed above make this possible by hiding the complexities associated with remote APIs.

Figure 6. MDP transparent access to distributed components/services
MDP transparent access to distributed components/services

For clarity sake the messenger component and the intrinsic processMessage() method have been removed from this and the following UML diagrams. Although asynchronous messaging is supported, only synchronous messaging is shown.

  1. Proxy: the message is sent to the remote component via its proxy.
  2. Remote Adapter : adapter responsible for interfacing with the remote API by converting the messages.
  3. Façade: forward the message to the appropriate remote component. It usually provides security capabilities as well.

Going back to our real-world analogy, the framework maintained by the phone company will require some sort of registry (phone book) so that other participants can be located. Each entity will have associated a phone number or ID. A simple naming mechanism is all that is required. In some cases we may need to provide a city code and/or country code. The postal service and your internet service provider also use a relatively simple naming scheme.

Other service providers take advantage of the framework and use custom authentication/authorization mechanisms. Your banking institution, for instance, makes use of the phone system and has Access Management mechanisms for authorization and authentication purposes. We are required to provide some piece of information to authenticate our identity before being granted access to an account.

The additional framework components required are not too different from the ones outline above. The façade component is usually responsible for security (messaging authorization and authentication). Before the message is forwarded to the receiver, Facade performs decryption, authorization and authentication on it.

Figure 7. MDP secure access to distributed components/services
MDP secure access to distributed components/services

The following are the components involved:

MessageCipher: component responsible for decrypting the input message and encrypting the reply message. This component can be configured to use a specific encryption scheme.

Component Registry: allows the system to register and look up components by ID.

AccessManager: responsible for granting/denying access to remote components. It authorizes and authenticates each message received. If the access manager is unable to authenticate the message, it never reaches the receiver.


Framework Security

MDP can deal with security challenges in a natural and intuitive manner. It provides end-to-end, non-repudiation and message-level security (as opposed to transport level security). It can also be used for selective encryption so that only sensitive portions of the message are encrypted. Well-known security mechanisms fit well with MDP. On the other hand, our model is not limited to a specific message format (XML, SOAP, etc.). Any message format and RESTful services can be accommodated. This includes proprietary and custom message formats.

Notice that under a messaging paradigm; most of the security aspects can be made transparent to message sender and receiver. For instance, sender and receiver don't need to be overly concerned as to whether or not security is being used and how it is being implemented. The framework provides the required security components and mechanisms ("plumbing"). Using our real-world analogy, in general you and your friend don't need to be concerned if the service provider is encrypting your conversation because of privacy and security considerations. The Jt framework also uses declarative security which avoids the need for error-prone security coding. Finally, custom security mechanisms can be accommodated based on specific requirements.


Asynchronous messaging, two-way messaging and multithreading

Now consider your email or postal mailbox. Messages can be sent asynchronously and placed in a message queue or pile until you are ready to "process" them. MDP is able to handle the complexities associated with and asynchronous messaging and multithreading. Framework components are able to execute in a separate/independent thread. This is a natural representation of the real world: each component (entity) is a self-contained unit able to execute independently for the rest of the system. Messages can be processed asynchronously using the component’s own independent thread. This capability is implemented in the context of the Jt framework via a messaging queue. The component does not need to add separate logic to manage multithreading which is time consuming, complex and prone to error.

You can also decide to send a message back asynchronously establishing a two-way communication. MDP is able to model two-way asynchronous messaging in which components and applications communicate with each other. A combination of synchronous and asynchronous messaging is also possible. Consider the case where a co-worker or supervisor comes to check on progress while you are reading your email messages.


Performance, scalability and fault-tolerant considerations

The MDP model is simple yet versatile and robust. It is able to handle complex issues associated with distributed applications. MDP is compatible with common scalability and availability mechanisms (clustering, load balancing, failover, caching, etc). For instance, SOA and ESB applications based on MDP can run on a cluster of computers to improve reliability and availability. You also have the flexibility of choosing and combining protocols and technology while using MDP. You are not limited to a specific technology or protocol. Your choices will depend on the specific performance and availability requirements.

MDP can also be extended in a very natural way to provide fault-tolerant capabilities and techniques. The replicated state machine approach is a general method for implementing fault-tolerant systems by replicating components and coordinating their interaction via consensus algorithms. Framework components happen to behave like a state machine: input message, output message and component state are part of the model.


Enterprise Service Bus (ESB) capabilities

The Jt Design Pattern Framework is also a messaging engine that provides Enterprise Service Bus (ESB) capabilities. It features transparent access to components running inside remote applications. Framework components (local and remote) are able to interchange messages securely. The Jt framework also allows you to connect heterogeneous applications regardless of the technologies being used, including JMS, Web Services, EJB, REST, HTTP, EJBs, etc. Design patterns implemented by the framework (messaging, adapters, remote proxies, strategy, facades, etc.) make this possible. The Jt Enterprise Service Bus implementation consists of the following main components:

  • Enterprise Service Bus Adapter
  • JMS Adapters (point-to-point and publish-subscribe)
  • EJB Adapter
  • EJB Proxy
  • RESTful web services Adapter
  • Secure web services Adapter (Axis)
  • Axis Proxy
  • Message Cipher
  • Message Authenticator
  • Access Manager
  • Data Access Objects
  • Java Mail Adapter
  • XML/Component transformer

These components can be interchangeably plugged into complex framework applications using the "lego/messaging" architecture. They can be assembled in a variety of configurations to meet specific business requirements. In this case, these building blocks have been put together to implement the Enterprise Service Bus (ESB) capabilities.

The framework ESB adapter connects applications to the Jt enterprise service bus. The ESB adapter can be configured to use any strategy for interchanging messages: JMS, secure Axis Web services, EJBs, secure Restful web services, HTTP, etc. Custom/proprietary strategies and protocols may also be used. The ESB adapter and the other ESB components are also responsible for automatically converting the messages to the appropriate format/protocol.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=492260
ArticleTitle=Jt - Java Pattern Oriented Framework
publish-date=05272010