I am looking for resources to show me how I can consume web services inside native C++ . Are there any popular libraries I can use?
TIA
Andrew
It really depends on what webservice architecture you are talking about... For XML-RPC IBM has a nice article showcasing XMLRPC++, for SOAP there is e.g. gSOAP or WSO2 WSF/C++, ...
There are the Axis2/C libraries, which, while C based rather than C++, are still easily employable - when I was working on Apache Tuscany, we used Axis2/C for our C++ Web Service bindings.
From the Axis2/C front page:
"Apache Axis2/C supports SOAP 1.1 and SOAP 1.2, as well as REST style of Webservices. A single service could be exposed both as a SOAP style as well as a REST style service simultaneously. It also has built in MTOM support, that can be used to exchange binary data."
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've had nothing but problems using libraries that claim to simplify consuming SOAP Web Services. I've been using KSoap2 on the Blackberry to accomplish this, but I'm not liking the process at all.
On Android I manually created my envelopes with much success, I ended up doing the same on iPhone after much disappointment using SudzC.
I would like to do this for Blackberry as well. What classes should I use and how should I structure the envelope?
Thanks a lot.
See this article on the use of the Java Wireless Toolkit to create your coded stubs from your wsdl. It will save you a lot of time (and pain). I based my SOAP web service code on this article, and it worked well for me.
http://www.johnwargo.com/index.php/blackberry/dbja2.html
I'm consuming REST services that output XML documents, and we're doing all XML processing with the DOM libraries provided by RIM (using classes like net.rim.device.api.xml.parsers.DocumentBuilder and net.rim.device.api.xml.parsers.DocumentBuilderFactory).
The HTTP part can be done Java ME IO support (with javax.microedition.io.HttpConnection). Making your own SOAP WS client sounds like a lot of work, but it can certainly be done.
I was thinking into digging a little dipper into the REST type of web services and noticed that there aren't any specifications for it as opposed to SOAP web services.
Why is that?
Each language uses its own standards.
According to Wikipedia:
Unlike SOAP-based web services, there is no "official" standard for RESTful web services. This is because REST is an architecture, unlike SOAP, which is a protocol.
http://www.w3.org/Protocols/rfc2616/rfc2616.html - Http Uniform interface specification
http://tools.ietf.org/wg/httpbis/ - Latest revisions to HTTP spec
https://datatracker.ietf.org/doc/html/draft-gregorio-uritemplate-04 - URI Templates
https://datatracker.ietf.org/doc/html/draft-nottingham-http-link-header-06 - Link Headers and link relations
http://www.iana.org/assignments/media-types/ - Loads of links to specs for media types
These should be all the specs you need to get going to build a RESTful system over HTTP.
Are there specific WS-* specifications that you feel you are missing to be able to build as REST based system?
Well, at least for Java there is JAX-RS http://en.wikipedia.org/wiki/JAX-RS, but i don't know if this is based on some other standards.
OData (http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html) is a standard for RESTful WebServices and should fit your needs (at least if you're using any MS framework).
Btw. if you want do use a standard and make the WebService as open and reusable as possible, WADL (http://www.w3.org/Submission/wadl/#x3-40001.3) the WSDL equivalent for REST could help.
How can I build a stand-alone SOAP-based Web Services using Delphi? Must work with Delphi 2009, but it'd be nice if it worked with older ones too.
The built-in WebBroker Web Services creates CGI or ISAPI. It would be nice to create a stand-alone executable that I can control from bottom to top, especially during development.
RemObjects SDK for Delphi (RO/Delphi).
Different messaging formats are
provided, including our own highly
efficient binary BinMessage format, as
well as support for SOAP, XML-RPC and
- new - JSON encoding, in case you want to make your servers accessible
to clients not using RO, or write
clients to access Web Services
provided by others.
Dave Nottage wrote Building a stand-alone Web service with Indy (source code).
This article explains how to fit Indy
into Delphi 6's Web services (SOAP)
support.
According to the comment on the page, it works with Delphi 2009 with some modification.
Edit: People in Indy 10 and IdHTTPWebBrokerBridge with CBuilder 2009 posted modified version. For example, IdHTTPWebBrokerBridge.pas is by Jochanan van der Niet.
It should be possible to build a web service with VCL for the Web (formerly: Intraweb). It has an option of creating a standalone executable that contains both: web server and web application
In D7 I used IdHTTPWebBrokerBridge (Indy 9). But i don't know if it is still available in D2009.
There are a series of SOAP articles on Dr. Bob's website and specifically there is RAD Studio 2007 XML, SOAP and Web Services Development manual, but it's 99 Euro.
Something I used in the past was idRunner which is an extension to the indy library and it allows you to develop ISAPI dll's which your application then runs. The advantage of this approach, is you can deploy a standalone application to run your soap service, that can easily be deployed via IIS at a later date.
For debugging, I strongly suggest the idDebugger on the same page. It makes debugging ISAPI applications very easy.
Here is a step-by-step solution "Delphi 7 Indy Standalone Web Services/SOAP Server" which looks like it can be useful for Delphi 2009 too:
http://www.digicoast.com/delphi_soap_standalone.html
Update:
this solutions uses IdHTTPWebBrokerBridge, it can be used in Delphi 2009 with minor changes.
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.