|
Author: Adel S. Eddin The author is the sole owner of all the concepts, intellectual property, terms, framework, and rights presented in this paper.
Download/Request Info
|
ASMAF CMI Unit
A CMI Unit is defined as a warehouse for the exchange of messages. The CMI Unit itself is based on 3 parts. A runtime (CMI runtime FRAK), a set of 2 queues, and a configuration library of all FRAKS registered with the CMI bus.
In a sense, A CMI Unit would operate like the ubiquitous Universal Serial Bus (USB) where devices (FRAKS) bulge into plug and play infrastructure that knows or can discover how to install and instantiate instances of the device (FRAK).
To construct the kind of messaging bus for ASMAF capabilities discussed in this framework, the primary focus of the CMI Unit is on creating and managing communication among the participants (FRAKS) instances who use the messaging bus to exchange messages.
The solution being manufactured should largely be unconstrained in how the CMI Unit delivers messages between FRAKS. Careful design of the CMI runtime should be taken into account when implementing the CMI runtime and the generic message interfaces.
Also, individual solutions being manufactured do not construct messaging capabilities in and of themselves. That functionality is solely controlled by the CMI bus.
Any adoption of the ASMAF framework should provide the CMI Unit connection mechanisms as part of the framework runtime.
The hard part is describing the unified message bus infrastructure and building a managing schema for the communication between the FRAKS. Since the CMI would work as the glue code that will connect all the FRAKS, do diligence should be observed when creating the CMI Unit infrastructure.
The CMI Unit is used for Manufacturing/constructing an ASMAF messaging bus capabilities on top of FRAKS using two-pronged techniques to construct and manage communication among participating FRAKS. For example FRAK “A”, let assume it is an accounting FRAK, may send a message to FRAK “B”, lets assume it is an IO FRAK, to read a file from the file system. FRAK “A” will send a message with FRAK “B” as the destination and places it in the synchronized queue of the CMI bus. The bus will immediately investigate the message structure against a list of valid structures in a configuration file. Once a match is found, the CMI bus will manufacture FRAK “B” (create an instance) and pass it the message payload. Also the payload structure is described in the configuration file. FRAK “B” will read the file and places the content of the file (or a pointer to the file) in the synchronized queue and then inform FRAK “A” that FRAK “B” is done.
The messages can contain targeting information from one FRAK to another or can be a broadcast type for all FRAKS on the CMI bus. Messages on the ASMAF bus can exchange data using two techniques, synchronous or asynchronous, where the CMI bus creates queues to handle each individual method separately. Synchronous methods are implemented through sinks or callbacks where asynchronous are implemented through timers and queues.
CMI Message Interface Logical Definition
A CMI message interface is an agreement that describing the relationships between “A” FRAK and the underpinning CMI Unit solution messaging bus. This agreement is stored and managed by the CMI runtime. A discovery service in the solution investigate the message metadata target FRAK and the services to be performed by the CMI runtime.
CMI Message Logical Definition
A CMI message is stateful, registered, and recoverable structure. It also has a binding mechanism that allows the message to bind to the different FRAKS on the bus. Stability of messaging structure is critical to manufacturing stable and scalable solution. Individual FRAK can change their implementation with no impact on the CMI bus; however, the same cannot be said of CMI bus structure.
Message structures will be defined as extended mark-up language (XML) schemas whose vocabulary will be well defined and explained by ASMAF.
CMI Message Bus Logical Definition
A CMI bus perform discovery services on individual FRAKS, will be able to read the FRAK metadata, capable of instantiating a FRAK instance, and finally manage the communication of the FRAK. The CMI bus will not be responsible for the Life cycle management of the FRAK though. This is the functionality of the FRAK itself or the platform the FRAK is targeted for.
In ASMAF, the CMI bus manages sets of loosely coupled FRAKS designed to work together seamlessly and securely to achieve the systems desired functionality and to allow the consumption of FRAKS.
FRAKS Services
A typical solution has many FRAKS. FRAKS offer services. There are two types of services that FRAKS will offer. Some are considered service consumers FRAKS where others are considered service providers FRAKS. The service each FRAK offer is registry with the CMI bus.
CMI bus Core services
The CMI bus will provide a set of core solution services, including
· Security service,
· Service discovery,
· FRAK-to-FRAK messaging,
· FRAK Creation and instances creations.
· and mediation for data transformation.
CMI Bus also utilizes general purpose core services to perform common functions.
What CMI bus is not?
Even though the CMI bus creates instances of FRAKS, its role does not extend to manages the life cycle of the FRAK. This functionality is the responsibility of the FRAK and/or the targeted platform garbage collection mechanisms.
Mechanizes of moving Messages on the bus
Moving messages between FRAKS on the CMI bus is remarkably similar to moving parts on an assembly line in a manufacturing plant. Decisions by the CMI bus and/or the FRAKS on the bus moves conversation messages through the CMI bus or terminate them inside a FRAK or on the CMI bus itself.
The CMI bus will also make decisions based on configuration settings, create the required FRAKS and hands the message to newly created FRAKS and wait for the FRAKS to make new decisions or terminate the conversations. The process is as follows:
Some Event that the CMI is listening to happens. So as a minimum, ever application must have the CMI as an entry point of any solution. It is what resides in memory once the application is started and the application instance is created.
The CMI will create a FRAK from its list of solution FRAKS that is capable of responding to the event.
The instantiated FRAK request the service of another FRAK. The initial FRAK will send a message with the other FRAK as the agent to fulfill this request.
CMI will search its list of FRAKS and see if this FRAK is part of this solution. If it is, it will create a new instance of the second FRAK and pass it the message from the original FRAK for processing. The CMI will never ever reuse existing instances on ant FRAK.