Web Services based architectures have already been established as the preferred way to integrate SOA specific components, from the front-end to the back-end business services. One of the key elements of such architecture are data-based or entity services. In this context, SDO standard and SDO related technologies have been confirmed as a possible approach to aggregate such enterprise-wide federation of data services, mainly backed by database servers, but not limited to them. In the followings, we will discuss an architectural purpose based on SDO approach to seamlessly integrate presentation and data services within an enterprise SOA context. This way we will outline the benefits of a common end-to-end data integration strategy. Also, we will try to argue that using HTML5 based clients as front end services in conjunction with SDO data services could be an effective strategy to adopt the mobile computing in the enterprise context.Keywords: SDO-Service Data Objects, Data Access Services, HTML5, Web Services, Cloud Computing, SQL, Data Integration, Mobile Computing1 Introduction: Data Architectures and Enterprise Mobile ComputingAlthough Service Oriented Architecture (SOA) have became a well established and widely acknowledged computing paradigm, its proliferation into the enterprise environment still struggles to resolve some crucial issues as heterogeneous data source integration. In fact, an entire class of SOA services is responsible with the data level and most often these are known as entity services. Their most obvious function is to abstract and then to integrate different data source providers (mostly database servers) across the enterprise, often very distinctive in their internal nature [1:293-323],As such, the Enterprise Data Source Integration [2] process ultimately assumes some kind of global and centralized data model, but in a decoupled, transparent and technologically independent manner. This process could be regarded as a Federative Data Integration strategy that assumes two aspects:* schema integration/denomination: the data services will use a common metadata layer to describe composite data structures, integrity rules and quality rules, that will hide the schema complexities and manage the changes of the data structures in evolution;* actual data integration: the data services will use a common data type system to operate on the data coming from a wide range of heterogeneous data sources. This data type system will provide a common data format layer that will hide the specific data formats and manage their changes in evolution.The Service Data Objects (SDO) based approach to integrate data services could be easily extend-able to standardize servicedata-based communication across the entire SOA stack, as in Figure 1. The traditional web presentation services, heavily based on server-side computing, seem to be a natural fit, but the adoption of the HTML5-based autonomous applications, easy to deploy in mobile computing context, might prove to be a very promising approach.In short, SDO is just another standardized specification aimed to handle data across multiple heterogeneous data source types. Among the most interesting characteristics of the SDO programming model [3], [4] we could mention:* offers a common platform to standardize access across heterogeneous data source types;* offers support for both static and dynamic data types; also SDO data model is grounded on data-graphs which do not consist only into a single data set, but into a cluster of data-sets containing interreferenced data-objects;* offers support to query, update, and to introspect data: SDO data structures are strong typed by separated metadata objects that come along with data-graphs; moreover, the SDO data model defines a special kind of transactional structures, named data object sequences, to describe CRUD changes on interchangeable data objects;* offers clean separation model of application code from data access code;* uses a feature-rich, very adaptive XML based data type format. …