Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 10949 invoked from network); 28 Aug 2009 17:05:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Aug 2009 17:05:00 -0000 Received: (qmail 89565 invoked by uid 500); 28 Aug 2009 17:04:59 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 89465 invoked by uid 500); 28 Aug 2009 17:04:59 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 89456 invoked by uid 99); 28 Aug 2009 17:04:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Aug 2009 17:04:59 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of isurues@gmail.com designates 74.125.92.144 as permitted sender) Received: from [74.125.92.144] (HELO qw-out-1920.google.com) (74.125.92.144) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Aug 2009 17:04:50 +0000 Received: by qw-out-1920.google.com with SMTP id 4so706475qwk.28 for ; Fri, 28 Aug 2009 10:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HDZ6N2P5/8ccvsAA7WH/IfXp8obiKNcgtcFa5uqf7A8=; b=aXd8JV9RQEaaPgip/Wmbv1aZgubo/9IPAwJmU7fer8en2yhvHDqBld2imZ4lymA7Aa 5KLZUlpi2PL6bNTihioyVXhLoxxy9hj3U1+XbUinl40MYG0bUTB1Wtm3Tthly3n+YXN5 sceZQd/mJTPoEXDD+cRXsrA6Z3mD1g0R06X4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mU9fCQdgFoE+iLKmwtDTk8BmxRRxoQkBsSTqKDTnBelkWYJvXUmNTZjTdIflviXXq6 MkFqOnmiS+BqSvqLqf918fQt+4rKEXHSGRiPgV2GqdxLGng/qa/KEyl83+ovH8LWTqIS 2Wz8FDF7E7iFeL/ynfOkbb+GLZhHChxpZkn8g= MIME-Version: 1.0 Received: by 10.224.123.198 with SMTP id q6mr1292433qar.209.1251479069394; Fri, 28 Aug 2009 10:04:29 -0700 (PDT) In-Reply-To: <9b85c45f0908280948h5738c65cv4c4dba769d9f0e49@mail.gmail.com> References: <4A97DCFC.4030708@gmail.com> <9b85c45f0908280730w38a88a7eief7bcd459bcdb8f3@mail.gmail.com> <4A97ED94.1080206@gmail.com> <9b85c45f0908280948h5738c65cv4c4dba769d9f0e49@mail.gmail.com> Date: Fri, 28 Aug 2009 22:34:28 +0530 Message-ID: Subject: Re: Supporting hierarchical service deployment From: Isuru Suriarachchi To: axis-dev@ws.apache.org Content-Type: multipart/alternative; boundary=00c09f8e5c38600ac4047236ad7b X-Virus-Checked: Checked by ClamAV on apache.org --00c09f8e5c38600ac4047236ad7b Content-Type: text/plain; charset=ISO-8859-1 Hi Azeez, On Fri, Aug 28, 2009 at 10:18 PM, Afkham Azeez wrote: > Isuru,I think that the age-old "I tested this on my machine thoroughly" > cannot be sold any longer. Like Dim's mentioned, you need to add unit tests > that demonstrates that. You also need to add unit tests to ensure that > nobody breaks the new functionality that you are trying to introduce, in the > future. > Completely agreed. I'm not telling that I covered everything. +1 for writing unit tests. Will do it definitely if we are going to put this feature in. :) Thanks, ~Isuru > > Perhaps, other people who make such changes or introduce such feature > enhancements should also do this. > > Azeez > > > On Fri, Aug 28, 2009 at 4:42 PM, Isuru Suriarachchi wrote: > >> Hi Andreas, >> >> On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen < >> andreas.veithen@gmail.com> wrote: >> >>> Guys, >>> >>> Are we actually discussing the right question? Looking at the patch >>> proposed by Isuru, I have the impression that versioning is merely one >>> use case, but that (in contrast to modules) the code doesn't make any >>> assumption about the meaning of the hierarchy in the repository (it >>> could be version number, but it could also something completely >>> different). Fundamentally the change is not about versioning, but >>> about giving the user the possibility to define the structure of the >>> endpoint URL. >> >> >> Yes you are correct. >> >> >>> >>> >>> I share Deepal's concern about the possible impact of this change. He >>> mentioned the WS-Addressing case, but I believe that this change will >>> also break autogeneration of WSDLs: probably the endpoint URLs in the >>> WSDLs will be wrong. >> >> >> No. I tested WSDL auto generation and invoked few sample service of >> different types using generated WSDLs. All are working fine with correct >> EPRs. >> >> Thanks, >> ~Isuru >> >> >>> >>> >>> Andreas >>> >>> On Fri, Aug 28, 2009 at 16:45, Deepal jayasinghe >>> wrote: >>> > >>> >> IMHO, service versioning & module versioning are two different things. >>> >> Module versioning is purely a deployment time concept, >>> > of course not, we can have two different version of the same module and >>> > engage the one we want based on our requirement, it is not deployment >>> > concept, it is also there in run time too. >>> >> while service versioning is both a deployment & dispatch time concept. >>> >> So there is no need to follow the same way of implementing it. I also >>> >> think that deriving the module version from the MAR name is messy, and >>> >> is not necessarily the best or better way of implementing it. >>> > There is a way that you can specify the name in the module.xml. >>> > It may be messy, but we discussed in the mailing list and implement >>> that >>> > way. >>> >> It should come from the module descriptor; module.xml. Java archives >>> >> do not have a standard way of having the version name in the artifact. >>> >> That is why OSGi introduced the bundle version in the manifest file. >>> >> So, IMO, trying to derive the name from a service, module or any other >>> >> artifact is a bad practice. >>> > I do not mind having version number in the services.xml, but I do not >>> > agree the way Isuru has implemented the version support. >>> > >>> > File name has to be unique right? I mean just because OSGi handle the >>> > version number using manifest file file name has to have the version >>> > number of some sort of unique suffix right? >>> >> >>> >> Unfortunately, there is no standard for Web service versioning, and >>> >> there are different ways of implementing it. A popular way is to make >>> >> the WSDL targetNamespace and/or the types namespace to contain the >>> >> version. >>> > I agree, sometime you need to reflect the version form tns and URL. >>> >> >>> >> Azeez >>> >> >>> >> On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe >> >> > wrote: >>> >> >>> >> Hi Isuru, >>> >> >>> >> Thank you for taking your time and looking to this issues, but I >>> >> do not >>> >> agree the way you have address it, please see my comments below. >>> The >>> >> reason I am telling this is, as I can see this has so many issues, >>> and >>> >> you have made it complicated too :) . I believe you might know >>> that we >>> >> have version support for modules and we do not handle that like >>> >> this. So >>> >> this simply break the consistency, and this introduce new URL >>> >> patterns , >>> >> though you have not encounter now, I am sure you are going to face >>> a >>> >> number of issues (when it come to dispatching). >>> >> >>> >> > Currently Axis2 can only deploy services at the >>> repository/services >>> >> > level. This makes it impossible to deploy several versions of >>> >> the same >>> >> > service. >>> >> I do not agree, you can have the version name in the aar file, for >>> >> example foo-1.0.aar and foo-1.1.aar. Then at the deployment time >>> just >>> >> append the version number to the service name (to make the service >>> >> name >>> >> unique) >>> >> > >>> >> > Therefore, I've improved our deployment engine to deploy >>> services by >>> >> > looking at the hierarchical path of the service. For example >>> this >>> >> > allows us to deploy a service >>> >> repository/services/foo/bar/version.aar. >>> >> > And also this allows us to deploy any number of services as >>> follows. >>> >> > repository/services/versionService/1.0.0/version.aar >>> >> > repository/services/versionService/1.0.1/version.aar >>> >> Don't you think this is complex ? what is different between >>> >> "services/versionService/1.0.1/version.aar" and >>> >> "services/version-1.0.1.aar" ?. As far as I know second one is >>> better >>> >> than the first one (and you do not need much modification to >>> handle >>> >> that). Which is the commonly used approach for all sort of version >>> >> management. (am I missing something?) >>> >> > >>> >> > In the implementation, I've attached the hierarchical part of >>> the >>> >> > service (versionService/1.0.1/) in front of the service name >>> >> which is >>> >> > read from the services.xml. And also I've fixed the URI based >>> >> > dispatching logics to dispatch the services correctly. >>> >> Then how about addressing based dispatching ? >>> >> I remember the mess we had when someone introduce portName into >>> >> the URL, >>> >> I think we still have issues with that (though no one uses the >>> >> feature). >>> >> > >>> >> > This improvement doesn't affect any of the existing >>> functionalities. >>> >> Of course it does? how do you make sure when you change the >>> dispatcher >>> >> it does not break any of the existing features ? (we do not have >>> >> enough >>> >> test cases to cover all the cases) I think I have enough >>> experience in >>> >> Axis2, what when someone change something hoping that does not >>> break >>> >> something. >>> >> > The only limitation of this is we can't deploy a RESTful service >>> in >>> >> > this manner. >>> >> This is a problem right? >>> >> When the system move from one version to other, client will notice >>> >> that >>> >> the service does not work any more? >>> >> > Those can only be supported at repository/service level. That is >>> >> > because, incoming URL of a RESTful service can contain '/' >>> separated >>> >> > parameters to the service. >>> >> oh boy, you are making system tooooooo, complicated. >>> >> >>> >> I am sorry I am -1 on this approach, we need to discuss this >>> >> before we >>> >> implement. >>> >> In fact I remember we had some discussion on this at one of the >>> >> apachecon, there also we did not come to a conclusion. >>> >> >>> >> Thanks, >>> >> Deepal >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Thanks >>> >> Afkham Azeez >>> >> >>> >> Blog: http://afkham.org >>> >> Developer Portal: http://www.wso2.org >>> >> WSAS Blog: http://wso2wsas.blogspot.com >>> >> Company: http://wso2.com >>> >> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >>> > >>> > >>> > -- >>> > Thank you! >>> > >>> > >>> > http://blogs.deepal.org >>> > http://deepal.org >>> > >>> > >>> >> >> >> >> -- >> Senior Software Engineer, >> WSO2 Inc. http://wso2.org/ >> Blog : http://isurues.wordpress.com/ >> > > > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > -- Senior Software Engineer, WSO2 Inc. http://wso2.org/ Blog : http://isurues.wordpress.com/ --00c09f8e5c38600ac4047236ad7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Azeez,

