Understanding Service-Oriented Architecture

Understanding Service-OrientedArchitecture

An introductory overview

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Two Important Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

The Services-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Components vs. Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

SOA and Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Architectural Overview of Versata Products Within a SOA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Versata Automation and SOA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

When to Use SOA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Contents

2004 Versata, Inc. All rights reserved 2

Introduction

The rapid adoption of J2EE standards, Java, XML and Web service technologies has resulted in

many enterprises adopting a much more loosely-coupled architectural framework in which to host

enterprise business applications. This framework is called the service-oriented architecture (SOA).

Although Web services are currently being used as a mechanism to promote a service-oriented

architecture, it is important to understand the architectural fundamentals of service orientation to fully

reap the benefits. Service orientation doesn't alter everything — in fact, far from it. Service-based

architectures are evolutionary, not revolutionary, and it is the aim of this short paper to discuss the

core concepts of a service-oriented architecture. In addition, the paper will also cover how the Versata

Logic Suite can be used within this architecture, and how it provides the most efficient software

development platform for service-based architectures.

Two Important Definitions

The service-oriented architecture is the architectural blueprint for the next wave of distributed applica-

tion development. Gartner’s definition is: Service-oriented architecture is a client/server software design

approach in which an application consists of software services and software service consumers (also

known as client or service requesters.). SOA differs from the more general client/server model in its

definitive emphasis on loose coupling between software components, and in its use of separately

standing interfaces.

Web services are a new breed of Web application and a better way to realize SOA on a large scale.

They are self-contained, self-describing, modular applications that can be published, located and

invoked across the Web. They perform functions from simple requests to complicated business

processes. Once a Web service is deployed, other applications (and other Web services) can discover

and invoke the deployed service.

The point to remember is that a service-oriented architecture is an overarching architectural

approach; Web services are enabling technologies.

Understanding SOA


The Service-Oriented Architecture

The requirement to realize a return on investment (ROI) and decrease total cost of ownership (TCO) is

forcing IT shops to evaluate existing software implementations. Reusing business services is one

way these monetary savings can be achieved.

The service-oriented architecture promotes the reuse of business services. It focuses on the building

of more loosely coupled applications that can be assembled from existing and new services to provide

new business functionality.

A service-oriented architecture (SOA) is an enterprise architecture that focuses on:

> The aggregation of components to satisfy a business driver;

> Granular components that promote the reuse of application components that are key to increased

productivity and rapid application deployment;

> A loosely coupled architecture that does not have fixed and inflexible connection points; and

> Layering that allows multiple layers to be developed in parallel and to be plugged together on

completion because connection points are abstracted by standard APIs.

A key focal point of a SOA is:

> Aggregating components, or internal back-office functionality, that can be exposed as services so

they can be accessed in a ubiquitous fashion. These services reside in a common runtime

infrastructure — the application server. This allows core business policies to more closely represent

business process workflow and not be tied to application silos and the need to involve all of a

packaged application’s functionality.

SOA can be evolved based on existing system investments to:

> Minimize rip-and-replace;

> Leverage existing legacy services that can be exposed and accessed in the same fashion as new

business services; and

Understanding SOA


> Rapidly build and deliver new transactional requirements to quickly satisfy business drivers.

SOA commoditizes Infrastructure:

> Commoditized infrastructure brings stability, promotes reuse, lowers cost and reduces risk.

SOA delivers faster time-to-market by:

> Allowing reuse of services across multiple business applications resulting in a much quicker build-

and-deployment cycles;

> By letting IT create business services that truly represent business policy;

> Enabling monitoring and revision; and

> Facilitating the continuous improvement that leads to competitive advantage and increased ROI.

Summarizing these observations from a business perspective, SOA is a way of architecting an enter-

prise to provide services to either end-user applications or other services through published interfaces

in a plug-and-play manner. Services offer a much better way to expose discrete business functionality

and provide an excellent way to develop applications that support business policy and processes. In the

long term, SOA can give business greater agility, stability and reduction in IT integration costs.

Components vs. Services

Services are not the same as components. This does not mean, however, that services cannot

be implemented using components. A component is merely an implementation approach used to

achieve a service. In this scenario, services are the logical grouping of components that satisfy a

business requirement or policy. How the service is built or assembled is hidden from the user.

Understanding SOA


SOA and Web Services

Web services are an important aspect of a SOA because they provide the universal jack which allows

services to be discovered and invoked. Note, however, that services can still be invoked locally without

the overhead of Web services. Distributed invocation is the essential requirement.

