One possibility is to embed the version in to the connector name itself. So
that the invocation would looks like either
<sfdc_2.0.query >
<batchSize>200</batchSize>
<queryString>select test</queryString>
</sfdc_2.0.query>
or as follows.
<sfdc.query version="2.0">
<batchSize>200</batchSize>
<queryString>select test</queryString>
</sfdc.query>
With this both ESB and DevS can handle multiple versions.
Other alternative is to introduce a versioning strategy in to connector
(former: mediation-lib) itself. However,IMO, this needs to be done along
with versioning support for all other artifacts such as sequence,
endpoints, proxy services etc.
On Mon, Aug 12, 2013 at 10:43 PM, Sanjiva Weerawarana <sanj...@wso2.com>wrote:
> Have we thought about $subject? Can someone elaborate the architecture for
> versioning of connectors please? Need to get that right.
>
> The tooling team also has to handle connector versions.
>
> Both ESB runtime and tool have to be able to load multiple connector
> versions at once (think data migration scenarios).
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
> 650 265 8311
> blog: http://sanjiva.weerawarana.org/
>
> Lean . Enterprise . Middleware
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
