|
The
Role of Transformation Services in SOA
Document ID: ZAPFLASH-2006103 | Document Type: ZapFlash As organizations move forward with their Service-Oriented
Architecture (SOA) implementation plans, they often find themselves grappling
with significant, long-lived problems of data and semantic integration among a
wide variety of data sources. The mismatch between the data representation that
one application provides and the data representation that another application
expects forms the core of this long-lived problem. This data integration problem is particularly troublesome
for SOA implementations because it limits the loose coupling between Service
providers and consumers, unless there is an effective way to decouple the
provider and consumer’s data representations. The need to access
information of so many disparate types from so many disparate sources forms the
semantic integration challenge that organizations must deal with today. Effective Service Composition Means
Effective Semantic Integration Furthermore, companies frequently make independent
decisions about technologies for different aspects of their business, and then
concern themselves with tying together these disparate systems at a later date.
In addition, many industries are prone to acquisition and merger activity,
leaving their companies a complex checkerboard of differing technology
implementations. As a result, there is rarely central decision making on
technology adoption, and heterogeneity always rules the business that adapts to
meet its changing market. Thus, companies continually find themselves with the
challenge of meeting their integration requirements in a heterogeneous
environment of continual change. The difficulties with solving the semantic integration issues
limit a company’s ability to respond to change quickly, and thus limits
SOA’s ability to provide business agility. Adherence to standards
insures, to some degree, the loose coupling and composition of Services and
data exchange mechanisms, but there is no guarantee that the data exchanged
with an individual Service will be universally comprehensible. Even when
organizations use metadata standards such as XML to format messages, the schema
of one Service might not match the schema of another, and fields with the same
meaning might use differing tags. In order for data to flow unimpeded in a SOA
implementation, therefore, we must liberate Service providers and consumers
from tightly-coupled knowledge of other’s data formats. Services should
be concerned with the semantic meaning of the data, not the structure of the
data. The issue here is therefore one of loose coupling. While we might loosely
couple application interfaces, if we deal with data the same way that we have
always done—by imposing the data structures of Service providers on
Service consumers, the result is every bit as tightly coupled as previous
architectural approaches. In order to deliver on the promise of seamless data
integration, we must transcend loosely coupling the application interface and
in addition provide loose coupling at the semantic level. A Service-Oriented Approach to Data
Integration The use of data transformation Services improves loose
coupling by separating the concerns of Service providers and consumers. The
builder of a specific Service can focus on the key functionality of that
Service, and the composer of a Service-Oriented Business Application (SOBA)
that implements a Service-oriented process can focus on process-level design
concerns. The transformation Services isolate the data transformation concerns,
allowing personnel skilled in transformation techniques to focus on developing
the data transformations. This approach leads to more maintainable solutions
and allows organizations to focus each component on what it does best, and
enables the organization to utilize its resources more effectively. When an application or Service must transform data from
one format to another in order to achieve some desired data integration goal,
the most common and straightforward approach is to embed data transformation
logic directly within the application, as the figure below illustrates: Using
an Embedded Transformation Embedding transformation logic within applications is a natural
object-oriented design technique, because in the object-oriented world,
applications encapsulate internal logic, including transformation logic.
Nevertheless, there are significant disadvantages to embedding transformation
logic within an application: ·
Other
applications or Services have no practical way of reusing the embedded
transformations ·
It’s
impossible to offload the CPU overhead that the embedded data transformations
cause ·
The
transformation logic is tightly coupled to the business logic within the
application, reducing the flexibility and reusability of the applications ·
The
transformation logic is handled programmatically vs. declaratively through
metadata, further impeding the flexibility of the application. While in many cases, data transformation logic may be so
specific that it is unlikely that another Service or application will need it,
and so well-built that it doesn’t consume many processing resources, the
real problem of embedded transformation logic is that over time, companies end
up with so much purpose-built, hard-coded, and tightly-coupled transformation
logic scattered across the enterprise. This scenario points out the danger of
hiding transformations from the enterprise: if we hide the cost and complexity
of transformation within the cost of tightly-coupled applications, there is no
way to gauge its true cost. An alternative to embedding transformation logic within an
application is to use an external transformation Service to handle the task. A
transformation Service, loosely-coupled in a SOA implementation of course,
accepts incoming data in one format, and outputs data with the same semantic
meaning in another format, as shown in the figure below. Service-Oriented
Transformation In addition to externalizing data and semantic integration
logic, use of an external transformation Service makes it possible to offload
CPU-intensive data transformations to systems optimized for such operations.
While the overhead of using a Service hosted on a remote system can incur the
overhead of passing data to and from a remote Server, the loosely-coupled, Service-oriented
approach of externalizing transformation logic through Service interfaces
allows organizations to independently scale the number of servers hosting the
transformation Service as necessary, without impacting existing Service
implementations. In addition to the benefits of loosely-coupled
transformation logic, transformation Services offer an organization
considerable cost savings by reducing the hodgepodge of data integration and
transformation tools spread across the enterprise. Licensing costs for these
tools add up, and reducing the number of such solutions that a business has to
deal with decreases hassles and cost. In addition, through the use of
transformation Services, organizations gain increased visibility of the
transformation activity within the enterprise. Increased awareness of such
transformation activities provides valuable insight, both for capacity planning
and, if necessary, for undertaking data migration efforts. Disjoint
transformation tools can’t provide these insights. The ZapThink Take The semantic integration challenge remains as an obstacle
to fully realizing SOA’s promise of business agility, however.
Organizations struggle with how to liberate the meaning of data from the
structure of its representation, so that information can flow seamlessly
between the Services that power the business. Data transformation Services can
address the challenge of data and semantic integration. By separating
transformation into a separate Service, it’s possible to handle data
transformation declaratively, increasing the flexibility of the
transformations. Transformation Services are most useful in groups of SOBAs
that share Services amongst themselves. Orchestration logic can route
information through a transformation Service, both before passing it to a
Service, and before processing a response from a Service. From the perspective
of the SOBA’s author, a transformation Service is simply another Service,
and data within the application flow seamlessly from one Service to another.
The transformation Services simply perform the necessary steps to make the
process work properly. (This ZapFlash is an excerpt of a recent
White Paper on this topic, Transformation Services for SOA)
SPONSORED LINKS
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe __,_._,___ |
Title: [ZapFlash] The Role of Transformation Services in SOA
