How are these two different from each other? As per my understanding, Spring-ws has annotations like #Endpoint, #PayloadRoot, #RequestPayload, #ResponsePayload, etc. In JAX-WS, there are annotations like #WebService, #WebMethod, #WebParam, #WebResult, etc. which correspond to the methods for Spring-WS.
I have browsed through various links trying to explain the difference between these two approaches, but all fail to clearly do the same. Some say that JAX-WS follows only code-first approach and Spring-WS follows only contract-first approach. Is this true?
Related
We are using Specflow for automating our regression suite but now we would like to take it to a next level of automating our webservices.
Using the Gherkin “Gven-When-Then”, how can I use / write the webservices calls.
For e.g : How do I write my given - when - then for the below request?
<ns:request>
<ns1:ServiceAuthenticationRequest>
<ns1:Password>?</ns1:Password>
<ns1:Station>?</ns1:Station>
<ns1:UserName>?</ns1:UserName>
</ns1:ServiceAuthenticationRequest>
…
</ns:request>
Unless you're writing webservice code itself, the behaviour of a generic webservice probably isn't that interesting.
What does your webservice do?
1) Can you give me an example?
2) Is there any situation in which your webservice would behave differently to that?
If you can answer those questions, you'll probably have a better idea of what to use as your first, and then second, scenario. The situations in which the webservice behaves differently are the contexts (givens); what you get as a result of those contexts will be the outcomes (thens). Calling the webservice will be your event. If your webservice has different capabilities, you'll probably have different events for each one.
As with anything related to BDD, have a conversation with someone and see if you can give them some examples of what you're thinking / ask them for some examples if they're more knowledgeable than you are.
I really can't get the difference between REST and POX web services. I mean, couldn't POX be considered as a REST web service with XML message definitions?
It depends on what your "Plain Old XML" contains.
The thing is, POX used to be compared with SOAP. SOAP is a very specific way to do XML over (mostly) HTTP and people were already doing "plain old XML" over HTTP. SOAP got a lot of criticism because it complicated the things people were already doing with POX. But I won't go into that, what I'm trying to say is that people used POX to do RPC.
REST isn't RPC. In REST, the XML is a representation of a resource, not a message definition as in RPC. There is also a very important REST constraint that people seem to forget or ignore that imposes constraints on the returned XML: the hypermedia constraint or HATEOAS.
If you want to find out more about how POX fits in REST, I recommend reading this article: Richardson Maturity Model, steps toward the glory of REST.
i just want to figure out how the two JSR difference, they are all used different way to implement the web service, one seems like using annotation, already included in jre1.6, the other is need to download some package axis, so i just think just two package to implement web serive or soap?
Yes, the rpc is older, and implement webserive and client are both different, they are actually two different package
I have been playing around with Apache CXF, in particular the various data bindings it supports: JAXB (the default), MTOM, Aegis and XMLBeans. Since all of these are supported, I suppose each has its merits. I came up with these:
Obviously, MTOM is to be preferred where large attachments are involved.
JAXB depends on annotations, so it is less suited when modification of classes is restricted.
Aegis has no wsdl2java tool, so it is less suited for "contract-first" development, i.e. start with a WSDL and generate your Java code from that.
It appears that Aegis provides slightly more control over the mapping between Java classes and XML through its declarative syntax in Class.aegis.xml files. On the other hand, I couldn't devise of any scenarios where JAXB did not do the trick.
I found this question juxtaposing JAXB and XMLBeans, but it doesn't give a comprehensive overview:
JAXB vs Apache XMLBeans
Besides these naive, a priori considerations, do you have any blood-and-guts experiences that would support the use of any other binding besides JAXB? I'm asking from a CXF point of view, but if any other options come to mind (e.g. Castor) please don't hesitate to elaborate.
If starting from scratch to create a WSDL first web service, then I definitely would recommend sticking with JAXB 95% of the time (maybe even higher). It's definitely the best tested databinding in CXF and performs quite well.
Where the other databindings come in are usually for one of two cases:
1) Java first use cases where you have something already written in Java that you want to expose as a web service with little to no modifications to the code. Aegis has it's strengths here as it's designed to be able to handle a wider range of things than JAXB. However, if you CAN modify the code, adding JAXB annotations usually isn't that hard. If you have mostly normal "beans", it's not a big deal.
2) Existing applications that use a particular mapping. If you have exising applications that are expecting XMLBeans beans (or SDO beans if using 2.3-SNAPSHOT of CXF, or JiBX beans if following the GSoC project), then using the other databindings could help by removing any needed mappings from JAXB to those object models.
Hope that helps a little.
Remember that JAXB is a specification so there are multiple implementations: Metro (Reference Implementation, MOXy (I'm the tech lead), etc.
JAXB can be used starting from Java classes or XML schema. If you have classes that cannot be modified individual JAXB implmentations offer extensions to handle that. See MOXy's externalizable metadata:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
JAXB was designed to work with MTOM attachments see the attachment marshaller/unmarshaller.
MOXy has XPath based mappings which offers full control of your object-to-XML binding see:
http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
parse google geocode with xstream
When providing a web services API (well, let's say SOAP), do you provide a library wrapper along with it to make it "easier" for people to use? Or do you just package up a WSDL and documentation for it and let people figure out what to do with it?
What are people doing usually? I've seen a bunch of examples where the wrapper is provided, but it has always seemed counter-productive to me.
WSDL is easily discoverable (all functions & types as declared), so there is usually no need to offer any package with it, and minimal documentation (apply an XSL to the WDSL and it's usually enough :) ). My theory about the appearance of libraries/wrappers is that it is directly related to security measures / needed authentication & hashes (usually: concatenating some fields with a secret & hash it), about which one simply doesn't want to answer every single question anymore.
Audience matters I think: if you want you run-of-the-mill hobby coder to be able to use your service, providing a package can get you that much more users. If you're more in business to business services, the webservice usually has to be integrated in some larger package and most libraries would be futile.
That being said, I'd say of the webservices I came across: about 60% of the libraries provided were hopeless spaghetti code fit for the bin, 30% were not the code I'd use, but could clear up some questions not answered by the documentation, and only about 10% were fit enough to integrate in a project (or the project small and/or worse enough to be no worse for it).
How you going to support multiple web-service stacks - JAX-WS, AXIS2, CXF etc? My choice - WSDL/XSD. In practice I got service built with JAX-WS and a client with AXIS2. And I don't want to build a client wich you are going to use. I don't even know your preferable web-service stack and your JVM version limitations. For example, I can call web-service from java 1.4 - there are no annotations and not possible to use client lib built with annotations for java 1.5. So WSDL is right way to build ws-client instead of providing generated client library.