jt--Framework for Java-mode

Overview

Jt is a design pattern framework for fast implementation of Java applications. Jt has applications in many large mission-critical systems. The framework achieves the following objectives:

The framework architecture is based on a messaging design pattern: A framework component can interact with information and perform calculations by sending, receiving, and processing messages. A messaging API is simple, powerful, and loosely coupled; You can use a "lego/messaging" schema to swap a framework component into a complex framework application. You can perform synchronous or asynchronous processing on a frame message. The framework fully utilizes the function and simplicity of the message design pattern/API.

The design pattern framework uses message routing to implement and/or promote the implementation of well-known design patterns such as Gang of Four (GoF) and Java EE. The framework itself has been completely created and implemented based on design patterns. The framework also facilitates and accelerates application implementation based on design patterns.

The framework lego/messaging schema provides transparent and secure access to remote components, and remote frame objects can be treated as local objects. Design patterns implemented by the framework (messaging, adapters, remote agents, and skins) hide the complexity associated with remote APIs for transparent and secure access. Built-in components for message encryption and authentication are also provided.

The framework provides transparent integration with other technologies through the implementation of framework adapters, agents, and related design patterns. These technologies include BPM, the Data Access Object Implementation (DAO), Model View Controller Implementation (MVC), EJBs, JSP, AJAX, ESB, JMS, XML, REST, and Web services.

The framework is designed for lightweight and fast features (small overhead/low memory footprint).

The framework Messaging/lego architecture enhances and simplifies design/development work. There is a close correspondence between the UML design diagram and the messaging-based framework applications and components required for implementation. The framework provides the wizards and automation required to build a framework application. You can easily add a framework component to a Bpm/bpel flowchart. In a future version of the framework, you should be able to generate an application module directly from a UML design diagram. The goal is still in the process of development.

Framework messaging architecture facilitates testing and debugging efforts. The framework can be tested by dividing components into stand-alone units by sending messages to components and validating reply messages.

Message Delivery design mode (MDP)

Intent (Intent): The Messaging design pattern supports the exchange of information between components and applications (for example, messages).

Motivation (Power): This design pattern can be used to solve a wide variety of problems in many different scenarios. A messaging paradigm is widely used in patterns and in the real world. There is a exchange of information around us. Entities are constantly sending, receiving, and processing messages. For example: When we watch TV, listen to music, answer the phone or communicate over the Internet. Now, you are reading this written message. Because computer applications seek to model the real world, it is most natural to design and write an application using messaging methods. We can say that this approach provides a more complex and accurate rendering of the real world (for example, models). As a result, the software engineering process has been significantly improved through the use of messaging design patterns.

Participants:

Message sender: The component that sends the message.

Message receiver (reciever): A component that receives input messages that may generate a reply (output message) after the message is processed. Generally, an input message may contain any type of information. Components may also perform calculations based on input messages.

Messenger: The intermediary that transmits information from the sender to the receiver. The sender and receiver do not need to care about the transmission of the information (Communication protocol, message format, encryption/security mechanism, etc.) and the conversion to the message along the way. This is the purpose and duty of the messenger. Similar to the real world, there is often no need to use messengers. You can send a message directly to the receiver. Communication modes include synchronous, asynchronous, and bidirectional message delivery.

Message: Any information (for example, data) that needs to be exchanged between the sender and the receiving party. Usually involves two kinds of messages: input messages and output messages (or reply messages). The reply message is not required.

Figure 1. Message Delivery interface

Figure 2. Message transfer design mode (sync mode)

Figure 3. Messaging design mode (sync mode without messenger)