You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrf-user@ws.apache.org by Bruno Harbulot <Br...@manchester.ac.uk> on 2006/05/04 15:37:44 UTC

WSDL Structure and port types

Hello,


I'm trying to reuse WSDL files for WSRF services (that weren't using 
Apache WSRF).
I'm only interested in the operations regarding the resource properties 
for the moment. I have several of these services, so I would like to 
avoid duplicating the same thing, in particular the port types for the 
WS-ResourceProperties operations.

At the moment, I've written a common WSRF.wsdl file that contains a port 
type of this form:

<wsdl:portType name="WSRFOperations">
   <wsdl:operation name="GetResourceProperty">
      <wsdl:input message="wsrp:GetResourcePropertyRequest" 
name="GetResourcePropertyRequest"/>
      <wsdl:output message="wsrp:GetResourcePropertyResponse" 
name="GetResourcePropertyResponse"/>
      <wsdl:fault message="wsrp:ResourceUnknownFault" 
name="ResourceUnknownFault"/>
      <wsdl:fault message="wsrp:InvalidResourcePropertyQNameFault" 
name="InvalidResourcePropertyQNameFault"/>
   </wsdl:operation>

   <wsdl:operation name="GetMultipleResourceProperties">
      <!-- ... -->
   </wsdl:operation>

   <!-- + other operations of WS-ResourceProperties ... -->

</wsdl:porttype>


In short, this is the same as 
<http://docs.oasis-open.org/wsrf/rpw-2.wsdl>, except that I've merged 
all the port types for all the operations into a single one.


Then, each resource WSDL uses:

   <import location="WSRF.wsdl" 
namespace="http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourceProperties"/>

   <service name="MyResource">
     <port binding="tns:MyResourceSpecificSoapBinding" 
name="MyResourcePort">
        <soap:address location="http://localhost/.../"/>
     </port>
     <port binding="wsrf:WSRFOperationsSoapBinding" 
name="MyResourceWSRFPort">
        <soap:address location="http://localhost/.../"/>
     </port>
   </service>

(I'm using two ports because one is for the WSRF properties and the 
other one is for operations specific to that resource.)



Unfortunately, WSDL2Java (in WSRF 1.0) generates two sets of classes, 
one for each port, whereas I would really like just one set of classes 
(one per service and not per port).

Is my way of writing the WSDL file incorrect or discouraged? I would 
assume not, since if I took 
<http://docs.oasis-open.org/wsrf/rpw-2.wsdl>, I would end up with even 
more sets of classes.

Is there any way to avoid copying and pasting all the 
WS-ResourceProperties entries into the WSDL file (to avoid what's done 
in the Filesystem example)?

Perhaps one way around this would be to use a single back end object for 
several instances of 'Resource' corresponding in fact to a single 
resource, therefore the factory would have to create several resources 
for a single back-end resource. This seems long and a bit hard to 
maintain and synchronise.



Regards,

Bruno.

---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org


RE: WSDL Structure and port types

Posted by "Campana Jr., Salvatore J" <sa...@hp.com>.
I agree with your observations...

As for the generation of a wsdl which contains all the spec
operations...from my perspective its all relative...We include a
template wsdl which contains all the operations you can use as a
starting point, else copy and paste...If we spent the time to make the
utility you speak of, then people would complain that they had to delete
the operations they don't want....I'm sure you know how it is...

But...

We always welcome contributuions...so get on it!!

Thanks Bruno!

-Sal 

-----Original Message-----
From: Bruno Harbulot [mailto:Bruno.Harbulot@manchester.ac.uk] 
Sent: Thursday, May 04, 2006 1:03 PM
To: wsrf-user@ws.apache.org
Subject: Re: WSDL Structure and port types



Campana Jr., Salvatore J wrote:
> Bruno,
> 
> WSDL 1.0 doesn't include inheritance..That is the issue.  That is why 
> you copy and paste what you want into your wsdl....
> I think that's answering part of your question...

Indeed it does. I was using two ports in a single service to circumvent
this limitation.


