A WSDL file could not be imported

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

A WSDL file could not be imported

stagirus
This post has NOT been accepted by the mailing list yet.
I am evaluating Petals, along with a few other SOA platforms. Petals seems to be pretty impressive thus far.
I have very complex WSDLs generated by Apache CXF. I was able to import two WSDLs. The third one, a much more complex WSDL, failed with the following error: A WSDL file could not be imported.

I am using Petals Studio 1.3.3 on Windows 7 (64bit). Just downloaded it from Petals site. The WSDL error message is not helpful at all.

What am I missing?


 
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
This post has NOT been accepted by the mailing list yet.
Is this message accepted yet?
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

Vincent Zurczak
In reply to this post by stagirus
Hi,

Can you validate your WSDL inside the studio?
It means copy your WSDL and its related local imports inside any Eclipse project, right-click on your WSDL file and click "Validate". Is your WSDL marked as valid?
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
Thank you Vincent. I found there was an extraneous character got inserted at the end of the WSDL file. Not sure how it got there. After removing that character, importing the WSDL was successful. Your suggestion of validating the XML/WSDLs is also very helpful.

I have a few other questions. I hope you can help me.
1. CXF generated WSDL files contain a complete definition of schema for each WSDL file. These definitions get repeated for every WSDL file. CXF correctly maintains namespaces according to Java package names. In the past, we had some challenges with Open ESB because of this issue. Their ESB/Studio complained that it could not use the same object definitions across multiple services because each service had its own schema definitions. So, my team had to manually extract the common schema definitions into a separate/shared schema file. This was a laborious process. How does Petals Studio handle this issue? Is this even an issue with Petals?

2. I have several CXF services/WSDLs to be imported into Petals Studio. Rather than saving and importing of each service/WSDL at a time, can Petals Studio import all WSDLs available on the App Server folder (/services) at once?

Thanks in advance for your help.
 
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

Vincent Zurczak
Hi,

stagirus wrote
1. CXF generated WSDL files contain a complete definition of schema for each WSDL file. These definitions get repeated for every WSDL file. CXF correctly maintains namespaces according to Java package names. In the past, we had some challenges with Open ESB because of this issue. Their ESB/Studio complained that it could not use the same object definitions across multiple services because each service had its own schema definitions. So, my team had to manually extract the common schema definitions into a separate/shared schema file. This was a laborious process. How does Petals Studio handle this issue? Is this even an issue with Petals?
Actually, I am not sure of understanding the issue. Somehow, I deduce this is probably not an issue with Petals. :)
In Petals, and in the studio, there is no global WSDL registry. Each project / service unit has its own directory. And the ESB's service registry puts a clear separation between WSDLs that are associated to different services. The jbi.xml is the key. The WSDL is a complement.

stagirus wrote
2. I have several CXF services/WSDLs to be imported into Petals Studio. Rather than saving and importing of each service/WSDL at a time, can Petals Studio import all WSDLs available on the App Server folder (/services) at once?
I guess you are only working with the SOAP component.
This is not possible in the studio, since it is a very specific usage. However, it would be possible to reuse the code of the studio to automatically generate service-units projets (or archives) from a set of given WSDL. That would be a new program based on the studio's code.
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
On the first issue of global WSDLs, let me rephrase the topic.
Let us say you have several services in your project. Some of them share a common data structure(POJO) say, Employee. Different services may need to pass the Employee object in different method invocations, without needing to tranform(assigns) of Employee object. One approach is to define these common structure in a shared WSDL/Schema file and import them into each service WSDL. Another approach, like the CXF approach, is to define each structure, Employee in this case, in every WSDL, keeping the namespace accurately. Do you see any issues with the second approach in Petals and BPEL design?
I hope this time, my issue makes sense.
 
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

Vincent Zurczak
OK, you are working with BPEL. Now, I understand. ;)

In this case, I think you will encounter troubles with the BPEL Designer (which is the Eclipse one). It will probably not indicate an error, but there will be some little things that will not work correctly (and you will not know why - I think to the quick pick as an example).

And you may also encounter issues with the BPEL engine.
I do not think this is a matter of Petals or Open ESB. If you reimport already defined structures, then it means they may be different, or in conflict. It is similar to what would happen if you had two classes with the same qualified name (same name, same package) in a Java project.

