Which approach (Contract-First/Code-First) should be used when creating Web services with Apache Axis2? If I choose the contract-first approach, which tool should I use to create wsdl? I am using the WSO2 platform.
Contract-first is the best approach IMHO. The reason is quite simple. When you code first and generate a WSDL, it might change. This may cause problems for other teams working on client code based on that WSDL.
In case of contract first, the WSDL will always be the subject of discussion between teams, and it will not just change because of code changes, but only when all parties agree.
It is best to use versioning in it as well.
You can create a WSDL in Eclipse, which also has excellent checks (requires internet access).
Definitlety contract first.
Interfaces are the way to go for strong typed web services.
Related
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.
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".
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.
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.