Can anyone point me to some decent introductions to WS-Security?
I'm looking for tutorials or something that provide a fairly gentle introduction to the subject, though I don't mind if it assumes basic knowledge of web services and SOAP. Most of the stuff I've seen so far is very technical and you need a lot of complex, detailed background knowledge to understand it properly.
We have to implement a web service in PHP and one or more clients in .NET, so resources covering both would be much appreciated.
I think the best introduction to the (any) subject are some good examples.
This article at codeProject gives a fairly easy to follow guide trough web service security for a .NET application.
I had to give myself a crash course in WS-Security a few months back, here are a few links that I found helpful:
http://www.ibm.com/developerworks/webservices/library/ws-security.html
http://www.devx.com/security/Article/15634
http://www.devx.com/Java/Article/28816
Check Kirk Evans' blog as it deals with the .NET Framework 2.0+ instead of the old .NET Framework 1.0 linked by Sven.
The implementation on Evans' blog is backwards compatible with clients running .NET Frameowrk 1.0.
You can find some good article on WS-Security and Apache Rampart - the open source WS-Security implementation - in WSO2 Online Library.
WSO2 WSF/PHP is a PHP Web services extension that has support for WS-Security and also interops with .NET Web services/clients seamlessly.
Related
I have been searching a good tutorial and resource to brush up SOAP web services knowledge. Even though there are lots of resources I found none of them truly solid to grab the main knowledge. Especially in Java, there are multiple approaches to do the same thing. I want to know what are the main advantages on choosing one approach to another, and where to decided to choose one to another. I appreciate if someone can share their experience on learning web services, specifically SOAP. If you have REST knowledge or if you can share a good valid resource, that would be useful for future reads. Any key reads and/or well covered tutorial will be helpful. Thanks!
Yes, SOAP java knowledge is very scattered and that's one of the reasons why Java EE 6 Web Services Developer Certified Expert is so hard.
You can start with the Oracle official webservices tutorial.
There are also good online resources.
You would also have to read some old books and the SOAP specs.
Also some good youtube videos.
Try blogs.
Books:
Java and SOAP. Building Web Services in Java
Java Web Services: Up and Running, 2nd Edition
Guys I almost spent a day on googling to find step by step tutorial for writing my first RESTFul service. No Luck
My environment is as follow
JDK 1.7
JBoss 713
Maven
Eclipse Indigo
Any pointer will be helpful. Thanks
Thank you. Though "RESTFul Java with JAX-RS" is quite old and lot of things evolved current past, gives good insight on the concepts. As Surya explained you need to go though multiple resources to get a good understanding on REST. What's the best source for learning how to create RESTful APIs in Java?
DropWizard provides end-end easy solution to write and deploy REST Services. Really impressive.
I'm trying to create an speech reconigtion based web. Afer some searching, i found that cmusphinx is a library quite good for speech reconigtion application. And my problem is how can communicate between cmusphinx and web ?
Sorry if this is a silly question.
Thanks for all your help !
In general, you need a web framework to marshal web requests to the Java or C code, then you just need to implement required speech-to-text methods with CMUSphinx API.
Here is the JAX-RS tutorial:
http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html
There are also more lightweight web service framework, for example Sinatra for Ruby.
You can also study existing implementations of web service using CMUSphinx, for example
https://github.com/alumae/ruby-pocketsphinx-server
Read more about it here.
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.
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.