You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by WJ Krpelan <kr...@yahoo.com> on 2009/09/01 14:53:18 UTC
Re: SOAP styles
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 <de...@ece.neu.edu> wrote:
> From: Demetris <de...@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 <de...@ece.neu.edu>
> wrote:
> >
> >
> >> From: Demetris <de...@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 <de...@ece.neu.edu>
> >>>
> >> wrote:
> >>
> >>>
> >>>> From: Demetris <de...@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
> >>>> <ma...@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
> >>>>>
>
> >>>> <ma...@wso2.com>;
> >>>> cell: +94 77 341 3097
> >>>>
>
> >>>>> blog: http://ruwansblog.blogspot.com
> >>>>>
>
> >>>>
>
> >>>
>
> >>
> >
> >
> >
> >
>
>
kSOAP2 to Axis
Posted by Demetris <de...@ece.neu.edu>.
Has anyone used the kSOAP API to access an Axis WS? If you have I am
wondering if you ever
ran into this exception - I think I have the client setup correctly and
yet the XmlPullParser is complaining.
Any ideas on this would be greatly appreciated. Thanks
request: <?xml version="1.0" encoding="UTF-8"
standalone="no"?><v:Envelope
xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
xmlns:d="http://www.w3.org/2001/XMLSchema"
xmlns:c="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:v="http://schemas.xmlsoap.org/soap/envelope/"><v:Header
/><v:Body><n0:getBooks id="o0" c:root="1" xmlns:n0="http://myBooks"
/></v:Body></v:Envelope>
response: <html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
</body>
</html>
org.xmlpull.v1.XmlPullParserException: expected: START_TAG
{http://schemas.xmlsoap.org/soap/envelope/}Envelope (position:START_TAG
<html>@1:6 in java.io.InputStreamReader@1d32ad89)
at org.kxml2.io.KXmlParser.exception(Unknown Source)
at org.kxml2.io.KXmlParser.require(Unknown Source)
at org.ksoap2.SoapEnvelope.parse(Unknown Source)
at org.ksoap2.transport.Transport.parseResponse(Unknown Source)
at org.ksoap2.transport.HttpTransport.call(Unknown Source)
at Utils.TestAxis.sendkSOAPOSGiPost(Unknown Source)
at Utils.TestAxis.main(Unknown Source)
at java.lang.reflect.Method.invoke(Compiled Method)(Unknown Source)
at sun.misc.CVM.runMain(Unknown Source)
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
Hi Wolfgang,
I think I lost the original thread contents so all I have is this below
- I asked originally if I can get the
Axis 1.x to generate/work with doc/lit instead of rpc/lit style and you
sent me some good pointers.
Is it possible I can get your take on this again (or if anyone else has
any more info on the list please
do not hesitate to send me your suggestions)?
Thanks much
WJ Krpelan wrote:
> 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 <de...@ece.neu.edu> wrote:
>
>
>
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
He he - I hear ya - indirections indirections ..
Not a bad idea and that's something we looked into it Wolfgang as a last
resort. Thanks for the pointers and I will keep the
list informed on the outcome.
WJ Krpelan wrote:
> 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 <de...@ece.neu.edu> wrote:
>
>
>> From: Demetris <de...@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 <de...@ece.neu.edu>
>>>
>> wrote:
>>
>>>
>>>
>>>> From: Demetris <de...@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 <de...@ece.neu.edu>
>>>>>
>>>>>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>> From: Demetris <de...@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
>>>>>> <ma...@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
>>>>>>>
>>>>>>>
>>
>>
>>>>>> <ma...@wso2.com>;
>>>>>> cell: +94 77 341 3097
>>>>>>
>>>>>>
>>
>>
>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>
>>>>>>>
>>
>>
>>>>>>
>>>>>>
>>
>>
>>>>>
>>>>>
>>
>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
>