On Tuesday 27 February 2007 11:05, Dan Diephouse wrote: > This brings up the question in my mind of whether or not we really want > to use EndpointReferenceType throughout the codebase. I'm uncomfortable > with the way things stand as > - EndpointRefenceType has an ugly API. It is not easy to create an EPR > from a String/URL and I think it should be doable via a constructor. > (Yeah, we can create factories, but thats ugly and it still doesn't make > retrieving values friendlier). > - We seem to have an odd mixture of EndpointReferenceTypes and > EndointInfos going on in our transport interfaces. On some methods we > require both. It seems like it should be either one or the other. > - WIth that said, using an EndpointInfo is odd to me as thats part of > the service model. Using an EPR seems unnatural for reasons I state > above. > > Whats the advantage of using EndpointReferenceType throughout the > codebase as opposed to our own class?
The main advantage is that it's schema driven/jaxb generated and can be written/read directly via normal JAXB operations. It also means it should (in theory) be easy to convert to/from other implementations (like the JAX-WS 2.1 EndpointReference). Contrary to what Eoghan said, the JAX-WS EndpointReference is actually LESS friendly. It doesn't provide ANY access to any of the information other than a "write(Result)" method to write it to a Result. The only "constructor" is: EndpointReference readFrom(Source eprInfoset) The main thing the JAX-WS stuff has is methods to automatically create proxies and for the EndpointReferences and to create EndpointReferences from the Service and such. Is there a way to get JAXB to generate it as "AbstractEPR" and then provide a concrete class that subclasses it that the ObjectFactory would create? We could provide a bunch of utility constructors, methods, etc... I think I need to read the jaxb extensor stuff a bit more. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
