Latest News

    • Web Services Architecture – When to Use SOAP vs REST

      SOAP (Simple Object Access Protocol) and REST (Representation State Transfer) are popular with developers working on system integration based projects. Software architects will design the application from various perspectives and also decides, based on various reasons, which approach to take to expose new API to third party applications. As a software architect, it is good practice to involve your development team lead during system architecture process.   This article, based on my experience, will discuss when to use SOAP or REST web services to expose your API to third party clients.   Web Services Demystified Web services are part of the Services Oriented Architecture. Web services are used as the model for process decomposition and assembly. I have been involved in discussion where there were some misconception between web services and web API.   The W3C defines a Web Service generally as:   A software system designed to support interoperable machine-to-machine interaction over a network.   Web API also known as Server-Side Web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via the web – most commonly by means of an HTTP-based web server. (extracted from Wikipedia)   Based on the above definition, one can insinuate when SOAP should be used instead of REST and vice-versa but it is not as simple as it looks. We can agree that Web Services are not the same as Web API. Accessing an image over the web is not calling a web service but retrieving a web resources using is Universal Resource Identifier. HTML has a well-defined standard approach to serving resources to clients and does not require the use of web service in order to fulfill their request.   Why Use REST over SOAP Developers are passionate people. Let's briefly analyze some of the reasons they mentioned when considering REST over SOAP:   REST is easier than SOAP I'm not sure what developers refer to when they argue that REST is easier than SOAP. Based on my experience, depending on the requirement, developing REST services can quickly become very complex just as any other SOA projects. What is your service abstracting from the client? What is the level of security required? Is your service a long running asynchronous process? And many other requirements will increase the level of complexity. Testability: apparently it easier to test RESTFul web services than their SOAP counter parts. This is only partially true; for simple REST services, developers only have to point their browser to the service endpoints and a result would be returned in the response. But what happens once you need to add the HTTP headers and passing of tokens, parameters validation… This is still testable but chances are you will require a plugin for your browser in order to test those features. If a plugin is required then the ease of testing is exactly the same as using SOAPUI for testing SOAP based services.   RESTFul Web Services serves JSON that is faster to parse than XML This so called "benefit" is related to consuming web services in a browser. RESTFul web services can also serve XML and any MIME type that you desire. This article is not focused on discussing JSON vs XML; and I wouldn't write any separate article on the topic. JSON relates to JavaScript and as JS is very closed to the web, as in providing interaction on the web with HTML and CSS, most developers automatically assumes that it also linked to interacting with RESTFul web services. If you didn't know before, I'm sure that you can guess that RESTFul web services are language agnostic. Regarding the speed in processing the XML markup as opposed to JSON, a performance test conducted by David Lead, Lead Engineer at MarkLogic Inc, find out to be a myth.   REST is built for the Web Well this is true according to Roy Fielding dissertation; after all he is credited with the creation of REST style architecture. REST, unlike SOAP, uses the underlying technology for transport and communication between clients and servers. The architecture style is optimized for the modern web architecture. The web has outgrown is initial requirements and this can be seen through HTML5 and web sockets standardization. The web has become a platform on its own right, maybe WebOS. Some applications will require server-side state saving such as financial applications to e-commerce.   Caching When using REST over HTTP, it will utilize the features available in HTTP such as caching, security in terms of TLS and authentication. Architects know that dynamic resources should not be cached. Let's discuss this with an example; we have a RESTFul web service to serve us some stock quotes when provided with a stock ticker. Stock quotes changes per milliseconds, if we make a request for BARC (Barclays Bank), there is a chance that the quote that we have receive a minute ago would be different in two minutes. This shows that we cannot always use the caching features implemented in the protocol. HTTP Caching be useful in client requests of static content but if the caching feature of HTTP is not enough for your requirements, then you should also evaluate SOAP as you will be building your own cache either way not relying on the protocol.   HTTP Verb Binding HTTP verb binding is supposedly a feature worth discussing when comparing REST vs SOAP. Much of public facing API referred to as RESTFul are more REST-like and do not implement all HTTP verb in the manner they are supposed to. For example; when creating new resources, most developers use POST instead of PUT. Even deleting resources are sent through POST request instead of DELETE.   SOAP also defines a binding to the HTTP protocol. When binding to HTTP, all SOAP requests are sent through POST request.   Security Security is never mentioned when discussing the benefits of REST over SOAP. Two simples security is provided on the HTTP protocol layer such as basic authentication and communication encryption through TLS. SOAP security is well standardized through WS-SECURITY. HTTP is not secured, as seen in the news all the time, therefore web services relying on the protocol needs to implement their own rigorous security. Security goes beyond simple authentication and confidentiality, and also includes authorization and integrity. When it comes to ease of implementation, I believe that SOAP is that at the forefront.   Conclusion This was meant to be a short blog post but it seems we got to passionate about the subject.   I accept that there are many other factors to consider when choosing SOAP vs REST but I will over simplify it here. For machine-to-machine communications such as business processing with BPEL, transaction security and integrity, I suggest using SOAP. SOAP binding to HTTP is possible and XML parsing is not noticeably slower than JSON on the browser. For building public facing API, REST is not the undisputed champion. Consider the actual application requirements and evaluate the benefits. People would say that REST protocol agnostic and work on anything that has URI is beside the point. According to its creator, REST was conceived for the evolution of the web. Most so-called RESTFul web services available on the internet are more truly REST-like as they do not follow the principle of the architectural style. One good thing about working with REST is that application do not need a service contract a la SOAP (WSDL). WADL was never standardized and I do not believe that developers would implement it. I remember looking for Twitter WADL to integrate it.   I will leave you to make your own conclusion. There is so much I can write in a blog post. Feel free to leave any comments to keep the discussion going.

