> How about the following: add a new constructor to AxisService as > follows: > > AxisService (URL wsdlURL, QName wsdlServiceName, String portName) > > This can have the logic for reading the WSDL and creating a properly > configured AxisService (including all the policies at the right places). > Module engagement would have t happen in the context of a > ConfigurationContext object I believe. > > Users can then create an AxisService and reuse it in any number of > ServiceClients using new ServiceClient (configContext, axisService). > > In fact, once we have that, we can either (1) remove the ServiceClient > constructor which takes a WSDL URL, or (2) do its implementation as > this (configContext, new AxisService (...)); > (I'd prefer to remove the constructor but I recognize I may be in the > minority in not liking choices in APIs.)
+1 with a small comment, We can use AxisServiceBuilder with the getAxisService(...) method for the same effect. We can put a constructor to AxisService too to make it explicit. I think it is good to keep service client constructor there as I do not think it is very easy to notice that one should use the service constructor and create a service and out it in. > > If I could do the constructor on wsdl4j does it help (I have to make > > time to do that). And please instruct me what I used for policy impl > > .. WOM or wsdl4j. It seems WOM based utilities are already written. > > I don't understand this comment - one more try please. For policy implementation at the service client, to parse the WSDL I can use WOM or WSDL 1.1 WSDL4j. I was asking which one I should be using. Few concerns 1) I think WOM has utility methods to manipulate the Policy e.g. PolicyAttachmentUtil modules/codegen 2) WSDL4J has some Utility methods e.g. AxisServiceBuilder, ClientUtils.creatAxisService(...) 3) both should be replaced by Wooden on day Do we have preference on one over the other? Can I used which ever easy to use? Srinath -- ============================ Srinath Perera: http://www.cs.indiana.edu/~hperera/ http://www.bloglines.com/blog/hemapani
