axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Afkham Azeez <afk...@gmail.com>
Subject Re: Supporting hierarchical service deployment
Date Fri, 28 Aug 2009 15:08:14 GMT
Andreas, you are right. It is not only about the version number. The
hierarchy may semantically reflect the version number. It could be used for
many things. e.g. in a multi-user/multi-tenant deployment, all services of a
particular user/tenant can be stored under a certain directory. This
structure is also reflected in the endpoint addresses.
Azeez

On Fri, Aug 28, 2009 at 3:00 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.
>
> 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.
>
> 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 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 <deepalk@gmail.com
> >> <mailto:deepalk@gmail.com>> 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
> >
> >
>



-- 
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

Mime
View raw message