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, 1 November 2009

ReST Web Services on Google App Engine using NetBeans 6.7

When Google announced early this year the availability of the Java language on their cloud system “App Engine”, this was turning point for Java on the web. The reason I am saying that is due to a simple questions; how many hosting providers support Java? And providing free hosting for that purpose... This was a good move in the direction of the JAVA community and the vast list of all the languages that run on the JVM.  But App Engine does not support the full range of the J2EE API. If you are looking to build any EJB, SOAP services or anything that access the file system, then the App Engine is not for you as it does not support it. To make matter worst, some URL connections are not supported by the Google cloud services. I am looking forward to the day when JBoss Seam will be supported entirely by their services without having to hack the code. Alright, it is not that bad; Google App engine supports a number of Java EE frameworks such as Spring.

Alright people, this was a long introduction but I believe it is worth it. You cannot create web services such as SOAP in the Google App Engine therefore, in this short article, I will show you how to develop a ReST based web services that works with the App Engine using NetBeans and Jersey API. Actually, NetBeans comes with Jersey support out the box. Now, let’s get started.
In order to follow the instructions, you will need the following:

NetBeans 6.7+

Google App Engine SDK

Google App Engine Plugin for NetBeans

I would expect you to know to be familiar with JAVA EE development and Google App Engine development. Once you have all the software and components installed, now we can start.

1.    Create a database structure to store your data. I used MySQL Workbench to design my DB structure (Google App Engine does not used MySQL and does not have plan to support it in the future). This schema is to help you understand the relationship between your entities. You can use any UML tools to design your objects’ relationship. There is a reason I chose to design DB in MySQL, the application generates SQL script which I will upload to MySQL DB. I will show you in the next step the main benefits.
 

2.    Based on your DB schema, create a database. You can use any database you want. I used MySQL to initially store my entities.


3.    Launch your NetBeans application and create new Web Application.
 

3.1    Choose Google App Engine as deployment server, click here to see how to register the App Engine in NetBeans.



4.    Now click on: File -> New File. In the popup window, choose Web Services in the Categories panel and RESTFul Web Services from Database and click next.
 

5.    Choose your the database that you want to generate your Entity classes from and click next. ( in the screenshot I am using the sample DB which came with the NetBeans and JAVA DB server. This is just for illustration purposes only as I have previously generated my Entity Classes from the DB schema I generated in step 1).


6.    Check your Class Names and how they relate to the database. Make any changes that you require in this screen, and then click next.
 

7.    In the next screen, just accept the default values and click finish.
 


Well we have done the hard parts. There is another step that missed out due to the fact that I already written the application. When generating Entities from Database, if you do not have a persistence unit available, it will ask to generate one. Here is more information on how to create a persistence unit with NetBeans. Make sure to make sure to choose “Create” as the table generation strategy.
 


By Now, you should be aware that we have create a back-end application store which we can call using normal http post, get, delete and create. NetBeans RestFull methods allows to use XML or JSON to send data to the services. The responses MIME can be anything you like as long as the application server supports it.
WARNING: JERSEY XML processing is not supported by Google App Engine as it uses JAXB. JAXB accesses API which is forbidden by the App Engine stack. If testing the application on the App engine, use the JSON MIME for your data.
Ok so we have generate the classes and methods require to expose our back-end to other application. As it is, this will not work on Google App Engine so we need to make a final change, this time we need to change the persistence.xml file manually. In the project window under the name of your project, click on Configuration files -> persistence.xml and open the file in the editor. Once the file is open in the editor, click on the XML tab and make the necessary changes to make it look like the screenshot.
 

Here is the content of persistence.xml; modify to reflect your entities and make sure the name of the provider is the same as mine and the properties are exactly the same.

    <?xml version="1.0" encoding="UTF-8"?>
    <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
        <persistence-unit name="ReSTWebApplicationPU" transaction-type="RESOURCE_LOCAL">
            <provider>org.datanucleus.store.appengine.jpa.DatastorePersistenceProvider</provider>
            <class>com.test.api.Userlogs</class>
            <class>com.test.api.Customer</class>
            <class>com.test.api.User</class>
            <class>com.test.api.Business</class>
            <class>com.test.api.Reviews</class>
            <exclude-unlisted-classes>false</exclude-unlisted-classes>
            <properties>
                <property name="datanucleus.NontransactionalRead" value="true"/>
                <property name="datanucleus.NontransactionalWrite" value="true"/>
                <property name="datanucleus.ConnectionURL" value="appengine"/>
            </properties>
        </persistence-unit>
    </persistence>