> We generate based on port because the port references the binding
which
> references the portType which contains the operations....The ports
seem
> like the obvious place to separate the endpoints...That being said,
> there is no reason you couldn't alter the generated interface and code
> to contain all the operations and map the resource to a single
> type....You can do this to meet your needs.  The thing to watch out
for
> is common operations in portTypes...If you had the same operation
> defined in two portTypes and you collapse this to one, does it still
> make sense for you?
> 
> Bottom line is you can do it.  I do not, however think we should
> generate one class just for the service as opposed to generating on
the
> ports...

If I can make an analogy between WS and Java (I'm aware I'm entering a 
dangerous ground), I would consider the portTypes to be equivalent to 
interfaces (which seems to make sense with respect to the WSDL 2.0 
recommendations) and services/bindings to be equivalent to classes (and 
this is indeed a short cut).
That's obviously arguable and I can see where it would pose some 
problems, in particular if there were several bindings for a single 
instance of the "class" behind. In this case, the workaround I've used 
to have something similar to inheritance in WSDL wouldn't work.
I think collapsing two port types wouldn't cause more problems that 
implementing in the same class two Java interfaces containing two 
methods of the same name would (it's mostly a input/output type problem,

which may itself depend on the limitations of the language used to 
implement the service).
Yet, if we assume everybody uses a SOAP over HTTP binding, it seems 
fine, and it would make sense to generate interfaces for the portTypes 
and classes for the services.
I must admit it really depends on the interpretation made by the tooling

behind the WSDL specification. I'm not quite sure if WSDL 2.0 is so much

better in that respect (I haven't really explored it, and it's a bit 
late to make objections to the working group anyway).


This being said, there might be a simpler way out of this in the context

of WSRF (well, simpler for the user at least): having a transformation 
that generates the WSDL for a WSRF service from a WSDL that only 
contains the custom operations. This could be another ant task with 
parameters to select which operations to include.



Bruno.


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org


Re: WSDL Structure and port types

Posted by Bruno Harbulot <Br...@manchester.ac.uk>.

Campana Jr., Salvatore J wrote:
> Bruno,
> 
> WSDL 1.0 doesn't include inheritance..That is the issue.  That is why
> you copy and paste what you want into your wsdl....
> I think that's answering part of your question...

Indeed it does. I was using two ports in a single service to circumvent 
this limitation.


> We generate based on port because the port references the binding which
> references the portType which contains the operations....The ports seem
> like the obvious place to separate the endpoints...That being said,
> there is no reason you couldn't alter the generated interface and code
> to contain all the operations and map the resource to a single
> type....You can do this to meet your needs.  The thing to watch out for
> is common operations in portTypes...If you had the same operation
> defined in two portTypes and you collapse this to one, does it still
> make sense for you?
> 
> Bottom line is you can do it.  I do not, however think we should
> generate one class just for the service as opposed to generating on the
> ports...

If I can make an analogy between WS and Java (I'm aware I'm entering a 
dangerous ground), I would consider the portTypes to be equivalent to 
interfaces (which seems to make sense with respect to the WSDL 2.0 
recommendations) and services/bindings to be equivalent to classes (and 
this is indeed a short cut).
That's obviously arguable and I can see where it would pose some 
problems, in particular if there were several bindings for a single 
instance of the "class" behind. In this case, the workaround I've used 
to have something similar to inheritance in WSDL wouldn't work.
I think collapsing two port types wouldn't cause more problems that 
implementing in the same class two Java interfaces containing two 
methods of the same name would (it's mostly a input/output type problem, 
which may itself depend on the limitations of the language used to 
implement the service).
Yet, if we assume everybody uses a SOAP over HTTP binding, it seems 
fine, and it would make sense to generate interfaces for the portTypes 
and classes for the services.
I must admit it really depends on the interpretation made by the tooling 
behind the WSDL specification. I'm not quite sure if WSDL 2.0 is so much 
better in that respect (I haven't really explored it, and it's a bit 
late to make objections to the working group anyway).


This being said, there might be a simpler way out of this in the context 
of WSRF (well, simpler for the user at least): having a transformation 
that generates the WSDL for a WSRF service from a WSDL that only 
contains the custom operations. This could be another ant task with 
parameters to select which operations to include.