In particular, Web services enable:

> Technology independence by removing the technology dependency between the provider and

requestor platforms. The actual endpoint is abstracted to provide loose technology coupling;

> Late binding that allows links between systems to be resolved at run-time;

> Dynamic inspection that allows availability and functionality of a service to be discovered at run-time,

rather than design time;

> Programmability that enables systems to call functions across the Internet, not just pass or present data;

> Use of standard protocols in place of multiple proprietary technologies; and

> Industry consensus on the application of Web services where previous interoperability approaches

have often lacked certain key players.

Services have unique characteristics that differentiate them from their implementation building

blocks. They are:

> Coarse-grained

> Loosely coupled

> Distributed

> Business-Driven

> Adhere to standards

Understanding SOA


Architectural Overview of Versata Within a SOA

SOA is based on a layered architectural concept in which each layer is loosely coupled and is able to

function independent of the layers around it, in much the same way that the early OSI model1 func-

tioned. This enables teams to work in parallel to achieve productivity gains in the development lifecycle.

1 Open Systems Interconnect (OSI) refers to a model of network architecture and a suite of protocols (a protocol stack), developed byISO in 1978 as a framework for international standards in heterogeneous computer network architecture.

Understanding SOA

Above all, Web services do not require the replacement of existing applications. Web services are

a set of new protocols, not a new platform that requires systems to be re-implemented. On the

contrary, Web services are the perfect way to enable existing systems to interoperate and evolve

alongside new applications.

Fig. 1 - SOAs are the classic triangle of service requester, service broker and service provider.


Understanding SOA

Versata products subscribe to this layered independence, and the artifacts produced from the business

rules and process model design function, as discrete layers within an SOA. Bindings to data stores are

also loosely coupled. Later, this paper discusses a large telecom organization’s use of Versata within a

SOA, and how it interacts with existing legacy COBOL programs. At design time, this work is done

against an Oracle back-end system and at pre-production this is plugged back into the real back-end for

testing purposes. This is achievable because of the loose coupling between the services generated

from the metadata (rules) and the underlying data binding.

A SOA is the classic triangle of service requester, service broker and service provider as shown

above in figure 1. A service-based architecture will often not have the service broker part — just the

service requester and service provider. In this type of architecture service endpoints are normally

fixed. Versata products can work within both types of architectures. The artifacts generated by

Versata at each layer also make use of industry recognized best practice patterns and optimizations

as shown in figure 2 below.

Fig. 2 - Versata makes use of industry recognized best-practice patterns and optimizations.


Versata-generated SOA services are designed to be called by either end users or programmer code.

Consider a loan service that allows clients to apply for loans online. The service is comprised of mul-

tiple building blocks, each of which has ancillary logic. Using Versata allows the analysts to change

the logic of the loan service by either adding a component or changing the rules — changing the

logic without any hand-coding. This requires no change in the client calling the service, because the

service access endpoint would not change.

Versata automation and SOA

Many organizations have embraced the Versata Logic Suite because it enables them to manage their

business policies through innovative business rules technology. Versata has allowed their business to

be agile and flexible in ways which other solutions cannot. Companies that have logic locked away in

packaged applications just cannot react as quickly to changing business demands.

Versata promotes the use of services through the abstraction of business rules by providing a very

sophisticated interface in which to enter logic as it occurs, instead of translating it into code. This logic

is stored as metadata (in XML) and used to generate the components and services for use in a SOA.

Versata’s business-rules automation injects flexibility and high productivity into the development

and maintenance lifecycle, yet is totally consistent and compatible with the leading J2EE/EJB 3-tier

environments that provide the performance, scalability and robustness needed by strategic IT

projects. The Versata vision is one of automation, but taken to a much higher level of productivity —

a level where the statements written by developers map to the actual requirements and rules of the

business as stated in business terms (e.g., customer balance equals the sum of unpaid orders).

Over the last decade, the industry has seen the successive rise of C, C++, Visual Basic and Java as

languages-of-choice for implementing business logic. What the industry has overlooked is the one

language that has remained the universally understood constant in the business community — English.

The concept of defining business logic using structured English-format statements is not new. Yet

the rules-based approach espoused by Versata deserves renewed attention because of the growing

level and dynamic nature of business content in modern day applications.

Understanding SOA


Versata is engineered to integrate and access the logic locked away in packaged or legacy applica-

tions. It fulfills the core concept of SOA — to be able to use existing services, as well as new ones,

and not just rip and replace.

