You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Susantha Kumara <su...@opensource.lk> on 2004/05/18 06:42:39 UTC
xsd:any support in Axis C++
Hi all,
I expect to work on implementing support for xsd:any in Axis C++. I had
a look at how other WS implementations (.net, Axis Java, wasp) do this.
Most of them passes a DOM tree kind of object in to the skeleton (to web
service method) or returns to the client application. If we take the
server side anyone writing a web service will have to browse through the
DOM tree kind of an object and extract the information. Why do people
use this way ?. I mean passing a DOM tree kind of object ?.
I see that we can have 2 other ways to do this.
1. Pass an object (interface) which contains set of functions that can
be called to get the information contained in SOAP message.
2. SOAP engine might be able to instantiate and populate the exact
runtime object and pass it directly to the skeletons (contained in a
generic structure).
Please give me your views/ideas so that I proceed in the correct way.
Thanks,
---
Susantha Kumara
Virtusa (pvt) Ltd.
Office : +94112714385
Mobile : +94777420453
RE: xsd:any support in Axis C++
Posted by Susantha Kumara <su...@opensource.lk>.
Hi all,
While keeping the XML pull model inside Axis we would be able to
implement the 2nd approach. That is,
> > 1. Pass an object (interface) which contains set of functions that
can
> > be called to get the information contained in SOAP message.
For this interface we can have method like what we have in the DOMNode.
For an example if we look at DOMNode in xerces (see
doc\html\apiDocs\classDOMNode.html in xerces documentation) we can have
sub set of those methods.
But if we adhere to pull model inside Axis (Axis will not create the
true DOM tree. But API shows that the user can browse a DOM tree), 2
restrictions will be there,
1. You can browse the DOM tree only from top to bottom sequentially (no
random access / no traversing back.
2. Same applies to building a DOM tree (writing to stream).
---
Susantha Kumara
Virtusa (pvt) Ltd.
Office : +94112714385
Mobile : +94777420453
> -----Original Message-----
> From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> Sent: Wednesday, May 19, 2004 7:17 PM
> To: Apache AXIS C Developers List
> Subject: Re: xsd:any support in Axis C++
>
> Susantha
>
> The advantages of a DOM is its easy and standard. DOM is not the most
> efficient object. But writing a generic object that supports XML
> structures isnt that easy. IBM has one in Java
> http://www-106.ibm.com/developerworks/library/j-commonj-sdowmt/ but I
> think DOM would be a good first step in C++.
>
> The other benefit, is this capability is mainly used when SOAP is
being
> used as a transport for existing XML documents, so DOM is a good
> programming model for these users.
>
> Paul
>
> Susantha Kumara wrote:
>
> > Hi all,
> >
> >
> >
> > I expect to work on implementing support for xsd:any in Axis C++. I
> > had a look at how other WS implementations (.net, Axis Java, wasp)
do
> > this. Most of them passes a DOM tree kind of object in to the
skeleton
> > (to web service method) or returns to the client application. If we
> > take the server side anyone writing a web service will have to
browse
> > through the DOM tree kind of an object and extract the information.
> > Why do people use this way ?. I mean passing a DOM tree kind of
object
> ?.
> >
> >
> >
> > I see that we can have 2 other ways to do this.
> >
> > 1. Pass an object (interface) which contains set of functions that
can
> > be called to get the information contained in SOAP message.
> >
> > 2. SOAP engine might be able to instantiate and populate the exact
> > runtime object and pass it directly to the skeletons (contained in a
> > generic structure).
> >
> >
> >
> > Please give me your views/ideas so that I proceed in the correct
way.
> >
> >
> >
> > Thanks,
> >
> > ---
> >
> > ** Susantha Kumara **
> >
> > // Virtusa (pvt) Ltd. //
> >
> > // Office : +94112714385 //
> >
> > // Mobile // // : +94777420453 //
> >
> >
> >
Re: xsd:any support in Axis C++
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Susantha
The advantages of a DOM is its easy and standard. DOM is not the most
efficient object. But writing a generic object that supports XML
structures isnt that easy. IBM has one in Java
http://www-106.ibm.com/developerworks/library/j-commonj-sdowmt/ but I
think DOM would be a good first step in C++.
The other benefit, is this capability is mainly used when SOAP is being
used as a transport for existing XML documents, so DOM is a good
programming model for these users.
Paul
Susantha Kumara wrote:
> Hi all,
>
>
>
> I expect to work on implementing support for xsd:any in Axis C++. I
> had a look at how other WS implementations (.net, Axis Java, wasp) do
> this. Most of them passes a DOM tree kind of object in to the skeleton
> (to web service method) or returns to the client application. If we
> take the server side anyone writing a web service will have to browse
> through the DOM tree kind of an object and extract the information.
> Why do people use this way ?. I mean passing a DOM tree kind of object ?.
>
>
>
> I see that we can have 2 other ways to do this.
>
> 1. Pass an object (interface) which contains set of functions that can
> be called to get the information contained in SOAP message.
>
> 2. SOAP engine might be able to instantiate and populate the exact
> runtime object and pass it directly to the skeletons (contained in a
> generic structure).
>
>
>
> Please give me your views/ideas so that I proceed in the correct way.
>
>
>
> Thanks,
>
> ---
>
> ** Susantha Kumara **
>
> // Virtusa (pvt) Ltd. //
>
> // Office : +94112714385 //
>
> // Mobile // // : +94777420453 //
>
>
>
RE: xsd:any support in Axis C++
Posted by Susantha Kumara <su...@opensource.lk>.
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Tuesday, May 18, 2004 6:44 PM
> To: Apache AXIS C Developers List
> Subject: RE: xsd:any support in Axis C++
>
> Susantha,
>
> > How large that object/array is not a problem as long as the runtime
type
> > (class or structure) is registered at the server (through
server.wsdd).
>
> Well, I think there can be situations where both the server and/or
client
> would not know what
> exactly the other side would be sending. (Or am I mistaken here?)
Yes the WSDL that describes the web service may not say the runtime
types correctly. But when you add the business logic to your skeletons
the developer should have the idea of what types are possible. In case
of the derived types the developer should have the idea of the base type
at least.
But this is only an argument. We can confirm this if we have some
written client applications or server side skeletons in any of the other
web service implementations (Axis Java, .Net, wasp (C++ and Java) and
gsoap etc). Do you have any ?
> In other words, availability of type mappings should not be assumed.
This
> is reasonable because
> the WSDL can use xsd:any and not define what is meant by xsd:any at
all.
>
> > Yes that flexibility is there. But do we really need that
flexibility ?.
> > Can't we assume that at skeleton implementation time the developer
knows
> > what kinds of objects are possible (will come in SOAP) ?.
> Yes, in enterprise applications, service provider should be able to
change
> the service product
> offerings, and the client should be able to pick them automatically,
> rather than service provider
> be dependent on other means of communicating the concrete types.
As long as the data structures that describes the various products
derive from a known base type (known to the first written client's
implementation or implemented server side skeleton) and the methods
accept those types as parameters this is OK. But if the data structures
change (do not comply to a base type) such objects cannot be handled
without improving and compiling the code again.
> Talking in programming terms, say the server change the schema and it
> would be nice if client
> could still manage, without the need for recompilation.
I don't think that this is possible in C/C++ unless we integrate the
code generator, a compiler / linker to Axis library :o .
Or else the skeleton or client application should give the XML (for the
runtime type) to an external entity who will understand the runtime
type. Ex: Sending xml to a database.
>
> >
> > In cases where complex types are inside another complex types
(nested
> > structures) the same can be applied.
> The problem is not nested types as I understand. The problem is how
many
> complex types that we are
> talking about.
>
> >
> > This way the skeleton implementation will look like following (lets
> > consider a simple method)
> >
> > int processOrder(AnyObject* pObject)
> > {
> > if (0 == strcmp(pObject->m_pcTypename, "OrderItem1"))
> > {
> > OrderItem1* pOrder = pObject->pObj;
> > //do what ever the logic to process order
> > }
> > else if (0 == strcmp(pObject->m_pcTypename, "OrderItem2"))
> > {
> > OrderItem2* pOrder = pObject->pObj;
> > //do what ever the logic to process order
> > }
> > }
>
> This is like hard coding the number of items possible. However I think
> xsd:any need to be studied
> more throughly before comming to a conclution.
Yes lets find out how other WS implementations do this and user
preferences.
>
> Is there any WSDL GURU out there who could help us here? :)
>
> > But the XML pull model used in Axis makes it difficult to have
> > SOAPElement (DOM tree like) object passing to skeletons. But it is
> > possible to pass an API to the Deserializer from which the users can
get
> > any information that contained in SOAP.
>
> Well, the best is to design the parser model to accomodate real world
> scenarios. Lets not allow
> the pull model to restict us.
Yes iff there is no other solution. But if we do that we might run into
problems of Memory management (let alone performance drawback).
>
> Thanks,
> Samisa...
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! - Internet access at a great low price.
> http://promo.yahoo.com/sbc/
RE: xsd:any support in Axis C++
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Susantha,
> How large that object/array is not a problem as long as the runtime type
> (class or structure) is registered at the server (through server.wsdd).
Well, I think there can be situations where both the server and/or client would not know what
exactly the other side would be sending. (Or am I mistaken here?)
In other words, availability of type mappings should not be assumed. This is reasonable because
the WSDL can use xsd:any and not define what is meant by xsd:any at all.
> Yes that flexibility is there. But do we really need that flexibility ?.
> Can't we assume that at skeleton implementation time the developer knows
> what kinds of objects are possible (will come in SOAP) ?.
Yes, in enterprise applications, service provider should be able to change the service product
offerings, and the client should be able to pick them automatically, rather than service provider
be dependent on other means of communicating the concrete types.
Talking in programming terms, say the server change the schema and it would be nice if client
could still manage, without the need for recompilation.
>
> In cases where complex types are inside another complex types (nested
> structures) the same can be applied.
The problem is not nested types as I understand. The problem is how many complex types that we are
talking about.
>
> This way the skeleton implementation will look like following (lets
> consider a simple method)
>
> int processOrder(AnyObject* pObject)
> {
> if (0 == strcmp(pObject->m_pcTypename, "OrderItem1"))
> {
> OrderItem1* pOrder = pObject->pObj;
> //do what ever the logic to process order
> }
> else if (0 == strcmp(pObject->m_pcTypename, "OrderItem2"))
> {
> OrderItem2* pOrder = pObject->pObj;
> //do what ever the logic to process order
> }
> }
This is like hard coding the number of items possible. However I think xsd:any need to be studied
more throughly before comming to a conclution.
Is there any WSDL GURU out there who could help us here? :)
> But the XML pull model used in Axis makes it difficult to have
> SOAPElement (DOM tree like) object passing to skeletons. But it is
> possible to pass an API to the Deserializer from which the users can get
> any information that contained in SOAP.
Well, the best is to design the parser model to accomodate real world scenarios. Lets not allow
the pull model to restict us.
Thanks,
Samisa...
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/
RE: xsd:any support in Axis C++
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Samisa,
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Tuesday, May 18, 2004 1:15 PM
> To: Apache AXIS C Developers List
> Subject: Re: xsd:any support in Axis C++
>
> Susantha,
>
> http://www-106.ibm.com/developerworks/xml/library/ws-xsdany.html is a
good
> referance (very simple
> but good enough)
>
> JAX-RPC uses javax.xml.soap.SOAPElement to hold xsd:any type.
>
> I do not think it would be possible to use an object for this. One
reason
> is that you never know
> how large/complex 'any' type would be (how many attributes etc.).
How large that object/array is not a problem as long as the runtime type
(class or structure) is registered at the server (through server.wsdd).
> Also it
> gives flexibility to end
> users when handling any types using something like SOAPElement. (they
can
> decide either to convert
> it to an object format or keep as XML)
Yes that flexibility is there. But do we really need that flexibility ?.
Can't we assume that at skeleton implementation time the developer knows
what kinds of objects are possible (will come in SOAP) ?.
I mean that the skeleton can be passed a structure that contains
1. Typename of the object (char*)
2. Namespace of the object type (char*)
3. The deserialized object or array (void*)
4. No of elements if it is an array (int)
In cases where complex types are inside another complex types (nested
structures) the same can be applied.
This way the skeleton implementation will look like following (lets
consider a simple method)
int processOrder(AnyObject* pObject)
{
if (0 == strcmp(pObject->m_pcTypename, "OrderItem1"))
{
OrderItem1* pOrder = pObject->pObj;
//do what ever the logic to process order
}
else if (0 == strcmp(pObject->m_pcTypename, "OrderItem2"))
{
OrderItem2* pOrder = pObject->pObj;
//do what ever the logic to process order
}
}
>
> However your concept of using an object could be mapped to creating a
C++
> equivalent of
> javax.xml.soap.SOAPElement.
But the XML pull model used in Axis makes it difficult to have
SOAPElement (DOM tree like) object passing to skeletons. But it is
possible to pass an API to the Deserializer from which the users can get
any information that contained in SOAP.
---
Susantha
>
> Thanks,
> Samisa...
>
> --- Susantha Kumara <su...@opensource.lk> wrote:
> > Hi all,
> >
> > I expect to work on implementing support for xsd:any in Axis C++. I
had
> > a look at how other WS implementations (.net, Axis Java, wasp) do
this.
> > Most of them passes a DOM tree kind of object in to the skeleton (to
web
> > service method) or returns to the client application. If we take the
> > server side anyone writing a web service will have to browse through
the
> > DOM tree kind of an object and extract the information. Why do
people
> > use this way ?. I mean passing a DOM tree kind of object ?.
> >
> > I see that we can have 2 other ways to do this.
> > 1. Pass an object (interface) which contains set of functions that
can
> > be called to get the information contained in SOAP message.
> > 2. SOAP engine might be able to instantiate and populate the exact
> > runtime object and pass it directly to the skeletons (contained in a
> > generic structure).
> >
> > Please give me your views/ideas so that I proceed in the correct
way.
> >
> > Thanks,
> > ---
> > Susantha Kumara
> > Virtusa (pvt) Ltd.
> > Office : +94112714385
> > Mobile : +94777420453
> >
> >
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! - Internet access at a great low price.
> http://promo.yahoo.com/sbc/
Re: xsd:any support in Axis C++
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Susantha,
http://www-106.ibm.com/developerworks/xml/library/ws-xsdany.html is a good referance (very simple
but good enough)
JAX-RPC uses javax.xml.soap.SOAPElement to hold xsd:any type.
I do not think it would be possible to use an object for this. One reason is that you never know
how large/complex 'any' type would be (how many attributes etc.). Also it gives flexibility to end
users when handling any types using something like SOAPElement. (they can decide either to convert
it to an object format or keep as XML)
However your concept of using an object could be mapped to creating a C++ equivalent of
javax.xml.soap.SOAPElement.
Thanks,
Samisa...
--- Susantha Kumara <su...@opensource.lk> wrote:
> Hi all,
>
> I expect to work on implementing support for xsd:any in Axis C++. I had
> a look at how other WS implementations (.net, Axis Java, wasp) do this.
> Most of them passes a DOM tree kind of object in to the skeleton (to web
> service method) or returns to the client application. If we take the
> server side anyone writing a web service will have to browse through the
> DOM tree kind of an object and extract the information. Why do people
> use this way ?. I mean passing a DOM tree kind of object ?.
>
> I see that we can have 2 other ways to do this.
> 1. Pass an object (interface) which contains set of functions that can
> be called to get the information contained in SOAP message.
> 2. SOAP engine might be able to instantiate and populate the exact
> runtime object and pass it directly to the skeletons (contained in a
> generic structure).
>
> Please give me your views/ideas so that I proceed in the correct way.
>
> Thanks,
> ---
> Susantha Kumara
> Virtusa (pvt) Ltd.
> Office : +94112714385
> Mobile : +94777420453
>
>
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/