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.

Sunday, 6 May 2012

Developers should not believe the HTML5 hype

As an Architect and Lead developer, I have to sit down with the non-techie and convince them why I think a technology or framework is the right one for a project and then I build my team to deliver the solution. The past two years or so, the marketing engine of technology companies have been spinning at full throttle. HTML5 is a the future, everything will run in the browser and more blah blah blah.
Don't get me wrong, HTML5 brings some good technologies to the web application developer. Nevertheless, I think there is a lot of hype as HTML5 doesn't really bring anything new to the table.
First of all, there are multiple type of applications that we are all well-aware of;

  • Consumer
  • Business
  • Enterprise

Consumer Application


If you are building a consumer oriented application which doesn't use any of the native functionality of OS, then I would recommend the application to be built in HTML5 and all the RIA fanfare that comes with it. You can best view this in the mobile space where developers build either native or web apps depending on the application requirement. Remember that web application (HTML5 ) do not have direct access to printers, USB port or any other hardware such as Bluetooth and network services. Simple word processing application that can be developed in HTML5 such as Google Doc (where this blog is typed from). I haven't come across any serious application written in HTML5 or the likes yet (JavaFX, Flash and Silverlight are not HTML5).

Business Application

Critical business application such as POS which requires access to barcode scanner as an example can't be written using HTML5. You can have a native application delivered through the browser such as Java Applets ( or JavaFX) using webstart. Java applets can access OS features and hardware and provides another layer of security. Business application are delivered in controlled environments, for example, the application can be deployed on Linux desktop in company "a" environment only. For as much "fanfare" one might create around HTML5, these type of application will not cease to exist.

Enterprise Application


Enterprise applications come in various forms, from desktop to servers. As this is a comparison to HTML5, I will only focus on desktop application. First, let take a financial company such as a stock brokerage firm. There is a reason why stock trading application run as closely to the OS as possible ( and also to the exchange), in one word, PERFORMANCE. Web browsers performance sucks regardless of which one you are using, JavaScript is just too slow to implement some of the logic. In the trading business, a millisecond is all that is required to lose millions of £. Can you for one second imagine building a Bloomberg trading platform using web technologies, that's laughable. There is a reason why the finance industry are still using Java Swing as their desktop technology of choice.

Conclusion

HTML5 is a promising step in the right direction to building scalable robust web application but it will not obliterate desktop applications, not today, not tomorrow, not ever (really!?). We can already see it in the mobile space where developers rather write native application so that they can utilize OS features and hardware. Web applications cannot access you local files directory (I am not talking uploading a file to a site) to read or write.  A simple operation such as reading available space in a directory or writing a log to a local directory is not possible (again I am not talking about downloading or saving a page). Therefore, developers should not believe the hype. HTML5 is not the silver bullet and it is a shame when companies such as Adobe sends mix-messages by discontinuing their Flex offering. Anyway, Adobe has never been a big player in the enterprise desktop application market.

If you disagree with my points, feel free to share your thoughts.

  • Blogger Comments
  • Facebook Comments

