How portable or compatible is JBossWS-CXF? My impression is that it is a "hybrid" because of a statement on the JBoss web site that states that it supports "almost all" of the features of CXF. If the goal is to produce services packaged as SAR files that can easily be deployed to application servers other than JBoss, if necessary, then should I stick with vanilla Apache CXF or use JBossWS-CXF?
If you stick with "pure JAX-WS" stuff, then the services should be completely portable to other applications servers. The hybrid nature comes from allowing a lot of the extra CXF features that don't have any equivalence in the JAX-WS spec. For example, if you use CXF's support for WS-Security, then the application would not be directly portable to another app server (unless they also use CXF). You would need to port that part of the code/configuration to whatever configuration is required for WS-Security on that app server.
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'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".
I created webservice in my system and
need to diploy it in a server which
contain OS other than windows,say
Mac or any others,so that those
working on Java or any other
technologies can acees my
webservice.Is there any possible solution
other than visual studio IDE is
there any utility for creating
webservice.i Heard about wsdlgen.exe
something like that .Is this useful
in this type of situation whoich i
explained above
A web service can be used (if written right) from many OS, however - when you say deploy - if you mean the actual service executable - you don't need to deploy it (probably you can't even) on mac or linux in order for other tech to access it.
you need to deploy it on the framework that you used to develope it (like win server for WCF / other dot net or c++ based server) and make sure it can be accessed by other technologies - by it's contracts / endpoints ect.
They will access it through tcp/ip probably http, using a common language that they can both talk.
** it doesn't matter if you deploy on IIS or as a service, or as a console application - as long as it implement the right standard other OS based client can access it.
Webservices are a platform independent setup. A webservice is a standardized way of communicating structured data. The language of the webservice is XML, thus it can be interpreted by most languages, and platforms (I haven't heard of webservices being used on DOS 3 yet. )
Your implementation of the webservice must be deployed to the compatible server. If you used a .NET language that is most likely on IIS (mono on its respected mod_net). If its in Java then on Tomcat, JBoss, etc.
Once you have deployed your webservice any client can access your webservice. The output of the webservice is [typically] contained in an HTTP message. Your client is not required to be written in the same language as the service its self, nor is it require the same platform that it is hosted on. I've heard of FPGA's using webservces, and I've been consumed a web service (written in java) from a Nokia N800 (using gSoap as the client).
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.