I am starting on a new project with commercial vendor. I need to write an integration module in our application to consume commercial vendor's web service. So, WSDL is not controlled by us.
I think the general approach is to do a "Contract First" development and generate stubs from the WSDL file. I would like to know what technologies are available to do this? I would really like the simplest approach that works. We use Maven 3.0.3 and Spring 3.0.5 extensively. Can I use Spring WebServiceTemplate?
Please let me know if the question isn't clear or additional details are needed.
Thanks,
Tapasvi
You can generate the java stubs with the maven plugin for JAX-WS. Then you can use the stubs in spring to expose them as a webservice. Luckily, it's quite simple :).
Just a suggestion, don't re-generate the stubs every time you build the project, as (obviously) you won't be able to add any code to the stubs, which is sometimes very useful. I made this mistake long time ago and it was quite painful, because I had to put code in places where it didn't belong. In the last few years I used a maven profile to generate the stubs on demand and then I merged them "manually" to add the extra code. Of course, this is only viable if the WSDL doesn't change very often.
I have used axis and the easiest way to do is to run the utility wsdl2java and pass the location of the webservice along with the ?wdsl option.
I know lots of IDE's these days will allow to generate you stubs from within. MyeclipseIDE has an option to ingest an WSDL so does intelliJ. I think the safer approach is to use wsdl. Also if you are using jax-ws you can try
wsimport -keep -verbose location to wsdl
JAX-WS is included in the standard Java 6 distribution making it very simple to use.
Generate stubs with wsimport in the JDK (remember to enable as many warnings as possible, as you want to know anything that may cause problems).
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.
I want to generate service implementation from WSDL (Top down approach) in Java but I dont want to use any tool. For example If we want to create stubs we can use wsimport.
Please let me know if this is a duplicate question.
Thanks
If you don't want to use any tool to generate code or stubs, maybe you would like to use Spring WebServices. This way you only create an EndPoint able to process WS messages, that is, you only worry about implementing server logic.
With this approach you can define beans to marshalling, using jaxb2 (or another), and the EndPoint brings you functionality to receive not XML payload, but Java Objects instead.
If you don't want to genereta code or stubs, I think Spring WS is nice for you.
If you don't want to use any tool at all, then sorry for my answer, but I believed what you didn't want is to generate code.
Below is the Maven plugins which create Java from WSDL:
Axis :
Axis plugin
CXF
CXF plugin
Given our maven projet provides some api for clients to interact with it, those are just few java interfaces which are implemented in interal codebase...
Now if we just build the jar and publish it anyone can see the internal classes we used for implementation, yet we only need few java interfaces to be published (along with few DTO classes maybe)...
Is it possible to pick exactly which java files we want to build jar for and create two artifacts like (product.jar/war and product-api.jar)
Prupose is to limit possible misuse of the code by other teams...
The best is to make separate modules in Maven which represent your modules like:
project-api
which contains only the interfaces and which can be used by others separately.
project-impl
one implementation etc.
The above makes testing easier etc. is a good choice with regards to separation of concerns.
Your question is about securing code instead of maven in general. You can have multi-module maven project but still anyone can download that and decomopile it.
Few thoughts as Java does have inbuilt mechanism to support this but there are workarounds...some thoughts..
When you package a project as jar, don't put.java classes in jar/build.
Well the code can be decompiled back to java but at-least u dont
give .java classes to start with.
You can obfuscate your code with
various available options. Read bit here...
At the extereme,
expose your api as web services where you define a contract for
request/response. No one can see your code...
I have a WSDL file using which I have generated server side classes in JAVA using axis2-eclipse-codegen-plugin-1.5.4 and Axis 2 Service plugin. The classes are created but I don't know how to use those classes and I cann't figure out which from all those classes is the main class. It has generated many other methods which I m unable to understand.
Now , I have to modify those classes for so that the service, when published, can send dummy data to client(I have to enter business logic). I am unable to do so. Can any body help/ any tutorials which can help.
You can start from this Axis2 tutorials and articles
If your setup will support it, starting with ejb3, writing basic beans and letting the server generate the wsdl on the fly might be easier. I've done this with glassfish3 and it worked really well.
Check out this tutorial: Developing Web Services Using Apache Axis2 Eclipse Plugins. It is using an older version of the Axis2 Eclipse Plugin (1.3 when you are using 1.5.4), but hopefully the same steps apply, or you can figure them out based on the old tutorial.
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.