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
Related
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'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'm beginning a project right now that will require a pretty extensive web back end. Of the different calling conventions, we have found that the easier and more cost effective approach is to build a standard SOAP web service.
So now, we are in the process of looking at the different web service frameworks in order to determine which will meet the business needs:
Security
Cost
Time
I've only worked with WCF, which I was fairly content with, but I would like to explore all other options before I make a definite decision. In your experience, what do you feel is the best web service framework?
Web Services Interoperability Technology (Java)?
WCF (.NET)?
ActionWebService (Ruby)?
On a side note, we need a framework that can securely be accessed via iPhones, Windows Mobile Devices, and Blackberries.
Thanks in advance for your help.
Chris
WCF can be used to make both SOAP and RESTful Web Services. Interoperability is guaranteed as long as you stick to standards. But the more standards you put on it, less platform can catch up. In that sense REST on Basic Auth over https would be very light weight. Also see WS-I Basic Profile. Java vs .NET would be matter of taste, I think. WCF is not perfect, but it mostly seems to do the job.
One thing to consider about WCF is that it has a very rich extensibility model. Anything it doesn't do out of the box, you can teach it to do, with little or no change to your basic service.
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.
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.