All connection information needs to be stored outside of the config , potentially in a security vault, same as userid/passwords. I think we need a connector security config, which can be also changed from one environment (dev, QA, etc.) to another.
Also, for all connectors who require OAuth for authentication , I think we need a common authentication module which manages access/refresh tokens , and can be used dynamically from a sequence/proxy. Isabelle. __________________________________________________ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 16, 2013, at 7:37 AM, Kasun Indrasiri <[email protected]> wrote: > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
