It’s time to discuss with the community the future of Wise and Lms. First of all a clarification: Alessio and me have being very busy in last months, but we are not planning to stop development of Wise and Lms.
We have 2 different approach possible, not mutually exclusive each other:
- integrate wise and Lms adding some functionality like saving request/response and code generation, making wise+lms a suite to test webservice, keeping QA people in mind and their relation with development people. We are thinking in this area about functionality to save, review and resend request and a common dashboard to manage wsdls, servers and so on.
- Separate wise-core (dynamic generation of jaxws client and object exchange) from wise-gui (or wise-seam as you like to call it). This step would be important to use wise-core as generic API to call webservice
Ok, first point is well known for our blog’s readers, but why we are starting a discussion now about the second point? Well, it comes from the idea to use wise to make an action for jbossesb for call web service instead of the current implementation. I took a look to what jbossesb is doing at the moment in this area, and I thought wise can do a lot of these things, using standard JAX-WS wsconsume APIC generated classes.
I don’t want to discuss here the specif needs of jbossesb, but in general I believe it could be a good approach when you need a total and effective decoupling of the client and server using ws to inter operate. It’s matter of fact that wsconsume tools is great for java developer, generating needed stub class, but it introduce a new (or renewed 
) level of coupling very similar to corba IDL. Generating statically webservice stub you are in fact coupling client and server.
So what is the alternative? Writing dynamic client using Dynamic dispatch JAX-WS API? Maybe, but I would prefer a solution using dynamic mapping on generated stub, exactly what wise 1.x does. In fact Wise did a mapping between a generuic user interface and generated stub objects. My idea is to extend this concept and permit to call a webservice mapping a generic Object Model to jaxws generated one. Are we reinventing the wheel? I don’t think so because IMHO JAX-WS dynamic dispatch isn’t a perfect turning wheel, and I hope Wise-core does the job better 
How wise-core does perform this generic task? In a nutshell it does the same wise 1.x did, generating on the fly classes using wsconsume runtime API, loading them in current class loader and use them with Java Reflection API. What we add is generic mapping API to transform an arbitrary object model in wsconsume generated ones, make the call, and mapping the answer back again to custom model.
The implementation can be viewed in our svn (trunk), and it’s based on a refactoring of our original code and an extensive use of Smooks. Smooks is an amazing tool! Have a look! I will post about shortly, stay tuned!
Here is some ideas done or in plan in the wise-core
- Much more unit tests. The core was really poor in this area. [DONE]
- Calling WS using a custom object model, and delegating to wise-core the responsability of required mapping action [DONE]
- Adding jaxws client handler(custom one and some ones implemented in the core, at least one smooks’ based [DONE]
- smooks based javabeans mapping from user object to wsconsume generated object [DONE]
- write examples of use [partially DONE]
- write good javadoc and user manual [TODO]
- write integration and example of integration with jbossesb [DONE, not in repository]
- generating Smooks config skeleton for generated object. Without them who write the smooks config file for mappers have to know the classes hierarchy generated by wsconsume (IOW generate it statically first time to have a look ) [TODO]
- Use wise-core in wise-gui, using smooks mapper against our proprietary TreeElement Object to map to generated classes [TODO, it needs next point]
- Dynamic generation of smooks config knowing target Object hirearchy (our TreeElement) and wsconsume’s generated objects. [TODO]
- Evaluate different mapping tools (to be added to smooks, not to substitute it for sure!). Maybe Dozer, even if I suspect some problem with it for our goals. [TODO]
In our svn you can find a test demostrating the use in a stand alone application.
any opinion?