SOAP Web Services in jQuery vs JavaScript
Image via Wikipedia
So I’ve been working with a LOT more SOAP-based Web Services since I’ve started up in a government software development position.
While in the past, most of my Web Service development has focused on creating or consuming RESTful Web Services, now my current position requires that I integrate with legacy systems built many years ago (with internal code largely untouched); in some cases, I don’t even have access to the original code, which doesn’t give me the option to switch or simply update the Web Services layer to use a simpler REST-based mechanism. Since we’re utilizing an ESB, I also need to maintain some form of data availability for the more complex stuff we need to do on the project (event-driven actions, rules, transformations, routing, logging and the like), and no, the ESB is NOT a good bandage for old systems, I think that is a common fallacy.
At the same time, we also need to build a Rich Internet Application and sometimes I want to go and get the data for a given object (i.e. User List upon loading). Thus, I’ve devised some approaches for calling SOAP-based Web Services directly from the client, via JavaScript and/or jQuery. My first choice was obviously to use jQuery but later I was told by my employer that due to licensing and other various business/political concerns it would not be desired in the final product, so I had to really go back to the old school and call the SOAP Web Services by hand from JavaScript directly.
In fact, I had to first prove it was even possible as I had many doubters on the team as well as superiors in charge of decision-making who doubted that it was even technically possible to call SOAP Web Services from JavaScript!
The following is the short and somewhat elegant (considering the situation) jQuery approach:
Read the rest of this entry »
Resurrecting the Google SOAP API
Original Photo courtesy of Magicfantasy on Flickr: http://www.flickr.com/photos/manicfantasy/889984960/
I know what you’re thinking, Let Sleeping Corpses Lie right?
Well let me first start off by saying I am not a huge fan of SOAP or anything, in fact, I much prefer REST about 90% of the time. However, there are still some cases where a fully controllable SOAP API which simply lists results as XML wrapped in a SOAP envelope, is a better way of interacting with data; particularly when that data is updated less frequently and is larger in size. Seeing Google results as XML can make them easier to manipulate and exchange, oh and lets not forget, that XML is what the X in AJAX stands for anyway, though JSON is used interchangeably these days, if not more often. With the debate between the SOAP and RESTful crowd all but won by REST and its simplicity, lets go ahead and awake the sleeping dinosaur that is the Google Search SOAP API for experimentation’s sake. For a quick history lesson, in 2006 the headlines rang to the predictable tune of “Google Drops the SOAP“, which Google eventually responded to by effectively saying “move on” and former managers for Google’s SOAP APIs came out and explained Why SOAP sucks.
In choosing between web scrapping and using the new Search API, I’ve opted to go for the more advisable Search API approach. The wrapper code for the Google AJAX Search API was done in PHP, using a simple client/server implementation, and referring to an old archive of the SOAP API’s WSDL here:
http://bcmoney-mobiletv.com/widgets/google/GoogleSearch.wsdl (here’s a sample SOAP request)
Read the rest of this entry »
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.