I am creating a web service in ASP.NET that needs to be accessed from Android, iOS and BB. The big stickler here is that I do not want to use any libraries on these mobile platforms to read the transmitted data. I know that Android has a JSON parser built-in, but iOS does not. I also know that WCF-format is out, since none of them read that.
Is my only choice using a proprietary format for the transmitted data to be read by these devices? Has anyone found a good (native) format for the communication with the service across the platforms that doesn't involve creating a proprietary format?
Use JSON. It's built into Android and Blackberry, and there are Objective-C libraries to use it with iOS. It's light and compact and easy to create and parse.
What is "WCF-format"? ASP.NET web services use SOAP by default. WCF services can also be configured to use SOAP or to be RESTful. SOAP is just XML so any framework with an XML parser should do, and with WCF REST you can work with XML or JSON easily.
Your best bet is to use JSON. Although iPhone SDK doesn't have a built-in SDK library, you will easily find an inplematation (json-framework for example). The big benefit willbe that you could configure WCF to output bare JSON, which will be easily understood by all platforms.
REST has less overhead than SOAP, since it is just an HTTP GET/POST/PUT/DELETE. If you need something more than simple CRUD however, SOAP may be appropriate.
Blackberry doesn't have built-in support for JSON as far as I know, at least not for older models. iOS doesn't have built-in support for any of the web services so you have to parse the XML manually if you don't use any third party library. I would say you if you want, you can use JSON with some borrowed library. I chose SOAP because I can use it across platforms including some really old windows mobile phones and I want to use as less third party lib as possible.
Related
Could you please let me know Any useful online resource to learns and implement some scenarios to explore more about it. Thanks.
Datapowers are historically, in order:
XML Tranformation acceleration Devices (that used to be a thing, XSLT was too slow to process)
SSL offloading devices (again, that used to be a thing, same reason)
Web site and Applications Gateways. Both web sites and web services security, concentrated around HTTP and SOAP/XML application layer mechanisms and standards (SSL/TLS, WS-S, SAML, etc.), but also token management, security conversion ... think "super SSO" + application security gateway
More specialized integration tools : Transformation of XML (with XSLT), Transformation to/from non-XML format (like CSV), Database connections, integration patterns (like routing, composing, and a LOT more). Some called the Datapower a lightweight ESB.
More specialized uses : B2B(EDI), JSON processing, REST/JSON support, API Mgmt (when used as deployment point for API Connect)
Notice that all later features needs the former ones (ESB is based on WS Security, etc.)
As you may know, most of Datapower devlopement is done with tranformations. The default, established language for them is XSLT (XQuery is also and historic, less popular option).
XSLT is both one of the most powerful and most horrible language to work with. Kind of like the Perl+REGEX of the XML world...
... but there is another problem with XSLT. It is not designed to work with JSON. Making the Datapower of 10 years ago heading for a fats retirement.
At first, IBM designed pseudo-XML ways of dealing with JSON. You could convert inbound JSON to XML and work with the JSON AS XML in XSLT. The inverse operation was to use XSLT to generate JSON... it worked perfectly but kind a looked like old school HTML/PHP merging code.
So IBM came up with a good idea: GatewayScript.
(Mostly based on many other good ideas)
GatewayScript is basically ECMAScript 2015 (ES6) + CommonJS 1.0 + Many super popular JS crypto libraries.
ECMAScript is obviously more known as JavaScript.
Pertaining to your question, the main advantage of GatewayScript is to enabled easier JSON Web Services Development of all the features in the list above, for modern REST/JSON APIs, instead of older (but still good) SOAP/XML Web Services.
GatewayScript has now been present for years, no longer a "beta" option.
Here are some other neat GatewayScript features:
Access to a DOM model, representing the incoming and outgoing version of the document, in simple JS notation.
Better errors in the logs when something does not work (you get the .js line number, unlike with the XSLT errors)
Better debugging options (you can enable a line-by-line debugger)
Some examples from the web written in Node.js and other JS frameworks can work... which is amazing
A very useful IBM site (Datapower Playground) where you can learn and test GatewayScripts examples without your own Datapower, à-la-w3cschool
And more.
I hope this helps.
GhislainCote's answer is very complete but basically GatewayScript is Node.js with an added framework for handling the session object which will contain your data/payload.
There are also some special objects, e.g. service-metadata and header-metadata that will contain DataPower variables and headers.
Sample scripts are available in the store:///gatewayscript/ directory and as the store:///healthcheck.js for example.
Also review the Knowledgecenter, it contains a lot of help and information about GatewayScript:
https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.7.0/com.ibm.dp.doc/gatewayscript_model.html
GatewayScript is very powerful, I've coded support for AS2 de-/en-veloping (for customers not having the B2B Module option) and RosettaNet handling in GatewayScript so there is pretty much no limit to what you can achieve!
I'd like to access some web api's using .net code, but am not sure if there's a way to generate a client side wrapper of some kind for these? Perhaps a code generator that can look at the web api documentation or through sample calls and generated .net classes and methods to encapsulate the api?
There isn't. REST-based APIs do not have a WSDL or service contract that could be used to generate a client stub.
That said, consider the following alternatives:
REST Coder: this is interesting research but no definitive tools yet.
Google for .NET WCF REST client: it turns up a lot of interesting results.
As far as I know, there isn't.
However, you can try one of the many wrappers available, that makes your life easier once you have to write less code.
Check this one out I've written a few months ago:
http://webapiclient.azurewebsites.net
I have a webservice (.asmx) hosted on an ASP server with which i would like to communicate using SOAP from an iOS application.
For some functions, the server returns primitives, structures and datasets (as in system.data.dataset).
Can you please recommend me a framework that will manage the communications and XML parsing for me?
What kind of class should I use to emulate a dataset, or would I need to make one of my own?
For your connections try this framework: http://allseeing-i.com/ASIHTTPRequest/
However apples NSURLConnection api is pretty good and easy to use.
For easy XML parsing try: https://github.com/TouchCode/TouchXML
Hope this helps :)
Sam
How can we consume any web services in Lotus Notes 6.5. I have seen reference to Soap Connect API. Is it the only way to do it..?
Any example will be a great help..
Thanks..
There is no out of the box solution for LotusScript and WS Consumers in R6. You would need to create your own system to shape the SOAP request, send it to the server and parse the SOAP response.
You are not going to get the benefits from using Web Services in this fashion. The whole point is that you should not have to do this.
If you use the Java route you can use Apache Axis libraries to add consuming functionality.
http://axis.apache.org/axis/
Here is a very old developerworks article on it:
http://www.ibm.com/developerworks/lotus/library/domino-webservices/
Ultimately though I'd recommend to upgrade to a later version that does support WS consumers in LotusScript. Although be aware that LS suffers in WS due to limitations of the programming language.
What I did in R6 is creating Web based agents using LotusScript which behaved like Web Services. It performed rather good for services that weren't called by too many users at the same time (as far as I remeber...)-
This presentation / sample might be helpful for you:
http://www.slideshare.net/billbuchan/jmp206-lotus-domino-web-services-jumpstart#btnNext
Full files from Bill's presentation including sample are available for download here:
http://www.hadsl.com/HADSL.nsf/Documents/Lotusphere+2008+-+JMP206+-+Web+Services+Bootcamp!OpenDocument
Another helpful link (if you want to use SOAP/Java):
http://www.ibm.com/developerworks/lotus/tutorials/lswsdom65/lswsdom65-pdf.pdf
If you are on Windows, you can use a COM object in LotusScript to call the webservice.
A good one that I used myself is PocketSOAP: http://www.pocketsoap.com/ . It has a lot of features, like support for https, using SOAP headers and sending attachments.
Many of PocketSOAPs features are unavailable or difficult to achieve even in a native R8 web service consumer, so this is an option for higher versions than Lotus Notes 6.5, too.
Right now a lot of my applications use GWT-RPC for retrieving POJO's from a GWT RemoteService which in turn calls a Web Service (SOAP) to get the data. I am evaluating Flex and didn't really see anything truly analogous to this simple architecture. Anything I may have missed?
AMF is Adobe's compact binary message format for use in Flash / Flex applications. BlazeDS is the open source reference implementation for Java, using essentially nothing more than a simple "message broker" servlet to handle requests. This is similar to how services are exposed in GWT, although Blaze uses a single servlet, not multiple as in GWT.
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
BlazeDS, particularly with Spring Integration.
Does this help you? I'm not too familiar with GWT-RPC, but is the AMF protocol what you're looking for?
As others have mentioned, the main choice here is BlazeDS, which is Adobe's open-sores server product for exposing flex-native server RPC and messaging. BlazeDS on its own is a bit clunky, and if you use Spring on the server, there is a slick integration available between Spring and Blaze.
Another, 3rd-party alternative is GraniteDS, which does much the same thing as Blaze, but is Spring-friendly out of the box, and does quite a lot more than Blaze (e.g. runtime compilation and generation of SWF files from the webapp). I haven't tried Granite, but it looks pretty good.