WSDL Section [2.2]
2.2 Types
....
Use the Soap:Array type for modeling array types (regardless of
whether the resulting form actually uses the encoding specified in
Section 5 of the SOAP v1.1 document). Use the name ArrayOfXXX for
array types (where XXX is the type of the items in the array).

From this I read that a part which is an array should be....
<part name="partName" type="tns:ArrayOfXXX"/>

where "tns:ArrayOfXXX" is defined in schema.  Therefore, all arrays
must be defined as "prefix:ArrayOfXXX" in WSDL.

I see this as a stoke of genius from the authors as
1) WSDL generation from methods is much simplied
    Example: VB
    Public Function(ByRef numberList() as Double) As Double
    ....
    End Function

    Translates into
    <part name="numberList" type="tns:ArrayOfDouble"/>

2) Code generation from WSDL documents
    If we can agree that "ArrayOf" with an xsd type of type defined
    in http://www.w3.org/TR/xmlschema-2/  sections [3.2.1] - [3.2.9]
    and sections [3.3.11] - [3.3.32] then we have something very
    valuable from an interop point of view.

    Comments?
    Especially, if MS SOAP Beta 2.0 guys are available.

-Matt

Hi,

I see your intention, but I still do not agree with it. The specification
says: The binding defines a message format and protocol details for
operations and messages defined by a particular portType. As far as I see a
WSDL document defines a protocol. If you have something like a local
binding, you do not specify a protocol. The local binding is language
specific. If you want to access local classes (also distributed as web
services), why don't you call the classes imidiatly without any WSDL
information? I think WSDL is the wrong place to define something like this.
On your server you need the information which class is implementing which
service. Just do a lookup for the class on the server. If it is on your
local machine, just call it. Otherway use a web service to invoke the
service.

Harald Dietrich
www.webfair.com
hdietrich@...

-----Original Message-----
From: Nirmal Mukhi [mailto:nmukhi@...]
Sent: Donnerstag, 8. Februar 2001 21:08
To: wsdl@yahoogroups.com
Subject: RE: [wsdl] Re: Local Web Services



Hi,

A service could have multiple bindings - a SOAP binding, a local binding
and so on. It's true that the local binding is irrelevant to clients to
whom the local binding is not available. But it still has value. The local
binding will allow some clients to access local java classes as web
services (we could of course define a local binding tied to some other
implementation, not java, but java is easiest), and could also double as a
way to deploy web services. Local services would also be great for testing
web services without having to set up a web server, SOAP and so on. And if
you can treat every class (whether local or remote) as a web service
described in WSDL it unifies the programming model. If we don't add this to
WSDL, how do we access web services locally?

Nirmal.


Dietrich Harald <h.dietrich@...> on 02/08/2001 01:35:55 PM

Please respond to wsdl@yahoogroups.com

To:   "'wsdl@yahoogroups.com'" <wsdl@yahoogroups.com>
cc:
Subject:  RE: [wsdl] Re: Local Web Services



Hi,

I am wondering if WSDL is the right place to define local bindings. I use a
WSDL document to deploy a service on a server or to query the information
how to access a service. If I want to access a service from a remote host,
it does not make sense to me to have this definition of local bindings.
Furthermore the client has to know, how it will access the service.

Regards,
Harald Dietrich
www.webfair.com
hdietrich@...

-----Original Message-----
From: Nirmal Mukhi [mailto:nmukhi@...]
Sent: Donnerstag, 8. Februar 2001 18:24
To: wsdl@yahoogroups.com
Subject: Re: [wsdl] Re: Local Web Services



Hi,

WSDL already allows multiple port types, bindings and ports (it's just that
almost every WSDL out there usually has just one of each & I'm not sure
about tool support for multiple bindings and such).

I think your work is very interesting and useful. But it looks like you are
a step ahead - you have a working way to transparently access local and
remote services already. But it's specific to your implementation. I think
it's necessary that we define local services properly within WSDL so that
we can do it consistently using any WSDL tool.

How about something like this for describing local services (this is almost
exactly like a SOAP service deployment descriptor):

<!-- here's a WSDL doc -->
<definitions>

      <message name="FooMessage">
           <part name="theMessage" type="tsn:MessageType">
      </message>

      <portType name="Foo">
           <operation name="doSomething">
                <input message="FooMessage"/>
                <output message="FooMessage"/>
           </operation>
      </portType>

      <!-- the interesting bit -->
      <binding name="LocalBinding" type="Foo">

           <!-- specify which local java class implements the port type -->
           <java:binding provider="com.mycompany.services.FooProvider"/>

           <!-- map service operations to methods within this implementation
-->
           <java:operationmapping operationname="doSomething" methodName
="execute"/>

           <!-- map complex types defined in the WSDL to local java classes
-->
           <java:typemapping xsdtype="MessageType" javatype
="com.mycompany.services.FooMessage"/>

           <!-- this basically says that when doSomething is called on port
type Foo, we should invoke the method -->
           <!-- FooMessage execute(FooMessage foo) -->
           <!--  on an instance of com.mycompany.services.FooProvider -->

      </binding>

      <service name="FooService">
           <port name="FooPort" binding="LocalBinding"/>
      </service>

      <types>
           <xsd:complexType name="MessageType">
                <xsd:element name="foobar1" type="xsd:string"/>
                <xsd:element name="foobar2" type="xsd:string"/>
           </xsd:complexType>
      </types>
</definitions>

The XML here is not syntactically correct, but hopefully conveys the
intent.

This is just a start. There are lot's of open issues: SOAP services can be
deployed as having Application, Session or Request scope (at least in
Apache SOAP). This in some sense governs the instance of the service
implementation that is used to satisfy the incoming request. Maybe we need
to reexamine this so that we have a uniform behavior between local and
remote services? Also, if a local service is something that is used by SOAP
as a sort of deployment descriptor, it will need to include (de)serializer
info, just like SOAP deployment descriptors do.

Nirmal.


Aleksander Slominski <aslom@...> on 02/06/2001 09:36:56 PM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:
Subject:  Re: [wsdl] Re: Local Web Services



Nirmal Mukhi wrote:

> I think our end objective is similar, but there's an important
> difference
> in our definition of local services:
>
> In one of your examples, a service whose "server" runs inside a
> different
> JVM from the "client" is remote - I notice that you check locality by
> checking references. My thinking was that a service available on the
> same
> machine (even running in a different JVM) is local, and you don't have
> to
> do very much (like (de)serialization and HTTP transport) to communicate
>
> with it - that is what defines locality in some ways. I favor this
> definition more since it can be made somewhat consistent across types
> of
> services...if we define locality in terms of JVMs for java services,
> what
> would we do for a C++ or python web service?

locality can be defined in terms of process boundaries for Java JVM is
simply process boundary. it is just that Java-Java communication can be
more efficient (RMI and native Java serialization) but as we have now
SOAP we have finally simple common fail-over communication protocol so as
long as all parties understand SOAP we can talk (though may be a bit
slow...).

in SoapRMI we have now common XML description for endpoints and it is
used both in Java and C++. we are also considering supporting multiple
endpoints (we have it now in XML but they are not used) and it will allow
runtime system (RTS) to choose the best communication endpoint _in
runtime_ (i would love to see multiple endpoints added to WSDL and as
well multiple portTypes...).

therefore the XML description of web service (such as WSDL or our Port
XML) is made available into some kind of registry (JNDI compatible
directory, UDDI, RMI registry etc.) can RTS can lookup this service, gets
XML description and chooses the most efficient transport to use. and this
will provide transparent access to services independent of location
(choosing closer locality or in worst case falling back to SOAP).

for example if we have web service published in JNDI that has following
endpoints:
* RMI endpoint bound to RMI registry (port:host)
* SOAP endpoint (port:host)
* private protocol that is supporting high performance communication but
only for special clients

RTS system can be very flexible. if C++ client is connecting it will
chose SOAP (as it does not know other protocols) or maybe special C++
client will have support for high-perf communication and the naturally
chose third option. Java client will chose RMI but it may still use SOAP
for short messages or as kind of signal channel.

if there were multiple endpoints of the same type (such SOAP) RTS could
chose the closest one (as measured by ping round-trip time or simply by
domain name) and in case of failure try to connect to next endpoint
(fail-over).

of course user should be able to override RTS default behavior, and say,
require only SOAP communication.


> Our approach, as you pointed out, is very WSDL-centric. I like WSDL,
> it's a
> nice flexible entry point for any kind of service. My thinking is that,
>
> once we define what local services are, a web service could advertise
> itself as being available at URI http://x.y.z/... over SOAP and also
> available in a local implementation as the java class foo.bar on
> machine
> 1.2.3.4. Then the proxy generator can automatically generate the most
> convenient proxy - the local one if available, otherwise the SOAP
> proxy.
> The client would just use the generated proxy, oblivious to the real
> nature
> of the service. But these are just pipe dreams yet...

in SoapRMI we have actually dynamic proxies so depending on XML port
description we can create specialized stub such as SOAP or not to create
it at all if it is local object.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com








To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com








To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Hi,

A service could have multiple bindings - a SOAP binding, a local binding
and so on. It's true that the local binding is irrelevant to clients to
whom the local binding is not available. But it still has value. The local
binding will allow some clients to access local java classes as web
services (we could of course define a local binding tied to some other
implementation, not java, but java is easiest), and could also double as a
way to deploy web services. Local services would also be great for testing
web services without having to set up a web server, SOAP and so on. And if
you can treat every class (whether local or remote) as a web service
described in WSDL it unifies the programming model. If we don't add this to
WSDL, how do we access web services locally?

Nirmal.


Dietrich Harald <h.dietrich@...> on 02/08/2001 01:35:55 PM

Please respond to wsdl@yahoogroups.com

To:   "'wsdl@yahoogroups.com'" <wsdl@yahoogroups.com>
cc:
Subject:  RE: [wsdl] Re: Local Web Services



Hi,

I am wondering if WSDL is the right place to define local bindings. I use a
WSDL document to deploy a service on a server or to query the information
how to access a service. If I want to access a service from a remote host,
it does not make sense to me to have this definition of local bindings.
Furthermore the client has to know, how it will access the service.

Regards,
Harald Dietrich
www.webfair.com
hdietrich@...

-----Original Message-----
From: Nirmal Mukhi [mailto:nmukhi@...]
Sent: Donnerstag, 8. Februar 2001 18:24
To: wsdl@yahoogroups.com
Subject: Re: [wsdl] Re: Local Web Services



Hi,

WSDL already allows multiple port types, bindings and ports (it's just that
almost every WSDL out there usually has just one of each & I'm not sure
about tool support for multiple bindings and such).

I think your work is very interesting and useful. But it looks like you are
a step ahead - you have a working way to transparently access local and
remote services already. But it's specific to your implementation. I think
it's necessary that we define local services properly within WSDL so that
we can do it consistently using any WSDL tool.

How about something like this for describing local services (this is almost
exactly like a SOAP service deployment descriptor):

<!-- here's a WSDL doc -->
<definitions>

      <message name="FooMessage">
           <part name="theMessage" type="tsn:MessageType">
      </message>

      <portType name="Foo">
           <operation name="doSomething">
                <input message="FooMessage"/>
                <output message="FooMessage"/>
           </operation>
      </portType>

      <!-- the interesting bit -->
      <binding name="LocalBinding" type="Foo">

           <!-- specify which local java class implements the port type -->
           <java:binding provider="com.mycompany.services.FooProvider"/>

           <!-- map service operations to methods within this implementation
-->
           <java:operationmapping operationname="doSomething" methodName
="execute"/>

           <!-- map complex types defined in the WSDL to local java classes
-->
           <java:typemapping xsdtype="MessageType" javatype
="com.mycompany.services.FooMessage"/>

           <!-- this basically says that when doSomething is called on port
type Foo, we should invoke the method -->
           <!-- FooMessage execute(FooMessage foo) -->
           <!--  on an instance of com.mycompany.services.FooProvider -->

      </binding>

      <service name="FooService">
           <port name="FooPort" binding="LocalBinding"/>
      </service>

      <types>
           <xsd:complexType name="MessageType">
                <xsd:element name="foobar1" type="xsd:string"/>
                <xsd:element name="foobar2" type="xsd:string"/>
           </xsd:complexType>
      </types>
</definitions>

The XML here is not syntactically correct, but hopefully conveys the
intent.

This is just a start. There are lot's of open issues: SOAP services can be
deployed as having Application, Session or Request scope (at least in
Apache SOAP). This in some sense governs the instance of the service
implementation that is used to satisfy the incoming request. Maybe we need
to reexamine this so that we have a uniform behavior between local and
remote services? Also, if a local service is something that is used by SOAP
as a sort of deployment descriptor, it will need to include (de)serializer
info, just like SOAP deployment descriptors do.

Nirmal.


Aleksander Slominski <aslom@...> on 02/06/2001 09:36:56 PM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:
Subject:  Re: [wsdl] Re: Local Web Services



Nirmal Mukhi wrote:

> I think our end objective is similar, but there's an important
> difference
> in our definition of local services:
>
> In one of your examples, a service whose "server" runs inside a
> different
> JVM from the "client" is remote - I notice that you check locality by
> checking references. My thinking was that a service available on the
> same
> machine (even running in a different JVM) is local, and you don't have
> to
> do very much (like (de)serialization and HTTP transport) to communicate
>
> with it - that is what defines locality in some ways. I favor this
> definition more since it can be made somewhat consistent across types
> of
> services...if we define locality in terms of JVMs for java services,
> what
> would we do for a C++ or python web service?

locality can be defined in terms of process boundaries for Java JVM is
simply process boundary. it is just that Java-Java communication can be
more efficient (RMI and native Java serialization) but as we have now
SOAP we have finally simple common fail-over communication protocol so as
long as all parties understand SOAP we can talk (though may be a bit
slow...).

in SoapRMI we have now common XML description for endpoints and it is
used both in Java and C++. we are also considering supporting multiple
endpoints (we have it now in XML but they are not used) and it will allow
runtime system (RTS) to choose the best communication endpoint _in
runtime_ (i would love to see multiple endpoints added to WSDL and as
well multiple portTypes...).

therefore the XML description of web service (such as WSDL or our Port
XML) is made available into some kind of registry (JNDI compatible
directory, UDDI, RMI registry etc.) can RTS can lookup this service, gets
XML description and chooses the most efficient transport to use. and this
will provide transparent access to services independent of location
(choosing closer locality or in worst case falling back to SOAP).

for example if we have web service published in JNDI that has following
endpoints:
* RMI endpoint bound to RMI registry (port:host)
* SOAP endpoint (port:host)
* private protocol that is supporting high performance communication but
only for special clients

RTS system can be very flexible. if C++ client is connecting it will
chose SOAP (as it does not know other protocols) or maybe special C++
client will have support for high-perf communication and the naturally
chose third option. Java client will chose RMI but it may still use SOAP
for short messages or as kind of signal channel.

if there were multiple endpoints of the same type (such SOAP) RTS could
chose the closest one (as measured by ping round-trip time or simply by
domain name) and in case of failure try to connect to next endpoint
(fail-over).

of course user should be able to override RTS default behavior, and say,
require only SOAP communication.


> Our approach, as you pointed out, is very WSDL-centric. I like WSDL,
> it's a
> nice flexible entry point for any kind of service. My thinking is that,
>
> once we define what local services are, a web service could advertise
> itself as being available at URI http://x.y.z/... over SOAP and also
> available in a local implementation as the java class foo.bar on
> machine
> 1.2.3.4. Then the proxy generator can automatically generate the most
> convenient proxy - the local one if available, otherwise the SOAP
> proxy.
> The client would just use the generated proxy, oblivious to the real
> nature
> of the service. But these are just pipe dreams yet...

in SoapRMI we have actually dynamic proxies so depending on XML port
description we can create specialized stub such as SOAP or not to create
it at all if it is local object.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com








To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Hi,

I am wondering if WSDL is the right place to define local bindings. I use a
WSDL document to deploy a service on a server or to query the information
how to access a service. If I want to access a service from a remote host,
it does not make sense to me to have this definition of local bindings.
Furthermore the client has to know, how it will access the service.

Regards,
Harald Dietrich
www.webfair.com
hdietrich@...

-----Original Message-----
From: Nirmal Mukhi [mailto:nmukhi@...]
Sent: Donnerstag, 8. Februar 2001 18:24
To: wsdl@yahoogroups.com
Subject: Re: [wsdl] Re: Local Web Services



Hi,

WSDL already allows multiple port types, bindings and ports (it's just that
almost every WSDL out there usually has just one of each & I'm not sure
about tool support for multiple bindings and such).

I think your work is very interesting and useful. But it looks like you are
a step ahead - you have a working way to transparently access local and
remote services already. But it's specific to your implementation. I think
it's necessary that we define local services properly within WSDL so that
we can do it consistently using any WSDL tool.

How about something like this for describing local services (this is almost
exactly like a SOAP service deployment descriptor):

<!-- here's a WSDL doc -->
<definitions>

      <message name="FooMessage">
           <part name="theMessage" type="tsn:MessageType">
      </message>

      <portType name="Foo">
           <operation name="doSomething">
                <input message="FooMessage"/>
                <output message="FooMessage"/>
           </operation>
      </portType>

      <!-- the interesting bit -->
      <binding name="LocalBinding" type="Foo">

           <!-- specify which local java class implements the port type -->
           <java:binding provider="com.mycompany.services.FooProvider"/>

           <!-- map service operations to methods within this implementation
-->
           <java:operationmapping operationname="doSomething" methodName
="execute"/>

           <!-- map complex types defined in the WSDL to local java classes
-->
           <java:typemapping xsdtype="MessageType" javatype
="com.mycompany.services.FooMessage"/>

           <!-- this basically says that when doSomething is called on port
type Foo, we should invoke the method -->
           <!-- FooMessage execute(FooMessage foo) -->
           <!--  on an instance of com.mycompany.services.FooProvider -->

      </binding>

      <service name="FooService">
           <port name="FooPort" binding="LocalBinding"/>
      </service>

      <types>
           <xsd:complexType name="MessageType">
                <xsd:element name="foobar1" type="xsd:string"/>
                <xsd:element name="foobar2" type="xsd:string"/>
           </xsd:complexType>
      </types>
</definitions>

The XML here is not syntactically correct, but hopefully conveys the
intent.

This is just a start. There are lot's of open issues: SOAP services can be
deployed as having Application, Session or Request scope (at least in
Apache SOAP). This in some sense governs the instance of the service
implementation that is used to satisfy the incoming request. Maybe we need
to reexamine this so that we have a uniform behavior between local and
remote services? Also, if a local service is something that is used by SOAP
as a sort of deployment descriptor, it will need to include (de)serializer
info, just like SOAP deployment descriptors do.

Nirmal.


Aleksander Slominski <aslom@...> on 02/06/2001 09:36:56 PM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:
Subject:  Re: [wsdl] Re: Local Web Services



Nirmal Mukhi wrote:

> I think our end objective is similar, but there's an important
> difference
> in our definition of local services:
>
> In one of your examples, a service whose "server" runs inside a
> different
> JVM from the "client" is remote - I notice that you check locality by
> checking references. My thinking was that a service available on the
> same
> machine (even running in a different JVM) is local, and you don't have
> to
> do very much (like (de)serialization and HTTP transport) to communicate
>
> with it - that is what defines locality in some ways. I favor this
> definition more since it can be made somewhat consistent across types
> of
> services...if we define locality in terms of JVMs for java services,
> what
> would we do for a C++ or python web service?

locality can be defined in terms of process boundaries for Java JVM is
simply process boundary. it is just that Java-Java communication can be
more efficient (RMI and native Java serialization) but as we have now
SOAP we have finally simple common fail-over communication protocol so as
long as all parties understand SOAP we can talk (though may be a bit
slow...).

in SoapRMI we have now common XML description for endpoints and it is
used both in Java and C++. we are also considering supporting multiple
endpoints (we have it now in XML but they are not used) and it will allow
runtime system (RTS) to choose the best communication endpoint _in
runtime_ (i would love to see multiple endpoints added to WSDL and as
well multiple portTypes...).

therefore the XML description of web service (such as WSDL or our Port
XML) is made available into some kind of registry (JNDI compatible
directory, UDDI, RMI registry etc.) can RTS can lookup this service, gets
XML description and chooses the most efficient transport to use. and this
will provide transparent access to services independent of location
(choosing closer locality or in worst case falling back to SOAP).

for example if we have web service published in JNDI that has following
endpoints:
* RMI endpoint bound to RMI registry (port:host)
* SOAP endpoint (port:host)
* private protocol that is supporting high performance communication but
only for special clients

RTS system can be very flexible. if C++ client is connecting it will
chose SOAP (as it does not know other protocols) or maybe special C++
client will have support for high-perf communication and the naturally
chose third option. Java client will chose RMI but it may still use SOAP
for short messages or as kind of signal channel.

if there were multiple endpoints of the same type (such SOAP) RTS could
chose the closest one (as measured by ping round-trip time or simply by
domain name) and in case of failure try to connect to next endpoint
(fail-over).

of course user should be able to override RTS default behavior, and say,
require only SOAP communication.


> Our approach, as you pointed out, is very WSDL-centric. I like WSDL,
> it's a
> nice flexible entry point for any kind of service. My thinking is that,
>
> once we define what local services are, a web service could advertise
> itself as being available at URI http://x.y.z/... over SOAP and also
> available in a local implementation as the java class foo.bar on
> machine
> 1.2.3.4. Then the proxy generator can automatically generate the most
> convenient proxy - the local one if available, otherwise the SOAP
> proxy.
> The client would just use the generated proxy, oblivious to the real
> nature
> of the service. But these are just pipe dreams yet...

in SoapRMI we have actually dynamic proxies so depending on XML port
description we can create specialized stub such as SOAP or not to create
it at all if it is local object.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com








To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Hi,

WSDL already allows multiple port types, bindings and ports (it's just that
almost every WSDL out there usually has just one of each & I'm not sure
about tool support for multiple bindings and such).

I think your work is very interesting and useful. But it looks like you are
a step ahead - you have a working way to transparently access local and
remote services already. But it's specific to your implementation. I think
it's necessary that we define local services properly within WSDL so that
we can do it consistently using any WSDL tool.

How about something like this for describing local services (this is almost
exactly like a SOAP service deployment descriptor):

<!-- here's a WSDL doc -->
<definitions>

      <message name="FooMessage">
           <part name="theMessage" type="tsn:MessageType">
      </message>

      <portType name="Foo">
           <operation name="doSomething">
                <input message="FooMessage"/>
                <output message="FooMessage"/>
           </operation>
      </portType>

      <!-- the interesting bit -->
      <binding name="LocalBinding" type="Foo">

           <!-- specify which local java class implements the port type -->
           <java:binding provider="com.mycompany.services.FooProvider"/>

           <!-- map service operations to methods within this implementation
-->
           <java:operationmapping operationname="doSomething" methodName
="execute"/>

           <!-- map complex types defined in the WSDL to local java classes
-->
           <java:typemapping xsdtype="MessageType" javatype
="com.mycompany.services.FooMessage"/>

           <!-- this basically says that when doSomething is called on port
type Foo, we should invoke the method -->
           <!-- FooMessage execute(FooMessage foo) -->
           <!--  on an instance of com.mycompany.services.FooProvider -->

      </binding>

      <service name="FooService">
           <port name="FooPort" binding="LocalBinding"/>
      </service>

      <types>
           <xsd:complexType name="MessageType">
                <xsd:element name="foobar1" type="xsd:string"/>
                <xsd:element name="foobar2" type="xsd:string"/>
           </xsd:complexType>
      </types>
</definitions>

The XML here is not syntactically correct, but hopefully conveys the
intent.

This is just a start. There are lot's of open issues: SOAP services can be
deployed as having Application, Session or Request scope (at least in
Apache SOAP). This in some sense governs the instance of the service
implementation that is used to satisfy the incoming request. Maybe we need
to reexamine this so that we have a uniform behavior between local and
remote services? Also, if a local service is something that is used by SOAP
as a sort of deployment descriptor, it will need to include (de)serializer
info, just like SOAP deployment descriptors do.

Nirmal.


Aleksander Slominski <aslom@...> on 02/06/2001 09:36:56 PM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:
Subject:  Re: [wsdl] Re: Local Web Services



