Now, working with Spring-WS, I sometimes miss the simplicity of working with axis, where you just call a tool on the WSDL and XSD, and it creates the java objects and marshaller configurations, an interface that represents the information in the WSDL, a complete webservice client that implements this interface, and a server stub. Within minutes you can start writing the actual code for the webservice.
With Spring-WS you have much more configuration work to do - you have configure a marshaller, an endpoint, code all the information in the WSDL manually, and using the soap faults from the WSDL in form of java Exceptions seems difficult. Is there any tool that simplifies this work to a similar degree? I understand and appreciate that Spring-WS is flexible and whatnot, but sometimes you just want to whip up a quick webservice.
If you want the quick-and-easy tooled approach, then Spring-WS is not for you. It emphasises flexibility, small footprint and runtime simplicity, at the expense of having a bit more to do at first.
If this isn't what you want, then stick with the more heavyweight stacks like CXF or Axis2.
It's explained on this page: Why Contract First?. Basically, since there are problems to be solved when starting from a WSDL, they have chosen to drop the ball. If you want to work from a WSDL and keep being integrated with Spring, then choose CXF.
Related
Recently I read the article http://www.ibm.com/developerworks/library/ws-noide1/ and this prompted me to review my knowledge of just how the SOA had evolved in the last decade or so. The review was a nice refresher however I soon discovered some gaps in my knowledge.
In particular I want to know, and could not find a definitive answer for wheather WSDL files are necessary regardless of which protocol, paradigm, or API is used in providing the web service. Is the creation and propagation of these files done by the servlet containers such as tomcat , jetty etc in the background?
Essentially HTTP protocol itself for example does not require a WSDL which leads me to believe that WSDL is a specification closely coupled to SOAP and that perhaps EJB, Spring, etc do not use require it.
I know similar questions to this have been asked such as JSON, REST, SOAP, WSDL, and SOA: How do they all link together
but I haven't been able to find a definitive answer to this specific question.
If you take a closer look to the Java specification you'll have a clue of what is clearly the WSDL.
When you build a Web Service in Java you have several way to do it.
SOAP, spec Jax-WS : this standard is kind of strict. It order to communicate with it you have to respect a contract. This contract, named the WSDL, is an XML that define how to reach the WS, which parameters are needed and what are their types. This file is provided by the service and most of modern IDE would generate it but you have to provide it to your client so it can call the WS respecting the contract.
REST, spec Jax-RS : this standard is far less strict as you have no contract. This provide an URL over a specific HTTP method (GET, POST, PUT, DELETE). To make a call to this kind of WS, just call it and you'll see what happen.
Queue JMS : this is a kind of different as the two others but seems important to me as it provide a way to create messaging reliable, decoupled et asynchronous. It is based on a connection factory to deals with the communication.
These standard are implemented in most of the main technologies today. Java EE with its EJB has implementation for the three of them, as do Spring.
SOA provides many ways to communicate now, depending on what are your needs.
I hope I helped, don't hesitate to ask if needed.
EDIT:
To explain use case I'll try to set up an example... It's a kind of hard exercise and not perfect but I hope it will help you.
Consider, you work for a house seller. You have three different call to WS: 1. you confirm a sale on your website, 2. you search in your catalog, 3 you inform your boss via a small message on the intranet.
I precise that using three different type of WS is not compulsory.
This action is really important for your workflow. Data that are
sent must arrived. You must be sure to respect what is expected on
the WS. Client side and server side must be perfectly matching.
You'll use SOAP because there is a specific contract between these
two sides.
For this you don't need a specific and rigid contract. Searching is just easy and does not need a structure with defined arguments. Just get data and print it on the screen. Here REST is maybe more suitable because it is easier to set up and if modification are needed, there is no contract to modify on client side.
For messaging, you want to send the message and that's all. JMS are queues waiting for "message". These messages are requests that will be consume asynchronously. The message will be stored waiting for a consumer to take them in the queue order (FIFO).
The generation of the WSDL is your task. It will generate an xml file based on your Java code of the WS. Notice that the contrary is possible too, if you have a WSDL you can generate the Java from it(see this. Most of the time you have an url corresponding to your WSDL file so it can be accessed from your client.
You can generate WSDL from the IDE. But I'm not sure using Maven is the right way. The WSDL is your contract, it may be the one you based your WS on. The generation with IDE is just a way to make your life easier but at the end the WSDL may not change a lot. If it does then maybe SOAP is not what you need. REST may be more "agile".
Look at these links for manually generation with IDE (IntelliJ, Eclipse) or with external tool WSGEN.
As far as I know, the predecessor of JAX-WS (JAX-RPC) was using a
Client-Stub (Proxy) <--> Server-Skeleton (also called serverside stub, or Tie) system for the communication between Client and Service.
But if I am reading on the topic of communication in JAX-WS, I can't find anything relating Skeletons, serverside stubs, or Ties. Neither can I find anyone writing, that JAX-WS no longer needs skeletons. My researches only lead me to JAX-RPC topics, java rmi, or WSDL to Java approaches (SEI-Skeletons, but i don't think that are the skeletons I am looking for). But something in JAX-WS has to handle and steer the work of taking the SOAP-request, marshalling/unmarshalling it with JAXB and giving the parameters to the Methods of the Service Implementation.
Does anyone know, if JAX-WS is still using skeletons/ties on the server side and how they are created (with link to a source would be cool)? And if they are not used anymore, how is their work done?
I hope, my english isn't too bad.
The skeleton is still there but you can't see it.
The "server stub" in the picture below is the skeleton. It is created based on your annotated classe (#WebService), when the application is deployed.
It is still responsible in parsing the content, but now using JAXB.
Take a look at this link:
http://qallme.sourceforge.net/docs/sec_CreatingAWSImplementationSkeleton.html
I need to work with a REST service that has a relatively simple and fixed (meaning predictably not very variant structure), yet I can't find a WADL anywhere on their site. I have previously worked with SOAP services, which had a decent WSDL and I used it to generate my Java classes to which my client app was marshalling the service data using Axiom2.
My question is: is there an easy way to reverse engineer a WADL with which to easily generate corresponding Java classes if the site is lacking one, using some implementation of JAX-RS (e.g. Jersey)? Another way to ask it is: given only a REST service, no WADL, and some form of JAX-RS, what is the easiest way to generate marshalled classes on the client side?
Currently, as the structure is simple, I do it the hard way of using straight DOM from Java SE (org.w3c.dom) to parse the document. It works fine but I do not like all the traversing I have to do within the document structure and I feel like I reinvented the wheel. I am sure there is a more elegant way.
If you're just doing this once why not just do it by hand? If you need to do this regularly then you may be out of luck wrt WADL (as an aside see: https://softwareengineering.stackexchange.com/questions/133145/should-i-use-wadl-to-describe-my-restful-api).
Are you just trying to generate Java classes for the DTOs from the service? In this case you could take some sample XML from the service and use this to generate a possible XSD (maybe using trang). Then use XJC to generate the corresponding Java classes.
If the REST service is implemented in Jersey, Jersey should auto generate the WADL at runtime. The default location is http://server:port/appcontextroot/application.wadl. If the REST service uses other implementation such as RESTEasy, you are out of luck. https://issues.jboss.org/browse/RESTEASY-166
I need to write integrations to multiple external web services. Some of them are SOAP (have WSDL), some of them pretty much ad hoc - HTTP(s), authentication either by basic auth or parameters in URL (!), natural-language like XML which does not really map nicely to domain classes..
For now, I've done the spike integrations using Spring Web 3.0 RestTemplate and binding using JAXB2 (Jaxb2Marshaller). Some kind of binding is needed because domain classes need to be cleaner than the XML.
It works, but it kind of feels bad. Obviously this partially just because how the services are built. And one minor issue I have is naming of RestTemplate as services have nothing to do with REST. This I can live with. JAXB2 feels a bit heavy though.
So, I'm looking for some other alternatives. Ideas? I'd like to have a simple solution (so RestTemplate is fine), not too enterprisey..
While some of your services may be schemaless XML, they will still probably have a well-documented API. One of the techniques that the Spring folks seem to be pushing, at least from the web-service server side, is to use XPath/XQuery for retrieving only the information you really need from a request. I know that this may only end up being part of your solution, but I'm not sure that this is a situation where one particular binding framework is going to meet all your needs.
If I understand correctly you have 1 application that has to make calls to various external (web) services by use of different technologies. The first thing that comes to mind is to have some intermediate level. While this could be something as elaborate as en ESB-solution, my guess is that is not what you're looking for.
You could for example achieve this intermediate level by having a class hierarchy with at its top an interface 'Consumer'. Method to be implemented: doConsume() and so on.
If you look into it you'll probably have the opportunity to make use of several design patterns like Strategy or Template. Remember to be pro-active and try to ask a few times 'What if ..' (As in: what if they need me to consume yet another service? etc.)
If JAXB feels too heavy there are other API's to be found:
Axis
JAX-WS
CXF
other
It'll depend on the situation which one would be better. If you run into troubles with any of them I'm sure you'll be able to find help here on SO (and from people who have more hands-on experience with them than me ;-)
Given a public SOAP web service and no WSDL, I need to build a .NET client that can communicate with this service.
I'm a .NET dev looking for a simple way to generate a WSDL file given this url? I'd prefer to do this with some tool directly from my windows development machine but the only thing I've found is the javatowsdl tool in Apache CXF or Axis2. Are there any tools (commercial or otherwise) that would accomplish this? I'm really hoping not to write my own WSDL by hand.
If I have to go the route of the javatowsdl, can this tool be used without having to setup a server to run apache/tomcat, etc? anyone know the steps necessary to actually make this work?
Update: This KB describes generating a proxy via wsdl.exe or VS both of which I've done before. The interesting part of this KB is the part at the top where it mentions using the WSTK from IBM to GET the WSDL in the first place. The WSTK no longer exists and I'm looking for alternatives. http://support.microsoft.com/kb/307324 Hope that helps to clarify things a little.
I didn't see this mentioned, but have you tried appending '?wsdl' to the end of the soap url and trying it out in a browser?
Say for example the url to the service is http://www.someserver.com/service/NewService. Then you could try this in any web browser and see if it works
http://www.someserver.com/service/NewService?wsdl
If the browser pulls up the wsdl, than you can also the same url to wsdl.exe and it will generate the .NET client stubs for you.
Supposing you are using Visual Studio, right click your project and click Add Web Reference. Then enter the end point URL and you should do fine from here. Further details here.
Not sure what you actually want to create the WSDL from...? You say this is about a public SOAP service without WSDL - which means that this service does NOT offer a WSDL by itself already, right?
So what do you know exactly about this service then? Because, if you only know the URL of where to invoke the service without any additional specification (and again, if the service does NOT publish it's WSDL itself already, like on the same URL with an appended ?wsdl), I guess you don't really have any basis to create something from.
So some more info required here I guess...
The usage for Java2WSDL is explained here. It requires Java classes or interfaces describing the web service for it to do the translation (i.e. you can't just give it a SOAP request/response and hope it'll work it out from there). WSDL2Java can generate Java client-side bindings when given a WSDL (which is probably useless if you want to write a .NET web service client). All of this can be done without running a Java application server (because you're not actually hosting the web service, you're just describing its inputs and outputs).
Therefore, if you wanted to go down this path, what you'd have to do is work out the server-side interfaces in Java, and use Java2WSDL to generate the WSDL. From there, you can feed the WSDL into Visual Studio as per the KB article you linked.
I can promise you now that it will be fiddly getting the interfaces correct. Regardless of whether you can get the inputs and outputs correct, there's still the matter of Document vs. RPC and all kinds of other parameters that might not be readily apparent from looking at SOAP requests/responses.
whoAfter lots of reading and research, I found this little gem: http://wscfblue.codeplex.com/ It took the XSD and generated a WSDL file and can also generate the proxy code if you choose. I don't have everything working end to end yet but I thought I'd go ahead a post this for anyone else you might have a similar question. If I remember, I'll post back any notes on this once I'm done.