by Laurence Melloul
Friday, October 12, 2012
RESTful Data Services for a Clean Integrated Data Landscape
Data services are services that expose data entities through CRUD-style operations (Create, Read, Update, Delete). Accessing and integrating data in an organization can be complex depending on the scale of the organization and the legacy of the applications.The REST architecture style has two constraints in particular that make it compelling for accessing and integrating data services:
- URLs are global identifiers that are used to identify resources, i.e., the data entities exposed trough data services
- URLs can also be used as links (pointers) to related resources, i.e. to identify composed/nested resources.
Therefore instead of copying by value one entity into another across data domains, one may maintain the IDs of related entities and follow the hypermedia links at runtime to navigate across entities.
The set of resources and links across entities reflect a nicely distributed data model across the resource scope. Netflix's movie and people catalog is a great example.
Such RESTful data service integration model may be applied across domains within organizations as well as across organizations.
Categories: REST, SOA
Monday, July 23, 2012
RESTful Objects vs Functional and Data Service Interfaces
The RESTful Objects specification just came out last month, describing a uniform interface to object's data (properties and collections) and methods (actions), both presented as RESTful resources.Modeling objects as services may not provide a robust solution:
- Objects have shared state (data members), which breaks the service model. Restricting the nature of RESTful objects to be with no shared state through a contract-first approach is limiting and may be breaking.
- Mixing nouns and verbs, e.g., /mybookservice/actions/lastorder/invoke breaks the resource model. In addition, specifying qualifyiers of the resources such as actions, properties, etc. as part of the URL is not quite RESTful.
In contrast, the service model has pushed forward a clean separation of concerns between functional services (which capture business logic) and data services (which capture CRUD operations on the underlying resources).
Hence a good compromise to capture both operations and data under the same semantics umbrella is to define two interfaces as part of the same service, one for data and one for business logic.
Categories: REST, SOA
Thursday, June 28, 2012
Think Service Degradation to Design For failure and Manage Your QoS
To design for failure and be robust against cascade of failures across services, including in a Cloud environment, a service must plan for the lack of or invalid responses from other services it interacts with.A key solution to this problem is service degradation. There is a great article from Netflix on how to plan for degradation of services (Graceful Degradation section) using alternative response data representations. For instance one may use the static list of most popular movies in case the personal recommendation service fails. This article was subsequent to the Amazon EBS failure in April 2011.
This notion of degradation may be extended to "backup services." For each key service in your application landscape, plan to failover to a backup service that will provide lower quality data or have more latency, for instance. You will hence be able to trade-off quality or latency for availability when appropriate. You may also check ezQoS to help you do so.
Categories: Cloud, DFF, QoS, SOA
Thursday, June 14, 2012
SOA vs DFF
From a reliability perspective, SOA helps with isolating failures across components which are not communicating with each other (thanks to loose coupling, a failure of one service may not cascade to other services that do not have pending requests to it).To go one step further and be robust against cascade of failures among services that interact with each others, a service must plan for the lack of or invalid responses from other services. This is Design For Failure (DFF).
Categories: DFF, SOA
Thursday, May 31, 2012
SOA and EDA
Service-Oriented Architecture and Event-Driven Architecture are not exclusive. They may be combined as follows:
- Services may emit events
- Events may be consumed by other services which perform some action upon such events
- These services may in turn emit events
- And so on and so forth.
Categories: SOA, EDA
OData and SQL
OData is a query language that may be used on top of REST services. Here is a basic mapping of the OData syntax with SQL notation:$select ~ select
url ~ from table
$expand ~ joins
$filter ~ where
Categories: REST
Friday, May 25, 2012
SOA, Cloud and Legos - or Design for SOA to Design for the Cloud
Think of SOA as putting together independent building blocks as lego bricks, with matching provided and consumed interfaces. Think of the Cloud as some of these lego bricks having strings attached to the core app and being pulled to other environment. To design for the Cloud, design for SOA and separate deployment decisions from design. Deployment configurations may be pre-defined or on demand.Categories: Cloud, SOA
Thursday, May 24, 2012
SOA and PubSub
People have the tendency to associate SOA with Request-Response and think it is exclusif of Publish-Subscribe. SOA is an architecture style and PubSub is a communication pattern. Hence they may well coexist.However there is a semantics break when using PubSub compared to the more traditional use of Request-Reply in SOA. With Request-Reply, the consumer of the functionality or information provided by a service is also the client (caller) of the relevant service's operation. In PubSub, the consumer of the functionality/information behaves as a client when it subscribes to the provider but becomes a service itself when it consumes the information/functionality. This is because it is being called to be notified. And vice-versa for the functionality/information provider.
Categories: SOA, EDA
REST and Service Interfaces
Some believe that RESTful services may not have an associated interface definition as one would have with Web Services, e.g., through a WSDL. This is not true. A RESTful service also has operations and types. Typically when implemented over HTTP the RESTful service's operations are the HTTP verbs with CRUD semantics associated to them: Create for POST, Read for GET, Update for PUT and Delete for DELETE. Operation types may also be defined through a schema such as an XSD.There is a direct mapping between a RESTful service operation call and an object-oriented function call, for instance between
GET url?parameters -> response and response = url.GET(patameters).
Strong typing may hence also be enforced by the used language.
Categories: REST, SOA