Two questions
Two questions on JAX-WS and JAX-RPC
Besides annotations, how do I distinguish JAX-WS from JAX-RPC?
What simple POCs can I do to appreciate JAX-WS is better to use than JAX-RPC? (besides the reason that JAX-RPC is the older version). I have read all about JAX-WS and it's advantages but I find it card to figure out thinking of concrete examples or simple proof of concept that would prove that its better use it than JAX-RPC.
Can anyone help?
Your first question is covered by this one. To summarize, there are descriptor files present for JAX-RPC, since it uses XML mapping documents to describe reflection-based rules for marshal/unmarshal.
As for your second question, I suggest writing the same HelloService web service (provider) using both frameworks. I think you'll find JAX-WS much easier, if for no other reason than finding tutorial documentation. Use two web modules and follow tutorials to create the same functionality.
Take a look at the artifacts for both. Also experiment with adding complex Java types as input or output. Notice that JAX-RPC cannot automatically convert many WSDL/schema constructs to a Java equivalent - a great side by side comparison article (and series) is here.
A personal anecdote - due to the JAXB underpinnings, the JAX-WS service will be much more forgiving if the request message has small deviations from the WSDL such as unexpected input elements, etc. Why is this important? Versioning & maintenance. With JAX-RPC, it was much more difficult to update the service provider with new fields without breaking JAX-RPC client applications, and vice versa.
Spec Time
I've seen it mentioned that JAX-RPC is deprecated as of JavaEE 6. I don't see that wording specifically (it is listed for server implementors as "proposed optional"; the PDF spec says the following:
EE.12.2.3
JAX-WS JAX-WS, along with JAXB and the Metadata for Web
Services specification, provides simpler and more complete support for
web services than is available using the JAX-RPC technology.
Applications that provide web services using JAX-RPC should consider
migrating to the JAX-WS API.
(emphasis mine).
The JavaEE 7 spec lists JAX-RPC not only as optional (for server implementors); it also includes it in the list of "pruned Java technologies" - candidates for outright removal in subsequent JavaEE spec versions.
All this to say: you don't earn your way out of the JavaEE specification if you're the better spec.
Related
One of our product publishes a webservice using contract-last approach. This has becoming a real problem as all of our clients (ws clients) have to rebuild their client apps as soon as we release a new version of our product. This is due to all namespace changes that comes as a cost with auto-generated wsdls. We use Axis1 for javatowsdl. I've been seeking for a good methodology/ tool to develop backward compatible webservice for this.
i.e. version 9.3 clients can still hit the 10.0 service, of cause they will miss some of the functionality, that is fine. But they should be able to function without breaking.
I do understand the whole problem is due to our contract last approach (Pls. correct me if I'm wrong). Therefore, if the solution is to go for contract-first webservice what are the tools and technologies I could use? Also what are the best practises around contract-first?
Thanks in advance.
As you already realized, the recommendation is to use a Contract-First (or Top-Down) approach to develop Web Services. That implies a manual definition of your WSDL interface and generate a Java Skeleton of the Web Service based on this document using automatic tools.
Is important that your WSDL complies to the WS-I standart to assure interoperability between clients on different platforms. You can use SOAP-UI to test whether your WSDL is compatible with the standard or not.
For the Skeleton generation, there are several Web Service Runtime API's that you can use: Like Apache Axis and JAX-WS. I personally prefer JAX-WS because is a Java Standard and is supported by all Java EE Containers. Each container provides tools for the Skeleton generation, Weblogic has some nice Ant Task for that but there's also WS-Import that is Container neutral.
I am working on a Java EE project where there is a need to incorporate Web Services to transmit and receive data to/from external sources. I am not sure which way to go, Axis2 or JAX-WS.
Any suggestions will be appreciated.
The choice of a web services stack depends on what standards you actually need. Here are some stacks currently available:
The JAX-WS reference implementation is part of Java and provides basic support, including WS-Addressing, but not WS-ReliableMessaging or WS-Security. The big advantage is that you do not get additional dependencies by using the RI.
Another option is Axis2, which also provides support for these standards. As far as I know, the use of Axis2 is declining and personally, I found it rather hard to use (That's basically an opinion, I do not want to start a flame war).
I would suggest to consider a third option: CXF. It is another implementation of a web service stack and supports roughly the same as Axis2. I found it rather easy to set up and use and personally prefer it to Axis2.
One more option is Metro. Metro bundles the JAX-WS reference implementation and the Web Services Interoperability Technologies (WSIT). WSIT provides an implementation for several more standards and is tuned to provide interoperability with WCF.
Here is an article that compares these stacks with a little more detail. My suggestion would be: If you only need basic stuff (no reliable messaging, security, etc.) use the reference implementation. If you need support for additional standards, go for CXF or Metro.
Metro is the way to go! At lest for me :)
please see my comment in a similar question.
It depends on your requirement. What type of implementation you require.Java from its 1.6 version provides API for JAX-WS type of web service creation. But, really it's just for the basic requirement. If you want ws-Security,ws-policy etc. then please go for Axis2. Actually in Axis2 they have made lot of improvement from it's Axis 1.x version. The new STAX implementation is one of them. Apart from that Axis2 has made service creation part lot easier. Even, they support RESTful web services also.
I was thinking into digging a little dipper into the REST type of web services and noticed that there aren't any specifications for it as opposed to SOAP web services.
Why is that?
Each language uses its own standards.
According to Wikipedia:
Unlike SOAP-based web services, there is no "official" standard for RESTful web services. This is because REST is an architecture, unlike SOAP, which is a protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616.html - Http Uniform interface specification
http://tools.ietf.org/wg/httpbis/ - Latest revisions to HTTP spec
https://datatracker.ietf.org/doc/html/draft-gregorio-uritemplate-04 - URI Templates
https://datatracker.ietf.org/doc/html/draft-nottingham-http-link-header-06 - Link Headers and link relations
http://www.iana.org/assignments/media-types/ - Loads of links to specs for media types
These should be all the specs you need to get going to build a RESTful system over HTTP.
Are there specific WS-* specifications that you feel you are missing to be able to build as REST based system?
Well, at least for Java there is JAX-RS http://en.wikipedia.org/wiki/JAX-RS, but i don't know if this is based on some other standards.
OData (http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html) is a standard for RESTful WebServices and should fit your needs (at least if you're using any MS framework).
Btw. if you want do use a standard and make the WebService as open and reusable as possible, WADL (http://www.w3.org/Submission/wadl/#x3-40001.3) the WSDL equivalent for REST could help.
I'm designing a set of web services to allow our clients to connect from their apps to one of our systems. Our clients have their apps developed in all varieties of frameworks (.NET, Java, PHP, Python and even the occasional all JS app), so obviously WS is the way to go.
Investigating a little about truly interop WS I've found that the way to go is to design first the WSDL and XSD and derive the implementations from there.
What i'm really looking for is guidance if this is really the way to go. I've read that WCF creates interoperable WS but i'm not a fan of MS creating something standard.
Should i use WCF or there is a good set of tools for designing WSDL and XSD without the pain i'm expecting.
Thanks in advance
If you want to interoperate with JavaScript, then best to make more of a REST style API. This is basically just standard HTTP calls, so you're interopable from the get-go. However, you've kindof indicated that you want to use SOAP, so ...
If you're going with SOAP/WSDL, I'd definitely advocate using the server platform - yes, even .NET - to generate the WSDL, then simply check that the options you're using are producing a good, interopable WSDL.
I'm a Java developer with a history of PHP & Perl, and I've interoperated with .Net on a number of WS projects, from both sides of the coin (as server and client). There's usually no major problems - just be wary of a couple of things:
certain proprietary elements that MS
mixes in with the open standards. For
example, they may offer NTLM-style
authentication, which really isn't
needed in most use cases,
particularly when you're using SSL
certificates.
SOAP has taken a few
different forms over the years
(Document/Literal, RPC/Encoded, ...)
you'll probably find you don't need
to worry about this, as RPC/Encoded
died along with old frameworks, and
most modern frameworks tend towards
Document/Literal
SOAP offers a few
bolt-on standards (e.g. MTOM & DIME
for attachments, and SOAP-WS for
authentication). Try to avoid those
bolt-ons, as different platforms
implement different subsets.
For security, I'd advise to use SSL for
the trust & confidentiality, and then
either HTTP basic auth, or simply custom
string tokens in your soap request definition.
Just keep the WSDL as minimal as possible, try interoperating quite early in the process, and you shouldn't have too many problems
You can use WCF and contract-first development.
If interoperability is the main concern then I would recommend using WCF to provide the service implementation but instead of relying on WCF to generate the service interface to use contract-first development to model the interface.
A really good article on how to develop this way is Schema-based Development with Windows Communication Foundation.
If you are going to roll your own WSDL and schemas you are probably going to want to get an editor like XmlSpy or LiquidXml. I like the price of LiquidXML (free!) but I can't recall if you have to pay for the web service features.
Another interesting tool for contract-first development with Visual Studio and WCF is WSCF.blue. I haven't used it but it does appear to be actively developed based on the WCSF.blue roadmap.
WSDL and XSD are language independent, you just have to have some mechanism to communicate using other languages. Good thing for you to do would be IMHO core data design, so you would not need so many XSD for the same data entities.
I'm not sure what you mean when you ask "should I use WCF"? WCF is the current mechanism for developing web services (and other kinds of communicating services) on .NET. There is no other current mechanism. The others are obsolete, or else considered "legacy technology".
My gut feel is that document based web services are preferred in practice - is this other peoples experience? Are they easier to support? (I noted that SharePoint uses Any for the "document type" in its WSDL interface, I guess that makes it Document based).
Also - are people offering both WSDL and Rest type services now for the same functionality? WSDL is popular for code generation, but for front ends like PHP and Rails they seem to prefer rest.
Document versus RPC is only a question if you are using SOAP Web Services which require a service description (WSDL). RESTful web services do not not use WSDL because the service can't be described by it, and the feeling is that REST is simpler and easier to understand. Some people have proposed WADL as a way to describe REST services.
Languages like Python, Ruby and PHP make it easier to work with REST. the WSDL is used to generate C# code (a web service proxy) that can be easily called from a static language. This happens when you add a Service Reference or Web Reference in Visual Studio.
Whether you provide SOAP or REST services depends on your user population. Whether the services are to be used over the internet or just inside your organization affects your choice. SOAP may have some features (WS-* standards) that work well for B2B or internal use, but suck for an internet service.
Document/literal versus RPC for SOAP services are described on this IBM DevelopWorks article. Document/literal is generally considered the best to use in terms of interoperability (Java to .NET etc). As to whether it is easier to support, that depends on your circumstances. My personal view is that people tend to make this stuff more complicated than it needs to be, and REST's simpler approach is superior.
As mentioned it is better to choose the Document Literal over RPC encoded whenever possible.
It is true that the old java libraries (Axis1, Glue and other prehistoric stuff) support only RPC encoded, however in today's most modern Java SOAP libs just does not support it (e.x. AXIS2, XFire, CXF).
Therefore try to expose RPC encoded service only if you know that you need to deal with a consumer that can not do better. But then again maybe just XML RPC could help for these legacy implementations.
BiranLy's answer is excellent. I would just like to add that document-vs-RPC can come down to implementation issues as well. We have found Microsoft to be Document-preferring, while our Java-based libraries were RPC-based. Whatever you choose, make sure you know what other potential clients will assume as well.