WPS: Mediation primitives :
Mediation flow components operate on message flows between service components. The capabilities of a mediation component are implemented by mediation primitives, which implement standard service implementation types.
A mediation flow component has one or more flows. For example, one for request and one for reply.
WebSphere® Process Server supports a supplied set of mediation primitives, which implement standard mediation capabilities for mediation modules or modules deployed into WebSphere Process Server. If you need special mediation capabilities, you can develop your own custom mediation primitives.
A mediation primitive defines an "in" operation that processes or handles messages that are represented by service message objects (SMOs). A mediation primitive can also define "out" operations that send messages to another component or module.
You can use WebSphere Integration Developer to configure mediation primitives and set their properties. Some of these properties can be made visible to the runtime administrator by promoting them. Any mediation primitive property that can be promoted can also be a dynamic property. A dynamic property can be overridden, at run time, using a policy file.
WebSphere Integration Developer also allows you to graphically model and assemble mediation flow components from mediation primitives, and assemble mediation modules or modules from mediation flow components. The administrative console refers to mediation modules and modules as SCA modules.
WebSphere Integration Developer also allows the definition of subflows in modules or their dependent libraries. A subflow can contain any mediation primitive except for the Policy Resolution mediation primitive. A subflow is invoked from a request or response flow, or from another subflow using the Subflow mediation primitive. Properties promoted from mediation primitives in a subflow are exposed as properties on the Subflow mediation primitives. These may then be promoted again until they reach the module level at which point they can then be modified by the runtime administrator.
Mediation flow components operate on message flows between service components. The capabilities of a mediation component are implemented by mediation primitives, which implement standard service implementation types.
A mediation flow component has one or more flows. For example, one for request and one for reply.
WebSphere® Process Server supports a supplied set of mediation primitives, which implement standard mediation capabilities for mediation modules or modules deployed into WebSphere Process Server. If you need special mediation capabilities, you can develop your own custom mediation primitives.
A mediation primitive defines an "in" operation that processes or handles messages that are represented by service message objects (SMOs). A mediation primitive can also define "out" operations that send messages to another component or module.
You can use WebSphere Integration Developer to configure mediation primitives and set their properties. Some of these properties can be made visible to the runtime administrator by promoting them. Any mediation primitive property that can be promoted can also be a dynamic property. A dynamic property can be overridden, at run time, using a policy file.
WebSphere Integration Developer also allows you to graphically model and assemble mediation flow components from mediation primitives, and assemble mediation modules or modules from mediation flow components. The administrative console refers to mediation modules and modules as SCA modules.
WebSphere Integration Developer also allows the definition of subflows in modules or their dependent libraries. A subflow can contain any mediation primitive except for the Policy Resolution mediation primitive. A subflow is invoked from a request or response flow, or from another subflow using the Subflow mediation primitive. Properties promoted from mediation primitives in a subflow are exposed as properties on the Subflow mediation primitives. These may then be promoted again until they reach the module level at which point they can then be modified by the runtime administrator.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.