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: [EMAIL PROTECTED]
| Sanjiva Weerawarana <[EMAIL PROTECTED]>
08/06/2006 11:48 PM
|
|
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