Friday, 13 March 2009

Mobile 2.0 Applications – back to the future

We are now seeing a surge on internet activity from mobile devices such as smart phones and PDAs. Nowadays, people are keeping track of their life on-the-go. Since its release in 2007, the Apple iPhone has set a new standard for accessing the web on mobile devices. Apple had predicted to sale about 10M+ units by end of 2008. In its short life, the iPhone has grabbed a large share of internet users in North America. The figure will change dramatically with the release of competitive devices from other manufacturers.

Chart provided by Net Application.

Anyhow, I am not a business analyst but and this not what this blog entry is all about. But it is important from a developer point of view in adopting a platform, that he understands where his choices lies in the market. The aim of this blog is to understand what tools and technology are available in order to develop products and target a large number of users. I will make some assumptions hopefully in the right places in order to emphasize on a point.

My first assumption is to understand the reason behind browsing the web on mobile devices.

With the recent rise in popularity of social sites such as Facebook, MySpace and Twitter, most of the mobile internet population will be updating their status or communicating with peers on the go. I blogged previously about the profitability of social sites from a business point of view but their market acceptance from a user point is very big. But the rise in population accessing the internet on the devices is also due to network carriers slashing their data plan price.

Ok. So we want to develop a mobile application and want to make available to a large number of users. I will take my own skills set to benchmark the different software development kit.

Here is the basic requirement:

Being an enterprise server-side developer, I decided to develop an application that will be used update users status on multiple social sites at once with just a single click. On top of the string of messages sent, I have a desire to make my mobile geographical location included as part of the message. I shall also be able to check for messages from networks peers to provide into the application tag by their sources and person who sent them.

