Single Client, Multiple Service Endpoints

[elcapitan]

G'day all,

This is probably quite straightforward, but I've been unable to turn much up about it. I'm deploying a reasonably complicated EJB3 application in an AS, and I've got four different stateless beans that I'd like to expose as webservices, to be consumed by a single client. I can't work out a tidy way to create and provide the client-side artefacts - at the moment, I can expose all the services, but I'm having problems generating mapping files and setting them up on the client side.

In order of preference, here's what I'd like to be able to do:

1. Instruct wstools to include information from more than a single WSDL file, and produce a single jaxrpc-mapping.xml file. At present, my wstools-config.xml looks like:

<configuration xmlns="http://www.jboss.org/jbossws-tools">
 <wsdl-java file="http://localhost:8080/crawler/WatchListManager?wsdl" unwrap="false">
 <mapping file="META-INF/jaxrpc-mapping.xml"/>
 </wsdl-java>
</configuration>

If I could get this to include multiple WSDLs, that would solve all my problems pretty neatly, I think.

2. If that's not possible, can I instruct the client to read mapping information from multiple files? As such, they won't all be named jaxrpc-mapping.xml, so how can I tell the client where to look?

3. If all else fails, I could always create a facade service interface, but for reasons of modularity I'd really like to avoid this.

Cheers, thanks in advance,

James

[elcapitan]

Bump.

[elcapitan]

The closest thing I have found to a solution for this so far is to create different mapping files for each service, i.e. service1-mapping.xml, service2-mapping.xml, etc., and then use the JBoss-proprietary ServiceFactoryImpl class's method createService(URL wsdlDocumentLocation, QName serviceName, URL mappingLocation) to create services on the client side. (The standard javax.xml.rpc.ServiceFactory class doesn't provide a createService method that allows explicit specification of the mapping file.)

The client-side code, then, looks something like the following (this is really just a test, so please excuse the hacky and hard-coded nature of it):

// URLs locating important files.
URL watchListWSDL = null;
URL watchListMapping = null;
URL crawlerWSDL = null;
URL crawlerMapping = null;
try {
 watchListWSDL = new URL("http://localhost:8080/crawler/WatchListManager?wsdl");
 watchListMapping = (new File("src/META-INF/watchlist-mapping.xml")).toURL();
 crawlerWSDL = new URL("http://localhost:8080/crawler/CrawlerManager?wsdl");
 crawlerMapping = (new File("src/META-INF/crawler-mapping.xml")).toURL();
} catch (MalformedURLException e) {
 e.printStackTrace();
}

// Qualified names of the services.
QName watchListQName = new QName("http://servercontroller.application.server.webcrawler.thedistillery.com.au/jaws",
 "WatchListManagerInterfaceService");
QName crawlerQName = new QName("http://servercontroller.application.server.webcrawler.thedistillery.com.au/jaws",
 "CrawlerManagerInterfaceService");

// Services (note that we use the org.jboss.ws.jaxrpc.ServiceFactoryImpl class)
ServiceFactoryImpl factory = null;
Service watchListService = null;
Service crawlerService = null;
try {
 factory = (ServiceFactoryImpl) ServiceFactory.newInstance();
 watchListService = factory.createService(watchListWSDL, watchListQName, watchListMapping);
 crawlerService = factory.createService(crawlerWSDL, crawlerQName, crawlerMapping);
} catch (ServiceException se) {
 System.out.println("Couldn't create service");
}

WatchListManagerInterface wlm = null;
CrawlerManagerInterface cm = null;
try {
 wlm = (WatchListManagerInterface) watchListService.getPort(WatchListManagerInterface.class);
 cm = (CrawlerManagerInterface) crawlerService.getPort(CrawlerManagerInterface.class);
} catch (ServiceException e1) {
 e1.printStackTrace();
}

// Code that actually uses the services goes here.

This seems to work OK, but I haven't tested it fully and since the services share classes, I'm not sure that it will work out alright in the long run. Any feedback would be extremely welcome!

Thanks guys,

James

[elcapitan]

I should mention that this solution is also not ideal because at some point down the track, this code may need to be ported to OracleAS, and hence using proprietary JBoss functionality is not a great idea.