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.
Related
I'm currently stuck between two options:
1) Store the object's information in the file.xml that is returned to my application at initialization to be displayed when the GUI is loaded and then perform asynchronous calls to my backend whenever the object is edited via the GUI (saving to the file.xml in the process).
-or-
2) Make the whole thing asynchronous so that when my custom object is brought up for editing by the end-user it queries the backend for the object, returns the xml to be displayed in the GUI, and then do another asynchronous call for if something was changed.
Either way I see many cons to both of these approaches. I really only need one representation of the object (on the backend) and would not like to manage the front-end version of the object as well as the conversion of my object to an xml representation and then breaking that out into another object on the flex front-end to be used in datagrids.
Is there a better way to do this that allows me to only manage my backend java object and create the interface to it on the front-end without worrying about the asynchronous nature of it and multiple representations of the same object?
You should look at Granite Data Services: http://www.graniteds.org If you are using Hibernate: it should be your first choice, as BlazeDS is not so advanced. Granite implements a great facade in Flex to access backend java objects with custom serialization in AMF, support for lazy-loading, an entity cache on the flex-side with bean validation. Globally, it is a top-down approach with generation of AS3 classes from your java classes.
If you need real-time features you can push data changes on flex client (Gravity module) and solve conflicts on the front side or implement conflict resolvers on the backend.
Still you will eventually have to deal with advanced conflicts (with some "deprecated" flex objects to work with on the server: you don't want to deal with that), a basic feature for instance is to add a version field and reject manipulation of such objects on the backend automatically (many ways to do that): you will have to implement a custom way for a flex client to update itself to the current changes implying that some work could be dropped (data lost) on the flex client.
If not so many people work on the same objects on your flex application, this will not happen a lot, like in a distributed VCS.
Depending on your real-time needs (what is the frequency of changes of your java object? This is the most important question), you can choose to "cache" changes in the flex side then updating the whole thing once (but you'll get troublesome conflicts if changes have happened) or you can check everytime the server-side (granite enables this) with less conflicts (and if one happens: it is simpler) but you'll generate probably more code to synchronize objects and more network traffic.
When building RESTful services, I always come up against the issue of how to develop a client library that can distribute to users of the system.
To take a simple example, say there is a entity call person, and you want to support the basic CRUD functionality through your RESTFul service.
To save a person, the client needs call POST method and pass the
appropriate data structure, say in JSON.
To find people by birthday, your service will reply with a response containing a list of people objects
To delete an person, your service will respond with a success or
failure message.
From the above examples, there are already two objects that may be shared with the client: the person object and the response object. I have tried a few ways of accomplishing this:
Including the Person object from your server call in the client library. The downside to this approach are:
The client code become tightly coupled with your server code. Any
changes from server side will require client to make update during
the same release.
Person's object may contain dependencies or annotation used for
persistence or serialization. The client cares nothing about this
libraries but are forced to include them.
Include a sub class of Map which is not directly tight to Person's object but contains some helper classes to set required fields.
Looser coupling, but could result in silent errors when data structure from server changes.
Use a descriptive file like Apache Thrift, WADL or Json Schema to generate client objects during compilation time. this solve the issue of object dependencies but still creates a hard dependency. This is almost like creating a WSDL for SOAP. However, this approach is not widely used and some times difficult to find examples.
What's the best way to publish a client jar for your application, so that
Its easy for client to use
Does not create tight coupling and some tolerance for server side changes
If you answer is better documentation of the API, what's is a good tool to generate these documents from Java annotation and POJOs.
This is a common problem, regardless of the protocol used for communication.
In some of the REST APIs we've been working with recently (JAX-RS based), we create DTO objects. These are just dumb POJOs (with some additional annotations for JAXB to do some marshalling/unmarshalling for us automatically). We build these as a submodule (in maven) and provide them as a JAR so that any other projects using our API can use the DTOs if they wish. Obviously, if you want to provide your own client library, it can make use of these DTOs. Having them provided as a separate JAR (which any app can depend on) means clients aren't pulling in crazy dependencies that they don't need (your whole serverside code).
This keeps things fairly well decoupled.
On the other hand, you really don't need to provide a client. It's REST after all. Provided your REST API is well constructed and follows HATEOAS principles, your API should be easily crawlable/browsable, i.e. you shouldn't need any other descriptive scheme. If you need WADLs or other similar constructs, your API probably isn't very RESTful.
I've got a specific project that I need to undertake and I would like some guidance from the masters before I take my first step.
We have a number of applications that receives input from some external sources (i.e. file, XML-RPC, web-service, etc), then processes it in some way, applying rules to it, communicating with other external systems (possibly), accessing a database (maybe) and then sending back a response. We are maintaining different versions of the same application to cater for all the small differences between our clients. (Yes, yes, I know. It's terrible, that's why I want to fix it...)
The idea I am playing with is to have a component based architecture where different components can be wired together through configuration and the flow of information is governed through business rules. It must, in essence, be possible to give each client a copy of the program with a different set of configuration. I am even dreaming of a GUI-based application where a system can be wired together in a VB-style drag and drop fashion.
Now, the above sounds definitely like something that has been done before... and I do not want to reinvent the wheel. The problem is that the above has to be able to handle high volumes of real-time transactions, so I am not sure whether something like BPEL will be the right choice.
Any recommendations before I go and make the wheel rounder?
I would write a very simple XML dialect for your application. Keep element-types to a minimum, and use class="my.class.name' attributes to build the correct class-instances at run-time. This makes it easy to have, say, a element with 3 implementations (for instance
<source class="my.package.XmlRpc">, <source class="my.package.LocalFile"> and <source class="my.package.WebService">). Each element-type, once instantiated, should read its XML contents to find any additional data it needs to configure itself correctly.
There are many easy-to-use XML parsing libraries (I recommend JDom), and there is a lot of tool support for XML viewing and editing. XML is easy to document, work with, and wrap into GUIs.
So: each component gets an element-type, and their specific implementation-dependent configurations are buried inside the elements. If you have simple wiring (specific component instances are only used in a single place), you can get away with inclusion. If you have complex wiring (you need to reuse component instances in several places; for instance, you want to re-use filters or compute intermediate results), first you define the component instances, and then you build the wiring out of references to these instances.
I am essentially advocating something like Ant build-files, and for keeping things as simple as possible.
At work, we currently have a WSDL interface as well as a semi-RESTful interface that we're looking to expand upon and take it to the next level.
The main application runs using Servlets + JSPs as well as Spring.
The idea is that the REST and WSDL are interfaces for an API that will be designed. These (and potentially other things in future) are simply a method through which clients will be able to integrate with the interface.
I'm wondering if there are any suggestions or recommendations on frameworks / methodologies, etc for implementing that under-lying API or does it make sense simply to create some Spring beans which is called either by WSDL or REST?
Hope that makes sense.
Have a look at Eunicate it is great . You are using spring , Spring has had support of SOAP for a while and Spring 3 has support of REST (Creating and Consuming).
Your approach makes sense. Probably the most important advice is to make the external API layer as thin as possible. You can use Axis, Apache CXF, Jersey, etc. to handle the implementation of the REST or SOAP protocols, but the implementation of those services should just load the passed in data into a common request object, and pass that into a separate service that handles the request and returns a response object which the external API layer will marshall into the correct format for you.
This approach works especially well when you have a competitor providing similar services and you want to make it easy for their customers to switch. You just build a new external API that mirrors the competitors, and simply translates their format to your internal api model and provided your services are functionally equivalent, you're done.
This is a really late response, but I have a different view on this topic. The traditional way as we know it is to unmarshall xml to java and marshall java to xml. However if the wsdl changes then it would effectively be a structural change in the code which would again require a deployment.
Instead of the above approach if we list the fields mentioned in the wsdl in a presistent store, load the mappings in memory and prepare our structures based on these mappings we would have to have many less changes for this..Thus IMO instead of using existing libraries a configurable approach to unmarshalling and marshalling should be taken.
I'm looking for a comprehensive setup that you've successfully used already. I've already loads of hints as to what building bricks I might use, but I'm not sure how to put it all together. Tools that need to be bought are OK, too.
Details:
I'm developing a Flex front end client for a Java server application and I have a set of model classes that represent objects in my business logic and should have the same properties and exhibit the same behaviour throughout all layers. These objects
have form validation logic for user input
are displayed in various forms (lists, detail views ...) throughout the UI
are retrieved from and sent to the server using XML or AMF
are validated again on the server
are stored in a RDBM with tables and fields corresponding to the classes and fields
This is a very common application structure, I guess. I'm already using:
ORM for the Java backend (Eclipse persistency package)
automatic mapping from XML to Action Script, using XML schema and the classes in mx.rpc.xml, as described here.
Now, what I'd really like to do is define the objects once (I already have them in XSD) and have tools set up class stubs for the whole chain. What can I use?
I've already heard of (but not evaluated):
XMLBeans to generate Java classes from XML Schema
Granite DS to generate AS classes from Java classes
I don't think your Flex UI should know or care about Java objects.
Take a "contract first", XML schema-drive approach and come up with the messages that you need to exchange between the Flex client and your service tier. Once you have that in place, the two are completely decoupled. That's a good start.
I'd also recommend not buying into a generation scheme. You'll only have to pay that price once during development.
I'm a Spring user, so I'd recommend Spring's "contract first" web services, using the Spring OXM interfaces. That will keep your UI and service tiers nicely decoupled. Use the org.springframework.oxm interfaces to do your mappings.
You can use Spring/BlazeDS to integrate your Flex UI with the Spring back end.
You have the full power of Spring IoC and AOP to create the back end.
I think you'll find it's a good approach for this problem.