axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From WJ Krpelan <krpelan...@yahoo.com>
Subject Re: SOAP styles
Date Tue, 01 Sep 2009 12:53:18 GMT
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 <demetris@ece.neu.edu> wrote:

> From: Demetris <demetris@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 <demetris@ece.neu.edu>
> wrote:
> > 
> >   
> >> From: Demetris <demetris@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 <demetris@ece.neu.edu>
> >>>       
> >> wrote:
> >>     
> >>>          
> >>>> From: Demetris <demetris@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
> >>     
> >>>>>         
>         
> >>>> <deepalk@gmail.com
> >>>> <mailto:deepalk@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: ruwan@wso2.com
> >>>>>         
>         
> >>>> <mailto:ruwan@wso2.com>;
> >>>> cell: +94 77 341 3097
> >>>>           
>   
> >>>>> blog: http://ruwansblog.blogspot.com
> >>>>>         
>         
> >>>>           
>   
> >>>           
>      
> >>     
> > 
> > 
> >       
> >   
> 
> 


      

Mime
View raw message