axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Demetris <demet...@ece.neu.edu>
Subject Re: SOAP styles
Date Mon, 31 Aug 2009 16:48:34 GMT

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