MobileFirst, API's, and PaaS - Field Perspective
rbarcia 1000005FXD 1,337 Visits
rbarcia 1000005FXD 1,538 Visits
Having a Mobile Testing Process
Read this over in the IBM Mobile Tech Preview Group Blog.
Why do we do this to ourselves. As my friend Keys said, we go through endless cycles as an industry solving the same problems again and again. Technology X is too complex, create technology Y cause it is much simpler. Then technology Y lacks features, so lets add it. Now technology Y is too complex, let's create technology Z, and so forth. I have gone through distributed technologies like ONC RPC, COM, CORBA, EJB, Web Services, SCA. I am a fan of REST, because it exploited existing HTTP infrastructure.
So, why the rant, cause I see people doing exactly what destroys simple technologies. Most recent is this link TX support for JAXRS and REST and transactions. Adding transactional support for JAXRS? Why would I want distributed transactions for REST. Really, don't we learn anything in this industry. Why on earth would we want to propagate transactions over REST? We already did that with SOAP? Or why would I want to expose a Tx API over multiple HTTP calls? Leaving Tx's open across multiple HTTP calls has already proven to be a bad practice? REST is stateless, and therefore makes middleware scalable.
A Business process or facade itself can be a resource (/MyBusinessProcess), but the implementation of that service can use regular Tx API's and hide those details.
REST is about "Exploitation." Web Services and SCA is about "Abstraction" Let's put a stake in the ground and use the right technologies for the job rather than destroy something as beautiful as REST.[Read More]
In my previous blog, I talked about how API's should be modeled from a Consumer Centric Approach. From an On Premise perspective, a typical logical architecture for supporting this type of deployment is shown in the figure below. A typical application architecture contains an Application Server hosting the interaction services, usually implemented as a set of REST services or Worklight Adapters. Typically, even in a Single Page Architecture, your application server does some type of session management, caching or storing of User Data, and Integration to the back end either by accessing the data or through an ESB or BPM engine. Because this tier was an entry point into your infrastructure from the Internet, it required a large amount of work to scale, maintain, upgrade, and so forth.
This week IBM announced the Open Beta for BlueMix. A Platform as a Service platform for building out next generation solutions out in the cloud. This includes tools for building web apps, mobile apps, and so forth.
Many Enterprises still will want to maintain their back ends and System of Records "On Premise." It is difficult to move generations of host systems out to the cloud. In addition, there are many security reasons why enterprises wish to hold their data "On Premise." However, the security maturity of Cloud Providers, like Softlayer, As such, the emergence of a Hybrid Cloud Architecture is emerging.
The REST/API tier that typically runs on-premise is now built in the cloud. You can built services using technology to meet the interactions patterns, weather it be push services through mobile networks, asynchronous IO with WebSockets and Node.JS, or application logic with Java. From an On-Premise perspective, exposing API's and API Management becomes a key capability as providing Data Services from the Enterprise will be the new name of the game.
rbarcia 1000005FXD 1,552 Visits
Sorry for not blogging for a while. I have been quite busy getting some REST. :-)
I have just published 2 new articles:
Implementing and testing server-driven content negotiation for your REST resources with WebSphere sMash
Scaling WebSphere sMash Web 2.0 applications: Part 1: Overview of WebSphere sMash topologies
But I have been spending a lot of time helping some of my customers with REST Architecture. I figured I would post some here. I will give some bullet points and will be publishing papers soon. Note, these are not in any order of importance. All are important. Note, I am just putting pointers in rough format here, and I will publish some more articles on the topics later.
1.) Understand REST. Here are the top 2 misconceptions about REST:
a.) REST is just any XML over HTTP not using SOAP? NO !!! REST is a Pattern of exchanging Resources. RPC is Not REST
b.) REST is only useful for CRUD(Create, Read,Update, and Delete) semantics.NO!!! Resources can be anything, from a Business Process to an Image.
RESTful Principals Include:
* Identifiable resources (URIs)http://sports.espn.go.com/oly/summer08/swimming/news/story?id=3530615
* Uniform InterfaceGET, PUT, POST, DELETE
* Stateless CommunicationScalable, loose coupling
* Resource RepresentationsMultiple ways to represent (PDF, HMTL, XML,) - via content typesHTTP has negotiation capabilities (e.g. ACCEPT)
* HypermediaServer provides links to resourcesAllows for evolution
2.) Define a strategy for defining resource/services:
* What are the resource identifiers?* Is there a hierarchy of resources?E.g. a list of employees may be one resource, each employee is another /employees vs. /employee/empid1* What HTTP Request/Response Headers SupportedAccept, Content-Type, Range, etc….What is the representation of the data exchanged?JSON? XML? PDF?
* What are the methods supported at each resource?Do you support POST, GET, PUT, DELETE?
* What are the status codes returned?HTTP defines standard return codes200 = ok301 = moved permanently400 = bad request , 401 = unauthorized , 404 = not found
3.) Categorize Resource types:
Example: * Simple Resource Types (".../
4.) Maintain Mutability of Verbs
* GET / HEAD (No Side Affects)* POST/PUT/DELETE (Assumed Side Affects)* Middleware State (No-no, State Transfer)* Atomic Operations - RESTful Resources should start and end DB Transactions.
5.) Implement Optimistic Concurrency
* Optimistic concurrency via E-Tags, Timestamps
* Check-in/Check-out semantics if stricter policy is needed, but never hold database locks
6.) Define a Consistent Query Syntax in your organization
REST defines no standards on query parameter names. For example, you may choose to provide standard params for filtering, Sorting, and Ranges.
/resource?filter="name startsWith b && age gt 30"
7.) Implement Filtering, Sorting, and Ranges for Data Sets
Even if you start out small, if your data grows, need to provide these.
8.) Linking over Relationships
Prefer Linking over tightly coupled data. Use ATOM as a payload for establishing relationships
9.) But, sometimes I have relationships....
Sometimes you need to do bulk loading of related data. Some Techniques:
* Special parameter/Order?loadRelated=LineItemsVery quickly starts becoming RPC
* Headers and Schemas (Better)Accept: application/eager+atom+xmlAccept: application/atom+xml
10.) Think about API Versioning from the start:
* Follow a Close Spec (slow moving)/Open Extension (Popular Extensions become the next wave of standards) Closed/Open* How do I represent Versions? a.) Use URI? /v/3/myResource (better for Bookmarking, expressive)
b.) Use Header (Cleaner looking)Accept: application/myVer+atom+xml Custom Header
11.) Lock Down your URI's and Implement Instance Based Security
With REST, I can easily secure URI's, but make sure to implement Instance Based security for User sensitive Data. If I log in successfully as /account/roland, I have to protect against /account/mike.
The service provider should make sure to access the identity from the Subject or Context and compare to the URI requested.
12.) READ THE HTTP SPECS and stick to themHTTP HeadersHTTP Response Codes
Do not add semantics to headers that are not meant. Routers and firewalls make use of many headers in strange and curious ways.
13.) Implement Content Negotiation
14.) Sometimes you need to Relax.Use cases emerge that may not fit naturally.
Partial UpdatesBatch Updates
Query params (Be careful, could become RPC Very Fast)
The HTTP Spec is looking at a new verb called PATCH
15.)Documentation As a Service.
Atom can be a great way to document since you can link to the service URI Patterns.
What should REST Documentation have?
Documentation as a Service/resource/formatsCatalog, Registry What are my URI PatternsWhat Headers do I support?What Verbs are valid for my resource?What Response codes do I support?What do they mean for my service?What formats do I support? (JSON, and ATOM)Which header do I use? Accept, query param?What schema describe it?
16.) Write your Unit Tests first using something like HttpUnit.
I demonstrate this here.
I am recovering from a very busy IBM Impact. It was great to meet with so many customers. By far, Mobile was the topic that I spoke the most about. One area of discussion is how web design is fundamentally different than mobile. Designing modern web 2.0 applications is like designing a mall directory. You show all the possible places and how to get there. Some shoppers go to the directory and plan out their shopping. They find the one or twenty stores they need and look for the directions. However, mobile is about having to run into the mall and be done in 5 minutes. You need to go right to the 1 store you are going to visit without looking at the mall directory as quickly as possible. The mobile web app is like having a personal guide who needs to know when you walk in and show exactly where you want to go.
Today I went out to eat with my wife and kids somewhere about an hour away from my home town. I did not know the area. She asked me to find the closest of a particular department store. I went to their mobile site and tried to use the "Locate Store" Feature on their mobile site. It asked me for an address. Of course I did not know where I was to begin with, so I did not have an address. Their Mobile Application failed them (not me, I did not want to go to the store, my wife did) because they missed the moment to guide me to their store. In turn we ended up driving home instead. We also have no plans to buy the item we needed cause something else came up. Their Mobile Website was designed like a normal website. An address locator makes sense behind my home computer, but not while I was trying to find you on my Blackberry Torch. That store lost revenue today.
A Mobile Web page of a store with locations should have a button that says: "Find Store Near You." Upon clicking, it should return a list of stores (5 max). I can touch the first store and it should use the Geolocation API to give me accurate directions. It can also integrate with my GPS application or integrate with a web based navigation system to provide my navigation.
Mobile applications need to know the road most traveled. It needs to provide me with the fastest route to the 1 item I am going to do. It needs to know where and sometimes when I am going to do it. It is the context of the phone use. That is the key word. If you miss the moment, then you lose. People will pass it up and not use your app.
I wrote a Blog Entry over in the Web 2.0 and Mobile Group Blog about using dojox.socket, Servlet 3.0, and EJB 3.1 Timers together: https://www.ibm.com/developerworks/mydeveloperworks/blogs/94e7fded-7162-445e-8ceb-97a2140866a9/entry/notifications_with_dojox_socket_servlet_3_0_async_and_ejb_3_1_timers20?lang=en
Many have commented on Oracle buying BEA out there in the blogging community. One thing I am very interested in seeing is which persistence mechanism is supported if they choose one. Most likely, we will see Oracle pushing BEA's App Server. TopLink has had a long history as a persistence provider and supports JPA. But BEA's App Server is based on OpenJPA (more specifically the Kodo product they purchased from SolarMetric.) IBM also built its JPA provider(available via the EJB 3 Feature Pack for WebSphere) on top of OpenJPA. It should be interesting to see which way Oracle/BEA goes with in persistence.
I recently released a tutorial on using the EJB 3 FP for WebSphere.[Read More]
rbarcia 1000005FXD 1,188 Visits
I have just finished 5 straight weeks of conferences starting with IBM Impact and finishing last week at the WebSphere Services Technical Conference which is an internal conference. I am glad it finished. Last week, my book, Persistence in the Enterprise was released.
Besides myself, my coauthors are Geoff Hambrick, Kyle Brown, Robert Peterson, and Kulvir Bhogal. The book focuses on the persistence layer of an application. The first half of the book is primarily focused on things like requirements (persistence focused), design, best practices, and criteria for selecting a persistence layer. The second half of the book focuses on implementing those using 5 different technologies: JDBC, IBatis, Hibernate, OpenJPA, and pureQuery.[Read More]
Milestone 3 of Project Zero has been released. As posted on the Project Zero Developer's Blog, some major highlight's include:
I will be presenting at AjaxWorld in NYC, in the month of March, about Project Zero.
Also, I recently released an article that shows you how to use the EJB 3 Feature Pack for WebSphere.[Read More]