On Fri, Aug 28, 2009 at 10:18 P= M, Afkham Azeez <a= fkham@gmail.com> wrote:
Isuru,
I think that the age-old "I tested this on my =A0machine th= oroughly" cannot be sold any longer. Like Dim's mentioned, you nee= d to add unit tests that demonstrates that. You also need to add unit tests= to ensure that nobody breaks the new functionality that you are trying to = introduce, in the future.=A0

Completely agreed. I'm not telling that I covered= everything. +1 for writing unit tests. Will do it definitely if we are goi= ng to put this feature in. :)

Thanks,
~Isuru
=A0

Perhaps, other people who make such changes or introduc= e such feature enhancements should also do this.

<= font color=3D"#888888">Azeez

On Fri, Aug 28, 2009 at 4:42 PM, Isuru Suriarach= chi <isurues@gmail.com> wrote:
Hi Andreas,
On Fri, Aug 28, 2009 at 8:30 PM, Andreas = Veithen <andreas.veithen@gmail.com> wrote:
Guys,

Are we actually discussing the right question? Looking at the patch
proposed by Isuru, I have the impression that versioning is merely one
use case, but that (in contrast to modules) the code doesn't make any assumption about the meaning of the hierarchy in the repository (it
could be version number, but it could also something completely
different). Fundamentally the change is not about versioning, but
about giving the user the possibility to define the structure of the
endpoint URL.

