Images have not been added due to some limitation in google docs. I am
attaching the images separately and resending.
WSO2 ESB connectors provides the capability to connect to publicly
available APIs using simple xml configurations. This makes the life easier
for the users who are using WSO2 ESB.We have come across a new requirement
for WSO2 ESB connectors for the ongoing IPAAS implementation. In this, we
are creating recipes which are a collection of 2 or more connectors. As an
example, we can define a recipe to get Salesforce account details and
upload them to google spreadsheet. When we do this kind of wiring of
connectors, output of the incoming connector(salesforce) and the input of
the outgoing connector(googlespreadsheet) should match to make this
scenario working as expected as shown in below picture.
In the current connector implementation, the output message format is not
defined for a given operation (method). Therefore, when wiring the
connectors with each other, we need to read through the documentation and
find the response format. Then user needs to transform that message to a
format which the outgoing connector (GoogleSpreadsheet) understands. This
is neither straight forward nor easy procedure to follow when creating
recipes.
We have come up with a solution to overcome this kind of behavior by
introducing type awareness to template mediators (connector templates).
With this solution, every connector template mediator will be associated
with a particular input type and output type. These input/output types are
defined in a separate schema file (avro schema - avsc). The below picture
depicts the conceptual view of the type definitions of a template mediator.
As depicted in the picture, we are going to define the type information in
a separate meta file (schema) such that any component which is going to
render the user interfaces which comprises of template mediators can easily
understand about the input/output data types. One good example is when we
are wiring connectors to create recipes, we can suggest the parameters
needs to mapped in the outgoing connector with the incoming connector.
We need to address the following issues to come up with a solution for this
implementation
How to associate these type definitions at configuration level
Type awareness is mainly used in ESB connector related mediators. Let’s
take the GoogleSpreadsheet connector as an example. It has an operation
named createSpreadsheet. This can be configured in synapse configuration as
mentioned below.
<googlespreadsheet.createSpreadsheet configKey="xxx">
<spreadsheetName>Employees</spreadsheetName>
<worksheetCount>2</worksheetCount>
</googlespreadsheet.createSpreadsheet>
With the current implementation, user of this mediator does not have an
idea about what is coming as the result. With the introduction of the type
awareness concept, this configuration will change as mentioned below.
<googlespreadsheet.createSpreadsheet configKey="xxx" inType=”in”
outType=”out”>
<spreadsheetName>Employees</spreadsheetName>
<worksheetCount>2</worksheetCount>
</googlespreadsheet.createSpreadsheet>
These type definitions are stored in a meta file. We are planning to use
Apache Avro as the underlying meta data serialization and deserialization
engine. We can define the schema for the above mediator like below.
{"namespace": "org.apache.synapse",
"type": "record",
"name": "SynapseDataType",
"fields": [
{"name": "in", "type":{ "type": "record", "name": "InputType",
"fields": [
{"name": "spreadsheetName",
"type": "string"},
{"name": "worksheetCount",
"type": ["int", "null"]}
]}},
{"name": "out", "type":{ "type": "record", "name": "OutputType",
"fields": [
{"name": "result", "type": "string"}
]}}
]
}
In the above meta data file, we have defined the input type and the output
type data format. Once we have this meta data file defined, users of this
mediator can derive the input/output data types without actually using
(calling) these mediators.
How the synapse runtime handle type definitions defined in the
configuration
Once we define these types in the synapse configuration, we need to
consider about the runtime perspective of these definitions. At the synapse
level, it does not care about the data flowing through the synapse engine
unless otherwise the user interacts with them. Therefore, we don’t need to
consider these definitions at run time. (This is open for debate)
What is the format of the meta data file (avro schema)
As mentioned in 1), we will be using Apache Avro as the underlying meta
data engine. It provides the capabilities for defining a schema for a given
connector operation mediator. Each connector operation will be associated
with a particular avro schema definition file (.avsc).
Where do we keep the metadata file?
This meta file is associated with the connector operation. Currently in the
connector archive, every operation has a separate xml file. We will define
a new avro schema file (.avsc) for each operation. As an example, we will
have a create_worksheet.avsc file in addition to the create_worksheet.xml
file. This file will be archived with the connector zip file.
How to use the schema file to generate the UI intelligently (Dev
Studio/Code Envy/IPAAS UI)
Once we define the schema meta file, applications which render the user
interfaces can read the data from this meta file. This meta file will
contain json data and that would make the life easier for the UI
application.
This is an initial design of the type awareness support in WSO2 ESB. Any
suggestions/feedback would be highly appreciated.
--
--
Chanaka Fernando
Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 773337238
Blog : http://soatutorials.blogspot.com
LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
Twitter:https://twitter.com/chanakaudaya
Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
