Difference between revisions of "Adapters-HowTo"
| Line 2: | Line 2: | ||
| − | == | + | == Adapter == |
| + | An adapter gives {{GVESB}} the ability to communicate with external systems. | ||
| + | Such systems can have their own protocol, language, APIs, services, etc. , and the adapter has to behave like an interface and integrate the external system's functionalities into {{GVESB}}. | ||
| + | An adapter is not tied to any particular structure or architecture, it can be implemented as desired, apart from the fact that it must use an interface (like described below) and receive/return a [[GVBuffer]]. | ||
== Configuration Files == | == Configuration Files == | ||
| Line 13: | Line 16: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
for the [[DataHandler]]. | for the [[DataHandler]]. | ||
| − | The Operation interface has three subinterfaces: CallOperation, EnqueueOperation and DequeueOperation, all defined into it.greenvulcano.gvesb.virtual package. The first one represents a syncronous call, the last two are used when dealing with queues. The main method of these interfaces is perform(), that accepts a GVBuffer as input and returns the same GVBuffer as output. When implementing a new adapter it's important to respect this rule and return the buffer received, after having added into it the data concerning the operation performed. This gives {{GVESB}} core the ability to access all input and output data of each operation in a workflow reading the buffer. | + | The Operation interface has three subinterfaces: CallOperation, EnqueueOperation and DequeueOperation, all defined into it.greenvulcano.gvesb.virtual package. The first one represents a syncronous call, the last two are used when dealing with queues. The main method of these interfaces is perform(), that accepts a GVBuffer as input and returns the same GVBuffer as output. |
| + | |||
| + | When implementing a new adapter it's important to respect this rule and return the buffer received, after having added into it the data concerning the operation performed. This gives {{GVESB}} core the ability to access all input and output data of each operation in a workflow reading the buffer. | ||
Revision as of 13:39, 12 October 2012
This is intended as a mini guide for a developer who wants to create a new adapter for GreenVulcano® ESB.
Adapter
An adapter gives GreenVulcano® ESB the ability to communicate with external systems. Such systems can have their own protocol, language, APIs, services, etc. , and the adapter has to behave like an interface and integrate the external system's functionalities into GreenVulcano® ESB. An adapter is not tied to any particular structure or architecture, it can be implemented as desired, apart from the fact that it must use an interface (like described below) and receive/return a GVBuffer.
Configuration Files
Interfaces methods
The Operation interface has to be implemented each time a new GVVCL object is designed to make a call to an external system. The Node passed to the init() method is the one that we can find in the GVAdapters.xml configuration file. Each time you create an adapter you will add a section (node) into such file, like, for example:
<GVDataHandlerConfiguration name="DH_ENGINE" type="module" version="1.0">
for the DataHandler. The Operation interface has three subinterfaces: CallOperation, EnqueueOperation and DequeueOperation, all defined into it.greenvulcano.gvesb.virtual package. The first one represents a syncronous call, the last two are used when dealing with queues. The main method of these interfaces is perform(), that accepts a GVBuffer as input and returns the same GVBuffer as output.
When implementing a new adapter it's important to respect this rule and return the buffer received, after having added into it the data concerning the operation performed. This gives GreenVulcano® ESB core the ability to access all input and output data of each operation in a workflow reading the buffer.
