axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject introduce AxisEndpoint? (was: Re: [Axis2] problem with WSDL1.1 and multiple ports per service)
Date Mon, 07 Aug 2006 04:48:12 GMT
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:

	collection of messages grouped together
	collection of operations offered at one spot
	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



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message