You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Thilini Gamage <tg...@gmail.com> on 2013/09/24 19:41:05 UTC
Re: Synapse Proxy Services Versioning
Hi all,
In Synapse Artifact versioning, I kept the versioning stuff like artifact
version key generators, versionFactory classes, version based serializer
classes etc in core module. But while proceeding with task versioning, I
faced with some dependency cycles between task module and core module. To
avoid this can't we migrate versioning stuff to commons module. Or is it ok
to create a separate module for versionong stuff?
On Tue, Aug 20, 2013 at 8:53 AM, Thilini Gamage <tg...@gmail.com>wrote:
> The UUID's are never exposed to users. There is a conversion of a given
> artifact name and version into uuid and that particular uuid is used for
> artifact deployment, removal, dispatching etc.
>
>
> On Tue, Aug 20, 2013 at 4:52 AM, Hiranya Jayathilaka <hiranya911@gmail.com
> > wrote:
>
>>
>> On Aug 19, 2013, at 2:02 PM, Udayanga Wickramasinghe <
>> mastershield2007@gmail.com> wrote:
>>
>> Hi,
>> sorry for my late reply.
>> +1 for hierarchical services. I think one other alternative is to
>> implement versioned proxy services through 'version' attribute which is how
>> sequences/endpoints are versioned right now. We plan to represent different
>> versions of same service using a unique id (uuid) and register them in
>> 'AxisConfiguration'/SynapseConfig.
>>
>>
>> This sounds good. It's consistent with how the other artifacts are
>> versioned in Synapse.
>>
>> However this requires a special handler (ie:- Axis2 handler/dispatcher)
>> to convert a name,version pair to the respective uuid and dispatch to the
>> relevant service.
>>
>> ie:- handler will convert /services/TestProxy/1.0.0 to
>> /services/TestProxy_1.0.0_{uuid}
>>
>>
>> The UUIDs are never exposed to the user right?
>>
>> Thanks,
>> Hiranya
>>
>>
>> Regards
>> Udayanga
>>
>> On Sun, Aug 11, 2013 at 2:46 PM, Hiranya Jayathilaka <
>> hiranya911@gmail.com> wrote:
>>
>>>
>>> On Aug 11, 2013, at 4:52 AM, Thilini Gamage <tg...@gmail.com>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm currently working on the GSOC project of 'Versioning of Synapse
>>> Artifact' [1] and up to now I have completed the versioning of Synapse
>>> sequences ( including main sequences) and endpoints. The versioning of
>>> sequence and endpoints is done by generating an unique identifier (based on
>>> artifact name and version) for each versioned artifact and maintaining that
>>> unique identifier in deployment and run time dispatching etc.
>>>
>>> Now I'm looking into proxy services versioning and according to my
>>> understanding the proxy services versioning can to be enabled by building
>>> axis2 service for each versioned proxy. The axis2 service deployment and
>>> dispatching should be done using a generated unique identifier.
>>>
>>>
>>> I think this should be similar to API versioning. APIs use the
>>> VersioningStrategy interface to determine how the version numbers are
>>> associated with individual APIs. The default implementation uses a
>>> URL-based strategy.
>>>
>>> e.g. /context/1.0.0/foo/bar
>>>
>>> You can take a similar approach for proxy services. May be we only need
>>> URL based versioning in the case of proxy services. Since proxy services
>>> deal with SOAP messages, I don't think other options make much sense. So we
>>> probably need something like:
>>>
>>> /services/TestProxy/1.0.0
>>>
>>> The main problem however is representing different versions of the same
>>> service in the SynapseConfiguration/AxisConfiguration. Axis2 supports
>>> something called hierarchical services (see
>>> https://issues.apache.org/jira/browse/SYNAPSE-914). May be you can try
>>> to leverage that.
>>>
>>> Thanks,
>>> Hiranya
>>>
>>>
>>>
>>> Any comments and suggestions on this?
>>>
>>> [1]-https://issues.apache.org/jira/browse/SYNAPSE-928
>>> --
>>> Thilini
>>> Thilini Shanika Gamage
>>> Department of Computer Science and Engineering
>>> University of Moratuwa
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>> Mayhem Lab/RACE Lab;
>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu
>>> E-mail: hiranya@cs.ucsb.edu <hi...@wso2.com>; Mobile: +1 (805)
>>> 895-7443
>>> Blog: http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/>
>>>
>>>
>>
>>
>> --
>> http://www.udayangawiki.blogspot.com
>>
>>
>> --
>> Hiranya Jayathilaka
>> Mayhem Lab/RACE Lab;
>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu
>> E-mail: hiranya@cs.ucsb.edu <hi...@wso2.com>; Mobile: +1 (805)
>> 895-7443
>> Blog: http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/>
>>
>>
>
>
> --
> Thilini
> Thilini Shanika Gamage
> Department of Computer Science and Engineering
> University of Moratuwa
>
--
Thilini
Thilini Shanika Gamage
Department of Computer Science and Engineering
University of Moratuwa
Re: Synapse Proxy Services Versioning
Posted by Udayanga Wickramasinghe <ma...@gmail.com>.
I think this is an inherent problem with tasks versioning because many of
the descriptors are on task module and not on core. I would like to see a
new module but considering that we don't have a whole lot , best option is
to migrate versioning stuff to commons and let modules/core and
modules/tasks depend on that.
On Tue, Sep 24, 2013 at 1:41 PM, Thilini Gamage <tg...@gmail.com>wrote:
> Hi all,
> In Synapse Artifact versioning, I kept the versioning stuff like artifact
> version key generators, versionFactory classes, version based serializer
> classes etc in core module. But while proceeding with task versioning, I
> faced with some dependency cycles between task module and core module. To
> avoid this can't we migrate versioning stuff to commons module. Or is it
> ok to create a separate module for versionong stuff?
>
>
> On Tue, Aug 20, 2013 at 8:53 AM, Thilini Gamage <tg...@gmail.com>wrote:
>
>> The UUID's are never exposed to users. There is a conversion of a given
>> artifact name and version into uuid and that particular uuid is used for
>> artifact deployment, removal, dispatching etc.
>>
>>
>> On Tue, Aug 20, 2013 at 4:52 AM, Hiranya Jayathilaka <
>> hiranya911@gmail.com> wrote:
>>
>>>
>>> On Aug 19, 2013, at 2:02 PM, Udayanga Wickramasinghe <
>>> mastershield2007@gmail.com> wrote:
>>>
>>> Hi,
>>> sorry for my late reply.
>>> +1 for hierarchical services. I think one other alternative is to
>>> implement versioned proxy services through 'version' attribute which is how
>>> sequences/endpoints are versioned right now. We plan to represent different
>>> versions of same service using a unique id (uuid) and register them in
>>> 'AxisConfiguration'/SynapseConfig.
>>>
>>>
>>> This sounds good. It's consistent with how the other artifacts are
>>> versioned in Synapse.
>>>
>>> However this requires a special handler (ie:- Axis2 handler/dispatcher)
>>> to convert a name,version pair to the respective uuid and dispatch to the
>>> relevant service.
>>>
>>> ie:- handler will convert /services/TestProxy/1.0.0 to
>>> /services/TestProxy_1.0.0_{uuid}
>>>
>>>
>>> The UUIDs are never exposed to the user right?
>>>
>>> Thanks,
>>> Hiranya
>>>
>>>
>>> Regards
>>> Udayanga
>>>
>>> On Sun, Aug 11, 2013 at 2:46 PM, Hiranya Jayathilaka <
>>> hiranya911@gmail.com> wrote:
>>>
>>>>
>>>> On Aug 11, 2013, at 4:52 AM, Thilini Gamage <tg...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I'm currently working on the GSOC project of 'Versioning of Synapse
>>>> Artifact' [1] and up to now I have completed the versioning of Synapse
>>>> sequences ( including main sequences) and endpoints. The versioning of
>>>> sequence and endpoints is done by generating an unique identifier (based on
>>>> artifact name and version) for each versioned artifact and maintaining that
>>>> unique identifier in deployment and run time dispatching etc.
>>>>
>>>> Now I'm looking into proxy services versioning and according to my
>>>> understanding the proxy services versioning can to be enabled by building
>>>> axis2 service for each versioned proxy. The axis2 service deployment and
>>>> dispatching should be done using a generated unique identifier.
>>>>
>>>>
>>>> I think this should be similar to API versioning. APIs use the
>>>> VersioningStrategy interface to determine how the version numbers are
>>>> associated with individual APIs. The default implementation uses a
>>>> URL-based strategy.
>>>>
>>>> e.g. /context/1.0.0/foo/bar
>>>>
>>>> You can take a similar approach for proxy services. May be we only need
>>>> URL based versioning in the case of proxy services. Since proxy services
>>>> deal with SOAP messages, I don't think other options make much sense. So we
>>>> probably need something like:
>>>>
>>>> /services/TestProxy/1.0.0
>>>>
>>>> The main problem however is representing different versions of the same
>>>> service in the SynapseConfiguration/AxisConfiguration. Axis2 supports
>>>> something called hierarchical services (see
>>>> https://issues.apache.org/jira/browse/SYNAPSE-914). May be you can try
>>>> to leverage that.
>>>>
>>>> Thanks,
>>>> Hiranya
>>>>
>>>>
>>>>
>>>> Any comments and suggestions on this?
>>>>
>>>> [1]-https://issues.apache.org/jira/browse/SYNAPSE-928
>>>> --
>>>> Thilini
>>>> Thilini Shanika Gamage
>>>> Department of Computer Science and Engineering
>>>> University of Moratuwa
>>>>
>>>>
>>>> --
>>>> Hiranya Jayathilaka
>>>> Mayhem Lab/RACE Lab;
>>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu
>>>> E-mail: hiranya@cs.ucsb.edu <hi...@wso2.com>; Mobile: +1 (805)
>>>> 895-7443
>>>> Blog: http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/>
>>>>
>>>>
>>>
>>>
>>> --
>>> http://www.udayangawiki.blogspot.com
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>> Mayhem Lab/RACE Lab;
>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu
>>> E-mail: hiranya@cs.ucsb.edu <hi...@wso2.com>; Mobile: +1 (805)
>>> 895-7443
>>> Blog: http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/>
>>>
>>>
>>
>>
>> --
>> Thilini
>> Thilini Shanika Gamage
>> Department of Computer Science and Engineering
>> University of Moratuwa
>>
>
>
>
> --
> Thilini
> Thilini Shanika Gamage
> Department of Computer Science and Engineering
> University of Moratuwa
>
--
http://www.udayangawiki.blogspot.com