Hi Isuru, Understood.
Is there refactoring support for version changes in the Developer Studio like if we update a sequence version, showing a prompt which would ask to pick references to be upgraded? I see the below pattern being used in a version management system when developing proxies and sequences using Developer Studio with different versions. - Create initial version in the master branch. - When the initial version is released, create a branch for the released version. - Upgrade the master branch version. At this point, upgrading a version of a sequence would mean the referencing proxies of that sequence should also be upgraded and ultimately the proxy versions should also be upgraded if they are in the same repository. Thanks, Akalanka. On Tue, Nov 8, 2016 at 8:19 AM, Isuru Udana <[email protected]> wrote: > Hi, > > On Mon, Nov 7, 2016 at 2:28 PM, Akalanka Pagoda Arachchi < > [email protected]> wrote: > >> Hi Amjadh, >> >> A WSDL can be provided externally to a Proxy instead of auto generating >> it. In this kind of scenario, WSDL is part of the proxy. The same goes for >> XSD files as well. Since they come under ESB artifacts shouldn't we provide >> a way to version them as well? >> >> If not we will have a set of artifacts that are version supported (Proxy, >> Sequence) and another set of artifacts (WSDL, XSD, Scripts, .etc) that are >> not supported for versioning. >> > WSDL, XSD, etc, are not ESB artifacts. They are resource files used by > artifacts like Proxy services. Having a versioning support implemented for > these resource files shouldn't be done at the ESB level, rather they need > to be versioned at the registry level. > >> >> Thanks, >> Akalanka. >> >> On Mon, Nov 7, 2016 at 2:16 PM, Amjadh Ifthikar <[email protected]> wrote: >> >>> Hi Akalanka, >>> >>> If we consider the WSDL file generated when creating a proxy service, >>> the information related to the version will be available in the WSDL file. >>> If someone needs to save the WSDL file, the versioning of those files >>> should be done seperately. >>> >>> Thank you, >>> Amjadh. >>> >>> On Mon, Nov 7, 2016 at 1:25 PM, Akalanka Pagoda Arachchi < >>> [email protected]> wrote: >>> >>>> Hi Amjadh, >>>> >>>> WSDL and XSD files are not files that are pointing to the proxy but >>>> rather, these are pointed by the proxy. In a real life scenario, when >>>> changing the version of the proxy with some changes, there's a good chance >>>> that these type of files will also get changed. Hence supporting versioning >>>> for these type of files will be necessary to successfully implement a >>>> versioning change for a proxy. Or else someone using the versioning of the >>>> proxy will have to manually manage these artifact versioning. >>>> >>>> Thanks, >>>> Akalanka. >>>> >>>> On Mon, Nov 7, 2016 at 12:29 PM, Amjadh Ifthikar <[email protected]> >>>> wrote: >>>> >>>>> Hi Akalanka, >>>>> >>>>> Since WSDL and XSD files are external files pointing to the proxy >>>>> service, the versioning of them should be done separately. >>>>> >>>>> Thank you, >>>>> Amjadh. >>>>> >>>>> On Mon, Nov 7, 2016 at 12:17 PM, Akalanka Pagoda Arachchi < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Amjadh, >>>>>> >>>>>> Typically a proxy service is affiliated with artifacts like WSDL >>>>>> files and XSD files. How will the versioning of these artifacts handled? >>>>>> IMO these also needs to be versioned along with the proxy services. >>>>>> >>>>>> Thanks, >>>>>> Akalanka. >>>>>> >>>>>> On Mon, Nov 7, 2016 at 10:38 AM, Dimuthu Leelarathne < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Amjadh, >>>>>>> >>>>>>> But what does this mean "When dragging and dropping available >>>>>>> sequences, the version will be appended automatically"? >>>>>>> >>>>>>> thanks, >>>>>>> Dimuthu >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 7, 2016 at 10:35 AM, Amjadh Ifthikar <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Malaka, >>>>>>>> >>>>>>>> Currently once a proxy service or a sequence is deployed, another >>>>>>>> version of the same artifact cannot be deployed. In this scenario, the >>>>>>>> carbon application acts only as a container and its version has no >>>>>>>> effect >>>>>>>> in the artifacts within it. >>>>>>>> >>>>>>>> A simple use case is that a user can create and deploy a new >>>>>>>> version of an existing artifact without taking down the existing >>>>>>>> artifact. >>>>>>>> >>>>>>>> >>>>>>>> For instance, I have my app foo v1.0.0 that is live with an URI >>>>>>>> http://esb_server/services/foo/1.0.0 >>>>>>>> >>>>>>>> User can deploy a v1.1.0 version with a new URI >>>>>>>> http://esb_server/services/foo/1.1.0 >>>>>>>> >>>>>>>> The user can also set a default artifact. If no version is >>>>>>>> mentioned in the request, the latest version is dispatched. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 7, 2016 at 10:02 AM, Malaka Silva <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Amjadh >>>>>>>>> , >>>>>>>>> >>>>>>>>> Thx for the detail explanation. >>>>>>>>> >>>>>>>>> I am bit unclear why we should do like this. Can you explain a use >>>>>>>>> case where we have to use the above versioning. >>>>>>>>> >>>>>>>>> The way I see this is we are simple creating a new artifact? >>>>>>>>> >>>>>>>>> Typically we get the requirement to support versioning with Carbon >>>>>>>>> Applications. I guess this is not covered as part of this? >>>>>>>>> >>>>>>>>> On Mon, Nov 7, 2016 at 9:39 AM, Amjadh Ifthikar <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I am currently working on the project “Versioning support for ESB >>>>>>>>>> artifacts”. I have completed implementing the solution in wso2 >>>>>>>>>> synapse and >>>>>>>>>> also done necessary changes in the developer studio as well. >>>>>>>>>> According to >>>>>>>>>> the project, proxy service and sequence artifacts will be deployed >>>>>>>>>> and >>>>>>>>>> dispatched as follows. >>>>>>>>>> >>>>>>>>>> Proxy service deployment >>>>>>>>>> >>>>>>>>>> A versioned proxy service should be defined as follows. >>>>>>>>>> >>>>>>>>>> <proxy name="testproxy" startOnLoad="true" trace="disable" >>>>>>>>>> transports="https http" version="1.0.0" isDefault=”true”></proxy> >>>>>>>>>> >>>>>>>>>> The defined version will be concatenated with the proxy name to >>>>>>>>>> generate a unique id for the proxy service. The proxy service will be >>>>>>>>>> deployed using this unique id. >>>>>>>>>> >>>>>>>>>> Eg. testproxy/1.0.0 >>>>>>>>>> >>>>>>>>>> The isDefault attribute helps the user to name the respective >>>>>>>>>> version as the default version.(See proxy service dispatching for >>>>>>>>>> effect of >>>>>>>>>> isDefault) >>>>>>>>>> >>>>>>>>>> If there is no version attribute defined, the proxy is deployed >>>>>>>>>> by its name. This measure is taken to support backward compatibility. >>>>>>>>>> >>>>>>>>>> Proxy service dispatching >>>>>>>>>> >>>>>>>>>> A proxy service should be referred in a request as follows. >>>>>>>>>> >>>>>>>>>> The following requests are processed and the proxy service is >>>>>>>>>> dispatched. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> http://localhost:8280/services/StockQuoteProxy/1.0.0 or >>>>>>>>>> http://localhost:8280/services/StockQuoteProxy/1.0.0.StockQu >>>>>>>>>> oteProxy/1.0.0HttpSoap11Endpoint >>>>>>>>>> >>>>>>>>>> <http://localhost:8280/services/StockQuoteProxy/1.0.0.StockQuoteProxy/1.0.0HttpSoap11Endpoint> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If the request is sent as follows, the proxy service with the >>>>>>>>>> respective version is deployed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> http://localhost:8280/services/StockQuoteProxy or >>>>>>>>>> http://localhost:8280/services/StockQuoteProxy.StockQuotePro >>>>>>>>>> xy/HttpSoap11Endpoint >>>>>>>>>> >>>>>>>>>> <http://localhost:8280/services/StockQuoteProxy.StockQuoteProxy/HttpSoap11Endpoint> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If a service is not found for the above request, >>>>>>>>>> >>>>>>>>>> 1). If the user have defined a proxy service with the attribute >>>>>>>>>> isDefault = “true” with the name requested, it will be dispatched. >>>>>>>>>> >>>>>>>>>> 2).If no axis service is found, it will see if there is only one >>>>>>>>>> proxy service containing the name provided. If so it is dispatched. >>>>>>>>>> >>>>>>>>>> 2). If there are many proxy services with the given name, the >>>>>>>>>> service with the highest version is dispatched. >>>>>>>>>> >>>>>>>>>> Serializing an artifact >>>>>>>>>> >>>>>>>>>> When serializing an artifact, both name and version can be taken >>>>>>>>>> from the artifact object to create the serialized artifact. >>>>>>>>>> >>>>>>>>>> Sequence deployment >>>>>>>>>> >>>>>>>>>> Ideally sequence deployment should be as follows. >>>>>>>>>> >>>>>>>>>> <sequence name="test" trace="disable" xmlns=" >>>>>>>>>> http://ws.apache.org/ns/synapse"; version=”1.0.0”> </sequence> >>>>>>>>>> >>>>>>>>>> The defined sequence name will be concatenated with the version >>>>>>>>>> to create a unique id. >>>>>>>>>> >>>>>>>>>> Eg.test/1.0.0 >>>>>>>>>> >>>>>>>>>> The deployed sequence will be added to the local registry with >>>>>>>>>> this unique id as the key. >>>>>>>>>> >>>>>>>>>> Sequence dispatching >>>>>>>>>> >>>>>>>>>> A versioned sequence should be referenced as follows. >>>>>>>>>> >>>>>>>>>> <sequence key="test/1.0.0”/> >>>>>>>>>> >>>>>>>>>> <target insequence=”testInSeq/1.0.0” >>>>>>>>>> outSequence=”testOutSeq/1.0.0”/> >>>>>>>>>> >>>>>>>>>> Developer Studio >>>>>>>>>> >>>>>>>>>> In the developer studio, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> When creating a proxy service the user can define a >>>>>>>>>> version(not a mandatory field). If the user is entering a version >>>>>>>>>> number, >>>>>>>>>> it is validated to see if it is in the right format. The user >>>>>>>>>> also can tick >>>>>>>>>> whether the proxy service is a default version. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> When creating a sequence, similarly the version can be >>>>>>>>>> provided(not mandatory). Also if a version is provided, it is >>>>>>>>>> validated >>>>>>>>>> whether it is in the right format. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> When dragging and dropping available sequences, the version >>>>>>>>>> will be appended automatically. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please do reply if there is any feedback. >>>>>>>>>> Thank you, >>>>>>>>>> Amjadh Ifthikar. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Amjadh Ifthikar >>>>>>>>>> Trainee Software Engineer >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile: +94777459181 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Malaka Silva >>>>>>>>> Senior Technical Lead >>>>>>>>> M: +94 777 219 791 >>>>>>>>> Tel : 94 11 214 5345 >>>>>>>>> Fax :94 11 2145300 >>>>>>>>> Skype : malaka.sampath.silva >>>>>>>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>>>>>>> Blog : http://mrmalakasilva.blogspot.com/ >>>>>>>>> >>>>>>>>> WSO2, Inc. >>>>>>>>> lean . enterprise . middleware >>>>>>>>> https://wso2.com/signature >>>>>>>>> http://www.wso2.com/about/team/malaka-silva/ >>>>>>>>> <http://wso2.com/about/team/malaka-silva/> >>>>>>>>> https://store.wso2.com/store/ >>>>>>>>> >>>>>>>>> Don't make Trees rare, we should keep them with care >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Amjadh Ifthikar >>>>>>>> Trainee Software Engineer >>>>>>>> WSO2 Inc. >>>>>>>> Mobile: +94777459181 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dimuthu Leelarathne >>>>>>> Director, Solutions Architecture >>>>>>> >>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>> email: [email protected] >>>>>>> Mobile: +94773661935 >>>>>>> Blog: http://muthulee.blogspot.com >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Darshana Akalanka Pagoda Arachchi,* >>>>>> *Senior Software Engineer, WSO2* >>>>>> *+94777118016 <%2B94777118016>* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Amjadh Ifthikar >>>>> Trainee Software Engineer >>>>> WSO2 Inc. >>>>> Mobile: +94777459181 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Darshana Akalanka Pagoda Arachchi,* >>>> *Senior Software Engineer, WSO2* >>>> *+94777118016 <%2B94777118016>* >>>> >>> >>> >>> >>> -- >>> Amjadh Ifthikar >>> Trainee Software Engineer >>> WSO2 Inc. >>> Mobile: +94777459181 >>> >> >> >> >> -- >> *Darshana Akalanka Pagoda Arachchi,* >> *Senior Software Engineer, WSO2* >> *+94777118016 <%2B94777118016>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Isuru Udana* > Technical Lead > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 3791887 > blog: http://mytecheye.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Darshana Akalanka Pagoda Arachchi,* *Senior Software Engineer, WSO2* *+94777118016*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