Consider one of Versata’s largest clients, a billion dollar a year telecom firm. The company implemented

one of the earliest SOAs using Versata. As most telecom firms do, it has a lot of legacy transactional

COBOL programs. Versata wrappers these legacy transactional programs and exposes higher level serv-

ices in the mid-tier that reside alongside other new services built with Versata. These services can then

be accessed ubiquitously via HTTP/RMI or using SOAP. Versata also uses its rules technology within the

wrappers to validate any access to these costly legacy transactions providing yet another cost savings.

As a result of using Versata to access and manage this legacy service, this telecom company is able

to service 250,000 calls into the Versata platform per day, which results in 750,000 transactions to

the Versata XDA Connector. This load translates into approximately 2.25 million calls to a back-end

CICS system. Over the course of a week, this load equates to 15.75 million CICS transactions and

over 68.25 million CICS transactions per month. Despite the volume of transactions, there is only a

monthly error rate of 350 transactions, of which 80% of these are timeouts in back-office systems.

At the rate of a $1 (USD) per transaction, this company is able to manage transactions to minimize its

error rate which, at this volume, would be incredibly expensive. Better still, they don’t have to rip and

replace a proven application to accommodate new business requirements.

With Versata, a SOA can contain, or be responsible for, all of the business logic in the enterprise.

Certainly there will be processes and transactional logic that will remain in the back-office

infrastructure that supports the organization. None of the business services, however, need to

remain isolated in this infrastructure. Business policies, processes and business compliance can

all now be handled at a higher level by business analysts. These requirements don’t just require

an SOA; they require business to be able configure and compose services in a way which is still

not possible in traditional programming languages.

Understanding SOA


Understanding SOA

A service-oriented architecture will not be applicable to every organization, but is definitely pertinent

to many. Versata products enable the user to choose how the architecture is deployed, be it loosely

or tightly coupled. Versata prefers the term “selectively coupled,” since there is no one-size-fits-all in

an enterprise organization.

For further information on this topic, please read Zapthink’s article, “When not to use SOA,” available

online at http://www.zapthink.com/report.html?id=ZAPFLASH-02162004.

When to Use SOA

Service-oriented architectures promote reuse of existing infrastructure and resources within some

distinctly defined concepts. No company today wants to write an application from scratch, particularly

when the application will have to interact with existing back-office functionality. Discrete reusable

business services are the industry Nirvana on which SOA is built. Versata utilizes and builds on this

concept with the notion of reuse by specification due to its inherent metamodel approach to building

business services.

Versata automates rules-based business logic without regard to the underlying technologies —

new or time-tested legacies. This makes it possible for analysts, architects and developers to take

full advantage of the benefits of SOA and Web services without worrying about them. Thus, they can

concentrate only on the business process – what, not how – expressing it in plain English. Versata

makes the development of service-oriented business applications easier and more cost-effective.

Summary

Versata helps automate and simplify the building, maintenance and ongoing evolution of data-intensive

applications, business processes and their data. These applications and processes typically access

numerous data sources, incorporate multiple database tables and user interfaces, execute business

transactions and can support thousands of users. The Versata solution effectively and efficiently

replaces time-intensive hand-coding efforts with simple, intuitive business rules and graphical process

flow specification.

Versata Global 2000 customers include American Management Systems, BT, J.P. Morgan Chase &

Co., Meridian Health Care Management and Union Bank of California. For more information, please

visit http://www.versata.com or call (800) 984-7638.

Understanding SOA

© 2004 Versata, Inc. All rights reserved. Versata, the Versata logo and Versata Logic Server are registered trademarks of Versata, Inc. Java and all Java-basedtrademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All other company and productnames mentioned are the trademarks or registered trademarks of their respective companies.

Headquarters

Versata, Inc. 300 Lakeside Drive, Suite 1300,Oakland, CA 94612 USAhttp://www.versata.comUS +1 800.984.7638 ph +1 510.628.1000 fx +1 510.238.4101

United Kingdom(Including Middle East and Africa)

VersataParkshot House5 Kew RoadRichmondSurrey TW9 2PREnglandph +44 (0) 20.8334.8080fx +44 (0) 20.8334.8180

Germany(Including Central, Eastern and Southern Europe)

Versata GmbHFlughafenstrasse 52D-22335 Hamburgph +49 (0) 800.VERSATAfx +49 (0) [email protected]

About Versata

Understanding Service-Oriented Architecture

Technology

Transcript of Understanding Service-Oriented Architecture