As we have all the core level improvements done to cater the requirements
of cloud connectors, we have started the implementation of the connectors.

So as the first milestone, we are planning to have Salesforce (basic impl)
and Google SpredSheet connectors and implement an integration scenarios out
of those connectors. Also for the first milestone, we will include the
twitter connector as well.

The plan is to ship connectors with ESB 4.9 along with tooling support from
DevS.  The set of connectors planned for this are Salesforce, Google Spread
Sheet, Twitter, Jira and Twilio.

Some of the sample configs from the twitter connector with its dynamic
synapse configs :


<proxy name="SearchPlacesTwitter"
          transports="https http"
          startOnLoad="true"
          trace="disable">
      <description/>
      <target>
         <inSequence>
            <log/>
            <twitter.search_places>
               <parameter name="oauth.consumerSecret"
                          value="xxx"/>
               <parameter name="oauth.accessTokenSecret"
                          value="xx"/>
               <parameter name="oauth.accessToken"
                          value="x-x"/>
               <parameter name="oauth.consumerKey" value="x"/>
               <parameter name="latitude" value="40.71435"/>
               <parameter name="longitude" value="-74.00597"/>
            </twitter.search_places>
            <header name="To" action="remove"/>
            <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
            <property name="RESPONSE" value="true" scope="default"
type="STRING"/>
            <send/>
         </inSequence>
      </target>
   </proxy>


   <proxy name="getUserTimeLine"
          transports="https http"
          startOnLoad="true"
          trace="disable">
      <description/>
      <target>
         <inSequence>
            <log/>
            <twitter.get_user_timeline>
               <parameter name="oauth.consumerSecret"
                          value="xx"/>
               <parameter name="oauth.accessTokenSecret"
                          value="xx"/>
               <parameter name="oauth.accessToken"
                          value="x-x"/>
               <parameter name="oauth.consumerKey" value="xx"/>
            </twitter.get_user_timeline>
            <header name="To" action="remove"/>
            <property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
            <property name="RESPONSE" value="true" scope="default"
type="STRING"/>
            <send/>
         </inSequence>
      </target>
   </proxy>




---------- Forwarded message ----------
From: Kasun Indrasiri <[email protected]>
Date: Fri, May 17, 2013 at 1:31 PM
Subject: Synapse Dynamic configuration for Cloud Connectors
To: architecture <[email protected]>, DEV <[email protected]>
Cc: Sanjiva Weerawarana <[email protected]>, Paul Fremantle <[email protected]>,
Samisa Abeysinghe <[email protected]>, Azeez Afkham <[email protected]>,
Isabelle Mauny <[email protected]>, Miyuru Wanninayaka <[email protected]>,
Dushan Abeyruwan <[email protected]>, Harshana Martin <[email protected]>,
Srinath Perera <[email protected]>


Hi,

As per the discussions we had on the Cloud Connector implementation in ESB,
initially we came up with a model where we have a <*connector*> element for
each connector invocation. That was mainly due to the limitations of
Synapse because of Synapse doesn't support dynamic config at that time.
Having a dynamic generation of config based each connector is having so
many advantages over the fixed connector config approach.

So, we have modified synapse such that it can load dynamic configuration,
iff a mapping template is defined as a mediation-library and imported in to
the synapse config.

There were few areas that we have to change to carter this requirement.
 - Initial sequence/mediator deployment during start-up.  (Look for imports
and resolve the dyn
-  Hot deployment of artifacts
- Synapse library and import apis.

In summary, the way how it works is:

- Connector is implemented as a mediation library along with all the
required templates and class mediators (or any other resource). Refer : *
wso2_twitter.zip*

- Once the connector (mediation lib) is deployed in the ESB, then the uses
can import it with the use of synapse imports which will be applied
globally for the synapse config.
eg: *<import xmlns="http://ws.apache.org/ns/synapse"; name="twitter"
package="org.wso2.carbon.connectors" /> *

- Once the required connector (mediation lib) is imported, users can write
the synapse config as the naming that's used in the connector. For
instance, say that I have defined a template named "*
twitter.update_status.xml*" in my connector, then a user can simply invoke
the connect as follows.


<sequence xmlns="http://ws.apache.org/ns/synapse"; name="doTweet">
 <*twitter.update_status*>
 <parameter name="oauth.consumerSecret" value="xxxxxxxxxxx"/>
 <parameter name="oauth.accessTokenSecret" value="xxxxxxxxxxx"/>
 <parameter name="oauth.accessToken" value="xxxxxxxxxxx"/>
 <parameter name="oauth.consumerKey" value="xxxxxxxxxxx"/>
<parameter name="status" value="WSO2 Twitter Connector - Dynamic Synapse
config test for Twitter.... #wso2"/>
 </*twitter.update_status*>
</sequence>


- Please note that above config is completely dynamic as it is resolved by
looking at the available connectors in the run time. So, any use can write
its own connector and its own invocation language in the synapse config.
Internally, the execution is pretty similar to a call-template mediator.

With this approach, I've implemented the twitter connector for update
status operation and it works fine. Please use the attached synapse-core
patch and all the required config are also attached.

- When it comes to tooling, DevStudio simply look at the provided connector
archive (eg: *wso2_twitter.zip*) and it can easily find what are the
operations provided by a given connector and generate
graphical constructs(eg;one for tweet, one for retweet etc) as per the
operations.

Thanks.

-- 
Kasun Indrasiri
Associate Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

cell: +94 71 536 4128
Blog : http://kasunpanorama.blogspot.com/



-- 
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

cell: +94 71 536 4128
Blog : http://kasunpanorama.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to