MobileFirst, API's, and PaaS - Field Perspective
So for my first post, I wanted to introduce myself. My name is Roland Barcia, but a lot of people call me Roly. I work for IBM Software Services for WebSphere . I am a Senior Technical Staff Member (STSM) and Lead Web 2.0 Architect for my group. My focus is to help customers apply Web 2.0 concepts using our SWG, specifically in the WebSphere Brand. I specialize in various platforms, including the new Project Zero Platform, The Web 2.0 Feature Pack for WebSphere , the EJB 3 Feature Pack, and other areas such as WebSphere MQ or DataPower in the context of Web 2.0.
I am going to post on Web 2.0 topics related to middleware, specifically building services around REST, data access in a web 2.0 context, Ajax Patterns, and anything else related to Web 2.0 that may apply. I will talk about technologies like Project Zero and the Dojo Toolkit, and comment generally on what I see people doing in the Web 2.0 space, and try to be as objective as possible.
My latest entries can also be seen on the new Developer Works Project Zero Space.
I hope you enjoy my blog!
In working with many Worklight clients, the question around direct REST Service calls vs. Worklight Adapters comes up often. REST services began its life as consumable services that can be invoked by Rich Internet Applications using an Ajax pattern. With Mobile, REST comes more to the forefront. In a previous blog, I discussed how Web API's should be designed around a User Model. Because we are in the age of omni-channel and multi-channel architectures, web API's are becoming more and more multipurpose. Once an API evolves into the public API realm, it becomes difficult to optimize for different clients. Even for API's behind the firewall, once an API evolves to support multiple clients, it takes a life cycle of its own. As such API providers maintain one life cycle, while consumer apps, maintain another. Once consumers have a different purpose and life cycle than API providers, client apps need to be able to evolve screens and use cases based on end users. App Store comments can bring a great speed of change to a UI, and a multipurpose Web API cannot respond to tons of clients for risk of breaking another clients. Therefore, the client applications need a place to write code to perhaps change API JSON data to UI specific JSON. They may also need to make multiple API calls to create the desired UI Model. Client applications can write client side code on a device to handle changes, however, this can cause lots of unwanted side affects. They can consume too much data, create extra network calls, and expose security characteristics. Therefore, there is a case for a piece of serverside code that is owned by API consumers. The code is meant to handle data transformation specific for their application without having to do this on the device. This is the role of a Worklight Adapter, it is a piece of serverside code that is owned by API consumers. It is not a technology for the creation of API's to a vast array of consumers. It can be a piece of logic shared by a set of consumers that is owned by the same application team, but it is specific to the consumer's life cycle. The figure below shows an example:
Having a Worklight Adapter tier has many advantages:
• Decouple development Life cycle of API provider and consumer.
- Mobile applications can evolve independent of API provider to incorporate quick changes to User Feedback
- API Provider life cycle bound to many consumers, moves slower.
- Change of API model for does not force consumers to re-download app.
• Security Enforcement point for MDM Secured Service. Allow for scenarios of private API bound to controlled client devices. (Cannot invoke from non managed client). This is particularly important for Employee facing applications.
• Aggregation of services for optimal network calls.
• Filtering of Data for smaller payload over mobile networks.
• Consumer owned Data Model specific to UI application, less transformation on the mobile device.
• Syncing with offline Storage database on client.
• Built in Analytics, location services, security framework, JSON transformation, and out of the box integrations.
• A place to Cache Data.
In a BlueMix model, you can use something like a CloudCode Service to provide this, but of course you pay for services you use using a cloud model. You can use API management technology or create specific REST Services for specific clients, but that puts the consumer mobile app team and the API provider team under shared infrastructure, dependent schedules and so forth.
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.
After 2 years, I have decided to start blogging again. I have no reason for this new motivation to write. The New focus of the Blog will be centered around Mobile, API's, and Platform as a Service.
When starting development for a Modern Web or Mobile Application, one key aspect to address is how to generate JSON from backend data sources. For many, JSON is just a view or format of back end data. For simple applications with one database, dedicated to that single application, exposing back end artifacts may be simple. However, things have evolved and the world is now speaking APIs. It is no longer as simple as saying expose data as JSON.
Enterprise back ends have grown more complex. The larger the enterprise, the better the possibility that you have to fetch data from a shared back end. This leads developers to develop an application Domain Model that represents the business view of the application. When an application will have to access multiple back ends then a Domain Model typically referred to as a Canonical Data Model, which represents the data model for an enterprise and maintains relationships to different back end systems.
The issue is that exposing your canonical or domain data directly as JSON will make it difficult for front-end developers and API consumers. Back end domains tend to be very rich and contain many details and relationships that may not be needed by end users. Therefore, when building enterprise systems, taking your back end data and exposing it can lead to very poor Web APIs.
You see, when building Modern Applications, your REST APIs can end up becoming the foundations for public Web APIs. REST design for these systems should be focused around creating a specific data model for the Consumer that we like to call the User Model. This is the view of the data that is meaningful to the end user. This model does not have to be bound to a single web view, but can be shared across all devices and browsers where the user accesses the data.
The foundation of Web API's is the Consumer's Data Model, and when designing Web API's, you must design the data around "How the user see's the data." What is a Bank User's view of his account, how does an insurance customer see his or her policy? You should be able to define your API's as a headless business.
User Models are usually flatter and channel constraint. Besides understandable data, it may also be aware of through what channel a user views the data. Implementations may account for things like slower mobile networks through paging. Both the structure and data tend to be updated more frequently through interactive conditions. They form the foundation of data for "systems of engagement." By contrast, Canonical data models are usually rich data models, with rich relationships. They tend to be the main record of the provider and are driven by key transactions. They are the data models for systems of record.
API's should then be designed around the consumer's view of the data. The initial design for the data can come out initial designs for a particular UI, and should evolve from there as users use different channels to access that data. A user flow using different channels may modify the data. For example, I might start a claim at the sight of an accident with my mobile phone. I might later complete the data entry behind a laptop. I might check the status on my tablet. An API's central source of design is the User's viiew of the world.
End user's do not always understand their requirements in the beginning. User needs change over time sometimes. As you are building new apps, you may need to put yourself in the user's shoes and imagine where they need to go. Therefore, API design should facilitate building the Minimum Viable Product (https://mushi387.wordpress.com/tag/build-measure-learn/). Meaning the consumer model might initially start small and grow over time as Agile methods add more requirements. That is why dynamic formats like JSON are more appealing.