Nirmal Mukhi wrote:

> I think our end objective is similar, but there's an important
> difference
> in our definition of local services:
>
> In one of your examples, a service whose "server" runs inside a
> different
> JVM from the "client" is remote - I notice that you check locality by
> checking references. My thinking was that a service available on the
> same
> machine (even running in a different JVM) is local, and you don't have
> to
> do very much (like (de)serialization and HTTP transport) to communicate
>
> with it - that is what defines locality in some ways. I favor this
> definition more since it can be made somewhat consistent across types
> of
> services...if we define locality in terms of JVMs for java services,
> what
> would we do for a C++ or python web service?

locality can be defined in terms of process boundaries for Java JVM is
simply process boundary. it is just that Java-Java communication can be
more efficient (RMI and native Java serialization) but as we have now
SOAP we have finally simple common fail-over communication protocol so as
long as all parties understand SOAP we can talk (though may be a bit
slow...).

in SoapRMI we have now common XML description for endpoints and it is
used both in Java and C++. we are also considering supporting multiple
endpoints (we have it now in XML but they are not used) and it will allow
runtime system (RTS) to choose the best communication endpoint _in
runtime_ (i would love to see multiple endpoints added to WSDL and as
well multiple portTypes...).

therefore the XML description of web service (such as WSDL or our Port
XML) is made available into some kind of registry (JNDI compatible
directory, UDDI, RMI registry etc.) can RTS can lookup this service, gets
XML description and chooses the most efficient transport to use. and this
will provide transparent access to services independent of location
(choosing closer locality or in worst case falling back to SOAP).

for example if we have web service published in JNDI that has following
endpoints:
* RMI endpoint bound to RMI registry (port:host)
* SOAP endpoint (port:host)
* private protocol that is supporting high performance communication but
only for special clients

RTS system can be very flexible. if C++ client is connecting it will
chose SOAP (as it does not know other protocols) or maybe special C++
client will have support for high-perf communication and the naturally
chose third option. Java client will chose RMI but it may still use SOAP
for short messages or as kind of signal channel.

if there were multiple endpoints of the same type (such SOAP) RTS could
chose the closest one (as measured by ping round-trip time or simply by
domain name) and in case of failure try to connect to next endpoint
(fail-over).

of course user should be able to override RTS default behavior, and say,
require only SOAP communication.


> Our approach, as you pointed out, is very WSDL-centric. I like WSDL,
> it's a
> nice flexible entry point for any kind of service. My thinking is that,
>
> once we define what local services are, a web service could advertise
> itself as being available at URI http://x.y.z/... over SOAP and also
> available in a local implementation as the java class foo.bar on
> machine
> 1.2.3.4. Then the proxy generator can automatically generate the most
> convenient proxy - the local one if available, otherwise the SOAP
> proxy.
> The client would just use the generated proxy, oblivious to the real
> nature
> of the service. But these are just pipe dreams yet...

in SoapRMI we have actually dynamic proxies so depending on XML port
description we can create specialized stub such as SOAP or not to create
it at all if it is local object.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Nirmal Mukhi wrote:

> I think our end objective is similar, but there's an important
> difference
> in our definition of local services:
>
> In one of your examples, a service whose "server" runs inside a
> different
> JVM from the "client" is remote - I notice that you check locality by
> checking references. My thinking was that a service available on the
> same
> machine (even running in a different JVM) is local, and you don't have
> to
> do very much (like (de)serialization and HTTP transport) to communicate
>
> with it - that is what defines locality in some ways. I favor this
> definition more since it can be made somewhat consistent across types
> of
> services...if we define locality in terms of JVMs for java services,
> what
> would we do for a C++ or python web service?

locality can be defined in terms of process boundaries for Java JVM is
simply process boundary. it is just that Java-Java communication can be
more efficient (RMI and native Java serialization) but as we have now
SOAP we have finally simple common fail-over communication protocol so as
long as all parties understand SOAP we can talk (though may be a bit
slow...).

in SoapRMI we have now common XML description for endpoints and it is
used both in Java and C++. we are also considering supporting multiple
endpoints (we have it now in XML but they are not used) and it will allow
runtime system (RTS) to choose the best communication endpoint _in
runtime_ (i would love to see multiple endpoints added to WSDL and as
well multiple portTypes...).

therefore the XML description of web service (such as WSDL or our Port
XML) is made available into some kind of registry (JNDI compatible
directory, UDDI, RMI registry etc.) can RTS can lookup this service, gets
XML description and chooses the most efficient transport to use. and this
will provide transparent access to services independent of location
(choosing closer locality or in worst case falling back to SOAP).

for example if we have web service published in JNDI that has following
endpoints:
* RMI endpoint bound to RMI registry (port:host)
* SOAP endpoint (port:host)
* private protocol that is supporting high performance communication but
only for special clients

RTS system can be very flexible. if C++ client is connecting it will
chose SOAP (as it does not know other protocols) or maybe special C++
client will have support for high-perf communication and the naturally
chose third option. Java client will chose RMI but it may still use SOAP
for short messages or as kind of signal channel.

if there were multiple endpoints of the same type (such SOAP) RTS could
chose the closest one (as measured by ping round-trip time or simply by
domain name) and in case of failure try to connect to next endpoint
(fail-over).

of course user should be able to override RTS default behavior, and say,
require only SOAP communication.


> Our approach, as you pointed out, is very WSDL-centric. I like WSDL,
> it's a
> nice flexible entry point for any kind of service. My thinking is that,
>
> once we define what local services are, a web service could advertise
> itself as being available at URI http://x.y.z/... over SOAP and also
> available in a local implementation as the java class foo.bar on
> machine
> 1.2.3.4. Then the proxy generator can automatically generate the most
> convenient proxy - the local one if available, otherwise the SOAP
> proxy.
> The client would just use the generated proxy, oblivious to the real
> nature
> of the service. But these are just pipe dreams yet...

in SoapRMI we have actually dynamic proxies so depending on XML port
description we can create specialized stub such as SOAP or not to create
it at all if it is local object.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)

Hi Alek,

I think our end objective is similar, but there's an important difference
in our definition of local services:

In one of your examples, a service whose "server" runs inside a different
JVM from the "client" is remote - I notice that you check locality by
checking references. My thinking was that a service available on the same
machine (even running in a different JVM) is local, and you don't have to
do very much (like (de)serialization and HTTP transport) to communicate
with it - that is what defines locality in some ways. I favor this
definition more since it can be made somewhat consistent across types of
services...if we define locality in terms of JVMs for java services, what
would we do for a C++ or python web service?

Our approach, as you pointed out, is very WSDL-centric. I like WSDL, it's a
nice flexible entry point for any kind of service. My thinking is that,
once we define what local services are, a web service could advertise
itself as being available at URI http://x.y.z/... over SOAP and also
available in a local implementation as the java class foo.bar on machine
1.2.3.4. Then the proxy generator can automatically generate the most
convenient proxy - the local one if available, otherwise the SOAP proxy.
The client would just use the generated proxy, oblivious to the real nature
of the service. But these are just pipe dreams yet...

Nirmal.


Aleksander Slominski <aslom@...> on 02/06/2001 12:30:22 AM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:   Madhusudhan Govindaraju <mgovinda@...>, Randall Bramley
       <bramley@...>, Dennis Gannon <gannon@...>
Subject:  [wsdl] Re: Local Web Services



Nirmal Mukhi" <nmukhi@...> wrote:

>    Date: Mon, 5 Feb 2001 16:45:01 -0500
>    From: "Nirmal Mukhi" <nmukhi@...>
> Subject: Local Web Services
>
> Hello,
>
> We have been thinking about extending the Web service abstraction to
> "local" web services, for example, treating a local java class as a web
> service. The advantage of that would be a uniform treatment of local and
> remote "services."
>
> Here's a start at defining what local web services are:
>
> 1. They are specified in the WSDL description of a service
> 2. A service should behave consistently irrespective of whether it is
local
> or remote.
> 3. It shoud be possible to access a local service without having to use
> XML-based transport, and thus there should be no requirement of data
> (de)serialization. However, there is the issue of mapping the schema
types
> to/from the native type system of the local service provider/user.
> 4. The process of enabling the client to use a service (running the WSDL
> through a tool to generate a local provider which acts as a proxy) should
> remain the same.
>
> Local services would also give us a clean way of deploying SOAP services,
> since the information contained in a SOAP deployment descriptor seems to
be
> just like a local binding specification. In the Apache SOAP case, this
> would mean that the RPCRouter is acting as a client of the local web
> service that is accessed remotely using SOAP....
>
> Some others have also hinted at this kind of an approach on various
lists.
> It'll be great to come up with a standard way to define local services
WSDL
> (with bindings for Java, COM, .Net, etc.).

Hi Nirmal,

i think that it is very good idea to provide location independent web
services
access mechanism. it is also desirable as you say in 3. that when accessing
local
objects there should be no need to with XML/HTTP.

in SoapRMI/Java we have implemented transparent access to local web
service. each
object that extends UnicastRemoteObject automatically becomes SOAP
accessible (by
using exportObject it is also possible to specify for remote object: TCP/IP
port,
object name or interface that it implements, and mappings from XML schema
types to
java types). therefore as local and remote objects are the same object we
are
meeting requirement 2.

the client when accessing web service (implemented as remote or local
object) will
need to lookup service in JNDI directory such as LDAP  (when JNDI is not
available
the client can still use our SoapRMI registry).

here is simple example of client accessing HelloService specified in this
Java
interface:


      public interface HelloService extends Remote {
        public String sayHello(String name) throws RemoteException;
      }

the client is looking up two objects "Bar" and "Foo" and then executes
method on
them - see (2). for testing this class accepts command line parameters with
list of
strings - each string will give a name to rebind new web service - see (1).
and
there is some code that actually check if object implementing web service
is local
or remote - see (3) and below HelloServiceImpl.java:


      public class HelloClient {
        public static void main (String args[]) throws Exception {
          // (1)  initialize local services - bind them to directory if
there are any
      command line arguments
          HelloServiceImpl.main(args);

          // if we were using Soap RMI registry:
          //HelloService bar = (HelloService) Naming.lookup("Bar");

          DirContext ctx = HelloServiceImpl.getInitialDirContext();
          // (2) lookup services in JNDI directory
          HelloService bar = (HelloService) ctx.lookup("Bar");
          HelloService foo = (HelloService) ctx.lookup("Foo");
          System.out.println("bar said: "+bar.sayHello("World"));
          System.out.println("foo said: "+foo.sayHello("World again!"));
          // (3) now we do check if objects are local or remote references
          System.out.println("bar is "+HelloServiceImpl.isLocal(bar));
          System.out.println("foo is "+HelloServiceImpl.isLocal(foo));
        }
      }

and here is implementation of web service - actual method implementing
HelloService
interface is in (1). method main() job is to bind web services to names
passed as
command line arguments (2).

in (3) parameter object is compared with list of created remote objects and
in (4)
there is simple utility method to obtain JNDI directory context:


      package samples.jndi;
      import java.util.Hashtable;
      import javax.naming.*;
      import javax.naming.directory.*;
      import soaprmi.RemoteException;
      import soaprmi.server.UnicastRemoteObject;
      public class HelloServiceImpl extends UnicastRemoteObject
        implements HelloService
      {
        public HelloServiceImpl() throws RemoteException {
        }
        public String sayHello(String name) throws RemoteException {
          return "Hello "+name; //(1)
        }
        public static Object createdObjects[];
        public static void main(String args[]) throws Exception {
          DirContext ctx = getInitialDirContext();
          createdObjects = new Object[args.length];
          for(int i = 0; i < args.length; ++i) { //(2)
            HelloService serverImpl = new HelloServiceImpl();
            createdObjects[i] = serverImpl;
            //Naming.rebind(args[i], serverImpl);
            ctx.rebind(args[i], serverImpl);
            System.out.println("Server created and bound"
               +" in the directory to "+args[i]);
          }
        }
        public static boolean isLocal(Object obj) {  //(3)
          for(int i = 0; i < createdObjects.length; ++i) {
            // this compares _references_ as equals() could be true for
stubs
            if(createdObjects[i] == obj)
             return true;
          }
          return false;
        }
        public final static String LDAP_URL =
          "ldap://xxx.extreme.indiana.edu/"
             +"o=JNDITest,dc=cs,dc=indiana,dc=edu";

        //(4)
        public static DirContext getInitialDirContext() throws
NamingException {
          Hashtable env = new Hashtable(11);
          env.put(Context.INITIAL_CONTEXT_FACTORY,
                  "com.sun.jndi.ldap.LdapCtxFactory");
          env.put(Context.PROVIDER_URL, LDAP_URL);
          env.put(Context.OBJECT_FACTORIES,
            soaprmi.jndi.SoapRMIPortFactory.class.getName());
          return new InitialDirContext(env);
        }

      }

so let see how it is all working :-)

first let start a client with all services available locally (so they are
local
objects): samples.jndi.HelloClient Bar Foo

      Server created and bound in the directory to Bar
      Server created and bound in the directory to Foo
      bar said: Hello World
      foo said: Hello World again!
      bar is true
      foo is true

now let start a service in another JVM - samples.jndi.HelloServiceImpl Foo:

      Server created and bound in the directory to Foo

and let start client with only one service object available locally -
samples.jndi.HelloClient Bar

      Server created and bound in the directory to Bar
      bar said: Hello World
      foo said: Hello World again!
      bar is true
      foo is false

as you can see here bar is local object but foo is now remote.

and let see what will happen if we do not have Bar service available or it
died
before - samples.jndi.HelloClient

      Exception in thread "main" IO Exception; nested exception is:
      java.net.ConnectException: Connection refused: no further information
              at java.net.PlainSocketImpl.socketConnect(Native Method)
              at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:312)
              at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:125)
              at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:112)
              at java.net.Socket.<init>(Socket.java:273)
              at java.net.Socket.<init>(Socket.java:100)
              at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
              at sun.net.www.http.HttpClient.openServer(HttpClient.java:331)
              at sun.net.www.http.HttpClient.openServer(HttpClient.java:517)
              at sun.net.www.http.HttpClient.<init>(HttpClient.java:267)
              at sun.net.www.http.HttpClient.<init>(HttpClient.java:277)
              at sun.net.www.http.HttpClient.New(HttpClient.java:289)
              at
      sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection
      .java:379)
              at
      sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLCo
      nnection.java:426)
              at
soaprmi.soaprpc.SoapDynamicStub.invoke(SoapDynamicStub.java:107)
              at $Proxy0.sayHello(Unknown Source)
              at samples.jndi.HelloClient.main(HelloClient.java:25)

i think that using JNDI (or UDDI in the future) will be a great way to hide
service
location and as we show above local objects can be still accessed very
efficiently
with no performance penalty at all - they are _actual_ service objects and
not
proxies.

as of 1. and 4. we do not use WSDL but very simple XML to describe remote
reference
and as actually it is pretty much a subset of WSDL so we can possibly in
future
allow to create a dynamic proxy for WSDL (we are doing it right now with
our
remote-ref XMLs). and we can of course always publish WSDL to our service
to make it
available to other SOAP WSDL-enabled implementations.

let me know what you think about it.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika
(1162-1241)




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Hi,

At this point we are just trying to define what local services are, what
additions would have to be made to the WSDL spec to support local services,
how SOAP service deployment would be affected, etc.

Nirmal.


"George I Matkovits" <matkovitsg@...> on 02/05/2001 10:27:21 PM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:
Subject:  Re: [wsdl] Local Web Services



Sounds like a really great idea! Which WSDL compiler are you planning to
use?
Regards - George

Nirmal Mukhi wrote:

> Hello,
>
> We have been thinking about extending the Web service abstraction to
> "local" web services, for example, treating a local java class as a web
> service. The advantage of that would be a uniform treatment of local and
> remote "services."
>
> Here's a start at defining what local web services are:
>
> 1. They are specified in the WSDL description of a service
> 2. A service should behave consistently irrespective of whether it is
local
> or remote.
> 3. It shoud be possible to access a local service without having to use
> XML-based transport, and thus there should be no requirement of data
> (de)serialization. However, there is the issue of mapping the schema
types
> to/from the native type system of the local service provider/user.
> 4. The process of enabling the client to use a service (running the WSDL
> through a tool to generate a local provider which acts as a proxy) should
> remain the same.
>
> Local services would also give us a clean way of deploying SOAP services,
> since the information contained in a SOAP deployment descriptor seems to
be
> just like a local binding specification. In the Apache SOAP case, this
> would mean that the RPCRouter is acting as a client of the local web
> service that is accessed remotely using SOAP....
>
> Some others have also hinted at this kind of an approach on various
lists.
> It'll be great to come up with a standard way to define local services
WSDL
> (with bindings for Java, COM, .Net, etc.).
>
> Nirmal.
>
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com



To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Absolutely... 'sequence' is the correct compositor for an model
group representing an array. cf. :

http://www.w3.org/TR/2000/CR-xmlschema-1-
20001024/#Model_Group_details

RC

> And while we're talking about WSDL arrays...
> In http://www.xmethods.net/sd/XMethodsListingsService.wsdl
>
> I have an array defined like this:
>
> <element name="itemArray">
>    <complexType name="ArrayOfSOAPService" base="soap:Array">
>       <all>
>          <element name="item" type="xsdl:SOAPService" />
>       </all>
> </complexType>
>
> But I now believe this is incorrect, since <all> groupings allow
> only 0 or 1 occurences of the enclosed element, in this case <item> -
> which isn't right for an array.
>
> So instead, <sequence> should be used rather than <all>
>
> Is everyone in agreement with this reassessment?
>
> Thanks!
>
> Tony
>
>
>
>
> ----------------------------------------
> XMethods Web Services Listings
> http://www.xmethods.net
>
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com
>
>

And while we're talking about WSDL arrays...
In http://www.xmethods.net/sd/XMethodsListingsService.wsdl

I have an array defined like this:

<element name="itemArray">
    <complexType name="ArrayOfSOAPService" base="soap:Array">
       <all>
          <element name="item" type="xsdl:SOAPService" />
       </all>
</complexType>

But I now believe this is incorrect, since <all> groupings allow
only 0 or 1 occurences of the enclosed element, in this case <item> -
which isn't right for an array.

So instead, <sequence> should be used rather than <all>

Is everyone in agreement with this reassessment?

Thanks!

Tony




----------------------------------------
XMethods Web Services Listings
http://www.xmethods.net

On Tue, 06 Feb 2001 00:15:41 -0000, in soap you wrote:

>I came across a good example of an interop issue.  The WSDL at this
>url
>http://www.xmethods.net/sd/XMethodsListingsService.wsdl
>has schema associated with its types element (this is included at the
>bottom).  The schema is entirely correct, but does provide an
>interesting issue when returning or sending objects.  This particular
>wsdl doc has an array of objects associated with it.  Under
>a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
>can be easily resolved without the aid of schema. 

Assuming xsd points to http://www.w3.org/1999/XMLSchema then
xsd:ArrayOfFloat doesn't exist. what i've seen everyone else do for
arrays, is to define their own type for arrays, following the
recommended naming convention from the WSDL spec. (there's still an
outstanding debate of how exactly the array should be defined)

This could be massively simplified by someone coming up with a schema
that defines all the common array types and importing it in. However
the current MS toolkit doesn't support import, and i'm not sure how
many others do.

>However, when the
>part has an element attribute the schema must be involved.  In our
>implementation an element attribute is equivalent to passing an
>object, e.g., this is a critical issue (for us).  In the example the
>response part's element attribute is "tns:ItemArray" .  A processor
>could correctly determine that this object is an array of objects by
>retrieving the preappended the "Array" from the text and prefixing
>with non-"xsd".   However, it would appear more gentle to
>use "tns:ArrayOfSOAPService" as this would be as easily resolvable
>into
>a) element attribute confirms schema is involved (object in our case)
>b) "tns" confirms same as [a]
>c) "ArrayOf" signals and array is present (which is same when xsd
>type is present.
>d) "SOAPService" gives us the root of the schema tree to resolve
>downward.
>
>Opinions.....?????

ok, try this.

1. complex types can be "linked" from the messages section to the
types section via a element name / element pair or a complex type /
type pair

2. the uri for tns needs to match the targetnamespace in the
\\types\schema section

3. the complex type definition is inheriting from soap:Array and this
should be used to indicate that its an array. the all/sequence/element
info within the complexType has the info to de-reference the array
contents.

(IMO) basing it on the text name is a mistake, you've got to pick your
way through all the schema references, I'm beginning to understand why
Jacek didn't like it !

Cheers
Simon
www.pocketsoap.com


To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

Nirmal Mukhi" <nmukhi@...> wrote:

>    Date: Mon, 5 Feb 2001 16:45:01 -0500
>    From: "Nirmal Mukhi" <nmukhi@...>
> Subject: Local Web Services
>
> Hello,
>
> We have been thinking about extending the Web service abstraction to
> "local" web services, for example, treating a local java class as a web
> service. The advantage of that would be a uniform treatment of local and
> remote "services."
>
> Here's a start at defining what local web services are:
>
> 1. They are specified in the WSDL description of a service
> 2. A service should behave consistently irrespective of whether it is local
> or remote.
> 3. It shoud be possible to access a local service without having to use
> XML-based transport, and thus there should be no requirement of data
> (de)serialization. However, there is the issue of mapping the schema types
> to/from the native type system of the local service provider/user.
> 4. The process of enabling the client to use a service (running the WSDL
> through a tool to generate a local provider which acts as a proxy) should
> remain the same.
>
> Local services would also give us a clean way of deploying SOAP services,
> since the information contained in a SOAP deployment descriptor seems to be
> just like a local binding specification. In the Apache SOAP case, this
> would mean that the RPCRouter is acting as a client of the local web
> service that is accessed remotely using SOAP....
>
> Some others have also hinted at this kind of an approach on various lists.
> It'll be great to come up with a standard way to define local services WSDL
> (with bindings for Java, COM, .Net, etc.).

Hi Nirmal,

i think that it is very good idea to provide location independent web services
access mechanism. it is also desirable as you say in 3. that when accessing
local
objects there should be no need to with XML/HTTP.

in SoapRMI/Java we have implemented transparent access to local web service.
each
object that extends UnicastRemoteObject automatically becomes SOAP accessible
(by
using exportObject it is also possible to specify for remote object: TCP/IP
port,
object name or interface that it implements, and mappings from XML schema types
to
java types). therefore as local and remote objects are the same object we are
meeting requirement 2.

the client when accessing web service (implemented as remote or local object)
will
need to lookup service in JNDI directory such as LDAP  (when JNDI is not
available
the client can still use our SoapRMI registry).

here is simple example of client accessing HelloService specified in this Java
interface:


      public interface HelloService extends Remote {
        public String sayHello(String name) throws RemoteException;
      }

the client is looking up two objects "Bar" and "Foo" and then executes method on
them - see (2). for testing this class accepts command line parameters with list
of
strings - each string will give a name to rebind new web service - see (1). and
there is some code that actually check if object implementing web service is
local
or remote - see (3) and below HelloServiceImpl.java:


      public class HelloClient {
        public static void main (String args[]) throws Exception {
          // (1)  initialize local services - bind them to directory if there are
any
      command line arguments
          HelloServiceImpl.main(args);

          // if we were using Soap RMI registry:
          //HelloService bar = (HelloService) Naming.lookup("Bar");

          DirContext ctx = HelloServiceImpl.getInitialDirContext();
          // (2) lookup services in JNDI directory
          HelloService bar = (HelloService) ctx.lookup("Bar");
          HelloService foo = (HelloService) ctx.lookup("Foo");
          System.out.println("bar said: "+bar.sayHello("World"));
          System.out.println("foo said: "+foo.sayHello("World again!"));
          // (3) now we do check if objects are local or remote references
          System.out.println("bar is "+HelloServiceImpl.isLocal(bar));
          System.out.println("foo is "+HelloServiceImpl.isLocal(foo));
        }
      }

and here is implementation of web service - actual method implementing
HelloService
interface is in (1). method main() job is to bind web services to names passed
as
command line arguments (2).

in (3) parameter object is compared with list of created remote objects and in
(4)
there is simple utility method to obtain JNDI directory context:


      package samples.jndi;
      import java.util.Hashtable;
      import javax.naming.*;
      import javax.naming.directory.*;
      import soaprmi.RemoteException;
      import soaprmi.server.UnicastRemoteObject;
      public class HelloServiceImpl extends UnicastRemoteObject
        implements HelloService
      {
        public HelloServiceImpl() throws RemoteException {
        }
        public String sayHello(String name) throws RemoteException {
          return "Hello "+name; //(1)
        }
        public static Object createdObjects[];
        public static void main(String args[]) throws Exception {
          DirContext ctx = getInitialDirContext();
          createdObjects = new Object[args.length];
          for(int i = 0; i < args.length; ++i) { //(2)
            HelloService serverImpl = new HelloServiceImpl();
            createdObjects[i] = serverImpl;
            //Naming.rebind(args[i], serverImpl);
            ctx.rebind(args[i], serverImpl);
            System.out.println("Server created and bound"
               +" in the directory to "+args[i]);
          }
        }
        public static boolean isLocal(Object obj) {  //(3)
          for(int i = 0; i < createdObjects.length; ++i) {
            // this compares _references_ as equals() could be true for stubs
            if(createdObjects[i] == obj)
             return true;
          }
          return false;
        }
        public final static String LDAP_URL =
          "ldap://xxx.extreme.indiana.edu/"
             +"o=JNDITest,dc=cs,dc=indiana,dc=edu";

        //(4)
        public static DirContext getInitialDirContext() throws NamingException {
          Hashtable env = new Hashtable(11);
          env.put(Context.INITIAL_CONTEXT_FACTORY,
                  "com.sun.jndi.ldap.LdapCtxFactory");
          env.put(Context.PROVIDER_URL, LDAP_URL);
          env.put(Context.OBJECT_FACTORIES,
            soaprmi.jndi.SoapRMIPortFactory.class.getName());
          return new InitialDirContext(env);
        }

      }

so let see how it is all working :-)

first let start a client with all services available locally (so they are local
objects): samples.jndi.HelloClient Bar Foo

      Server created and bound in the directory to Bar
      Server created and bound in the directory to Foo
      bar said: Hello World
      foo said: Hello World again!
      bar is true
      foo is true

now let start a service in another JVM - samples.jndi.HelloServiceImpl Foo:

      Server created and bound in the directory to Foo

and let start client with only one service object available locally -
samples.jndi.HelloClient Bar

      Server created and bound in the directory to Bar
      bar said: Hello World
      foo said: Hello World again!
      bar is true
      foo is false

as you can see here bar is local object but foo is now remote.

and let see what will happen if we do not have Bar service available or it died
before - samples.jndi.HelloClient

      Exception in thread "main" IO Exception; nested exception is:
      java.net.ConnectException: Connection refused: no further information
              at java.net.PlainSocketImpl.socketConnect(Native Method)
              at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:312)
              at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:125)
              at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:112)
              at java.net.Socket.<init>(Socket.java:273)
              at java.net.Socket.<init>(Socket.java:100)
              at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
              at sun.net.www.http.HttpClient.openServer(HttpClient.java:331)
              at sun.net.www.http.HttpClient.openServer(HttpClient.java:517)
              at sun.net.www.http.HttpClient.<init>(HttpClient.java:267)
              at sun.net.www.http.HttpClient.<init>(HttpClient.java:277)
              at sun.net.www.http.HttpClient.New(HttpClient.java:289)
              at
      sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection
      .java:379)
              at
      sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLCo
      nnection.java:426)
              at soaprmi.soaprpc.SoapDynamicStub.invoke(SoapDynamicStub.java:107)
              at $Proxy0.sayHello(Unknown Source)
              at samples.jndi.HelloClient.main(HelloClient.java:25)

i think that using JNDI (or UDDI in the future) will be a great way to hide
service
location and as we show above local objects can be still accessed very
efficiently
with no performance penalty at all - they are _actual_ service objects and not
proxies.

as of 1. and 4. we do not use WSDL but very simple XML to describe remote
reference
and as actually it is pretty much a subset of WSDL so we can possibly in future
allow to create a dynamic proxy for WSDL (we are doing it right now with our
remote-ref XMLs). and we can of course always publish WSDL to our service to
make it
available to other SOAP WSDL-enabled implementations.

let me know what you think about it.

thanks,

alek
--
Aleksander Slominski, LH 316, IU, http://www.extreme.indiana.edu/~aslom
As I look afar I see neither cherry Nor tinted leaves Just a modest hut
on the coast In the dusk of Autumn nightfall - Fujiwara no Teika (1162-1241)

WSDL make using tcpTrace (or the Apache original) more troublesome, as
you normally have to tweak the WSDL so that the URLs it contains go
through your trace setup. I got fed up with that and made a version of
tcpTrace that acts as a real HTTP proxy server, making it much easier
to test WSDL based tools with (assuming you have a SOAP client with
proxy server support)

www.pocketsoap.com/tcptrace/pt.asp

Cheers
Simon
www.pocketsoap.com

Sounds like a really great idea! Which WSDL compiler are you planning to use?
Regards - George

Nirmal Mukhi wrote:

> Hello,
>
> We have been thinking about extending the Web service abstraction to
> "local" web services, for example, treating a local java class as a web
> service. The advantage of that would be a uniform treatment of local and
> remote "services."
>
> Here's a start at defining what local web services are:
>
> 1. They are specified in the WSDL description of a service
> 2. A service should behave consistently irrespective of whether it is local
> or remote.
> 3. It shoud be possible to access a local service without having to use
> XML-based transport, and thus there should be no requirement of data
> (de)serialization. However, there is the issue of mapping the schema types
> to/from the native type system of the local service provider/user.
> 4. The process of enabling the client to use a service (running the WSDL
> through a tool to generate a local provider which acts as a proxy) should
> remain the same.
>
> Local services would also give us a clean way of deploying SOAP services,
> since the information contained in a SOAP deployment descriptor seems to be
> just like a local binding specification. In the Apache SOAP case, this
> would mean that the RPCRouter is acting as a client of the local web
> service that is accessed remotely using SOAP....
>
> Some others have also hinted at this kind of an approach on various lists.
> It'll be great to come up with a standard way to define local services WSDL
> (with bindings for Java, COM, .Net, etc.).
>
> Nirmal.
>
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com

On Tue, 06 Feb 2001 00:15:41 -0000, in soap you wrote:

>I came across a good example of an interop issue.  The WSDL at this
>url
>http://www.xmethods.net/sd/XMethodsListingsService.wsdl
>has schema associated with its types element (this is included at the
>bottom).  The schema is entirely correct, but does provide an
>interesting issue when returning or sending objects.  This particular
>wsdl doc has an array of objects associated with it.  Under
>a "normal" processor a part with type attribute = "xsd:ArrayOfFloat"
>can be easily resolved without the aid of schema.

Assuming xsd points to http://www.w3.org/1999/XMLSchema then
xsd:ArrayOfFloat doesn't exist. what i've seen everyone else do for
arrays, is to define their own type for arrays, following the
recommended naming convention from the WSDL spec. (there's still an
outstanding debate of how exactly the array should be defined)

This could be massively simplified by someone coming up with a schema
that defines all the common array types and importing it in. However
the current MS toolkit doesn't support import, and i'm not sure how
many others do.

>However, when the
>part has an element attribute the schema must be involved.  In our
>implementation an element attribute is equivalent to passing an
>object, e.g., this is a critical issue (for us).  In the example the
>response part's element attribute is "tns:ItemArray" .  A processor
>could correctly determine that this object is an array of objects by
>retrieving the preappended the "Array" from the text and prefixing
>with non-"xsd".   However, it would appear more gentle to
>use "tns:ArrayOfSOAPService" as this would be as easily resolvable
>into
>a) element attribute confirms schema is involved (object in our case)
>b) "tns" confirms same as [a]
>c) "ArrayOf" signals and array is present (which is same when xsd
>type is present.
>d) "SOAPService" gives us the root of the schema tree to resolve
>downward.
>
>Opinions.....?????

ok, try this.

1. complex types can be "linked" from the messages section to the
types section via a element name / element pair or a complex type /
type pair

2. the uri for tns needs to match the targetnamespace in the
\\types\schema section

3. the complex type definition is inheriting from soap:Array and this
should be used to indicate that its an array. the all/sequence/element
info within the complexType has the info to de-reference the array
contents.

(IMO) basing it on the text name is a mistake, you've got to pick your
way through all the schema references, I'm beginning to understand why
Jacek didn't like it !

Cheers
Simon
www.pocketsoap.com

is the WSDL 1.1 spec published yet ?

Thanks
Simon

On Sun, 4 Feb 2001 21:04:01 -0800 , in soap you wrote:

