My client suggests that implementing a web service using WS-Policy entries inside the WSDL (using WS-SecurityPolicy standard, which seems to be the recommended way) might cause incompatibility issues with clients that call the web service. My first question is, are his concerns correct? If not, how can I prove to my client that it is safe to use WS? I could not find anything on the subject.
If compatibility issues can indeed occur, I need to find a different way to implement WS-Security requirements (like signing parts etc.) without Spring, using JavaEE APIs. I could not find anything on that subject either. The only thing I could find is about standalone web services but I do not want that, I want a web application and I need to use JavaEE APIs (so no Spring).
Any help will be appreciated.
If you have pre-existing clients already using this webservice, then yes it will break compatibility if you add WS-Security.
But if no one is using it, or it hasn't been developed yet, how will this cause compatibility issues?
Personally I see WS-Security as rather complex, particular in the area of signing and encryption, so if your client had said that some clients might not have the skills to implement the web service I would have been inclined to agree with him.
Related
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 thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck
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".
We developed a web service which is accessed by various platforms clients, for example it is requested by c++ and Java enabled clients.
I want to use simple, effective encryption Algorithm which is easily decrypted by JAVA - C++ and JAVA script based clients.
Why not just deliver your service over HTTPS?
Why write anything?
The most widely-compatible method of Web Service security that is still actually secure is Transport with Message Credentials. This uses SSL (https) for transport-layer security, which handles the encryption aspect, and passes a username/password in the SOAP header, which handles the authentication side.
It is not as secure as mutual-certificate authentication, which also gives you non-repudiation, but it is good enough for the vast majority of applications.
Several other options exist, but T/MC is usually the easiest to get working across platforms (.NET, Java, C++).
If you need to add javascript into the mix then I'm afraid you may be disappointed, as that is a serious game-changer. Although there do seem to exist various JavaScript SOAP Client implementations, SOAP is a second-class citizen in the JavaScript world, and I don't believe that any existing libraries have proper support for WS-Security or really WS-Anything except for the basic profile.
If you want your web service to be consumable by JavaScript then you want to go for REST instead of SOAP. I know that .NET (WCF) is pretty good at this but I'm not too sure how well Java and C++ fare. I believe that the transport security should be simple enough (it's just SSL), but it's likely that you'll have to implement some custom authentication code to get it working across platforms. Either way, you definitely want to go the SSL route; please do not try to roll your own encryption scheme.
If you already have the service implementation which is Base profile compliant and you want to keep on supporting various platform clients, extend your current service with WS-Security/WS-Trust. This will allow for encrypting/signing the content of the message, without loosing interoperability.
Depending on which toolset you used for your original implementation, the inclusion of WS-Security can be as easy as 'flicking a switch and selecting some options in your configuration file' (WCF/ASMX+WSE).
Since you mention the various platforms client side, I assume this is one of your main requirements.
Hope this helps.
You can simply use HTTPS which is easily implementable in both C++/Java clients (e.g. using the GNUtls library). On the server side, you will only need some small configuration changes.
Apart from the different request code, you have to create a self-signed SSL server certificate and install it on the clients. Of course this is not a good idea if the web service is public, where you need trust (= a real SSL certificate). But if it's only used internally, self-signed certificates are a quite good solution, as long as you keep the private key secret.
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.