Envisioning a Data Services Product Line-Part II

In part 1 of this series, the rationale for a data services product line was introduced. In this part, I want to identify specific benefits in taking a service oriented approach to building a data services product line:

Abstraction: Enterprise data entities are complex to assemble and deliver. Core data entities might be physically stored in several repositories often requiring several dozen queries to assemble a customer or product. The enterprise data service needs to abstract the data service consumer from the physical implementation details of multiple sources and source–specific data access logic and semantics. From a consumer perspective, the service is a capability that they can access and interact with as though it is a single record. SOA can provide this abstraction in the form of one or more web services.

Federation: If all the repositories and services for a core enterprise data entity reside in a single department or division federation will be less attractive. But, given mergers and acquisitions as well as the need for getting access to enterprise data from several touch points exist federation is a real business need. The data service can federate across systems or repositories based data category or other criteria. Alternatively, the data service can be part of a composition of services that are used to support a larger enterprise-wide requirement. Either way, SOA provides the necessary machinery to federate data.

Interoperability-Data services need to be interoperable across several computing platforms and technologies. This is a fundamental requirement because the enterprise has several different technologies that aren’t going to suddenly become homogenous. SOA stacks with support for open web-based standards such as SOAP, HTTP, and XML are ideal to realize this need.

Integration-Enterprise data services need to be integrated with external consuming applications via two primary message exchange patterns namely on-demand (request/reply) and event driven (publish/subscribe).  The service logic needs to be implemented by integrating across multiple data repositories and applications.  The integration glue layer has connectivity components, error handling considerations, data transformations, data cleansing/lookup rules, and various data source specific considerations.

Reuse-Data services are meant to be reusable assets that get leveraged across the enterprise. Services can be reused across multiple physical transports, distribution channels, and business process orchestrations. The real benefit provided by SOA is the ability to reuse a service from a number of different computing platforms via open protocols. The ease of interoperability is a key enabler for service reuse.

Versioning-Multiple versions for services as a whole as well as fine grained service capabilities are essential for the product line. SOA provides mechanisms to host multiple service versions either as co-existing units of logic (e.g. using XML schema namespace-based versioning) or by having an adapter layer that can support multiple service versions  (the adapter can translate the prior version request to a newer version and vice versa). This provides service consumers the flexibility to upgrade to newer versions of the service gracefully over time.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to del.icio.us post to facebook

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: