axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Remote references - future architectural idea
Date Thu, 13 Dec 2001 04:04:56 GMT
Jacek Kopecky wrote:

>  1) Is there a strong reason for having portType as a structure
> with the URI and name while it can be a simple QName (perfectly
> valid and making sense in XML, with not so perfect support in
> Java, but that's being worked on, I hear)

the reason is that our remote reference is currently an object called Port
that contains PortType object that contains two String properties (uri and localName)
this way we can serialize and deserialize our remote references (Port)
just using already built SOAP encoder (no need for WSDL parsing and
we map in application portType to java interface).

>  2) How do you use the Name of the remote reference? If it's only
> for documentation purposes, it could go into XML comment, don't
> you think?

it is used in XSOAP C++ implementation to transfer and maintain name of
remote object when it is bound to repository...

>  3) Listing a reference to a WSDL portType and replacing WSDL
> binding mechanism seems a little inconsistent. Why don't you
> rather have a reference to a WSDL binding?

the reason is that XSOAP currently is not WSDL dependent
and portType being just a pair of (namespace uri, local name) could reference
not only WSDL portType but also some other web services definition
- even XML schema could be used to describe remote object interface ...

that was our original thinking but now we are moving into direction
of embracing WSDL so it is no longer that important to be generic
and WSDL independent...

>  4) We chose the path of regenerating the WSDL pointed to if we
> want to change the access URI (should we keep instanceIDs in the
> access URIs), but actually a very small portion of the WSDL file
> needs to be generated, as you showed below, and the static rest
> could be imported.

that sounds good!

if you already are doing it then why instead of proprietary remote reference
format not to send WSDL document that was generated?

that could be something simple like WSDL below that imports
binding from static WSDL doc (binding could be dynamic too if necessary):

<definitions name="SOAP Interop Testing Service Instance"
  <import namespace=""

   <service name="SOAPInterop22332">
    <documentation>Interop Services Instance</documentation>
    <port name="InteropTestPort" binding="interop:InteropTestSoapBinding">
     <soap:address location="http://myshost:22332"/>

in case of Apache SOAP 2.x the inclusion of SOAP binding would be
necessary if new service instance will also new SOAPAction and
invocation has to go through shared router servlet ...

>  5) I intentionally omitted the optional instanceID element in
> our remote reference for I see instance IDs as an extension,
> while remote references can be used to just point to services.

if instanceID is omitted then such remote reference is not self-contained
and to be able to talk to actual service instance one would need to use
some proprietary mechanism (discovery?) to guess instanceID or just
ignore this problem and assume no instanceID must be used...

> I
> also think that putting instance IDs into the access URI or
> SOAPAction is a bad practice for these approaches tie you to a
> transport,

maybe. however i think that remote reference should support
*every* possible way to describe service instance including URL,
soap action, your instance Id and some other unspecified mechanism
that  we have not envisioned yet. and as long as we agree to use
WSDL and both sides can agree on extensions in WSDL (if any)
such WSDL remote reference can be processed by programs
easily and changes in WSDL format will not be afecting code
that is working with remote references (as long as WSDL processing
code is separate and well abstracted so can be updated without
need to change user code)

> while putting instanceIDs in SOAP Headers is IMHO a
> SOAP extension as it was meant to be. 8-)

this is just one possible way to identify service instance and
i think that it can not be just one as there may be already SOAP
toolkits that use different mechanisms or even similar SOAP header
but with different content...

as WSDL can describe how instanceId is mapped into SOAP header
- this can be done in WSDL by defining new extensibility element.

so WSDL seems like good enough to be a  'common language' to
describe service instance - we can just assume if something can not
be described in WSDL it is no web service and we do not worry about it :-)

>  6) In WASP, the portType mapping can be configured statically on
> the receiver but we do allow for sending this information along
> with the reference so that (again, in the best case when the Java
> receiver has the same classes available) the receiver need not
> have this static configuration.

i agree that it is useful information but i think as it is Java specific this should
be regarded as an optional extension and used only in Intranets (possible security
risks can be involved if you can map receiving service to any destination class ...)

>  To compare our approaches:
>  I think your approach effectively adds the name.


>  I think our approach is more cleanly tied to WSDL.

you reference WSDL doc so to use remote reference the application
must have already processed this WSDL - in XSOAP we requires mappings.

>  We allow extensibility of this structure via additional elements
> (as I said, those would have to be namespace qualified in the
> final remote reference accepted spec) like instanceID or
> portTypeMappings, you allow extensibility through subtyping of
> the binding element inside the endpoint element.


>  Otherwise, the approaches are equivalent in the functionality,
> of course.

agreed but we are regarding our current remote reference to be too limiting:
for example we can only send one portType of service and we were already thinking
on how to extend remote-ref to support multiple portTypes (mapped to java
remote object that implements multiple java interfaces) - this can be naturally
expressed in WSDL already (though there are some semantics problems
as WSDL does not specify how those portTypes are related to services part...)

we think that next major revision of XSOAP may use simply WSDL
to represent remote reference - that will allow us to access any service
instances and exchanging remote references (that are simply WSDL docs)
with other SOAP implementation  that do not even have notion of
remote reference but can generate self-describing WSDL (or provide
link to it via UDDI or other directory service ...). and i think that
this is a potential big gain as in XSOAP we will be able to provide
a  remote object layer around existing web services with just a little
of mappings by ising WSDL as remote reference to the web service
- we just need to add some mapppings for  WSDL portTypes to java interfaces ...

the only limitation of such approach is how to do SOAP on small devices
where adding WSDL parsing may stretch limits already pushed by
requiring XML parser and SOAP processor - using WSDL effectively requires
to have support for two separate types of XML documents: SOAP encoded
and WSDL 1.1. but even then i think that WSDL can work as for small devices
with some additional limitations on structure of WSDL that can be imposed -
for exmaple only Services section can be present in WSDL doc and the rest of
WSDL (binding+portType) is hardcoded into such application ...

>  Please correct me if I'm wrong somewhere.

i do not think that there is wrong or bad approach but i am more thinking
about interoperability required for remote references in much longer perspective
and at least in my opinion WSDL is extremely good candidate for remote reference
as it can work already without any new standards or extensions (!) and such
WSDL/remote-reference enabled applications can easily blend
and use non-remote-reference aware apps as long as some WSDL is shared...

just my 0.02 grosze (ie. cents)


BTW: if there are any other SOAP implementations that defined remote references ...

View raw message