[Users] A WSDL file could not be imported

[Vincent Zurczak]

Hi,


stagirus wrote
> You guys are the SOA experts, of course! You know manually extracting the
> common definitions to build a shared schema file is very laborios if not
> totally boring!
> 
> 1. Can the BPEL Studio consolidate the common definitions? If not, why
> cannot the BPEL studios be built to smarter?
> 
> 2. Can we configure Apache CXF to generate common schema definitions into
> a single file?
> 
> Any other solutions. Appreciate your suggestions.

Here are some suggestions.

First one: I guess you are using the JAX-B data-binding in CXF. If so, you
could keep on with your common dependencies in a single project, and then
add in each service project a JAX-B configuration file that would customize
the name space of the common packages. This way, there would not be
conflicts anymore. The drawback is that each service would be considered to
have different parameter types. And this would lead to use assignations in
the BPEL process (simple assignations though).

Second idea: what can be done manually could be automated. The schema that
are generated by CXF should be similar from one service to another. By
building some kind of catalog, and by comparing schema files (e.g. with XML
Unit, which should make it for this use case), you should be able to clean
your XML model inside your BPEL project.

Third idea: this would be where I would push the BPEL tooling if I was given
time to work on it. Writing BPEL is painful. Manipulating XML is painful.
These solutions are good with respect to interoperability and standards. But
they are not convenient for developers. So, if I could, I would push a
generation approach. Write some DSL (domain specific language), similar to
what developers are used to, and be able to generate fully-compliant BPEL
processes. You would start with your service definitions (WSDL), write some
pseudo-code that uses what is in the WSDL (with auto-completion...), and
then generate a BPEL process and/or deployment archive. Such a generation
work has been studied by our R&D team, but starting from a BPMN (2) diagram,
and not from pseudo code. BPMN 2 could be considered as a DSL.

So, here are the ideas...
Now... Why isn't it already made like this in the tools?
First, the BPEL Designer started (not so far) 10 years ago. It was not yet
at Eclipse.org. And I guess that the first contributors had not planned this
use case, and that people would a clean XML model with few risks of
conflict. If you did not plan such a conflict, you cannot work on how to
avoid it. Second, this use case is very specific. Actually, I have only seen
once until now. It does not mean it is a bad choice. ;) But I did not see it
very often and I did not feel we had to address it specifically. So, this is
about the lack... This is one issue, among other ones, with this tool.

Last, but not least, what about the future?
For the moment, I am not working anymore on Petals tooling (at least, not
the Eclipse one). Or very briefly. And I am much less involved in Petals
than before. I cannot say yet whether this is a temporary organization or
not. However, I keep on maintaing the builds of some Eclipse projects at the
Eclipse foundation. So, I may work on it again sooner or later. And the
other Petals developers are more focused on the server for the moment
(taylor its architecture for cloud usages, add probes for the platform
monitoring, and so on).

The most accessible solution for you and your team, would be the second
option I described above.
If you are willing to work on it, and if you are interested, I could help
with the integration inside the Eclipse tooling. And even to help you to
publish your code inside the Eclipse foundation.



-----
« Petals M.D. »
--
View this message in context: http://forum.petalslink.com/A-WSDL-file-could-not-be-imported-tp4025421p4025433.html
Sent from the Users (get help, provide help) mailing list archive at Nabble.com.