Data Sources as Web Services
October 25, 2007
WSO2 (WS OH 2) is growing in popularity and the team continues to produce quality products. The WSO2 (a.k.a. Web Services Oxygen Tank) team that has pulled together a platform around Apache SOA projects, producing an application server, ESB, Web 2.0 mashup engine, and more. Most recently, they have released Version 2.1 of the Web Services Application Server (WSAS). The release includes a lot of compelling features, but this article focuses upon WSO2 Data Services.
This article introduces WSO2 Data Services, a new feature available in WSO2's WSAS 2.0 platform (the latest release is version 2.1). I will begin by introducing Data Services, examining their architecture and utilization, and then exploring pros and cons of this convenient feature.
Introducing Data Services
Once you move past novelty web services that echo a string you sent or perform some sort of trivial mathematical computation (e.g., MySquareRootService or CalculatorService), services are either facilitating the insertion or retrieval of data. Whether you want to retrieve customer and product data via a service request or you want to be able to expose supply chain operations to key business partners, folding your data access layer into your SOA architecture is key. WSO2 Data Services provide a convenient and well-engineered mechanism for service orienting your data.
In Figure 1, a conceptual WSO2 enterprise deployment is illustrated. Data services are standard web services that have been configured within WSAS to map to data source calls to one or more backend data sources. Configuration is captured in XML and can either be performed by hand and uploaded as a complete deployment module, or deployed via the web-based Data Service configuration wizard. Once deployed, these services can either be consumed by other WSAS services or be made available to external* clients.
*Exposing select services outside the firewall (as depicted in Figure 1) is not a feature that is explicitly supported by WSAS. It is, however, representative of industry best practices for SOA and is supported by a variety of implementation solutions (proxy server, selective firewall configuration, SOA networking appliance, etc.).
With the recent production release of WSAS 2.1, the following data sources are supported:
- Relational databases (including support for calling stored procedures)
- CSV data sources (both local and remote files via HTTP)
- Excel data sources (both local and remote files via HTTP)
- JNDI data sources
When configuring a WSO2 data service, you'll need data source connection info (varies depending upon the source type). Then you specify the queries, input/output mappings (map XML element names to column names), and finally map each query to a service operation. Once deployed, these services can then be configured like any other service with various security requirements, policies, and AXIS runtime processing handlers.
Data Services Architecture and Utilization
Data Services are essentially the SOA-equivalent of the Data Access Object pattern. Granted, Data Services are at a much higher level of abstraction, but they serve a similar role in a layered architecture. They enable higher level services or even client applications to access underlying datasets without regard for the implementation details involved. Consider the SOA reference architecture depicted in Figure 2. Data services function in a similar fashion to standard Web services. The key difference is that they provide more direct access to underlying data (albeit with operation-to-query mapping and element-to-column mapping) rather than accessing data indirectly via applications and business objects (EJBs, POJOs, etc.).
To explore WSO2 Data Services for yourself, a number of resources are available, including:
- Getting Started with WSO2 Data Services (simple tutorial)
- How to call MySQL 5 stored procedures from Data Services (more advanced tutorial)
- Hosting WSO2 Data Services on WSAS (administrator's guide documentation)
- Getting Started with Data Service Samples (20 MB tutorial-style movie)
If you should decide to make WSO2 Data Services an option for SOA solutions, governance will be important. The simplicity of Data Services can potentially lead to ill-conceived utilization of this convenient capability. It's funny, but it almost makes it too easy to expose data as services. Consequently, developers may be tempted to generate one or more services based off of existing data sources as a quick fix, rather than designing the solution appropriately and developing the architectural layers that are really needed to ensure a robust and reusable solution. In a similar vein, creation of Data Services may promote more of a bottom-up approach to service orientation. This is not an inherently bad thing, but often a top-down strategy will yield a better alignment with long-term business goals. If it is too easy to expose existing data sets as services, developers are not forced to critically analyze the requirements and evaluate whether or not the current data sets really address the problem at hand. All of this points to a need for stronger governance regarding how and under what circumstances this particular capability can be acceptable leveraged.
Advantages of WSO2 Data Services
WSO2 Data Services offer some significant benefits to enterprises that are interested in service orientation, including the following:
- Convenient service orientation of existing data sources such as RDBMS, CVS, Excel, and JNDI data sources
- Ability to service orient RDBMS stored procedures
- Configurable Data Service Layer including service operation mapping and element name mapping
- Apply role-based security to data access, including digital signatures, encryption, and various security tokens
- Apply WS-policy assertions to data access services
- Selectively expose underlying datasets through queries and XML mapping
- Great for proof-of-concept SOA projects to quickly expose data via simple Web services
WSO2 Data Services clearly have a lot going for them. They provide a convenient way to quickly service orient data, but still allow for enterprise-grade configuration and architectural decisions to be made.
Disadvantages of WSO2 Data Services
WSO2 Data Services also have some drawbacks that need to be considered, including the following:
- Exposing data tables as services is easy, but does not really promote the architecture aspect of SOA
- Creation of data services may promote a bottom-up service orientation approach, when a top-down strategy might yield better results
- Data service queries cannot span multiple data sources (each service is tied to one data source)
The great irony of WSO2 Data Services is that their very strength (quick, convenient exposure of enterprise data) is also their biggest weakness. In some respects, it is too easy to expose these services. Moreover, although it is possible to incorporate this into a well-planned architecture, the simplicity may lead some to just deploy these services and consider it good enough without really thinking through the architectural implications. The take away here is to ensure that strong governance is in play to guide the utilization of the powerful and simple and feature.
Service-Oriented Data Access
The heart of any enterprise application is data. Applications provide the ability to view, sort, filter, edit, create, and delete data. In a SOA, access to data is also paramount. Typically this involves wrapping an existing business object (EJB or POJO) with a web service. Another option is to bypass this additional layer and directly expose data capabilities via WSO2 Data Services. Data services are convenient, configurable, and great for service oriented data for a demo or even as a part of a SOA. When you get the chance, swing by WSO2 and take WSAS 2.X and Data Services for a spin.