Bruno.


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org


RE: WSDL Structure and port types

Posted by "Campana Jr., Salvatore J" <sa...@hp.com>.
Bruno,

WSDL 1.0 doesn't include inheritance..That is the issue.  That is why
you copy and paste what you want into your wsdl....
I think that's answering part of your question...

We generate based on port because the port references the binding which
references the portType which contains the operations....The ports seem
like the obvious place to separate the endpoints...That being said,
there is no reason you couldn't alter the generated interface and code
to contain all the operations and map the resource to a single
type....You can do this to meet your needs.  The thing to watch out for
is common operations in portTypes...If you had the same operation
defined in two portTypes and you collapse this to one, does it still
make sense for you?

Bottom line is you can do it.  I do not, however think we should
generate one class just for the service as opposed to generating on the
ports...

-S

 

-----Original Message-----
From: Bruno Harbulot [mailto:Bruno.Harbulot@manchester.ac.uk] 
Sent: Thursday, May 04, 2006 9:38 AM
To: wsrf-user@ws.apache.org
Subject: WSDL Structure and port types

Hello,


I'm trying to reuse WSDL files for WSRF services (that weren't using
Apache WSRF).
I'm only interested in the operations regarding the resource properties
for the moment. I have several of these services, so I would like to
avoid duplicating the same thing, in particular the port types for the
WS-ResourceProperties operations.

At the moment, I've written a common WSRF.wsdl file that contains a port
type of this form:

<wsdl:portType name="WSRFOperations">
   <wsdl:operation name="GetResourceProperty">
      <wsdl:input message="wsrp:GetResourcePropertyRequest" 
name="GetResourcePropertyRequest"/>
      <wsdl:output message="wsrp:GetResourcePropertyResponse" 
name="GetResourcePropertyResponse"/>
      <wsdl:fault message="wsrp:ResourceUnknownFault" 
name="ResourceUnknownFault"/>
      <wsdl:fault message="wsrp:InvalidResourcePropertyQNameFault" 
name="InvalidResourcePropertyQNameFault"/>
   </wsdl:operation>

   <wsdl:operation name="GetMultipleResourceProperties">
      <!-- ... -->
   </wsdl:operation>

   <!-- + other operations of WS-ResourceProperties ... -->

</wsdl:porttype>


In short, this is the same as
<http://docs.oasis-open.org/wsrf/rpw-2.wsdl>, except that I've merged
all the port types for all the operations into a single one.


Then, each resource WSDL uses:

   <import location="WSRF.wsdl" 
namespace="http://www.ibm.com/xmlns/stdwip/web-services/WS-ResourcePrope
rties"/>

   <service name="MyResource">
     <port binding="tns:MyResourceSpecificSoapBinding" 
name="MyResourcePort">
        <soap:address location="http://localhost/.../"/>
     </port>
     <port binding="wsrf:WSRFOperationsSoapBinding" 
name="MyResourceWSRFPort">
        <soap:address location="http://localhost/.../"/>
     </port>
   </service>

(I'm using two ports because one is for the WSRF properties and the
other one is for operations specific to that resource.)



Unfortunately, WSDL2Java (in WSRF 1.0) generates two sets of classes, 
one for each port, whereas I would really like just one set of classes 
(one per service and not per port).

Is my way of writing the WSDL file incorrect or discouraged? I would 
assume not, since if I took 
<http://docs.oasis-open.org/wsrf/rpw-2.wsdl>, I would end up with even 
more sets of classes.

Is there any way to avoid copying and pasting all the 
WS-ResourceProperties entries into the WSDL file (to avoid what's done 
in the Filesystem example)?

Perhaps one way around this would be to use a single back end object for

several instances of 'Resource' corresponding in fact to a single 
resource, therefore the factory would have to create several resources 
for a single back-end resource. This seems long and a bit hard to 
maintain and synchronise.



Regards,

Bruno.

---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrf-user-unsubscribe@ws.apache.org
For additional commands, e-mail: wsrf-user-help@ws.apache.org