>p.s. we clarified this in 1.1.
>
>:-)
>
>-erik
>
>-----Original Message-----
>From: Sanjiva Weerawarana [mailto:sanjiva@...]
>Sent: Sunday, February 04, 2001 3:52 AM
>To: wsdl@yahoogroups.com
>Subject: Re: [wsdl] Re: SOAP Wrapper Element Tag Name
>
>
>Me too! This is the only correct interpretation of WSDL that is
>consistent with the SOAP 1.1 spec!
>
>Sanjiva.
>
>----- Original Message -----
>From: erikc@... <mailto:erikc@...>
>To: wsdl@yahoogroups.com <mailto:wsdl@yahoogroups.com>
>Sent: Friday, February 02, 2001 6:35 PM
>Subject: [wsdl] Re: SOAP Wrapper Element Tag Name
>
>I agree (yes, this is different than what I posted earlier).
>
>-Erik
>--- In wsdl@y <mailto:wsdl@y> ..., mikedeem@m <mailto:mikedeem@m> ... wrote:
>> I anticipate that the clarification will be that the wrapper
>element
>> is named identically to the operation name and its namespace is the
>> value of the namespace attribute on the soap:body element. This is
>> consistent with section 7.1 of the SOAP 1.1. specification.
>>
>>   == Mike ==
>>
>>
>> --- In wsdl@y..., "Bob Cunnings" <cunnings@l...> wrote:
>> > Hello,
>> >
>> > This is not a new issue, but I would like to see if a consensus
>has
>> emerged.
>> >
>> > No matter how hard I try, I see nothing in the WSDL 1.0 spec that
>> > addresses directly the matter of specifying the tag name of
>> the "wrapper
>> > element" that is the immediate child element of a SOAP section 7
>> RPC
>> > call. The wrapper element is described in section 3.5
>> > of WSDL 1.0 [1].
>> >
>> > -- WSDL co-author Eric Christensen states: [2]
>> > "You should use the name of the <input> element under the
>> <operation>
>> > element of the portType for the request element name (see section
>> 2.4.5
>> > of the WSDL 1.0 spec for more information). Similarly, you should
>> use
>> > the name of the <output> element under the <operation> element
>for
>> the
>> > response element name (but, as specified in the SOAP 1.1 spec,
>the
>> > name of the response element is not signficant)."
>> > It is clear that Eric is referring to the name of the <input> and
>> <output>
>> > elements themselves, *not* the names of the associated <message>
>> > elements.
>> >
>> > However, looking at WSDL files on the 'net, <input> and <output>
>> > elements names are usually left to the defaults per the spec,
>> section 2.4.5
>> > [3]. The same is done here. These defaults, if accepted, lead to
>a
>> de
>> > facto mapping to the <operation> element name that is harmonious
>> with
>> > SOAP 1.1 section 7.1.
>> >
>> > So, athough not explicit in the spec, [2] sounds like the way to
>go
>> as a
>> > non-normative convention. It leaves unanswered one question in my
>> > mind:
>> > Is the namespace URI of the tag name of this "wrapper element"
>> > specifiable by the <soap:body> extension element 'namespace'
>> attribute?
>> > If not, where? Or is it something outside the scope of the SOAP
>> binding
>> > extension mechanism in WSDL?
>> > At present, the SOAP processor at the server side (in the
>> > implementation here) looks to the WSDL to find this namespace
>URI.
>> It
>> > is needed  to validate the qualified method name actually found
>in
>> the
>> > request message.
>> >
>> > It remains my humble opinion that the WSDL spec needs to
>explicitly
>> > address this issue and provide a normative means of specifying
>the
>> tag
>> > name and namespace of this "wrapper element" in the SOAP Binding
>> > section.
>> >
>> > Ideas, anyone?
>> >
>> > RC
>> >
>> > [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
><http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body>
>> >
>> > [2]
>> > http://discuss.develop.com/archives/wa.exe?A2=ind0011
><http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35>
>&L=SOAP&P=R35
>> > 208
>> >
>> > [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names
><http://msdn.microsoft.com/xml/general/wsdl.asp#_names>
>
>
>
>To unsubscribe from this group, send an email to:
>wsdl-unsubscribe@yahoogroups.com
>
>
>
>
>
>Yahoo! Groups Sponsor
>
>
>
><http://rd.yahoo.com/M=176325.1307935.2900315.1248727/D=egroupmail/S=1700701
>014:N/A=567177/R=1/*http://domains.yahoo.com>
><http://rd.yahoo.com/M=176325.1307935.2900315.1248727/D=egroupmail/S=1700701
>014:N/A=567177/R=2/*http://domains.yahoo.com>
>
>www.
>
>
><http://us.adserver.yahoo.com/l?M=176325.1307935.2900315.1248727/D=egroupmai
>l/S=1700701014:N/A=567177/rand=240546454>
>
>To unsubscribe from this group, send an email to:
>wsdl-unsubscribe@yahoogroups.com
>
>
>

Hello,

We have been thinking about extending the Web service abstraction to
"local" web services, for example, treating a local java class as a web
service. The advantage of that would be a uniform treatment of local and
remote "services."

Here's a start at defining what local web services are:

1. They are specified in the WSDL description of a service
2. A service should behave consistently irrespective of whether it is local
or remote.
3. It shoud be possible to access a local service without having to use
XML-based transport, and thus there should be no requirement of data
(de)serialization. However, there is the issue of mapping the schema types
to/from the native type system of the local service provider/user.
4. The process of enabling the client to use a service (running the WSDL
through a tool to generate a local provider which acts as a proxy) should
remain the same.

Local services would also give us a clean way of deploying SOAP services,
since the information contained in a SOAP deployment descriptor seems to be
just like a local binding specification. In the Apache SOAP case, this
would mean that the RPCRouter is acting as a client of the local web
service that is accessed remotely using SOAP....

Some others have also hinted at this kind of an approach on various lists.
It'll be great to come up with a standard way to define local services WSDL
(with bindings for Java, COM, .Net, etc.).

Nirmal.

ANYONE WANTING TO MAKE A MSSOAP/WSDL CLIENT TALK TO AN APACHE SERVER...

I found Sanjiva's example in his comments as posted on soap-dev after making the
xsi:type change
I can confirm that this works - ms soap toolkit client using wsdl can talk to
apache soap if you follow the instructions

anyone interested can go to the following page to see how this works
http://marc.theaimsgroup.com/?l=soap-dev&m=97901982213396&w=2

you will need to have apache soap 2.1 (rc1) and update you deployment descriptor
  as described

Nick






mlong@... on 02/02/2001 09:51:14 AM

Please respond to wsdl@yahoogroups.com

To:   wsdl@yahoogroups.com
cc:   (bcc: Nicholas Quaine)
Subject:  RE: [wsdl] Making VB talk to an Apache SOAP Server




Nick,

We have a VB Soap Client and WSDL Interrogator that generates VBScript for
method calls from WSDL Documents it runs on the xmethods SOAP:Lite and
Apache SOAP implementations no problem.

We have been testing against xmethods for awhile and have had no problems
executing on either port 80 or 8080.

Here are some examples of the code generated from some of the xmethods WSDL
URLs with the WSDL Interrogator.  This is about as simple as I can make it
right now.  We will release the complete vbSOAP SDK in two weeks or less.

Examples from WSDL Interrogator (of course you could convert this VBScript,
to VB or JScript and still execute it.

-Matt


................Weather Temperation @xmethods.com..................

Function getTemp ( ByVal zipcode )

     ' zipcode type = xsd:string

     Set objClient = Server.CreateObject("vbSoapClient.Messaging")
     objClient.soapAction = ""
     objClient.soapAddress =
"http://services.xmethods.net:80/soap/servlet/rpcrouter"
     objClient.operationName = "getTemp"
     objClient.operationNamespace = "urn:xmethods-Temperature"
     objClient.xsdNamespace = "http://www.w3.org/1999/XMLSchema"
     objClient.xsiNamespace = "http://www.w3.org/1999/XMLSchema-instance"

     objClient.setParameter "zipcode", 1, "xsd:string", zipcode

     'output type = xsd:float

     getTemp = objClient.getValue( "return" )
End Function

............FedExTracker @xmethods.com..............

Function getStatus ( ByVal trackingNumber )

     ' trackingNumber type = xsd:string

     Set objClient = Server.CreateObject("vbSoapClient.Messaging")
     objClient.soapAction = "urn:xmethodsFedEx#getStatus"
     objClient.soapAddress =
"http://services.xmethods.net:80/perl/soaplite.cgi"
     objClient.operationName = "getStatus"
     objClient.operationNamespace = "urn:xmethodsFedEx"
     objClient.xsdNamespace = "http://www.w3.org/1999/XMLSchema"
     objClient.xsiNamespace = "http://www.w3.org/1999/XMLSchema-instance"

     objClient.setParameter "trackingNumber", 1, "xsd:string", trackingNumber

     'output type = xsd:string

     getStatus = objClient.getValue( "return" )
End Function




> All,
>
> has anyone out there managed to make a Visual Basic client (Microsoft
> SOAP Toolkit v2.0) which exploits a WSDL file work against a SOAP
> server implemented with Apache SOAP 2.0 or 2.1 ?
>
> I have made a VB client work against an Apache SOAP server by
> exploiting the low level API (ie. manipulating the soap envelope
> directly on the VB side to include the xsi:type param) but would like
> to get it working by exploiting the high level API / WSDL file.
>
> Apparently Apache SOAP 2.1 has "Reduced dependency on xsi:type for
> deserialization" - but I haven't yet seen how. examples...
> 1) If I take my VB client written with a low level API and remove the
> code which inserts the xsi:type line into the envelope, I get
> a server
> side error : "No Deserializer found" for my 'type' (actually my
> method's parameter name) - see actual error message below.
> 2) If I use the high level API and exploit a wsdl file I get the same
> error
>
> No Deserializer found to deserialize a ':imntType' using encoding
> style 'http://schemas.xmlsoap.org/soap/encoding/'.
>
> many thanks for any help you can provide
> I can be reached at quaine_nicholas@...
>
> Nick Quaine
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> eGroups is now Yahoo! Groups
> Click here for more details
> http://click.egroups.com/1/11231/1/_/_/_/981116288/
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com
>
>



To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com










This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co. Incorporated, its
subsidiaries and affiliates.

----- Original Message -----

From: erikc@...

To: wsdl@yahoogroups.com

Sent: Friday, February 02, 2001 6:35 PM

Subject: [wsdl] Re: SOAP Wrapper Element Tag Name

I agree (yes, this is different than what I posted earlier).

-Erik
--- In wsdl@y..., mikedeem@m... wrote:
> I anticipate that the clarification will be that the wrapper
element
> is named identically to the operation name and its namespace is the
> value of the namespace attribute on the soap:body element. This is
> consistent with section 7.1 of the SOAP 1.1. specification.
>
>   == Mike ==
>
>
> --- In wsdl@y..., "Bob Cunnings" <cunnings@l...> wrote:
> > Hello,
> >
> > This is not a new issue, but I would like to see if a consensus
has
> emerged.
> >
> > No matter how hard I try, I see nothing in the WSDL 1.0 spec that
> > addresses directly the matter of specifying the tag name of
> the "wrapper
> > element" that is the immediate child element of a SOAP section 7
> RPC
> > call. The wrapper element is described in section 3.5
> > of WSDL 1.0 [1].
> >
> > -- WSDL co-author Eric Christensen states: [2]
> > "You should use the name of the <input> element under the
> <operation>
> > element of the portType for the request element name (see section
> 2.4.5
> > of the WSDL 1.0 spec for more information). Similarly, you should
> use
> > the name of the <output> element under the <operation> element
for
> the
> > response element name (but, as specified in the SOAP 1.1 spec,
the
> > name of the response element is not signficant)."
> > It is clear that Eric is referring to the name of the <input> and
> <output>
> > elements themselves, *not* the names of the associated <message>
> > elements.
> >
> > However, looking at WSDL files on the 'net, <input> and <output>
> > elements names are usually left to the defaults per the spec,
> section 2.4.5
> > [3]. The same is done here. These defaults, if accepted, lead to
a
> de
> > facto mapping to the <operation> element name that is harmonious
> with
> > SOAP 1.1 section 7.1.
> >
> > So, athough not explicit in the spec, [2] sounds like the way to
go
> as a
> > non-normative convention. It leaves unanswered one question in my
> > mind:
> > Is the namespace URI of the tag name of this "wrapper element"
> > specifiable by the <soap:body> extension element 'namespace'
> attribute?
> > If not, where? Or is it something outside the scope of the SOAP
> binding
> > extension mechanism in WSDL?
> > At present, the SOAP processor at the server side (in the
> > implementation here) looks to the WSDL to find this namespace
URI.
> It
> > is needed  to validate the qualified method name actually found
in
> the
> > request message.
> >
> > It remains my humble opinion that the WSDL spec needs to
explicitly
> > address this issue and provide a normative means of specifying
the
> tag
> > name and namespace of this "wrapper element" in the SOAP Binding
> > section.
> >
> > Ideas, anyone?
> >
> > RC
> >
> > [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
> >
> > [2]
> > http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
> > 208
> >
> > [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names



To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

To:              <wsdl@yahoogroups.com>
From:            "Matt Long" <mlong@...>
Date sent:       Fri, 2 Feb 2001 20:59:41 -0600
Send reply to:   wsdl@yahoogroups.com
Subject:         RE: [wsdl] SOAP Wrapper Element Tag Name

Matt,

Yes, that is exactly what we are doing here, for rpc, as it seemed
to make the most sense once we had plunged into an actual
implementation. Since the applications here are exclusively rpc,
this was an issue that came into focus right away. I had hoped to
clear up the uncertainty a bit so that we didn't find ourselves in a
blind alley in terms of design and interoperablility.

RC
> Bob,
> Given the example generated, we use the name attribute of the operation
> element as scoped by the portType element as the first child of the
> SOAP-ENV:Body element in the request.  This applies only to rpc.  If this
> was a "document" message the name attribute of the operation is immaterial
> to the soap message as the "document" is enclosed by the SOAP-ENV:Body
> element, i.e., no "wrapper" for the operation.  We have found this extremely
> helpful when reading external WSDL documents, as we can generate VBScript
> from the WSDL and interop with other soap services, namely xmethods.com.  We
> have not have the opportunity to test throughly the "document" type of
> message has most services external services are focus on rpc.
>
> <portType name="MathbySOAP.IMathvariancePortType">
>  <operation name="variance">
> 	 <input message="tns:MathbySOAP.IMathvarianceRequest"/>
> 	 <output message="tns:MathbySOAP.IMathvarianceResponse"/>
>  </operation>
> </portType>
> <message name="MathbySOAP.IMathvarianceRequest">
>  <part name="numberList" type="xsd:ArrayOfFloat"/>
> </message>
> <message name="MathbySOAP.IMathvarianceResponse">
>  <part name="result" type="xsd:double"/>
> </message>
>
> >
> > Hello,
> >
> > This is not a new issue, but I would like to see if a
> > consensus has emerged.
> >
> > No matter how hard I try, I see nothing in the WSDL 1.0 spec that
> > addresses directly the matter of specifying the tag name of
> > the "wrapper
> > element" that is the immediate child element of a SOAP section 7 RPC
> > call. The wrapper element is described in section 3.5
> > of WSDL 1.0 [1].
> >
> > -- WSDL co-author Eric Christensen states: [2]
> > "You should use the name of the <input> element under the <operation>
> > element of the portType for the request element name (see
> > section 2.4.5
> > of the WSDL 1.0 spec for more information). Similarly, you should use
> > the name of the <output> element under the <operation>
> > element for the
> > response element name (but, as specified in the SOAP 1.1 spec, the
> > name of the response element is not signficant)."
> > It is clear that Eric is referring to the name of the <input>
> > and <output>
> > elements themselves, *not* the names of the associated <message>
> > elements.
> >
> > However, looking at WSDL files on the 'net, <input> and <output>
> > elements names are usually left to the defaults per the spec,
> > section 2.4.5
> > [3]. The same is done here. These defaults, if accepted, lead to a de
> > facto mapping to the <operation> element name that is harmonious with
> > SOAP 1.1 section 7.1.
> >
> > So, athough not explicit in the spec, [2] sounds like the way
> > to go as a
> > non-normative convention. It leaves unanswered one question in my
> > mind:
> > Is the namespace URI of the tag name of this "wrapper element"
> > specifiable by the <soap:body> extension element 'namespace'
> > attribute?
> > If not, where? Or is it something outside the scope of the
> > SOAP binding
> > extension mechanism in WSDL?
> > At present, the SOAP processor at the server side (in the
> > implementation here) looks to the WSDL to find this namespace URI. It
> > is needed  to validate the qualified method name actually
> > found in the
> > request message.
> >
> > It remains my humble opinion that the WSDL spec needs to explicitly
> > address this issue and provide a normative means of
> > specifying the tag
> > name and namespace of this "wrapper element" in the SOAP Binding
> > section.
> >
> > Ideas, anyone?
> >
> > RC
> >
> > [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
> >
> > [2]
> > http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
> > 208
> >
> > [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-~>
> > eGroups is now Yahoo! Groups
> > Click here for more details
> > http://click.egroups.com/1/11231/1/_/_/_/981145254/
> > --------------------------------------------------------------
> > -------_->
> >
> > To unsubscribe from this group, send an email to:
> > wsdl-unsubscribe@yahoogroups.com
> >
> >
>
>
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com
>
>

Bob,
Given the example generated, we use the name attribute of the operation
element as scoped by the portType element as the first child of the
SOAP-ENV:Body element in the request.  This applies only to rpc.  If this
was a "document" message the name attribute of the operation is immaterial
to the soap message as the "document" is enclosed by the SOAP-ENV:Body
element, i.e., no "wrapper" for the operation.  We have found this extremely
helpful when reading external WSDL documents, as we can generate VBScript
from the WSDL and interop with other soap services, namely xmethods.com.  We
have not have the opportunity to test throughly the "document" type of
message has most services external services are focus on rpc.

<portType name="MathbySOAP.IMathvariancePortType">
	 <operation name="variance">
		 <input message="tns:MathbySOAP.IMathvarianceRequest"/>
		 <output message="tns:MathbySOAP.IMathvarianceResponse"/>
	 </operation>
</portType>
<message name="MathbySOAP.IMathvarianceRequest">
	 <part name="numberList" type="xsd:ArrayOfFloat"/>
</message>
<message name="MathbySOAP.IMathvarianceResponse">
	 <part name="result" type="xsd:double"/>
</message>

>
> Hello,
>
> This is not a new issue, but I would like to see if a
> consensus has emerged.
>
> No matter how hard I try, I see nothing in the WSDL 1.0 spec that
> addresses directly the matter of specifying the tag name of
> the "wrapper
> element" that is the immediate child element of a SOAP section 7 RPC
> call. The wrapper element is described in section 3.5
> of WSDL 1.0 [1].
>
> -- WSDL co-author Eric Christensen states: [2]
> "You should use the name of the <input> element under the <operation>
> element of the portType for the request element name (see
> section 2.4.5
> of the WSDL 1.0 spec for more information). Similarly, you should use
> the name of the <output> element under the <operation>
> element for the
> response element name (but, as specified in the SOAP 1.1 spec, the
> name of the response element is not signficant)."
> It is clear that Eric is referring to the name of the <input>
> and <output>
> elements themselves, *not* the names of the associated <message>
> elements.
>
> However, looking at WSDL files on the 'net, <input> and <output>
> elements names are usually left to the defaults per the spec,
> section 2.4.5
> [3]. The same is done here. These defaults, if accepted, lead to a de
> facto mapping to the <operation> element name that is harmonious with
> SOAP 1.1 section 7.1.
>
> So, athough not explicit in the spec, [2] sounds like the way
> to go as a
> non-normative convention. It leaves unanswered one question in my
> mind:
> Is the namespace URI of the tag name of this "wrapper element"
> specifiable by the <soap:body> extension element 'namespace'
> attribute?
> If not, where? Or is it something outside the scope of the
> SOAP binding
> extension mechanism in WSDL?
> At present, the SOAP processor at the server side (in the
> implementation here) looks to the WSDL to find this namespace URI. It
> is needed  to validate the qualified method name actually
> found in the
> request message.
>
> It remains my humble opinion that the WSDL spec needs to explicitly
> address this issue and provide a normative means of
> specifying the tag
> name and namespace of this "wrapper element" in the SOAP Binding
> section.
>
> Ideas, anyone?
>
> RC
>
> [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
>
> [2]
> http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
> 208
>
> [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> eGroups is now Yahoo! Groups
> Click here for more details
> http://click.egroups.com/1/11231/1/_/_/_/981145254/
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com
>
>

Erik, what made you change your mind ?

Thanks
Simon

On Fri, 02 Feb 2001 23:35:23 -0000, in soap you wrote:

>I agree (yes, this is different than what I posted earlier).
>
>-Erik
>--- In wsdl@y..., mikedeem@m... wrote:
>> I anticipate that the clarification will be that the wrapper
>element
>> is named identically to the operation name and its namespace is the
>> value of the namespace attribute on the soap:body element. This is
>> consistent with section 7.1 of the SOAP 1.1. specification.
>>
>>   == Mike ==
>>
>>
>> --- In wsdl@y..., "Bob Cunnings" <cunnings@l...> wrote:
>> > Hello,
>> >
>> > This is not a new issue, but I would like to see if a consensus
>has
>> emerged.
>> >
>> > No matter how hard I try, I see nothing in the WSDL 1.0 spec that
>> > addresses directly the matter of specifying the tag name of
>> the "wrapper
>> > element" that is the immediate child element of a SOAP section 7
>> RPC
>> > call. The wrapper element is described in section 3.5
>> > of WSDL 1.0 [1].
>> >
>> > -- WSDL co-author Eric Christensen states: [2]
>> > "You should use the name of the <input> element under the
>> <operation>
>> > element of the portType for the request element name (see section
>> 2.4.5
>> > of the WSDL 1.0 spec for more information). Similarly, you should
>> use
>> > the name of the <output> element under the <operation> element
>for
>> the
>> > response element name (but, as specified in the SOAP 1.1 spec,
>the
>> > name of the response element is not signficant)."
>> > It is clear that Eric is referring to the name of the <input> and
>> <output>
>> > elements themselves, *not* the names of the associated <message>
>> > elements.
>> >
>> > However, looking at WSDL files on the 'net, <input> and <output>
>> > elements names are usually left to the defaults per the spec,
>> section 2.4.5
>> > [3]. The same is done here. These defaults, if accepted, lead to
>a
>> de
>> > facto mapping to the <operation> element name that is harmonious
>> with
>> > SOAP 1.1 section 7.1.
>> >
>> > So, athough not explicit in the spec, [2] sounds like the way to
>go
>> as a
>> > non-normative convention. It leaves unanswered one question in my
>> > mind:
>> > Is the namespace URI of the tag name of this "wrapper element"
>> > specifiable by the <soap:body> extension element 'namespace'
>> attribute?
>> > If not, where? Or is it something outside the scope of the SOAP
>> binding
>> > extension mechanism in WSDL?
>> > At present, the SOAP processor at the server side (in the
>> > implementation here) looks to the WSDL to find this namespace
>URI.
>> It
>> > is needed  to validate the qualified method name actually found
>in
>> the
>> > request message.
>> >
>> > It remains my humble opinion that the WSDL spec needs to
>explicitly
>> > address this issue and provide a normative means of specifying
>the
>> tag
>> > name and namespace of this "wrapper element" in the SOAP Binding
>> > section.
>> >
>> > Ideas, anyone?
>> >
>> > RC
>> >
>> > [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
>> >
>> > [2]
>> > http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
>> > 208
>> >
>> > [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names
>
>
>
>To unsubscribe from this group, send an email to:
>wsdl-unsubscribe@yahoogroups.com
>
>

I agree (yes, this is different than what I posted earlier).

-Erik
--- In wsdl@y..., mikedeem@m... wrote:
> I anticipate that the clarification will be that the wrapper
element
> is named identically to the operation name and its namespace is the
> value of the namespace attribute on the soap:body element. This is
> consistent with section 7.1 of the SOAP 1.1. specification.
>
>   == Mike ==
>
>
> --- In wsdl@y..., "Bob Cunnings" <cunnings@l...> wrote:
> > Hello,
> >
> > This is not a new issue, but I would like to see if a consensus
has
> emerged.
> >
> > No matter how hard I try, I see nothing in the WSDL 1.0 spec that
> > addresses directly the matter of specifying the tag name of
> the "wrapper
> > element" that is the immediate child element of a SOAP section 7
> RPC
> > call. The wrapper element is described in section 3.5
> > of WSDL 1.0 [1].
> >
> > -- WSDL co-author Eric Christensen states: [2]
> > "You should use the name of the <input> element under the
> <operation>
> > element of the portType for the request element name (see section
> 2.4.5
> > of the WSDL 1.0 spec for more information). Similarly, you should
> use
> > the name of the <output> element under the <operation> element
for
> the
> > response element name (but, as specified in the SOAP 1.1 spec,
the
> > name of the response element is not signficant)."
> > It is clear that Eric is referring to the name of the <input> and
> <output>
> > elements themselves, *not* the names of the associated <message>
> > elements.
> >
> > However, looking at WSDL files on the 'net, <input> and <output>
> > elements names are usually left to the defaults per the spec,
> section 2.4.5
> > [3]. The same is done here. These defaults, if accepted, lead to
a
> de
> > facto mapping to the <operation> element name that is harmonious
> with
> > SOAP 1.1 section 7.1.
> >
> > So, athough not explicit in the spec, [2] sounds like the way to
go
> as a
> > non-normative convention. It leaves unanswered one question in my
> > mind:
> > Is the namespace URI of the tag name of this "wrapper element"
> > specifiable by the <soap:body> extension element 'namespace'
> attribute?
> > If not, where? Or is it something outside the scope of the SOAP
> binding
> > extension mechanism in WSDL?
> > At present, the SOAP processor at the server side (in the
> > implementation here) looks to the WSDL to find this namespace
URI.
> It
> > is needed  to validate the qualified method name actually found
in
> the
> > request message.
> >
> > It remains my humble opinion that the WSDL spec needs to
explicitly
> > address this issue and provide a normative means of specifying
the
> tag
> > name and namespace of this "wrapper element" in the SOAP Binding
> > section.
> >
> > Ideas, anyone?
> >
> > RC
> >
> > [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
> >
> > [2]
> > http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
> > 208
> >
> > [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names

Based on previous discussions I've been involved in, the name should be the
value of the name attribute on the input element
(\\porttype\operation\input) taking a default value of the message attribute
if no name attribute is specified.

The namespace is the namespace attribute on the soap:body element (
\\binding\operation\input\soap:body ).

We started a project on the soapbuilders list (that probably should be moved
here), to produce a well documented complete (i.e. including complex types
and arrays) WSDL example, that will help nail some of this stuff down.

Cheers
Simon

-----Original Message-----
From: Bob Cunnings [mailto:cunnings@...]
Sent: Friday, February 02, 2001 12:11 PM
To: wsdl@yahoogroups.com
Subject: [wsdl] SOAP Wrapper Element Tag Name


Hello,

This is not a new issue, but I would like to see if a consensus has emerged.

No matter how hard I try, I see nothing in the WSDL 1.0 spec that
addresses directly the matter of specifying the tag name of the "wrapper
element" that is the immediate child element of a SOAP section 7 RPC
call. The wrapper element is described in section 3.5
of WSDL 1.0 [1].

-- WSDL co-author Eric Christensen states: [2]
"You should use the name of the <input> element under the <operation>
element of the portType for the request element name (see section 2.4.5
of the WSDL 1.0 spec for more information). Similarly, you should use
the name of the <output> element under the <operation> element for the
response element name (but, as specified in the SOAP 1.1 spec, the
name of the response element is not signficant)."
It is clear that Eric is referring to the name of the <input> and <output>
elements themselves, *not* the names of the associated <message>
elements.

However, looking at WSDL files on the 'net, <input> and <output>
elements names are usually left to the defaults per the spec, section 2.4.5
[3]. The same is done here. These defaults, if accepted, lead to a de
facto mapping to the <operation> element name that is harmonious with
SOAP 1.1 section 7.1.

So, athough not explicit in the spec, [2] sounds like the way to go as a
non-normative convention. It leaves unanswered one question in my
mind:
Is the namespace URI of the tag name of this "wrapper element"
specifiable by the <soap:body> extension element 'namespace' attribute?
If not, where? Or is it something outside the scope of the SOAP binding
extension mechanism in WSDL?
At present, the SOAP processor at the server side (in the
implementation here) looks to the WSDL to find this namespace URI. It
is needed  to validate the qualified method name actually found in the
request message.

It remains my humble opinion that the WSDL spec needs to explicitly
address this issue and provide a normative means of specifying the tag
name and namespace of this "wrapper element" in the SOAP Binding
section.

Ideas, anyone?

RC

[1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body

[2]
http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
208

[3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names


To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

I anticipate that the clarification will be that the wrapper element
is named identically to the operation name and its namespace is the
value of the namespace attribute on the soap:body element. This is
consistent with section 7.1 of the SOAP 1.1. specification.

   == Mike ==


--- In wsdl@y..., "Bob Cunnings" <cunnings@l...> wrote:
> Hello,
>
> This is not a new issue, but I would like to see if a consensus has
emerged.
>
> No matter how hard I try, I see nothing in the WSDL 1.0 spec that
> addresses directly the matter of specifying the tag name of
the "wrapper
> element" that is the immediate child element of a SOAP section 7
RPC
> call. The wrapper element is described in section 3.5
> of WSDL 1.0 [1].
>
> -- WSDL co-author Eric Christensen states: [2]
> "You should use the name of the <input> element under the
<operation>
> element of the portType for the request element name (see section
2.4.5
> of the WSDL 1.0 spec for more information). Similarly, you should
use
> the name of the <output> element under the <operation> element for
the
> response element name (but, as specified in the SOAP 1.1 spec, the
> name of the response element is not signficant)."
> It is clear that Eric is referring to the name of the <input> and
<output>
> elements themselves, *not* the names of the associated <message>
> elements.
>
> However, looking at WSDL files on the 'net, <input> and <output>
> elements names are usually left to the defaults per the spec,
section 2.4.5
> [3]. The same is done here. These defaults, if accepted, lead to a
de
> facto mapping to the <operation> element name that is harmonious
with
> SOAP 1.1 section 7.1.
>
> So, athough not explicit in the spec, [2] sounds like the way to go
as a
> non-normative convention. It leaves unanswered one question in my
> mind:
> Is the namespace URI of the tag name of this "wrapper element"
> specifiable by the <soap:body> extension element 'namespace'
attribute?
> If not, where? Or is it something outside the scope of the SOAP
binding
> extension mechanism in WSDL?
> At present, the SOAP processor at the server side (in the
> implementation here) looks to the WSDL to find this namespace URI.
It
> is needed  to validate the qualified method name actually found in
the
> request message.
>
> It remains my humble opinion that the WSDL spec needs to explicitly
> address this issue and provide a normative means of specifying the
tag
> name and namespace of this "wrapper element" in the SOAP Binding
> section.
>
> Ideas, anyone?
>
> RC
>
> [1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body
>
> [2]
> http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
> 208
>
> [3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names

Hello,

This is not a new issue, but I would like to see if a consensus has emerged.

No matter how hard I try, I see nothing in the WSDL 1.0 spec that
addresses directly the matter of specifying the tag name of the "wrapper
element" that is the immediate child element of a SOAP section 7 RPC
call. The wrapper element is described in section 3.5
of WSDL 1.0 [1].

-- WSDL co-author Eric Christensen states: [2]
"You should use the name of the <input> element under the <operation>
element of the portType for the request element name (see section 2.4.5
of the WSDL 1.0 spec for more information). Similarly, you should use
the name of the <output> element under the <operation> element for the
response element name (but, as specified in the SOAP 1.1 spec, the
name of the response element is not signficant)."
It is clear that Eric is referring to the name of the <input> and <output>
elements themselves, *not* the names of the associated <message>
elements.

However, looking at WSDL files on the 'net, <input> and <output>
elements names are usually left to the defaults per the spec, section 2.4.5
[3]. The same is done here. These defaults, if accepted, lead to a de
facto mapping to the <operation> element name that is harmonious with
SOAP 1.1 section 7.1.

So, athough not explicit in the spec, [2] sounds like the way to go as a
non-normative convention. It leaves unanswered one question in my
mind:
Is the namespace URI of the tag name of this "wrapper element"
specifiable by the <soap:body> extension element 'namespace' attribute?
If not, where? Or is it something outside the scope of the SOAP binding
extension mechanism in WSDL?
At present, the SOAP processor at the server side (in the
implementation here) looks to the WSDL to find this namespace URI. It
is needed  to validate the qualified method name actually found in the
request message.

It remains my humble opinion that the WSDL spec needs to explicitly
address this issue and provide a normative means of specifying the tag
name and namespace of this "wrapper element" in the SOAP Binding
section.

Ideas, anyone?

RC

[1] http://msdn.microsoft.com/xml/general/wsdl.asp#_soap:body

[2]
http://discuss.develop.com/archives/wa.exe?A2=ind0011&L=SOAP&P=R35
208

[3] http://msdn.microsoft.com/xml/general/wsdl.asp#_names

Nick,

We have a VB Soap Client and WSDL Interrogator that generates VBScript for
method calls from WSDL Documents it runs on the xmethods SOAP:Lite and
Apache SOAP implementations no problem.

We have been testing against xmethods for awhile and have had no problems
executing on either port 80 or 8080.

Here are some examples of the code generated from some of the xmethods WSDL
URLs with the WSDL Interrogator.  This is about as simple as I can make it
right now.  We will release the complete vbSOAP SDK in two weeks or less.

Examples from WSDL Interrogator (of course you could convert this VBScript,
to VB or JScript and still execute it.

-Matt


................Weather Temperation @xmethods.com..................

Function getTemp ( ByVal zipcode )

     ' zipcode type = xsd:string

     Set objClient = Server.CreateObject("vbSoapClient.Messaging")
     objClient.soapAction = ""
     objClient.soapAddress =
"http://services.xmethods.net:80/soap/servlet/rpcrouter"
     objClient.operationName = "getTemp"
     objClient.operationNamespace = "urn:xmethods-Temperature"
     objClient.xsdNamespace = "http://www.w3.org/1999/XMLSchema"
     objClient.xsiNamespace = "http://www.w3.org/1999/XMLSchema-instance"

     objClient.setParameter "zipcode", 1, "xsd:string", zipcode

     'output type = xsd:float

     getTemp = objClient.getValue( "return" )
End Function

............FedExTracker @xmethods.com..............

Function getStatus ( ByVal trackingNumber )

     ' trackingNumber type = xsd:string

     Set objClient = Server.CreateObject("vbSoapClient.Messaging")
     objClient.soapAction = "urn:xmethodsFedEx#getStatus"
     objClient.soapAddress =
"http://services.xmethods.net:80/perl/soaplite.cgi"
     objClient.operationName = "getStatus"
     objClient.operationNamespace = "urn:xmethodsFedEx"
     objClient.xsdNamespace = "http://www.w3.org/1999/XMLSchema"
     objClient.xsiNamespace = "http://www.w3.org/1999/XMLSchema-instance"

     objClient.setParameter "trackingNumber", 1, "xsd:string", trackingNumber

     'output type = xsd:string

     getStatus = objClient.getValue( "return" )
End Function




> All,
>
> has anyone out there managed to make a Visual Basic client (Microsoft
> SOAP Toolkit v2.0) which exploits a WSDL file work against a SOAP
> server implemented with Apache SOAP 2.0 or 2.1 ?
>
> I have made a VB client work against an Apache SOAP server by
> exploiting the low level API (ie. manipulating the soap envelope
> directly on the VB side to include the xsi:type param) but would like
> to get it working by exploiting the high level API / WSDL file.
>
> Apparently Apache SOAP 2.1 has "Reduced dependency on xsi:type for
> deserialization" - but I haven't yet seen how. examples...
> 1) If I take my VB client written with a low level API and remove the
> code which inserts the xsi:type line into the envelope, I get
> a server
> side error : "No Deserializer found" for my 'type' (actually my
> method's parameter name) - see actual error message below.
> 2) If I use the high level API and exploit a wsdl file I get the same
> error
>
> No Deserializer found to deserialize a ':imntType' using encoding
> style 'http://schemas.xmlsoap.org/soap/encoding/'.
>
> many thanks for any help you can provide
> I can be reached at quaine_nicholas@...
>
> Nick Quaine
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-~>
> eGroups is now Yahoo! Groups
> Click here for more details
> http://click.egroups.com/1/11231/1/_/_/_/981116288/
> --------------------------------------------------------------
> -------_->
>
> To unsubscribe from this group, send an email to:
> wsdl-unsubscribe@yahoogroups.com
>
>

-----Original Message-----
From: quaine_nicholas@... [mailto:quaine_nicholas@...]
Sent: Friday, February 02, 2001 4:18 AM
To: wsdl@yahoogroups.com
Subject: [wsdl] Making VB talk to an Apache SOAP Server

All,

has anyone out there managed to make a Visual Basic client (Microsoft
SOAP Toolkit v2.0) which exploits a WSDL file work against a SOAP
server implemented with Apache SOAP 2.0 or 2.1 ?

I have made a VB client work against an Apache SOAP server by
exploiting the low level API (ie. manipulating the soap envelope
directly on the VB side to include the xsi:type param) but would like
to get it working by exploiting the high level API / WSDL file.

Apparently Apache SOAP 2.1 has "Reduced dependency on xsi:type for
deserialization" - but I haven't yet seen how. examples...
1) If I take my VB client written with a low level API and remove the
code which inserts the xsi:type line into the envelope, I get a server
side error : "No Deserializer found" for my 'type' (actually my
method's parameter name) - see actual error message below.
2) If I use the high level API and exploit a wsdl file I get the same
error

No Deserializer found to deserialize a ':imntType' using encoding
style 'http://schemas.xmlsoap.org/soap/encoding/'.

many thanks for any help you can provide
I can be reached at quaine_nicholas@...

Nick Quaine



To unsubscribe from this group, send an email to:
wsdl-unsubscribe@yahoogroups.com

All,

has anyone out there managed to make a Visual Basic client (Microsoft
SOAP Toolkit v2.0) which exploits a WSDL file work against a SOAP
server implemented with Apache SOAP 2.0 or 2.1 ?

I have made a VB client work against an Apache SOAP server by
exploiting the low level API (ie. manipulating the soap envelope
directly on the VB side to include the xsi:type param) but would like
to get it working by exploiting the high level API / WSDL file.

Apparently Apache SOAP 2.1 has "Reduced dependency on xsi:type for
deserialization" - but I haven't yet seen how. examples...
1) If I take my VB client written with a low level API and remove the
code which inserts the xsi:type line into the envelope, I get a server
side error : "No Deserializer found" for my 'type' (actually my
method's parameter name) - see actual error message below.
2) If I use the high level API and exploit a wsdl file I get the same
error

No Deserializer found to deserialize a ':imntType' using encoding
style 'http://schemas.xmlsoap.org/soap/encoding/'.

many thanks for any help you can provide
I can be reached at quaine_nicholas@...

Nick Quaine

Hi all,

To kick this forum off I thought I might point folks to
a board I've been maintaining on XMethods to document
WSDL-related issues that I've been running into while
working on XMethods.

It's located at:

http://www.xmethods.net/x/Ultimate.cgi

It's the "WSDL" forum under "Toolkit Development".

The board is meant to be more of a issues repository, as
opposed to this list which is meant to be more for
email-based discussion.

Cheers.

Tony
XMethods