Yes you are correct.
=A0
=


I share Deepal's concern about the possible impact of this change. He mentioned the WS-Addressing case, but I believe that this change will
also break autogeneration of WSDLs: probably the endpoint URLs in the
WSDLs will be wrong.

No. I tested WSDL auto gene= ration and invoked few sample service of different types using generated WS= DLs. All are working fine with correct EPRs.

Thanks,
~Isuru
=A0


Andreas

On Fri, Aug 28, 2009 at 16:45, Deepal jayasinghe<deepalk@gmail.com> wrote:
>
>> IMHO, service versioning & module versioning are two different= things.
>> Module versioning is purely a deployment time concept,
> of course not, we can have two different version of the same module an= d
> engage the one we want based on our requirement, it is not deployment<= br> > concept, it is also there in run time too.
>> while service versioning is both a deployment & dispatch time = concept.
>> So there is no need to follow the same way of implementing it. I a= lso
>> think that deriving the module version from the MAR name is messy,= and
>> is not necessarily the best or better way of implementing it.
> There is a way that you can specify the name in the module.xml.
> It may be messy, but we discussed in the mailing list and implement th= at
> way.
>> It should come from the module descriptor; module.xml. Java archiv= es
>> do not have a standard way of having the version name in the artif= act.
>> That is why OSGi introduced the bundle version in the manifest fil= e.
>> So, IMO, trying to derive the name from a service, module or any o= ther
>> artifact is a bad practice.
> I do not mind having version number in the services.xml, but I do not<= br> > agree the way Isuru has implemented the version support.
>
> File name has to be unique right? I mean just because OSGi handle the<= br> > version number using manifest file file name has to have the version > number of some sort of unique suffix right?
>>
>> Unfortunately, there is no standard for Web service versioning, an= d
>> there are different ways of implementing it. A popular way is to m= ake
>> the WSDL targetNamespace and/or the types namespace to contain the=
>> version.
> I agree, sometime you need to reflect the version form tns and URL. >>
>> Azeez
>>
>> On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deepalk@gmail.com
>> <mailto:= deepalk@gmail.com>> wrote:
>>
>> =A0 =A0 Hi Isuru,
>>
>> =A0 =A0 Thank you for taking your time and looking to this issues,= but I
>> =A0 =A0 do not
>> =A0 =A0 agree the way you have address it, please see my comments = below. The
>> =A0 =A0 reason I am telling this is, as I can see this has so many= issues, and
>> =A0 =A0 you have made it complicated too :) . I believe you might = know that we
>> =A0 =A0 have version support for modules and we do not handle that= like
>> =A0 =A0 this. So
>> =A0 =A0 this simply break the consistency, and this introduce new = URL
>> =A0 =A0 patterns ,
>> =A0 =A0 though you have not encounter now, I am sure you are going= to face a
>> =A0 =A0 number of issues (when it come to dispatching).
>>
>> =A0 =A0 > Currently Axis2 can only deploy services at the repos= itory/services
>> =A0 =A0 > level. This makes it impossible to deploy several ver= sions of
>> =A0 =A0 the same
>> =A0 =A0 > service.
>> =A0 =A0 I do not agree, you can have the version name in the aar f= ile, for
>> =A0 =A0 example foo-1.0.aar and foo-1.1.aar. Then at the deploymen= t time just
>> =A0 =A0 append the version number to the service name (to make the= service
>> =A0 =A0 name
>> =A0 =A0 unique)
>> =A0 =A0 >
>> =A0 =A0 > Therefore, I've improved our deployment engine to= deploy services by
>> =A0 =A0 > looking at the hierarchical path of the service. For = example this
>> =A0 =A0 > allows us to deploy a service
>> =A0 =A0 repository/services/foo/bar/version.aar.
>> =A0 =A0 > And also this allows us to deploy any number of servi= ces as follows.
>> =A0 =A0 > repository/services/versionService/1.0.0/version.aar<= br> >> =A0 =A0 > repository/services/versionService/1.0.1/version.aar<= br> >> =A0 =A0 Don't you think this is complex ? what is different be= tween
>> =A0 =A0 "services/versionService/1.0.1/version.aar" and<= br> >> =A0 =A0 "services/version-1.0.1.aar" ?. As far as I know= second one is better
>> =A0 =A0 than the first one (and you do not need much modification = to handle
>> =A0 =A0 that). Which is the commonly used approach for all sort of= version
>> =A0 =A0 management. (am I missing something?)
>> =A0 =A0 >
>> =A0 =A0 > In the implementation, I've attached the hierarch= ical part of the
>> =A0 =A0 > service (versionService/1.0.1/) in front of the servi= ce name
>> =A0 =A0 which is
>> =A0 =A0 > read from the services.xml. And also I've fixed t= he URI based
>> =A0 =A0 > dispatching logics to dispatch the services correctly= .
>> =A0 =A0 Then how about addressing based dispatching ?
>> =A0 =A0 I remember the mess we had when someone introduce portName= into
>> =A0 =A0 the URL,
>> =A0 =A0 I think we still have issues with that (though no one uses= the
>> =A0 =A0 feature).
>> =A0 =A0 >
>> =A0 =A0 > This improvement doesn't affect any of the existi= ng functionalities.
>> =A0 =A0 Of course it does? how do you make sure when you change th= e dispatcher
>> =A0 =A0 it does not break any of the existing features ? (we do no= t have
>> =A0 =A0 enough
>> =A0 =A0 test cases to cover all the cases) I think I have enough e= xperience in
>> =A0 =A0 Axis2, what when someone change something hoping that does= not break
>> =A0 =A0 something.
>> =A0 =A0 > The only limitation of this is we can't deploy a = RESTful service in
>> =A0 =A0 > this manner.
>> =A0 =A0 This is a problem right?
>> =A0 =A0 When the system move from one version to other, client wil= l notice
>> =A0 =A0 that
>> =A0 =A0 the service does not work any more?
>> =A0 =A0 > Those can only be supported at repository/service lev= el. That is
>> =A0 =A0 > because, incoming URL of a RESTful service can contai= n '/' separated
>> =A0 =A0 > parameters to the service.
>> =A0 =A0 oh boy, you are making system tooooooo, complicated.
>>
>> =A0 =A0 I am sorry I am -1 on this approach, =A0we need to discuss= this
>> =A0 =A0 before we
>> =A0 =A0 implement.
>> =A0 =A0 In fact I remember we had some discussion on this at one o= f the
>> =A0 =A0 apachecon, there also we did not come to a conclusion.
>>
>> =A0 =A0 Thanks,
>> =A0 =A0 Deepal
>>
>>
>>
>>
>> --
>> Thanks
>> Afkham Azeez
>>
>> Blog: http://afkha= m.org
>> Developer Portal: http://www.wso2.org
>> WSAS Blog: http://wso2wsas.blogspot.com
>> Company: http://wso2= .com
>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 =A0B2A2 4AE2 C887 665E 0= 760
>
>
> --
> Thank you!
>
>
> http://blogs.dee= pal.org
> http://deepal.org<= br> >
>


=

--
Senior Software Engineer,
WSO2 Inc. http://wso2.org/
Blog : http://isurues.wordpress.c= om/



--
Thanks
Afkham Azeez

Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http:= //wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C= 9 =A0B2A2 4AE2 C887 665E 0760



--
Senior Software Enginee= r,
WSO2 Inc. http://wso2.org/
Blog := http://isurues.wordpress.com/
--00c09f8e5c38600ac4047236ad7b--