30 comments :

  1. Hi thanks for sharing the information.

    ReplyDelete
  2. I understand your POS\Barcode scanner scenario was just an example, but it was an incorrect example. Barcode, Mag Stripe and Proximity readers can all interface as a keyboard with standard ascii input and can be programmed to send carriage returns after reading the card. There are actually standard keyboards with reader slots built in. This would be usable by any computer program including a browser.

    ReplyDelete
  3. Hi, if you talk about business applications - I think in real life you will develop only the UI part in HTML and JS (or Dart) and the business logic (BL) will live on the server side.

    I asume your Application is already separated between UI and BL.
    In the future you have just one more choice for UI-Technology and we all know - UI stuff if much harder to port from one OS to the other then BL. So to me the idea about HTML as universal UI-Language is not a bad one ;-)

    ReplyDelete
  4. Aniruddh Chitre7 May 2012 at 08:09

    I agree with this articles view that HTML 5 is hyped. It certainly has a role in the mobile space but its not the silver bullet. Also I would like to add that HTML 5 standard is still under development and it could undergo some changes.

    ReplyDelete
  5. I'm still looking for someone that can explain me why HTML5 is so 'AWESOME'.

    I agree with you, i also think that there is hype around HTML5.

    It has good things, but every problem needs its own solution.

    ReplyDelete
  6. @Miloskov (DZone commenter), Thanks for your feedback but I still don't believe that at all. Unless the HTML5 can fully implemented and compatible across all browsers ( you can see that right now with the different implementation in browsers), and have full access to hardware then I don't see it replacing all the desktop application such as point of sale. I don't know which barcode scanner you came across lately in you supermarket but they still require the hardware and fallback to a keyboard if the scanner did not work in the first place. So what about trading applications, have you came across any written in the browsers used by brokers. Maybe I should provide more examples but this was based on my experience and the industry I work in. HTML5 will be very useful as a standard and it has its place in developing application but we still need languages like Java and C++. Well I am sure that you know that you can develop iOS and Android application in C++. By the way, I do not need to go back to Java as that is the language I used on the daily basis even to write HTML5 based application (GWT, Vaadin, JSF Primefaces etc...).

    ReplyDelete
  7. Why does everyone insist on creating black and white comparisons between HTML5 and Native/Desktop apps? They can co-exist and each brings their own benefits. OK so you can't do everything using HTML5 - so what? Not all the thing you write need those features anyway.

    Access to barcode scanners and hardware can be easily done using Qt-Webkit or a desktop build of Phonegap - so why can't you use "HTML5" apps for this? I'm not saying you should but being so negative about the situation is wrong. I assume you've not dabbled in these technologies yet?

    I've used "HTML5" technologies extensively throughout my time in the Financial/Enterprise world - both in Desktop and Mobile. Haven't had an issue with performance so far (in fact in one occasion improved on it). Remember deploying a desktop application across a large global organization is next to impossible - in a recent company the cost of deploying an app was in the millions and a year later they only reached 80% of their target deployments. "Native" apps may be better but if people can't use them whats the point?

    The points you've made sound like the chants of old when the web swallowed the desktop market whole. But yes of course there are times when "HTML5" wont be a good fit - fact of life it's not a pancea - it's a technology.

    ReplyDelete
    Replies
    1. So true, every new hype comes in as if it will solve world hunger. But in reality there is no one size fits all solution. Developer need to be really be mindful in picking up the right options for the project.

      Delete
  8. I came across this link yesterday which is right on the topic of not believing all the hype. http://www.paulgraham.com/icad.html

    It talks about pointy haired bosses who know little about technology and the rationale for their choices.

    its mantra is newer is not always better, but it presents another view entirely.

    Good reading for any solution architect.

    ReplyDelete
  9. Cross platform portability... the new mantra...

    ReplyDelete
    Replies
    1. Cross platform indeed...but wait, it doesn't even work the same on browsers running on the same platform (IE, Firefox, Chrome, Opera, Safari etc...) so I guess we have a long way to go.

      Delete
  10. I'm the same way I do my best to remain neutral. It's hard if you communicate with the person the other person dislikes then you fall out of favor with them! I simple can't dislike a person just because someone else does I just can't.http://celabright.com/

    ReplyDelete
  11. It is very rare these days to find blogs that provide information someone is looking for. I am glad to see that your blog share valued information that can help to many readers. Thanks and keep writing! http://celabrightreviews.com/

    ReplyDelete
  12. I must also sometimes make such a perfectly website with such good information. I hope your website will still survive for very long. They are wonderful! Thank you!

    For more info click here http://www.scarprin.com/

    ReplyDelete
  13. Youre so cool! I dont think Ive read anything like this before. So good to find somebody with some original thoughts on this subject. Thanks for starting this up. This blog is something that is needed on the web someone with a little originality. Good job for bringing something new to the internet!
    round dining tables for 4

    ReplyDelete
  14. I have to say i am very impressed with the way you efficiently blog and your posts are so informative. You have really have managed to catch the attention of many it seems keep it up!
    Canton Fitness

    ReplyDelete
  15. I think I will become a great follower.Just want to say your article is striking. The clarity in your post is simply striking and i can take for granted you are an expert on this subject.
    Car Buying Tips

    ReplyDelete
  16. The post was able to express what it wants to convey to the readers. It has been a very effective approach which resulted to a profitable output for all who have been fortunate enough to come across it!
    tutoring online

    ReplyDelete
  17. I have seen fantastic blogs and I have seen not so fantastic blogs. This blog is very informative in many ways and certainloy ranks in the former category. Really appreciate the information your providing use avid readers!
    beach decals

    ReplyDelete
  18. I'm happy I found this blog! From time to time students want to cognitive the keys of productive literary essays composing. Your first-class knowledge about this good post can become a proper basis for such people. Thanks.
    detective agency

    ReplyDelete
  19. Im glad to have found this post as its such an interesting one! I am always on the lookout for quality posts and articles so i suppose im lucky to have found this! I hope you will be adding more in the future...
    mailing list

    ReplyDelete
  20. Nice blog from the admin. I appreciate this fantastic work. It tells us the HTML coding and it main theme is about Developers should not believe the HTML5 hype. So thank you admin for your interesting work...
    Web Development

    ReplyDelete
  21. Better Forex brokers
    You don’t have to lose your money anymore. Choose a forex broker that is easy going with. Get better now with forex trading.
    forex trading

    ReplyDelete
  22. You can use signals and robots and binary option trading
    but i can tell you that before you can use any strategy you have to understand yourself first, how is your mind work, without it you will continue the up and down profit/loss, feeling pressure/calm.Visite
    click here http://www.automatedbinaryoptions.co/?p=178

    ReplyDelete
  23. HTML5 bought drastic change in Web Application Development.Here, you have shared informative post on it.

    Digital Marketing

    ReplyDelete
  24. I found lots of interesting information here. The post was professionally written and I feel like the author has extensive knowledge in this subject.

    ReplyDelete
  25. It is very impressive for useful information on this blog, making use of the large amount of information is visible in this blog. I’m so proud of you. Great job! Thank.

    ReplyDelete
  26. You made some good points .I did a little research on the topic and found that most people agree with your blog.

    ReplyDelete
  27. In my opinion,HTML5 isn’t overhyped anymore.
    HTML5 looks to be the overwhelming favorite development platform of choice for mobile developers, according to a new study by Kendo UI, which makes an HTML5 toolkit for mobile web development. Already, 50 percent of developers have developed in HTML5, and 90 percent plan to use the technology in 2013.
    Only 15 percent of developers would go native-only when building an app for multiple platforms, a stat that might be a little shocking to those witnessed Facebook famously and loudly abandoning HTML5 development last year in favor of a faster, smoother, better native app experience.
    In fact, the new Facebook app includes a lot of HTML5, Anglin said, adding that Facebook has said that HTML5 makes it faster to develop and maintain multiple apps.




    Labels: Developer iPhone Barcode HTML5 Application

    ReplyDelete

Item Reviewed: Developers should not believe the HTML5 hype Description: Rating: 5 Reviewed By: Unknown