IBM® is a registered trademark of International Business Machines Corporation. Anmonk, New York, U.S.A. Other names used herein may be registered trademarks, trademarks or product names of International Business Machines Corporation or other companies.
1. Field of the Invention
This invention relates to aspect oriented programming, and particularly to systems, methods and computer products for data oriented aspect programming in message flows.
2. Description of Background
Message Oriented Architecture (MOA) describes a system integration approach where applications can communicate with other applications though the exchange of messages without having to know what platform or processor the other application resides on within the network. The messages can contain formatted data, requests for action, or both. A message flow describes a controlled and directed flow of messages across a sequence of flow primitives, usually starting with the receipt of a message by an operation and ending with the return of the response from the operation or calls to an external Service partner. A flow primitive in a message flow typically represents a unit of work that must be completed before the next flow primitive or next set of flow primitives are executed. These flow primitives are used to broker messages, typically performing Junctions like routing, logging and transformation. There need be no restriction on the function of these flow primitives, but they typically act on or change the content or context (headers) of the message.
Message Flows are also used in an Enterprise Service Bus (ESB) to support Service Oriented Architecture (SOA), whereby the message is simply the payload or parameters of a Service call. However, current message flow programming model often relies on the user to define message flow statically. The user often has to go back to the original tool to change the message flow if there are any changes in business conditions. One of the advantages provided by the ESB is the use of a canonical logical Message format based on XML. By leveraging the canonical format, it enables the introduction of AOP (Aspect-Oriented Programming) to messages flow based on a set of static and dynamic data-oriented join conditions. The data for the join conditions is the content and context of the messages, as described by their canonical format.
There exists a need for applying AOP to message flow based on a set of static and dynamic data-oriented join conditions.
Exemplary embodiments include a method for supporting dynamic changes in message flow using aspect oriented programming technique within a computing system, the method including defining a set of static and dynamic rules to identify a plurality of data-oriented join points in a message flow, wherein each of the plurality of join points is a specific point in the message flow at runtime, defining a set of actions for each of the plurality of data-oriented join points, the set of actions executing once a respective join point condition of a set of static and dynamic conditions are met, inserting the set of static and dynamic rules into the message flow at each of the plurality of data-oriented join points and executing the set of actions for each one of the inserted set of static and dynamic rules in response to a respective static and dynamic condition being met.
Further exemplary embodiments include a system for supporting dynamic changes in aspect oriented programming, the system including a processing device having a memory, a process residing in the memory having instructions for defining a set of static and dynamic rules to identify a plurality of data-oriented join points in a message flow, wherein each of the plurality of join points is a specific point in the message flow at runtime, defining a set of actions for each of the plurality of data-oriented join points, the set of actions executing once a respective join point condition of a set of static and dynamic conditions are met, inserting the set of static and dynamic rules into the message flow at each of the plurality of data-oriented join points, executing the set of actions for each one of the inserted set of static and dynamic rules in response to a respective static and dynamic condition being met and defining a message subflow containing message oriented programming.
System and computer program products corresponding to the above-summarized methods are also described and claimed herein.
Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention. For a better understanding of the invention with advantages and features, refer to the description and to the drawings.
As a result of the summarized invention, technically we have achieved a solution which applies AOP to message flow based on a set of static and dynamic data-oriented join conditions.
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
The detailed description explains the preferred embodiments of the invention, together with advantages and features, by way of example with reference to the drawings.
In exemplary embodiments, the systems and methods described herein implemented data-oriented AOP to support dynamic changes to message flows at runtime. In exemplary embodiments, the systems and methods described herein implement a set of static and dynamic rules to identify data-oriented “join points” in a message flow. A “join point” is a specific point in a message flow at runtime based on static and dynamic conditions. Furthermore, the systems and methods described herein implement a flow aspect, which is a “join point”, together with a set of actions that execute once the “join point” condition is met.
Turning now to the drawings in greater detail, it will be seen that in
Based on the message flow programming model as illustrated by the flow diagram 300 and the use of a canonical data format, the join points 305, 310 can be qualified by providing additional selection filter such as the use of certain data types in message, the use of certain primitive types, and the existence of certain values in the message. In exemplary embodiments, an arbitrary selection filters can be inserted at the join points 305, 310 for evaluation at runtime. For example, based on the flow specified in
In addition, join point 310 can be specified to select both terminal B and C, the following join condition is specified:
In exemplary embodiments, a message flow aspect is a combination of one or more join points together with an action to be performed once one of the join points is identified. The action used in a flow aspect can be described by using another message flow (i.e. a standalone subflow).
Based on the above definition, any time the condition specified in join point 305 is satisfied, the flow ActionLog is executed based on the priority sequence specified in this aspect when compared to other aspects that may also be invoked. Other uses of flow aspects are common error handling or logging for governance purposes.
In exemplary embodiments, a message flow meta-aspect is an aspect that can be applied on top of an existing aspect. A meta-aspect is used to handle exception condition of a regular aspect. Depending on the programming model, a meta-aspect may not be applied to another meta-aspect. Furthermore, in exemplary embodiments, a message flow aspect should a separately installable entity to any message flow runtime, which allows the system administrator to turn on/off an aspect based on business needs. In exemplary embodiments, once a message flow aspect is deployed, it is registered with the runtime flow engine. Initially, static conditions are evaluated to scope down the set of possible aspects for any given flow. During message flow execution, each potential aspect is evaluated against the runtime canonical logical message format. Once a join point condition is matched, the flow specified in the aspect is executed.
As such, it is appreciated that by applying the described mechanism to the message flow programming model, dynamic on-demand modification of message flow at runtime based on a data-oriented aspect programming model is supported.
The capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof.
As one example, one or more aspects of the present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.
Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.
The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.
While the preferred embodiment to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.