In spring-ws reference documentation, they say that it uses a contract-first approach (i.e. WSDL comes first), and that spring-ws even doesn't support a contract-last approach. But then, in the first example (page 15), a Java class is created, annotated with #Endpoint, and the WSDL is generated afterwards.
So, isn't it contract-last approach?
It's always a discussion if it's first or last. But you've got to start somewhere. I don't know exactly what you are referring to, but mostly the WSDL is generated based on the XSD. You might even have used the XSD to generate Java classes based on the elements in it. Those classes can be used for your endpoint mappings.
Spring-WS stands for Spring Web Services. Spring-WS focuses on document driven Web Services i.e. Contract-first development approach. Spring-WS aims at providing the best features of Web services along with the proven features of Spring like dependency injection, powerful mappings, support to ws-security etc..Spring-WS, the service contract can usually be generated automatically. But you must create the data contract yourself
Related
I've been asked to complete some documentation related to a number of web services in an application and indicate for each service if it as implemented using JAX-WS or JAX-RPC. The services have been developed over a number of years, and probably using a variety of methods including the built in web-service wizard in RAD, as well as using wsimport, called from Maven. And they've changed and evolved over time as well - even in some cases where there was original documents saying that the service was one or the other, I'm not sure how much they can be trusted.
Are there any clear markers to let me know if a service is JAX-WS or JAX-RPC? I have full access to the source code, WSDLs and schemas. I'm just not 100% sure what to look for.
If you see #WebService in the Java source, that's certainly a JAX-WS service class. JAX-WS uses a combination of its own annotations and leverages JAXB annotations (#XmlType in pojos) for serializing/deserializing Java to/from XML.
If you see webservices.xml or XML files in a web module whose names seem to map to known web service names and that may look like this example, those are JAX-RPC services. JAX-RPC uses reflection and mapping files to convert a limited set of Java types to and from XML. You may even be able to search/grep the codebase for XML namespace values such as http://www.ibm.com/webservices/xsd/j2ee_jaxrpc_mapping_1_1.xsd or http://java.sun.com/xml/ns/jax-rpc/ri/config to find such mapping files - their names will likely guide you to the services implemented with JAX-RPC.
I want to create new RESTful application. I am bit confused about framework I can do it with spring+jersey , but can I do same application using jersey alone?
What is major difference between SpringREST and jersey?
Which is more convenient? why?
I've used both frameworks a bit. Spring is a large framework/API that covers many areas, one of which is rest services. Jersey on the other hand just covers rest. It's the reference implementation for the JAX-RS API (JSR 311 & JSR 339).
This is basically the "standard" way to do rest in Java. There are also other implementations like RestEasy. In theory your code will only need to reference the common JAX-RS interfaces meaning you ought to be able to swap to a different implementation later if required. This obviously only works if you don't become reliant on bespoke functionality that isn't part of the JAX-RS standard.
If you were to use Jersey, you might still decide you want spring. It can be useful just for its dependency injection alone. In this case you might have a JAX-RS class handling rest requests which then calls a spring service which has been injected. This is actually how I'm writing rest API's.
Whether you should use spring to write the rest services or JAX-RS is subjective and really up to you. Personally I went with the standard JAX-RS API because I found it was more focused on rest. The spring rest approach is basically an extension of spring-mvc which was originally intended for JSP's. I found things like error handling were easier using JAX-RS than spring-mvc. That said someone else may beg to differ. The other benefit is by following the standard in theory you have more flexibility in future if you want to switch to a different provider.
The main difference is that Jersey is standards-based, and Spring MVC is not, if that matters to you. Both are very good.
The main advantage I found in Jersey (I used 1.x) was that it could automatically use Jackson JSON Views automatically, and Spring MVC could not. Also, error handling in Spring MVC is kind of irritating, as error pages default to standard HTML.
There is another project you have not listed, and that is Spring Data + Spring HATEOAS, which is newer, but seems pretty good.
In my experience, most distributed object technologies (RMI, CORBA, etc.) work something like this:
define a service interface
write an implementation of the interface
use a tool (rmic, IDL compiler, etc.) that generates code which enables a client to get a reference to an implementation of the interface given some endpoint (URL).
The important point is that the service interface is a shared contract that both the client and service must adhere to. I've had a look at metro, and it doesn't seem to follow this pattern.
I'm looking for alternative suggestions that do support this kind of interface-based web service development. Unfortunately, I'm required to use SOAP, so libraries that only support RESTful services are no good to me.
Ideally, I would like to follow a code-first, rather than a contract-first appeoach, i.e. I define the (Java) service interface and the WSDL is generated from that, rather than the other way around.
Solutions that support defining or implementing the service using Groovy (instead of Java) are particularly welcome.
Metro allows you to annotate a given method, put a hint or two about the endpoints in the servlet container configuration files, and then have the WSDL generated automatically on request.
This is very nice, and save you all the trouble of having to create a full WSDL for just exposing a method or two.
Metro is good (+1), but Apache CXF's Simple Frontend goes one step further: you don't have to annotate anything. It generates WSDLs, clients and servers from plain Java interfaces.
I recently wrote some data access methods (plain old Java) that use immutable objects for both the request objects and the resulting data objects. I like the immutable objects because they prevent a good deal of confusion from appearing in the client code which I've seen in the past when people attempt to mutate and reuse objects.
Anyway, that was months ago. Now a colleague is having trouble with some web service generation stuff (attempting to expose my methods) which expects everything everywhere to be a JavaBean.
My question is: does web service stuff generation stuff always mandate use of JavaBeans? Is there another way?
Most web service frameworks provide some way for you to supply custom serializers/deserializers for types. Sounds like that is what you need here.
If it isn't clear why that's necessary, it is because the framework needs to know how to translate your Java class into XML and vice versa. Serializing and deserializing JavaBeans (classes with get and set properties) is easy if you follow the naming strategy, but you should also be able to supply your custom type serializers for classes that do not follow the bean pattern.
There are two general approaches to Web service development: top-down and bottom-up.
In the top-down approach, a Web service is based on the Web service interface and XML types, defined in WSDL and XML Schema Definition (XSD) files. The developer first designs the implementation of the Web service by creating a WSDL file. From this skeleton Java classes can be created to which the developer can add the required code. This skeleton implementation serves as an interface with the business logic. This process is also one of the J2EE standard - JAX-RPC based API for Web services which defines standard mappings between Java classes and XML types.
In the bottom-up approach, a Web service is created based on the existing business logic in Java beans or EJBs. A WSDL file is generated to describe the resulting Web service interface. Seems like your colleague is using this approach.
I would recommend a top-down rather than a bottom approach as you would have more control on the interface definitions and naming. Also your colleague could use your existing classes through the tooling generated skeleton interface.
I've just finished reading about SOAP via Spring-WS in "Spring in Action", 2nd edition, by Craig Walls from Manning Publications Co. They write about Contract First, much like the Spring docs, with making a message and method XML and then transforming that to XSD and then again to WSDL, while wiring up the marshalling and service path in Spring.
I must admit, I'm not convinced. Why is this a better path than, let's say, making a service interface and generating my service based on that interface? That's quite close to defining my REST #Controllers in Spring3. Do I have options of going a path like this with making SOAP webservices with Spring?
Also: I'd like to duplicate an already existing webservice. I have its WSDL and I can have my service placed instead of it. Is this recommended at all? If so, what's the recommended approach?
Cheers
Nik
I think you must have your wires crossed.
Contract first means defining a WSDL, and then creating Java code to support this WSDL.
Contract last means creating your Java code, and generating a WSDL later.
The danger with contract last is if your WSDL is automatically generated from your Java code, and you refactor your Java code, this causes your WSDL to change.
Spring-WS only supports contract first
2.3.1. Fragility
As mentioned earlier, the
contract-last development style
results in your web service contract
(WSDL and your XSD) being generated
from your Java contract (usually an
interface). If you are using this
approach, you will have no guarantee
that the contract stays constant over
time. Each time you change your Java
contract and redeploy it, there might
be subsequent changes to the web
service contract.
Aditionally, not all SOAP stacks
generate the same web service contract
from a Java contract. This means
changing your current SOAP stack for a
different one (for whatever reason),
might also change your web service
contract.
When a web service contract changes,
users of the contract will have to be
instructed to obtain the new contract
and potentially change their code to
accommodate for any changes in the
contract.
In order for a contract to be useful,
it must remain constant for as long as
possible. If a contract changes, you
will have to contact all of the users
of your service, and instruct them to
get the new version of the contract.
Toolkit's point about Java interfaces being more brittle is correct, but I think there's more.
Just like there's an object-relational impedance mismatch, there's also an object-XML mismatch. The Spring web service docs do a fine job of explaining how collections and the rest can make generating an XML document from a Java or .NET class problematic.
If you take the Spring approach and start with a schema you'll be better off. It'll be more stable, and it'll allow "duck typing". Clients can ignore elements that they don't need, so you can change the schema by adding new elements without affecting them.