axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Kopecky <>
Subject Re: Remote references - future architectural idea
Date Wed, 12 Dec 2001 12:20:32 GMT
 I have a few remarks:
 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)
 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?
 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?
 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.
 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. 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, while putting instanceIDs in SOAP Headers is IMHO a
SOAP extension as it was meant to be. 8-)
 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.

 To compare our approaches:
 I think your approach effectively adds the name.
 I think our approach is more cleanly tied to WSDL.
 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.

 Please correct me if I'm wrong somewhere.

 Others, please comment on what you think the structure for
remote references should look like or which of the approaches
presented you like more and what, if anything, you would change
on it. 8-)
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Tue, 11 Dec 2001, Aleksander Slominski wrote:

 > hi,
 > here is how remote reference to service described in [1] could look in XSOAP:
 > <Port id='id1' xsi:type='ns1:port'
 >         xmlns:ns=''>
 >           <name xsi:type='xsd:string'>InteropTestPort</name>
 >           <portType id='id4' xsi:type='ns:port-type'>
 >              <uri xsi:type='xsd:string'></uri>
 >              <name xsi:type='xsd:string'>InteropTestPortType</name>
 >            </portType>
 >           <endpoint id='id2' xsi:type='ns:endpoint'>
 >             <location
 > xsi:type='xsd:string'></location>
 >             <binding id='id3' xsi:type='ns:binding'>
 >               <name xsi:type='xsd:string'></name>
 >             </binding>
 >           </endpoint>
 > </Port>
 > Name - is pretty much like valueof WSDL service name attribute.
 > PortType -of course there must be registered A mapping for java interface to
 > port type (, InteropTestPortType) in XSOAP
 > but we do not put as part of remote resefrence.
 > Endpoint - conatins actual location of service - how is it done in WASP?
 > in your examplke there is only SOAP action so if i need to use
 > service instance that was dynamically created and available and some URL
 > how i would do it? would i need to regenerate WSDL file that us pointed
 > by  <wsdl> element?
 > Binding - in XSOAP we use binding element to keep SOAP action and in priniciple
 > binding can be subclassed to any new kind of binding however we
 > have never explored it as it was becoming more obvious for us that what
 > we really want as remote refernece is more more looking like WSDL,
 > for example this remote refernce could be very easily expressed
 > using valid and _small_ WSDL document:
 > <?xml version="1.0"?>
 > <definitions name="SOAP Interop Testing Service Instance"
 > targetNamespace="http://myhost/GLOBALLY_UNIQUE-ID_OF SERVICE_INSTANCE"
 > xmlns:tns="http://myhost/GLOBALLY_UNIQUE-ID_OF SERVICE_INSTANCE"
 > xmlns:interop=""
 > xmlns=""
 > xmlns:soap=""
 > >
 >  <service name="SOAPInterop">
 >   <documentation>Interop Services</documentation>
 >   <port name="InteropTestPort" binding="interop:InteropTestSoapBinding">
 >    <soap:address location=""/>
 >   </port>
 >  </service>
 > </defintions>
 > this should be enough to describe instance of remote service and effectively
 > represent remote reference without need to use anything but WSDL.
 > and we could even add Java-PortType extension element to WSDL
 > to express what is WASP doing in portTypeMappings.
 > let me know what you think about it.
 > thanks,
 > alek
 > [1]
 > Jacek Kopecky wrote:
 > >  Aleks,
 > >  I agree with your conclusion about showing the few different
 > > approaches on a concrete example and going on from there. 8-)
 > >  Lemme start:
 > >  Let's take the Apache SOAP Interop WSDL at [1].
 > >  Our remote reference would look like the following. I've
 > > excluded the namespace declarations as I think they are not
 > > really needed in this exercise and they should be obvious. The
 > > only non-obvious (IMHO) namespace prefix is declared.
 > >
 > >  <x xsi:type="idoox:serviceReference"
 > >      xmlns:apache="">
 > >    <service xsi:type="xsd:qname">
 > >      apache:SOAPInterop
 > >    </service>
 > >    <wsdl xsi:type="xsd:anyURI">
 > >
 > >    </wsdl>
 > >    <portTypeMappings xsi:type="idoox:ArrayOfInterfaceMappings"
 > >      soap-enc:arrayType="idoox:interfaceMapping[1]">
 > >      <item>
 > >        <portType xsi:type="xsd:qname">
 > >          apache:InteropTestPortType
 > >        </portType>
 > >        <className>
 > >          demo.interop.InteropServiceInterface
 > >        </className>
 > >      </item>
 > >    </portTypeMappings>
 > >  </x>
 > >
 > >  The portTypeMappings element need not be there, as I said, it's
 > > just for zero-config best-case scenario.
 > >  An interesting activity again... 8-)
 > >
 > >                    Jacek Kopecky
 > >
 > >                    Senior Architect, Systinet (formerly Idoox)
 > >      
 > >
 > > [1]

View raw message