Now we are ready to run the application and test it in our local environment. Right click your project name in the projects window and click Test RestFul web services, your favourite web browser with page that shows your resources. You can test your services by clicking on the nodes and or drilling through the nodes.
 

You can also use the Firefox RESTClient Plugin to test your app. Also, Google App Engine does not fully support JPA and might throw some exception about not supporting “integer type object for primary key”. If you do experience this issue, change the type of your key.
This is it for now, looking forward to your feedback, good or bad, they are all welcome. Also, if you need JAVA EE help, contact me directly. Also join me on facebook. Hope the guide or tutorial or whatever you call it, was good enough to help you with something.

Please support my blog and its advertisers by clicking on the interesting products/ services on the right (Google ads).  Cheers.





  • Blogger Comments
  • Facebook Comments

22 comments :

  1. Very, very interesting...thanks much for laying this out.

    ReplyDelete
  2. thnax for the comments guys.

    ReplyDelete
  3. nice blog.

    But in google apps engine , we can go for many-many relations generated from the netbeans from tables

    ReplyDelete
  4. it's a valid try , but im getting follwoing exception:

    [java] java.lang.NoClassDefFoundError: javax.naming.InitialContext is a restricted class. Please see the Google App Engine developer's guide for more details.
    [java] at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:51)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.getContext(ServletContainer.java:654)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.validate(ServletContainer.java:629)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:621)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.load(ServletContainer.java:538)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:197)
    [java] at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:433)
    [java] at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:256)
    [java] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
    [java] at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:612)
    [java] at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
    [java] at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218)
    [java] at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500)
    [java] at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
    [java] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
    [java] at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
    [java] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
    [java] at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
    [java] at org.mortbay.jetty.Server.doStart(Server.java:217)
    [java] at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
    [java] at com.google.appengine.tools.development.JettyContainerService.startContainer(JettyContainerService.java:188)
    [java] at com.google.appengine.tools.development.AbstractContainerService.startup(AbstractContainerService.java:120)
    [java] at com.google.appengine.tools.development.DevAppServerImpl.start(DevAppServerImpl.java:217)
    [java] at com.google.appengine.tools.development.DevAppServerMain$StartAction.apply(DevAppServerMain.java:162)
    [java] at com.google.appengine.tools.util.Parser$ParseResult.applyArgs(Parser.java:48)
    [java] at com.google.appengine.tools.development.DevAppServerMain.(DevAppServerMain.java:113)
    [java] at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:89)
    [java] Feb 13, 2010 8:21:03 PM com.google.apphosting.utils.jetty.JettyLogger warn
    [java] WARNING: failed com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@1bc82e7{/,C:\Users\raghu\Documents\NetBeansProjects\WebApplication1\build\web}
    [java] java.lang.NoClassDefFoundError: javax.naming.InitialContext is a restricted class. Please see the Google App Engine developer's guide for more details.
    [java] at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:51)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.getContext(ServletContainer.java:654)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.validate(ServletContainer.java:629)
    [java] at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:621)

    ReplyDelete
  5. please give some sample project with lib list. it would help ..

    tx

    ReplyDelete
  6. @Raghunath

    I did not get that error and Jersey is compatible with Google App Engine. Can you describe your problem in more details.

    ReplyDelete
  7. @Raghunath

    Have you tried the samples with App Engine SDK 1.2.5 as it has been reported that App Engine SDK 1.3.0 seems to report some errors.

    ReplyDelete
  8. @Raghunath

    The problem is that GAE doesn't support EJB and Jersey gets barred while trying to look up JNDI via javax.naming.InitialContext..

    A solution for this is found here:
    http://lqd.hybird.org/journal/?p=123

    The above works on Jersey 1.0, for some reason fails on 1.1..

    ReplyDelete

  9. I feel satisfied to read your blog, you have been delivering a useful & unique information to our vision even you have explained the concept as deep clean without having any uncertainty, keep blogging. Google cloud Online course

    ReplyDelete
  10. Excellent Blog! I would like to thank for the efforts you have made in writing this post. I am hoping the same best work from you in the future as well. I wanted to thank you for this website! Thanks for sharing. Web Services!

    ReplyDelete

Item Reviewed: ReST Web Services on Google App Engine using NetBeans 6.7 Description: Rating: 5 Reviewed By: Unknown