You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2006/08/07 06:48:12 UTC
introduce AxisEndpoint? (was: Re: [Axis2] problem with WSDL1.1 and
multiple ports per service)
On Fri, 2006-08-04 at 15:55 -0500, Lori Van Gulick wrote:
> Hi,
>
> I have opened a JIRA for this problem - AXIS2-965. It contains a patch
> which basically extends WSDL11ToAxisServiceBuilder to take a wsld
> input file and return a List of AxisService objects. The specific
> changes are:
Sorry for missing your original post .. I do have an opinion on it (as
you might suspect ;-)):
> My first thought was that it seems like there should be another object
> representing the port that would sit between AxisService and
> AxisOperation (e.g. "AxisPort" - or if you prefer the WSDL 2.0
> terminology "AxisEndpoint"). I was wondering if this has ever been
> considered in the past? This would allow
> WSDL11ToAxisService.polulateService to return a single AxisService
> that would contain, as children, all the ports defined to that service
> in the wsdl.
Yeah this was considered. AxisService basically is like a representation
of an portType rather than a port. Its a place to keep the set of all
operations that are available at an endpoint.
I too have been thinking for several months about adding another thing:
AxisEndpoint, except with one difference from you .. that AxisEndpoint
would come below AxisService! That is:
AxisOperation
collection of messages grouped together
AxisService
collection of operations offered at one spot
AxisEndpoint
the endpoint at which a service is offered
So 1..n AxisEndpoint structures would be created by Axis2 @ runtime to
represent each endpoint it manages. That is, an AxisEndpoint effectively
corresponds to a combination of a transport listener and an AxisService.
Why do we need this? An AxisEndpoint would also be the place where we
keep transport dependent service policies. So if (on the client side)
when we read a WSDL there are multiple ports, then instead of returning
multiple AxisService objects as you did, we'd return multiple
AxisEndpoint objects, with each representing that configured endpoint,
including the TransportListener via which messages come for that
particular service endpoint.
The problem with hacking AxisService to do this is duplication of data-
the list of operations etc. that's in AxisService is the same for all
the endpoints and if we hack it we'd lose that info. Also, dispatch can
get screwed with that; if you have multiple services then each one has
to have a different name .. and something like RM that adds an operation
will behave weirdly.
I haven't thought thru all the ramifications of this change but they
don't seem daunting to me at an abstract level. Reality will likely be
different!
Thoughts?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: introduce AxisEndpoint? (was: Re: [Axis2] problem with WSDL1.1 and
multiple ports per service)
Posted by Lori Van Gulick <lo...@us.ibm.com>.
Sanjiva,
It is interesting that you were considering a AxisEndpoint -> AxisService
-> AxisOpertion hierarchy. I can see this would work fine for WSDL 2.0
since all endpoints in a service need to implement the same interface, and
will therefore have the same operations. However I'm having a hard time
seeing how this will work for WSDL 1.1 since, as Jeff points out, a service
can have multiple ports each with a different portType, operations, etc.
Are you envisioning moving the binding info out of AxisService into the new
AxisEndpoint? How do you see the mapping from Axis objects to wsdl
elements? Something like this maybe?
AxisOperation wsdl 1.1 operation wsdl 2.0
operation
AxisService wsdl 1.1 portType wsdl 2.0
interface
AxisEndpoint wsdl 1.1 binding/port wsdl 2.0
endpoint
AxisEndpoint[] wsdl 1.1 service wsdl 2.0
service
That still leaves us with a problem with wsdl files that contain multiple
services. Although maybe all that's required is that we store the wsld
service name on the AxisEndpoint for later reference.
So then would the dispatch code use the AxisEndpoint instead of
AxisService?
I think a big part of the problem here is that WSDL11ToAxisServiceBuilder
gives the AxisService the wsdl service name, implying that it is a
representation of the WSDL service. As you point out, if we have multiple
ports per service, we will end up with AxisService objects with the same
name. I think it would be good if we could agree on a better name for
AxisService that won't result in duplicates.
My patch attempts to work around this by renaming the resulting AxisService
with the portName - but only if you use my new method -
WSDL11ToAllAxisServicesBuilder.populateAllServices(). Just for fun I tried
changing WSDL11ToAxisServiceBuilder to always name the AxisService with the
wsdl portName. There was only one failure in the axis2 tests and that was
because the testcase was expecting the Stub to be named
<serviceName>Stub.java, and it was now named <portName>Stub.java. I'm not
sure how big a impact on users changing the AxisService name would have,
but based on the tests it doesn't look too bad.
Thanks,
Lori.
Lori Van Gulick
WebSphere Development
IBM Austin
(512) 838-7929
Jeff
Barrett/Austin/IB
M@IBMUS To
axis-dev@ws.apache.org
08/07/2006 02:25 cc
PM
Subject
Re: introduce AxisEndpoint? (was:
Please respond to Re: [Axis2] problem with WSDL1.1
axis-dev@ws.apach and multiple ports per service)
e.org
Hi Sanjiva,
I was indeed surpised you hadn't posted an opinion yet :-)
It is interesting that an AxisService correlates to a WSDL portType. From
looking through the code, I came to the different conclusion that an
AxisService currently represented a WSDL port (or endpoint in
WSDL20-speak), or actually a combination of the WSDL service + port +
binding, with the portType being represented only implicitly by virute of
the operations attached to the AxisService.
However, if an AxisService represents a portType as you say, then there's a
problem with supporting WSDL1.1 in that a single WSDL service can have
multiple ports which refer to different portTypes. The fact that an
AxisService can be constructed based on encoutering a WSDL service tag and
uses the name from the WSDL service tag as the name of the AxisService
seems to be a problem in this case. I realize in WSDL2.0 all ports
(endpoints) under a service must implement the same portType (interface),
so the idea of AxisService-as-portType might work; but for WSDL1.1 I think
it is broken.
I do see your point of duplicate operations for multiple ports which are
using the same portType. One way to address that would be to model the
WSDL more closely and (using WSDL20-speak) have something like:
AxisService // WSDL 1.1
Service
AxisEndpoint[] // WSDL 1.1
Port + Binding
AxisInterface // WSDL 1.1
PortType
AxisOperation[]
Where an AxisInterface can be shared across multiple AxisEndpoint
instances, although the AxisEndpoint would probably need to carry binding
information, specific to paramater serialization into the body or a header
for example. This is actually similar to the direction we are going in the
JAX-WS metadata layer (i.e. the *.jaxws.description package) since we want
to keep track of JAX-WS metadata (i.e. annotation) information at a more
granular level.
Ignoring the introduction of an AxisInterface and/or the duplicaton of
AxisOperations, it seems to me you and Lori and basically saying similar
things in that an AxisService should contain multiple AxisEndpoints
corresponding to the ports (or endpoints in WSDL20).
Thanks,
Jeff
IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: barrettj@us.ibm.com
Sanjiva Weerawarana
<sa...@opensource.lk>
To
axis-dev@ws.apache.org
08/06/2006 11:48 PM cc
Subject
Please respond to introduce AxisEndpoint? (was: Re:
axis-dev@ws.apache.org [Axis2] problem with WSDL1.1 and
multiple ports per service)
On Fri, 2006-08-04 at 15:55 -0500, Lori Van Gulick wrote:
> Hi,
>
> I have opened a JIRA for this problem - AXIS2-965. It contains a patch
> which basically extends WSDL11ToAxisServiceBuilder to take a wsld
> input file and return a List of AxisService objects. The specific
> changes are:
Sorry for missing your original post .. I do have an opinion on it (as
you might suspect ;-)):
> My first thought was that it seems like there should be another object
> representing the port that would sit between AxisService and
> AxisOperation (e.g. "AxisPort" - or if you prefer the WSDL 2.0
> terminology "AxisEndpoint"). I was wondering if this has ever been
> considered in the past? This would allow
> WSDL11ToAxisService.polulateService to return a single AxisService
> that would contain, as children, all the ports defined to that service
> in the wsdl.
Yeah this was considered. AxisService basically is like a representation
of an portType rather than a port. Its a place to keep the set of all
operations that are available at an endpoint.
I too have been thinking for several months about adding another thing:
AxisEndpoint, except with one difference from you .. that AxisEndpoint
would come below AxisService! That is:
AxisOperation
collection of messages grouped together
AxisService
collection of operations offered at one spot
AxisEndpoint
the endpoint at which a service is offered
So 1..n AxisEndpoint structures would be created by Axis2 @ runtime to
represent each endpoint it manages. That is, an AxisEndpoint effectively
corresponds to a combination of a transport listener and an AxisService.
Why do we need this? An AxisEndpoint would also be the place where we
keep transport dependent service policies. So if (on the client side)
when we read a WSDL there are multiple ports, then instead of returning
multiple AxisService objects as you did, we'd return multiple
AxisEndpoint objects, with each representing that configured endpoint,
including the TransportListener via which messages come for that
particular service endpoint.
The problem with hacking AxisService to do this is duplication of data-
the list of operations etc. that's in AxisService is the same for all
the endpoints and if we hack it we'd lose that info. Also, dispatch can
get screwed with that; if you have multiple services then each one has
to have a different name .. and something like RM that adds an operation
will behave weirdly.
I haven't thought thru all the ramifications of this change but they
don't seem daunting to me at an abstract level. Reality will likely be
different!
Thoughts?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: introduce AxisEndpoint? (was: Re: [Axis2] problem with WSDL1.1 and
multiple ports per service)
Posted by Jeff Barrett <ba...@us.ibm.com>.
Hi Sanjiva,
I was indeed surpised you hadn't posted an opinion yet :-)
It is interesting that an AxisService correlates to a WSDL portType. From
looking through the code, I came to the different conclusion that an
AxisService currently represented a WSDL port (or endpoint in
WSDL20-speak), or actually a combination of the WSDL service + port +
binding, with the portType being represented only implicitly by virute of
the operations attached to the AxisService.
However, if an AxisService represents a portType as you say, then there's
a problem with supporting WSDL1.1 in that a single WSDL service can have
multiple ports which refer to different portTypes. The fact that an
AxisService can be constructed based on encoutering a WSDL service tag and
uses the name from the WSDL service tag as the name of the AxisService
seems to be a problem in this case. I realize in WSDL2.0 all ports
(endpoints) under a service must implement the same portType (interface),
so the idea of AxisService-as-portType might work; but for WSDL1.1 I think
it is broken.
I do see your point of duplicate operations for multiple ports which are
using the same portType. One way to address that would be to model the
WSDL more closely and (using WSDL20-speak) have something like:
AxisService // WSDL 1.1
Service
AxisEndpoint[] // WSDL 1.1 Port +
Binding
AxisInterface // WSDL 1.1
PortType
AxisOperation[]
Where an AxisInterface can be shared across multiple AxisEndpoint
instances, although the AxisEndpoint would probably need to carry binding
information, specific to paramater serialization into the body or a header
for example. This is actually similar to the direction we are going in the
JAX-WS metadata layer (i.e. the *.jaxws.description package) since we want
to keep track of JAX-WS metadata (i.e. annotation) information at a more
granular level.
Ignoring the introduction of an AxisInterface and/or the duplicaton of
AxisOperations, it seems to me you and Lori and basically saying similar
things in that an AxisService should contain multiple AxisEndpoints
corresponding to the ports (or endpoints in WSDL20).
Thanks,
Jeff
IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: barrettj@us.ibm.com
Sanjiva Weerawarana <sa...@opensource.lk>
08/06/2006 11:48 PM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
introduce AxisEndpoint? (was: Re: [Axis2] problem with WSDL1.1 and
multiple ports per service)
On Fri, 2006-08-04 at 15:55 -0500, Lori Van Gulick wrote:
> Hi,
>
> I have opened a JIRA for this problem - AXIS2-965. It contains a patch
> which basically extends WSDL11ToAxisServiceBuilder to take a wsld
> input file and return a List of AxisService objects. The specific
> changes are:
Sorry for missing your original post .. I do have an opinion on it (as
you might suspect ;-)):
> My first thought was that it seems like there should be another object
> representing the port that would sit between AxisService and
> AxisOperation (e.g. "AxisPort" - or if you prefer the WSDL 2.0
> terminology "AxisEndpoint"). I was wondering if this has ever been
> considered in the past? This would allow
> WSDL11ToAxisService.polulateService to return a single AxisService
> that would contain, as children, all the ports defined to that service
> in the wsdl.
Yeah this was considered. AxisService basically is like a representation
of an portType rather than a port. Its a place to keep the set of all
operations that are available at an endpoint.
I too have been thinking for several months about adding another thing:
AxisEndpoint, except with one difference from you .. that AxisEndpoint
would come below AxisService! That is:
AxisOperation
collection of messages grouped together
AxisService
collection of operations offered at one spot
AxisEndpoint
the endpoint at which a service is offered
So 1..n AxisEndpoint structures would be created by Axis2 @ runtime to
represent each endpoint it manages. That is, an AxisEndpoint effectively
corresponds to a combination of a transport listener and an AxisService.
Why do we need this? An AxisEndpoint would also be the place where we
keep transport dependent service policies. So if (on the client side)
when we read a WSDL there are multiple ports, then instead of returning
multiple AxisService objects as you did, we'd return multiple
AxisEndpoint objects, with each representing that configured endpoint,
including the TransportListener via which messages come for that
particular service endpoint.
The problem with hacking AxisService to do this is duplication of data-
the list of operations etc. that's in AxisService is the same for all
the endpoints and if we hack it we'd lose that info. Also, dispatch can
get screwed with that; if you have multiple services then each one has
to have a different name .. and something like RM that adds an operation
will behave weirdly.
I haven't thought thru all the ramifications of this change but they
don't seem daunting to me at an abstract level. Reality will likely be
different!
Thoughts?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org