SOA based Data Architecture for HTML 5 Web Applications

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.


Introduction: Data Architectures and Enterprise Mobile Computing
Although 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 meta-data 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.

Fig. 1. SDO-based Data Integration Architecture
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.The mobile computing paradigm proliferated in the consumer area, but still struggles in the enterprise area.In our opinion, the following issues could represent some key aspects to overcome this blocking stage in the mobile enterprise evolution: • adopting a common access and processing paradigm to enterprise data (as in SOA); • building feasible frameworks and architectures to develop presentation layer services across multi-device environments (as could be HTML5).Anyone could note that the SOA approach already provides some reasonable answers to the first issue, but regarding the second one, many authors consider that the new HTML5 framework for web applications will represent one of the most prolific environments for the next generation of mobile applications taking into consideration the followings [5], [6], [7], [8] Consequently, the new HTML5 standard could represent a solid enterprise mobile computing foundation and a feasible path towards the proliferation of this kind of applications.
In the context of SOA and SDO marriage to effective integration of entity services, we will try to prove that the same SDO based integration approach could be used to achieve the integration of the HTML5-based presentation services with the enterprise data services.In figure 2 we have tried to envision a conceptual and synthetic perspective of such architecture.Consequently, Core-DIA represents the key layer as the foundation to the entire integration infrastructure to be used among the enterprise-internal data services and further to internal or external presentation services, as mobile and autonomous HTML5 applications will be.
Our efforts to build a feasible Core-DIA layer yielded an architecture who's the most important components are rendered in Figure 4. To preserve the objective of achieving a SDO-based, dynamic, versatile and straightforward data integration model, we had to manage a complex of Java based technologies like Javaasist (to introduce dynamics into otherwise static and strong typed Java context), JDBC (to get a straightforward connection with SQL data source), JAXB (to convert Java beans to XML format), Eclipse-Link as an open source implementation of SDO standard.Our first concern was to provide the possibility to work with dynamic typed data objects, a feature uncommon to most Java business applications.For this purpose we have used a special Java library to manipulate or to generate Java bytecode at runtime.Listing 1 tries to show how, starting from a collection containing field names, we've build a dynamic data type schema.The dynamic nature of our process to generate Java data beans is very important because the ResultSet can be created in an offhand manner starting from a declarative SQL-SELECT phrase that could invoke any relation or table from database schema with any column projection on it.The next step is essential regarding the conversion process of the Java data beans into Service Data Objects.Specifically, the final result consist in an XSD file that describe SDO schema and an XML file that will contain the serialization form of Service Data Objects.The Listing 4 suggests how to use SDO API implemented by the Eclipse-Link project to materialize SDO data objects from JDBC result set.

Listing 4. Generating Dynamic SDO schema and XML format public void getDynamicSDO(ResultSet rSetvalues) throws Exception{
// Generate Java Data beans to be converted in SDOs Some samples, of the two SDO related files (XSD and XML), that will be dynamically generated could look like in Listing 5.The Java context, where SQL Data are translated to Service Data Objects, could be entirely operational within the Oracle database system (the Oracle instance).In this regard, we have managed to load all the support libraries into an Oracle schema in order to exploit the built-in support for Javato-PL/SQL interoperability.This kind of interoperability was used to publish our OJDBC-EclipseLink-based SDO-engine as a PL/SQL Web service through DBMS_XDB and ULT_HTTP package functionality.Consequently, the starting point to deliver such Oracle database "native" web service is a plain simple PL/SQL procedure that will invoke the Java method from Listing 6.This method will be accessible in the PL/SQL context using an Oracle Object Type mapped on the Java class that will host this method.Loading and mapping Java classes as Oracle Object Types is a very interesting feature of Oracle 11g modern database.Another approach is to build a "natural" pure Javabased Rest service using JAX-RS API with an implementation like Jersey.We are aware that we only proved the possibility to build such wide-integration architecture.Other conceptual and experimental efforts are necessary to prove the real feasibility of this architecture taking into consideration at least the following questions:

Listing 5. SDO related files
• performance issues from simple to complex query tasks, or scalability (some benchmark tests need to be run); • developing complexity and developers' acceptance; • productivity and supporting tools (MDA with modeling tools based on UML metamodels seems to be a promising strategy); • security issues concerning access control to enterprise data assets; • SDO transaction management in the context of inter-architectural levels.