How to merge common parts of WSDL and XSD from different services?

I have to interact with a set of web-services that each come with their own WSDL and XSD. The XSD are sometimes merged in a single file sometimes spread along multiple files (20-30). However, from experience I know that most of the message structure and data share a large common subset, perhaps only 20% are different amongst the different transactions.

Unfortunately I开发者_如何转开发 have no control over the server parts or the declaration of the services so getting them to fix it is out of the question. A first version of the client generated each services separately and then used them as individual facades to form a coherent higher level service as an adapter for another system.

I used CXF with the default JAXB binding and imposed different generated packages for each services. I did this because some most services use a common data model but not all use the same version or customization so I have conflicts and thus opted for the brute force so I can get the system done.

However, this causes the memory requirements of the adapter to go through the roof as each services load their context. Right now I have upwards 500M of memory utilized just for the adapter that houses the service clients even before I start sending requests and processing responses. Although I can run the system without problems using current situation this create constraints that jeopardize the deployment of the solution; my client would like to reduce this dramatically (60% or more) so that this system can be installed along side others without requiring hardware upgrades.

Question is follows : Is there a tool or technique that would allow me to put the common parts of each transactions together such that they can be generated once and referenced where needed ?

I am not bound to CXF or JAXB other than the time required to re-factor the system towards a different framework or data bindings.

Thank you in advance for your help.

--- EDIT ---

Thank you Blaise. This points to a feature of JAXB that would be useful : episodes. Unfortunately I still need to extract the common base part of the different services. So now what I need is a means to extract this common parts through a structural diff, that is a diff tool that would be aware of the structure and type hierarchy the XSD describes so that proper references be put in place to connect the common sections with the specialized parts.

If you want to trim down a little, an alternative marshalling technology (in any framework) might do the trick - drop JAXB and try JiBX, which was added to the latest CXF release, or maybe just StAX.

Since you're looking to do something a little more custom than the conventional JAX-Ws/JAXB style services, you may want to consider Spring-WS.

Spring-WS gives you control over all aspects of the web services stack. It can route messages in different ways (payload, XPath expressions, etc), and you can use any marshalling/serialization technology you want (Jibx, jDOM, SAX, etc)

Here is a table that illustrates the options: http://static.springsource.org/spring-ws/sites/2.0/reference/html/server.html#d4e1062

If you really want to get fancy, you can take one of the lower level APIs, start marshalling the message and once you hit critical mass for one of your common areas, start a JAXB marshall right on the spot.

The ability to route messages to different 'endpoints' (in Spring-WS) terms, means you can also do things like "accept any message" on this one interface (that looks like DOM/SAX/etc) and then have one big marshalling operation there.

The key thing Spring-WS will buy you here is to break out of the JAX-WS mold, do play a little up front game, and then you can always marshall back to JAXB later, whether it be in interceptors, your app, etc. In theor you can the same with JAXB DOM Source, but it's my opinion that the Spring-WS stack gives you the finest grained control for special situations like you have here.

The best trick is to serve a static wsdl. Just open the wsdl, save it, upload in the server and indicate to the client to point to the static one instead of the dynamic-self generated.