There is a gap (or a step, it depends on the people) between the web service habits and the BPEL ones.
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
Vincent:
I am glad to hear that we understand the problem. I was hoping that you could offer some solutions here. 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.  
Reply | Threaded
Open this post in threaded view
|

Re: 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. »
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
Thank you Vincent, for your excellent suggestions and flexibility. We are currently using CXF Aegis Data Binding with CXF Simple Front-End. We did not want to use annotations in our Java App.

I am also looking into CXF. If most of the ESBs/BPEL Studios cannot handle duplicated schema definitions, then it would make sense for CXF to provide an option to generate common/shared definitions into a separate file. So far I did not find any helpful tool. Their Java2WS can only handle one service at a time, pretty dumb. Let me dig deeper into CXF tools for some solutions for this issue.

Do you know any solutions within CXF?
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
Vincent:
I have explored various options with CXF build tools. I even posted my questions to Apache/CXF forum. No luck yet. Their build tools are not properly integrated into their run-time tools. So their run-time WSDLs and build-time WSDLs are different because their run-time features are more advanced in terms of Spring integration and type overrides.

Finally, it is appearing that the approach you had suggested: writing a tool that can download the CXF WSDLs and repackaging the WSDLs by moving the data type definitions into external XML Schema files would be ideal. Do you or other folks at Petals have appetite to support this feature in the short-term? I can also contribute to this effort.

Please let me know.
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

Vincent Zurczak
Hi,

stagirus wrote
Finally, it is appearing that the approach you had suggested: writing a tool that can download the CXF WSDLs and repackaging the WSDLs by moving the data type definitions into external XML Schema files would be ideal.

Do you or other folks at Petals have appetite to support this feature in the short-term? I can also contribute to this effort.
No, sorry, this is not on our roadmap. And we have such constraints on the deliverables that we cannot integrate it. So, unless you contact our commercial support, we can only give you hints or perform code reviews.
« Petals M.D. »
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

Christophe DENEUX
Administrator
This post has NOT been accepted by the mailing list yet.
Hi stagirus,

I think that you use a bad approach to design your service contract. The approach "bottom/up" that generates service contract from the implementation can be use for proof of concept. I you have service implementations sharing the same model you MUST write this model instead of generating it because each service will not use all the model.
The right approach is to:
  1/ generate a first WSDL from a service implementation
  2/ update the build of the servive to generate its java classes from the previous WSDL
  3/ for other services:
        a/ write their WSDL (inspired of the WSDL of the first service)
        b/ generate Java classes from the WSDLs

So you should get several WSDL importing the same model.
Christophe DENEUX
Petals ESB Architect
Linagora
Twitter: @ChrisDENEUX
Reply | Threaded
Open this post in threaded view
|

Re: A WSDL file could not be imported

stagirus
Christopher:
Thank you for your passionate remarks. It is sounding very religious towards contract-first approach. Having been in the  technology field for 20+ years, there is no right or wrong religion. It all depends on your perspectives, in our case productivity and maintenance objectives.

The tools (CXF) we are using have some minor limitations. I am sure we can resolve it.

From an (Petals) ESB perspective, your assumption that one should import cleanly packaged WSDLs is pretty accurate.

Thanks

On Jan 25, 2013, at 6:47 AM, "Christophe DENEUX [via Petals Forums]" <[hidden email]> wrote:

Hi stagirus,

I think that you use a bad approach to design your service contract. The approach "bottom/up" that generates service contract from the implementation can be use for proof of concept. I you have service implementations sharing the same model you MUST write this model instead of generating it because each service will not use all the model.
The right approach is to:
  1/ generate a first WSDL from a service implementation
  2/ update the build of the servive to generate its java classes from the previous WSDL
  3/ for other services:
        a/ write their WSDL (inspired of the WSDL of the first service)
        b/ generate Java classes from the WSDLs

So you should get several WSDL importing the same model.
Christophe DENEUX
Linagora
Twitter: @ChrisDENEUX



If you reply to this email, your message will be added to the discussion below:
http://forum.petalslink.com/A-WSDL-file-could-not-be-imported-tp4025421p4025454.html
To unsubscribe from A WSDL file could not be imported, click here.
NAML