Hi, small wonder. One possibility is of course given by the saying "every IT-Problem can be solved by another indirection" create new webservices out of the description of the old ones and let the new ones call the old ones - performance-issues to the side kind of usual IT-madness, dont cite me Cheers, Wolfgang
--- On Mon, 8/31/09, Demetris <demet...@ece.neu.edu> wrote: > From: Demetris <demet...@ece.neu.edu> > Subject: Re: SOAP styles > To: axis-dev@ws.apache.org > Date: Monday, August 31, 2009, 6:48 PM > > Hi Wolfgang, > > thanks for the good info - I did see some > of these links and I will go over them. > > We have an underlying p2p infrastructure > that intercepts the SOAP messages from > clients to servers without distrupting the operation of the > upper layers ( so the soap > enginers and the WS implementations remain as is) and > routes them across peers. > Now that we are adding mobile peers in the mix, including > CXF-based ones, Axis2 > ones etc. we are seeing some incompatability issues - for > ex. CXF does not handle > rcp/encoded styles. So how do you suggest we avoid the > migration and manage to > handle these issues? > > Thanks again > > WJ Krpelan wrote: > > Hi > > http://ws.apache.org/axis/java/reference.html > > hopefully answers your last question, dont expect > bugfixes any more ;-) > > there is a migration guide for axis1 to axis2 > webservices, > > http://ws.apache.org/axis2/1_5/migration.html > > dont think there is any special attention to > preserving soap-styles however. its really not in the spirit > nowadays, see > > http://ws-i.org/ > > you didnt mention why you would want to migrate > > good luck, > > Wolfgang > > > > --- On Fri, 8/28/09, Demetris <demet...@ece.neu.edu> > wrote: > > > > > >> From: Demetris <demet...@ece.neu.edu> > >> Subject: Re: SOAP styles > >> To: axis-dev@ws.apache.org > >> Date: Friday, August 28, 2009, 7:41 PM > >> > >> Well I will certainly push the notion of upgrading > the > >> target servers but there are cases where the > customer does > >> not > >> want to do that. So we NEED to deal with > deprecated styles > >> - so the question will remain if Axis 1.4 can > generate > >> one and only or multiple (even if deprecated) > styles > >> programmatically? > >> > >> Cheers > >> > >> WJ Krpelan wrote: > >> > >>> Hi, > >>> all SOAP styles except doc/lit are kind of > deprecated > >>> > >> by now and are no longer fully supported by most > frameworks, > >> if at all. > >> > >>> You better migrate everything to doc/lit, > resp. > >>> > >> doc/lit "wrapped" I suppose > >> > >>> Cheers, Wolfgang > >>> > >>> > >>> --- On Thu, 8/27/09, Demetris <demet...@ece.neu.edu> > >>> > >> wrote: > >> > >>> > >>>> From: Demetris <demet...@ece.neu.edu> > >>>> Subject: SOAP styles > >>>> To: axis-dev@ws.apache.org > >>>> Date: Thursday, August 27, 2009, 10:10 PM > >>>> Hi all, > >>>> > >>>> we have some legacy systems still using > Axis 1.4 > >>>> > >> and we > >> > >>>> need clients from them to generate SOAP > >>>> rpc/lit or doc/lit instead of rpc/enc - > does > >>>> > >> anyone know if > >> > >>>> the latter is the default for Axis 1.4 > >>>> and how it can be manipulated > programmatically? > >>>> > >>>> Thanks > >>>> > >>>> Ruwan Linton wrote: > >>>> > > >>>>> On Thu, Aug 27, 2009 at 11:21 PM, > Deepal > >>>>> > > >> jayasinghe > >> > >>>>> > > >>>> <deep...@gmail.com > >>>> <mailto:deep...@gmail.com>> > >>>> wrote: > >>>> > > >>>>> > > >>>>> > No > I can't, I guess > >>>>> > > >> I > >> > >>>>> > > >>>> have explained why I can't use it as > well, > >>>> > > >>>>> > > because I cannot > >>>>> > > >>>> differentiate the undeployment call for > the hot > >>>> > > >>>>> > > update and real > >>>>> > > >>>> undeployment. Well, what Amila suggested > will > >>>> > >> work > >> > >>>> > > >>>>> > > though :-) > >>>>> Of > course you can if the > >>>>> > > >> file > >> > >>>>> > > >>>> is there then that is hot-update else it > >>>> > > >>>>> is un > deployment. > >>>>> > > >>>>> > > >>>>> > > >>>>> > > > > >> > >>>> > > >>>> > > >>>>> > > > > >> > >>>> > I propose > adding a update method > >>>> > >> to > >> > >>>> the Deployer interface or > >>>> > > >>>>> > > > > >> > >>>> passing > >>>> > > >>>>> > > > > >> > >>>> > the state as > an argument, > >>>> > > >>>>> > > > > >> I > >> > >>>>> > > >>>> would consider undeploy as the update > method you > >>>> > >> can do > >> > >>>> > > >>>>> > whatever you > >>>>> > > > > >> > >>>> want there, and > you can just ignore > >>>> > >> at > >> > >>>> when it call deploy > >>>> > > >>>>> > method. > >>>>> > > > > >> > >>>> (I know in > undeploy method you only > >>>> > >> get > >> > >>>> the filename, but > >>>> > > >>>>> since > your > >>>>> > > > > >> > >>>> deployer is domain > specific you know > >>>> > >> what > >> > >>>> to do with the > >>>> > > >>>>> file > name) > >>>>> > > >>>>> > > >>>>> > > No, the issue is we > >>>>> > > >> need > >> > >>>>> > > >>>> to invoke a different code in the case > >>>> > > >>>>> of hot > >>>>> > > update. > >>>>> Yes, as > I mentioned > >>>>> > > >> earlier if > >> > >>>>> > > >>>> the file is there then that is > >>>> > > >>>>> > hot-update, else > >>>>> > > >>>> un-deployment. So it should not be a big > issues. > >>>> > > >>>>> > > >>>>> > > Anyway I feel I > >>>>> > > >> should go > >> > >>>>> > > >>>> for a synapse deployer :-) > >>>> > > >>>>> I > though you already have > >>>>> > > >>>> deployer for synapse. > >>>> > > >>>>> I mean a new deployer framework > >>>>> > > >> implementation, not an > >> > >>>>> > > >>>> deployer.. anyway synapse doesn't have a > deployer > >>>> > >> yet. > >> > >>>> > > >>>>> Thanks, > >>>>> Ruwan > >>>>> > >>>>> -- Ruwan Linton > >>>>> Technical Lead & Product Manager; > WSO2 > >>>>> > > >> ESB; http://wso2.org/esb > >> > >>>>> WSO2 Inc.; http://wso2.org > >>>>> email: ru...@wso2.com > >>>>> > > >>>> <mailto:ru...@wso2.com>; > >>>> cell: +94 77 341 3097 > >>>> > > >>>>> blog: http://ruwansblog.blogspot.com > >>>>> > > >>>> > > >>> > > >> > > > > > > > > > >