So I decided to research the mobile market, as done above, to pick the right software development kit (SDK). I decided to review the following:

  • iPhone – the market has a large market share but that's for America, I am based in Europe and would like to primary target to European market. I do not have enough data on the European to start with so it still sounds like a good device to go for.

    The iPhone's applications are developed in Objective-C, this language is not much popular outside of the Apple world and seems to be a barrier in what I want to do with my One-man army of developers. After looking at the available tutorials on the internet, I decided to keep and possibly use it as they have a simple drag and drop IDE. I will probably run into problem when I try to implement more advanced features.


  • Java ME – voila! A language that I am familiar with. First of all, I think it was wrong by the guys from Net Application to include Java ME as MobileOS. The Java ME can run on any devices that support its standard (mobile JVM) and per se is not bound to single device. As far as I know, only Apple has restricted the use of Java ME and similar technologies on their platform. This might be due to the popularity of the technology; developers will drop the Objective-C in favour of Java ME written application. OK so right now, if I chose this technology, my application will not be available to iPhone consumers, OUCH!


  • Android – this is the new entrant of the market but it is poised to become very popular in the near future, grabbing about 6% of the American market within 3 months of introduction. Android is written in JAVA but there's no current support for Java ME. How does that work? I have no idea! Nevertheless, Android is led by the Google guys and promises to offer most of their freely available API straight out of the box, therefore eliminating the need to call remote web services and then parsing the result.


So I still cannot make my mind about which platform to use. But the fact that Android does not support Java Me out the box is not the end of the world as there are freely available software that allows you to run Java ME on Android devices such as MicroEmulator. For this reason, I will now bring the comparison to two groups of devices: iPhone vs Java ME/ Android. As a developer, you want to be able to have good access to the market so let's what is available to facilitate market penetration of our application:

Short term market

  • iPhone - At the time of writing, iPhone had more software download than Android (come-down I know that Android is relatively new). The success of the iPhone is its App Store which allowed developers to write their applications and use the App Store like an Ebay to promote and sell it. iPhone is targeting 500M+ downloads but a large number of those application are actually download for free use with no cost associated with it. So basically your application has to be available for free. Also, Apple vets applications that can be sold through the App Store channels and might reject your application leaving you in the cold. But right now, it is a developer best friend to make money and make a name for him.


  • Android – the Google guys took the idea of the Apple App store and develop their own. But this time, in order to attract a large number of developers, they decide not to vet applications and let the developers make some money and or fame for themselves. There are currently no much available on in their store which will make good for developers' application to be more accessible to consumers.


In the short term, the iPhone, with its App Store, is a more attractive option. But as the number of applications increases, yours will be pushed back to make place for the new and most popular one. What about if you write this "killer-app" that competes with an application provided with the iPhone out the box, Apple would reject it and not make it available through their store in contrast to Android's store.

Long term market

Apple dominance of the mobile application market will come under severe competitions as more handset manufacturers introduce competing devices. Also, people feeling frustrate by apple strict regulation of the App Store will turn to clone sites such as the guys from Cidya Store and network carriers. I suppose, a Java ME store can also be open on the internet to allow greater choice.


Conclusion

This is a blog and I have to make it a short. In conclusion, in the short term, any developers wanting to develop for advanced devices should develop for the iPhone and allow them to sell it through the popular iPhone App Store.

In contrast, the long term prospect of the market will be dominated once more by Java ME as its support by handset manufacturers keeps on growing. I do believe that the Java ME needs an App store maybe which can be a plug-in to Firefox or IE. Java ME phones can already installed application over the air so on-demand installation would not a be a problem.

For now, I am developing on Java ME and iPhone and this pain as I would like my application to work on multiple devices without me needing to change my codes over and over.

Hope this help to give you an idea of the tools and market for mobile devices. Before embarking on commercial mobile project, you are advised to conduct more thorough feasibility studies.

I am not a geek... you are nerd



  • Blogger Comments
  • Facebook Comments

5 comments :

  1. The Forum Nokia Developer Conference will take place on the 2nd of March, 2010 on Australian soil. The Developer Day will be held at the Doltone House by the Jones Bay Wharf in Sydney between 8:30 AM and 5:00 PM. The event is jointly organized by the Australian Interactive Media Industry Association(AIMIA) and Forum Nokia. Registration is free and the event is an excellent opportunity for content providers and mobile application developers.

    ReplyDelete
  2. If it's not too much trouble share more like that. Acupuncture Pen

    ReplyDelete
  3. Nice knowledge gaining article. This post is really the best on this valuable topic. Schmerzmittel bei Rückenschmerzen

    ReplyDelete

Item Reviewed: Mobile 2.0 Applications – back to the future Description: Rating: 5 Reviewed By: Unknown