I'm looking for a solution of dynamic web service client such as DII from JAX-RPC.
I need to generate a client from a WSDL.
But the WSDL is only known at runtime (so I don't have any available interface).
I had a look on JbossESB, JbossWS, JaxWS,JaxRPC, but I could'nt find anything that fits this requirements.
Thanks for your help.
It appears that this is possible with CXF and some java reflection.
jax-ws-dynamic-dispatch-with-cxf
I'm personally looking for a solution for this + a dynamic server model as well.
Good luck.
finding a ready-made solution to your problem is not easy. at least none exist AFAIK. due to the inherent, unknown complexity of the backing schema types associated w/ an operation's request and response, it's not possible to have such a solution.
however, putting together the correct tools, or using some open-source frameworks/libraries/tools you might be able to achieve something similar. basically you'll need to have a WSDL4J implementation, along with a schema parser like XMLBeans to get this working.
A tool which comes to my mind is SoapUI. it achieves something similar - user loads a WSDL at runtime and thereafter can execute operations. the source of this tool is also available for modification under LGPL here. you'll need to strip and salvage the core functionality that suits your need. or best, build one of your own :]
Related
I am trying to incorporate swagger-codegen in my new greenfield project, using Java (jaxrs-jersey2).
There are a lot of resources out there already documenting various parts of the project; however, I still haven't been able to find out any high-level advice on the best workflow to use with these tools.
As I understand it, swagger-codegen will be able to generate client-side code to interact with my API, such that I don't have to write this myself. This will happen by looking at a swagger.yaml (2.0) or openapi.yaml (3.0) file. This part is clear.
However, there seems to be multiple ways of generating this specification file. As I understand it, there are two primary ways:
Write a server implementation using a combination of jaxrs and Swagger annotations - have a maven plugin run as part of the compile step, generating a swagger.yaml specification file to be used by the client-generation plugin.
Write a swagger.yaml specification first, and generate server-stub code for Jersey, implementing only business logic, separate from all server boilerplate.
Which of these two ways is the recommended workflow? It sounds like (2) means writing less code and focusing on just application logic, without worrying too much about Jersey-specific glue to make the API work. This also means that the single source of truth for the API becomes a simple yaml file, rather than a bunch of Jersey code.
However, I'm unsure how to properly set this up:
Does my build need to have a compilation phase where server stubs are constantly regenerated?
Do I simply extend from the generated server stub and never worry about annotating API paths with #Path, #GET, etc?
Am I misunderstanding the use-case for server-stub generation? I.e. is the first approach (Jersey code-first) more appropriate?
If there is no real difference between the two approaches, when would you pick (1) over (2) and vice-versa?
Many thanks.
so here is my problem.
I'm using wsdl2java tool, to transform my web services into Java API.
The thing is, when I generate java stubs, my code contains something like that:
public void function(com.xxxxx.ssssss.Myclass myclass){...}
My question is:
how to remove this part "com.xxxxx.sssss." from the whole code, and put it in import section, and all that, not manually, because it would be too long.
Thank you
The vast majority of those classes shouldn't ever be edited at all; just generate them from the WSDL and leave them well alone. Yes, they'll be verbose but you'll just have to live with that (or offer to work on a better code generator for the CXF project, of course!)
The one class that you can edit is the skeleton (…Impl.java) that is generated with the -impl option. In fact, that's the source file that you should edit as it will contain the implementation logic for the service, which is your job. You generate it once and can change it however you want thereafter provided you implement the correct interface and have the right annotations. In particular, using refactoring tools to generate import declarations is perfectly fine (I find that this is easy to do in Eclipse; I'd be startled if other Java IDEs didn't also support something similar).
The only real fly in the ointment comes if you start altering the original WSDL significantly. While adding and removing methods is not too hard to deal with, the bigger the change the more work it is to support. You may have to look carefully at whether the service skeleton should be regenerated from scratch, but that will cost you all your changes; if you're expecting to be doing that a lot, it's a good idea to factor out much of the actual implementation of the service into worker classes so that you only need to rebuild the actual connection to the SOAP service. (Luckily, using Spring DI makes this sort of factorization really easy to manage, so much so that it's a good idea to use it anyway.)
I am attempting to expose documentation (like Javadocs) for a SOAP Service. Best case, it would either be exposed directly from the WSDL or through an autonomously generated report. I am using CXF as my SOAP implementation.
I have tried using the WSDL Viewer found here, but I havn't found a good tutorial on how to annotate my methods to get the structure and level of detail seen in his example.
The best solution that I’ve found thus far is to use an engine known as Enunciate (http://enunciate.codehaus.org/). Once added to the project it reads the JavaDocs and composes a set of HTML files. I don't fully understand all of the features or problems (it generates and links to its own WSDL, which isn't ideal, and does "scratch work" within an extra folder in the project which then reads as an error unless deleted), but it does successfully read and expose the JavaDocs in a clear and useable manner.
I have to admit that I am pretty confused how annotations work in java (SOAP) webservices.
What does adding a tag do? I think that maybe adding a tag generates some xml or maybe a wsdl? When I build should I see a difference in those files?
Any description or link would be great. I have done a lot of searching but I think maybe I am searching for the wrong things. For example when I search for:
#securityDomain
I just get garbadge results. I am having difficulty finding a good description of what specific tags do as well as how tags in general work.
Update:
So is it safe to say that you can either use annotations or you can write your own xml/wdsl?
#nnotations are defined by the Java language. An Annotation is a class. When you mark something with an annotation, the compiler and runtime arrange for an object of that class to be visible at runtime via java reflection.
The JAX-WS and JAX-B standards each define a raft of annotations. At runtime, or at java2ws(dl) time, they look at those annotations to decide what to do.
It looks to me as if #SecurityDomain in particular is part of JBoss, not any global standard, so you have to read the JBoss documentation to find out what it does.
I found this.
I use XFire to create a webservice wrapper around my application. XFire provides the webservice interface and WSDL at runtime (or creates them at compile time, don't know exactly).
Many of our customers don't know webservices very well and additionally they simply don't read any external documentation like Javadoc. I know that it's possible to add documentation (for parameters and methods) directly to the WSDL file.
I thought about Annotations or Aegis XML files but I don't know how... Do you know a way?
Edit: I just found this JIRA issue but the last activity was 2006. Any ideas?
XFire is slowly headed for /dev/null. Use CXF instead. In other words, XFire is being deprecated in favor of CXF - it's pretty much the same developers.
Since you use the Java-first approach, I suggest you generate you WSDL once and for all with CXF's java2wsdl tool, then you put your documentation in that and tell CXF to use that documented WSDL instead of letting CXF generate its own (undocumented) WSDL at runtime/deploy-time.
This page has pretty much everything you need to know about creating a web service in CXF.
And my last hint regarding CXF - use Aegis for data binding instead of JAXB. It doesn't work for complex POJO.
In my experience we have no problem with complex POJO and JAXB, the only problem is that the code starts to be cluttered with JAXBElements. On the other hand, Aegis documentation is pretty sparse and not well-maintained with relation to CXF.
Let's me add my two cents regarding XFire. We had very serious issue with XFie under JDK6 (both Tomcat 6.0 and 5.5).Please take a glance at that issue. In our case XFire with 4+ web services under JDK6 leads to hanging application servers (thread deadlocks etc.). It's interesting, but under JDK5 everything was OK.
And I completely agree with Christian Vest regarding migration to CXF from XFire. It has sense in many cases e.g. ESB Mule 2 doesn't support native XFire connectors anymore (see also).
And I wish to add that migration from XFire to CXF is not straitforward way (e.g. CXF has jar dependences that conflict with some hibernate releases see also), but it's doable. In our case we did it for couple days without code correction (Spring only configuration).
And my last hint regarding CXF - use Aegis for data binding instead of JAXB. It doesn't work for complex POJO.