SOA EnAblEmEnT EdiTiOn | iSSuE 2, 2009 TECHniques Spotlight

To find the Software AG office nearest you, please visit: www.softwareag.com© 2009 Software AG. All rights reserved. Software AG and all Software AG products are either trademarks or registered trademarks of Software AG. Other product and company names mentioned herein may be the trademarks of their respective owners.

TECHniquesSOA EnAblEmEnT EdiTiOn | iSSuE 2, 2009

2009Spotlight

Consequently, when we think our current

widgets are becoming “legacy” we simply

buy new ones. And when we think the

new ones are becoming legacy, we buy

newer ones. And on and on it goes until

we amass a huge pile of technology that

must be maintained and supported.

Take SOA Enablement as an example. It is

very tempting in our widget wonderment

to think of SOA Enablement as one more

new class of widgets that will help connect

our existing core systems to a whole new

class of widgets out there called Services.

Then we can play in the huge new widget

sandbox called SOA.

But in a broader and more important sense,

exactly the opposite is true. SOA Enablement

is not primarily about technology at all (just

as SOA is not primarily about technology).

SOA Enablement is a philosophy and

approach that says the best way to solve a

new class of business problems is not

always to abandon what currently works.

Often the best way is to adapt what

currently works to meet new challenges.

This approach is usually less expensive,

less risky and less time-consuming. SOA

Enablement is about beginning with a solid

We who have made our careers in IT were

drawn to technology for various reasons.

But my guess is that many of us have a

strong streak of “widget wonderment*”

deep in our hearts (*i.e. a childlike fascina-

tion with devices, creations and contrap-

tions). When we hear about XML or SOA or

Cloud Computing or Virtualization, we want

to jump in with both feet and squish around

in all that sexy technology as if it was a

big vat of juicy red grapes. We want to

stamp out all the techno-essence and

make something fantastic from it, just like

a skilled vintner.

The problem with widget wonderment is

that in our ecstasy we can forget what the

technology is for in the first place. It can

easily become an end in itself, and we just

want to collect more widgets and expand

our widget kingdom and see how they will

all play together. Of course, the organiza-

tions that pay our salaries see our widget

world as a means to an end, not the end

itself. Our job is to solve business problems

now and in the future. And if we can

accomplish this job with the widgets we

already have, even better.

But unfortunately our widget wonderment

often leads us to conclude that the best

way to address new business challenges is

to go out and buy new widgets. This is a

problem, because analysts tell us that IT

organizations are great at collecting

technologies, but very bad at eliminating

technologies (after all, cleaning house is

expensive, complex, time consuming and

produces nothing new).

SOA EnAblEmEnT iS All AbOuT TEchnOlOGy, RiGhT? Wrong. By Gerd Schneider, SVP, Enterprise Transaction Systems, Software AG

foundation and then re-discovering, re-

energizing and transforming essential

capabilities that have been tested and

proven over time.

From Software AG’s perspective, SOA

Enablement is just one approach – along

with Web enablement, SQL enablement,

performance optimization and others – to

make your existing core systems work

better at solving business problems or

supporting business processes.

New widgets are fun. But from the stand-

point of the business, gaining maximum

value from existing investments and

organizational domain knowledge to meet

current and future challenges is what

makes the world go ‘round. Succeed at

that – then go treat yourself to an iPhone.

As technologists, our “widget wonderment” can sometimes blind us to what the business truly cares about. How do we see

past the sparkle and make choices that create the most organizational value?

SAG_

2009

Spot

_SOA

Enab

lem

ent_

Iss2

-09_

25M

ar09

SoA Enablement is about beginning

with a solid foundation and then

re-discovering, re-energizing and

transforming essential capabilities

that have been tested and proven

over time.



ProfessionalPonderings

SOA: A WAy FOrWArd...Three simple principles need to be applied

in order to overcome institutional inertia

and to successfully liberate applications, data

and processes from their underlying silos:

Start with Agreement

Move forward with Measurements

Connect Measurements to Incentives

First and foremost, in order to overcome

organizational silos and the inertia they

represent, you must establish agreements.

At the heart of the agreements is consent

between two tribes (or between a tribe and

the enterprise as a whole) on the desired

outcome, as well as Key Performance

Indicators (measurements) that can help

track the project as it moves forward.

Finally, and most importantly, the perfor-

mance indicators need to be tied to both

organizational and individual incentives.

Provider organizations need to be compen-

sated for providing, supporting and main-

taining services. Developers need to earn

bonuses or job security through reuse of

services and other behaviors conducive to

supporting architectural goals.

1.

2.

3.

Despite the great promise of SOA, 2009

kicked off with a bang with Burton Group’s

Anne Thomas Manes declaring “SOA is

Dead”. Why are such extreme views

coming out now? You can blame the

economic slowdown, and what a leading

analyst firm calls the “trough of disillusion-

ment”. However, there are some big errors

that are contributing to the chaos.

The BiggeST SOA Killer iS A FAilure TO underSTAnd “TriBAliSm”...The biggest error in understanding SOA is

the failure to understand that for every

silo, there is a “tribe” – a group of people

who own, control and protect the capability

in that silo. “Freeing” the capability requires

working with these people.

By ignoring this natural tendency of human

nature, we fail to interconnect siloed

systems and create a bunch of SOA ideas

that will never work, such as:

Business process trapped in a single

technology platform

“Single Vendor SOA”

SOA without governance

And so forth. This may work for a limited

time, but without a system for SOA adop-

tion, such as the one we describe in our

“Dummies” book, these temporary solu-

tions tend to fall apart over time.

•

•

•

SOA iS dEAd? Hardly... By Miko Matsumura, Vice President, Deputy CTO, Member, Global Leadership Team, Software AG

SOFTWAre Ag iS The leAder...Software AG is a leader in SOA Adoption

and Governance, and we continue to

pioneer the field with innovations such as

the SOALink Cookbook and the upcoming

SOA Summit events. Industry analysts

recognize our world-class products, and we

invest heavily in advancing our products,

such as CentraSite and webMethods Insight,

as well as our popular integration and

application modernization portfolios.

In addition, at CeBIT 2009, we launched the

innovative Alignspace.com site, which is

designed to help forge the “cross-silo”

agreements on business process that form

the initial stages of many successful SOA

projects.

Software AG works with all major vendors

in a completely neutral way, and as such

you can move ahead with the utmost

confidence. We pride ourselves in our long

standing “leave and layer” strategy that

modernizes and maximizes the value of

existing investments, but enables you to

achieve business agility goals both today

and in the future. You can rely on us.

soa Has arrived...As Software Ag described in its free e-book, SOA Adoption for dummies, enterprises are reaching the

breaking point of architectural degradation. Consolidating mergers and acquisitions, geographic expansions, and business

decisions are creating a “sprawl” of slabs, silos and spaghetti. Business and regulatory conditions force the modernization of

infrastructure towards a much more agile state. in this environment, SOA creates value by applications, business processes

and data that live in the network and traverse across silos, through slabs and without spaghetti!

SAg_

Prof

Pond

_SOA

dead

_iss

2-09

_30m

ar09

TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009

technology Spotlight

implementation and container types is an

absolute necessity! An additional challenge

faced by businesses adopting SOA-centric

application development is how to bridge

the gap between the sketchy drawings of

the business processes conceived by the

business departments with the myriad

details of the actual implementation and

deployment of the software artifacts

owned by the IT departments. Hence, the

composition architecture must also decouple

the implementation details from the

component interface and composition

definition level.

To address these two key requirements, a

new standard called Service Component

Architecture (SCA) is emerging in the OASIS

consortium. The SCA suite of specifications

identifies a simple, yet powerful, recursive

‘component definition and assembly model’

that enables building SOA-based service

components, composites and integrations,

independent of underlying implementation

and deployment container types.

Service-oriented Architecture (SOA) is a

core technological approach that enables

flexibility and reduces the complexity of

solutions in an enterprise IT environment.

A key characteristic of SOA lies in realizing

business applications, and their inherent

computational logic, as aggregations of

reusable ‘service’ components, so that

existing implementations are reused in

different applications, instead of reinvent-

ing the wheel each time around. However,

in a typical large enterprise environment,

implementations happen in different

languages and programming paradigms

involving a multitude of runtime environ-

ments. This kind of environment results in

a heterogeneous population of service

(SOA) components, each of which may be

implemented in any language, deployed

into disparate containers and runtime

environments. To fully realize the power of

SOA and to enable enterprises to leverage

existing and legacy implementations, a

‘service composition architecture’ that can

encompass service components of varying

Service component Architecture – A tEchnicAl OvErviEwBy Prasad Yendluri, Vice President, Deputy CTO, Software AG

Figure 1: SCA Assembly Model

SCA Overview Service Component Architecture (SCA)

defines a simplified programming and

composition model for SOA. It identifies a

recursive composition model for building

elemental service components, assembling

those components into composites and

eventually into applications that can be

deployed into distributed runtime environ-

ments. SCA permits mixing and matching

components of any implementation type

that can be accessed using native or Web

services access methods, in a platform,

language, implementation, and container

independent way, as depicted in Figure 1.

Either existing implementations (bottom-up

approach) or newly created interfaces and

code (top-down) can be turned into SCA

components by encasing them in simple

XML-based metadata wrappers. SCA

composition tools can make these compo-

nents available for composition via simple

“wiring” together, without exposing the

implementation details. SCA currently

supports components of different imple-

mentation types including Java, C++, EJB,

COBOL, Ruby, Spring and even orchestra-

tions defined in BPEL.

Figure 1 captures the concepts of SCA

components, composites and associate

assembly model in a concise fashion. At

the lowest or atomic level, an SCA compo-

nent exposes a service interface such as a

WSDL port-type or a Java Interface. The

component is realized or implemented by

any of the possible implementation types

including Java, C++, BPEL, COBOL etc. Each

component may also have dynamically

configurable values called “properties” that

can potentially take different values for

each instance of the component.

SCA DeplOyMent ArChiteCtureSCA specifies a packaging format for

bundling an SCA-based solution along with

its metadata and implementations into a

deployable entity called “SCA contribution”

(like zip archives). The SCA contributions are

deployed into “SCA runtimes” that manage

deployment and coordination of constituent

components of SCA contributions into

appropriate runtime containers. SCA

runtimes are conceptual middleware compo-

nents that can be ESBs that understand SCA

formats directly or a thin layer of middle-

ware that interfaces with the ESBs, keeping

ESBs immune to the details of SCA packag-

ing formats. Another example of SCA

runtime is the Java Business Integrator (JBI).

The concept of SCA contribution and the

deployment of the contributions into SCA

runtimes realized by the ESB infrastructure in

an SOA platform are shown in Figure 4. This

also shows how the development and life

cycle of SCA components and composites

can be governed via an SOA governance

framework, just like all other SOA artifacts.

2

Examples of properties are:

A “Currency” property which can take

values like Euro or Dollar.

A “Time-Zone” property that signifies a local time zone.

A component may also declare the inter-

faces it invokes (or needs) called “Refer-

ences”. References are interfaces supplied

by other components that a particular

component depends on or invokes to

accomplish its purpose. A component

can only define a single service interface

(the service it provides) but may have

multiple references (use multiple other

service interfaces).

In the SCA assembly model, other larger

components (called composites) may be

built recursively by assembling other

components or composites by “wiring”

them together (as shown in Figure 1). The

resultant SCA composite promotes one of

the constituent component service interfaces

as its own service and all unsatisfied

references as references of the composite.

All properties of the constituent compo-

nents also get exposed as the properties of

the composite.

SCA components and composites are

serialized into instances of documents in

the format defined by the SCA standard,

called Service Component Description

Language (SCDL). SCDL is an XML-based

description language used to capture the

SCA specific metadata associated with a

component. An example of an SCA compos-

ite serialized in SCDL is shown in Figure 2.

The composite’s service interface, constitu-

ent components, properties and references

are highlighted and correlated with the

pictorial depiction of the composite.

A multitude of like or disparate types of

components and composites can, in turn,

be integrated into solutions or applications

called “domains” (in SCA terminology).

One such integration is depicted in Figure 3.

•

•

Figure 2: SCA Composite Serialized in SCDi

Figure 3: Component/Composite integration into Domains

SCA SpeCiFiCAtiOnSSCA specifications went through compre-

hensive refinement and stabilization in the

OSOA consortium, of which Software AG is

a member. The ‘stable’ six key SCA specifi-

cations from OSOA were submitted to

OASIS last year and are being normalized

in six respective OASIS TCs.

The progress in OASIS has been very rapid

and Software AG expects the SCA specifica-

tions to become OASIS standards in less

than a year (most likely summer 2009). In

addition to contributing to the develop-

ment of the SCA specifications in OSOA,

Software AG has been a member of the

SCA-related technical committees in OASIS

since their inception and is involved in the

development of these specifications.

Figure 5 is an overview of the SCA specifi-

cations, illustrating their hierarchical

dependency. SCA specifications are split

into four major groups. The Assembly

group that sits at the top of the hierarchy

is the primary specification that defines the

SCA component and assembly model for

composing SCA components into compos-

ites and domains, etc. The assembly

specification also specifies the syntax for

the Service Component Description Lan-

guage (SCDL). The packaging and deploy-

ment aspects, including the SCA contribu-

tion meta-format, are also specified by the

SCA assembly specification. The SCA

binding specifications define the runtime

and protocol bindings for accessing/

invoking the service interface offered by

the SCA components. SCA currently defines

the binding for Web services (WS-*/SOAP

based) access, Java Messaging Service

(JMS), EJB Session Bean, Java EE Connectiv-

ity Architecture (JCA) and vendor specific

access method (called SCA binding). Other

bindings such as REST are in development

for future normalization. SCA language

specifications specify concrete language

mappings of SCA assembly model. They

specify how to define an SCA component

for an implementation in a specific lan-

guage (conversely how to realize imple-

mentations in a specific language as SCA

components). Currently the SCA language

specifications are available for Java (POJO,

EJB, Spring Framework), C, C++, BPEL and

COBOL. PHP and Ruby are also in develop-

ment. SCA policy specifications enable

specification of Quality of Service Policy

requirements of the components as policy

intents and bind them to concrete policy

specifications in the form of policy asser-

tions in concrete policy frameworks such as

W3C WS-Policy Framework and the related

WS-Policy Attachment mechanisms. The SCA

policy Framework also makes it possible to

attach different policy requirements based

on the specific bindings for the interfaces

(and references) of the subject SCA compo-

nents and composites.

3

Figure 4: SCA Contribution and Deployment of Contributions into SCA runtimes

Figure 5: SCA Specifications Overview

COnCluSiOnThe SCA suite of specifications is a major step forward in realizing the SOA promise of

service re-use and recursive composition. SCA provides a programming model for building

composite applications and systems based on the SOA principle that business function is

provided as an aggregation of reusable service components assembled together to create

solutions that serve a particular business need. These composite applications contain both

new services created specifically for the application and business function from existing

systems and applications implementations, reused as part of the composition. SCA provides

a model both for the composition of solutions and for the creation of service components,

including the reuse of existing application function within SCA compositions. SCA also

defines a packaging and deployment model that is aligned with runtime infrastructure

typically found in an ESB environment.

SAG_

teCh

Spot

_SCA

_iss

2-09

_01A

pr09

to find the Software AG office nearest you, please visit: www.softwareag.com© 2009 Software AG. All rights reserved. Software AG and all Software AG products are either trademarks or registered trademarks of Software AG. Other product and company names mentioned herein may be the trademarks of their respective owners.


natural Spotlight

These approaches are broken and wrong

because they continue to bury complex

logic in silos – compromising future agility

in favor of taking the path of least resis-

tance. It’s much easier to keep doing

“business as usual” than to forge a better

path to solve the problems of the present –

one that does not compromise the future.

Nevertheless, you may need to continue

the operational qualities (e.g. performance,

availability) of these applications in our

new century.

Agility tomorrow...And Beyond...Pushing logic from mainframes to distributed

systems just pushes cost and complexity

sideways. It provides no new business

functionality or agility and fails to extract

the maximum value from investments

already made.

Instead of moving the logic “sideways” from

one complex developer code to another,

the trend is to truly express value to the

business by moving the logic “up” within

the business, to expose business services

and processes so that anyone can under-

stand their value.

Imagine if you could deliver a business

application that:

Dynamically adopts data structure changes

throughout all application tiers (e.g. from

a database to a user interface layer)

Renders the information automatically, depending on the connected end-user device (e.g. PC, Netbook, PDA, cell phone) and the context an end-user works in

•

•

technology Agility todAyBefore we think about new paradigms, it is

important to understand how business

applications are implemented today. Most

business logic (processes, workflows, rules

and functions) is still contained within

custom developed or packaged applica-

tions. Multi-tier application architectures

(e.g. Client-Server) and integration solutions

(e.g. Middleware, ETL, batch processes)

expand this business logic to other IT

systems that then interact with this business

logic or information in order to process it

further for the purpose of end-user interac-

tion, reporting, analyzing, data exchange

or follow-up computation. The flexibility of

these applications in the context of change

varies. However, the change that occurs is

usually in one of the following areas:

Changing or developing new source code

Changing customization parameters (e.g. in packaged applications)

Applying changes in each application tier, especially when changing data structures

Adopting the system infrastructure (e.g. to improve scalability)

In addition, the information and data that

form a logical entity (e.g. customer, order)

are mostly spread across different informa-

tion systems (e.g. databases, files, document

management systems, data warehouse),

making it a challenge to achieve a single

customer or order view.

•

•

•

•

buSinESS ApplicAtiOnS in 2015By Guido Falkenberg, Vice President, Deputy CTO, Software AG

those of us who support business applications are facing accelerating pressure to support new technologies and new business

demands. regardless of your vertical industry, mergers and acquisitions, new regulations and competition are driving a

breakneck pace of change. how can we develop applications that respect the past (avoiding expensive rip-and-replace), cope

with the present, but don’t compromise our future?

Scales according to defined service-level agreements (e.g. response time, concur-rent user)

Provides business activity monitoring by design

Gives multiple options of how to deploy business rules (e.g. code, rule engine)

Ensures transactional reliability and consistency even when hitting unpredict-able data volumes

Provides unified processing capabilities no matter where the data is stored or what data structure it has (e.g. database records, document management systems, Excel sheet, archives, data warehouse)

Develops reusable services and events no matter the programming language paradigm or underlying communication protocol

Runs business processes continuously even when the application portfolio is changing or new sourcing strategies are chosen

Synchronizes and automates business processes across IT applications, telecom-munication systems and batch environments

Provides automatic discovery and registra-tion of all application assets in a transpar-ent and manageable way

Actively involves business end-users in the development process, e.g. designing the user interfaces, business rules and processes in an interactive and collabora-tive fashion.

•

•

•

•

•

•

•

•

•

•

processes) or in an SOA/BPM centric area

(process C = e.g. workflow centric and

cross-application order approval processes).

Most business processes might always

have a mix of code and SOA/BPM (e.g.

business process C has 20% coding and

80% SOA/BPM logic). The future architec-

ture of business applications will give you

the flexibility to move processes from one

area to another to provide a key element

for speed and change flexibility (e.g. from

A to B). Software AG is committed to

linking the building blocks, helping you to

develop business applications that are

ready for 2015 and beyond.

SAg_

nAt

Spot

_Bus

Apps

2015

_iss

2-09

_31m

ar09


Does this sound too good to be true? Well,

you might be right, but let’s connect some

‘dots’ that we are already seeing in today’s

IT world. Did you ever think 10 years ago

that you would use your office desktop

application in a “cloud” (‘Software as a

Service’ – SaaS), not knowing where it was

hosted and always flexible enough to scale

according to your data volume requirements?

Did you ever imagine that companies

would be able to have full transparency

across their supply chain, always knowing

how well the business was doing in real-

time? Or did you ever think that business

processes could be impervious to applica-

tion changes and dynamically change their

behavior based on trend/predictive analy-

sis or ad-hoc decisions of involved stake-

holders? The answer to nearly all of these

questions is most likely a resounding ‘NO’,

or at least a skeptical ‘maybe’, depending

on the type of business application you are

considering (e.g. HR, ERP, CRM).

Current IT trends, such as Service-oriented

Architecture (SOA), Business Process

Management (BPM), Business Activity

Monitoring (BAM), Rich Internet Applications

(RIA), Software as a Service (SaaS), Virtual-

ization and Policy-driven provisioning of

system resources, are available today and

have proven their success in real-world

customer scenarios. These are some of the

first building blocks for future-building

applications – as the ‘dots’ get more and

more connected in an easy fashion, they

will create new levels of business applica-

tion dynamics.

Future architectures of business applications

will have a variable hybrid model, where

the technology is used in a dynamic best-

of-breed approach according to the business

process types they need to support. Figure 1

shows how different types of processes

stay in a code centric implementation area

(process A = e.g. month-end closing batch

Figure 1: Business Process types


natural Spotlight

If no changes occur in the memory struc-

ture of a buffer pool, any usage informa-

tion collected is of subordinate importance.

Serialization operations do not show any

advantage and – what is most important –

do not help to protect data against damage.

On the contrary, serialization operations

only consume CPU power and delay the

execution of Natural objects.

Basic concepts of a Read-only BuffeR poolThe read-only buffer pool is designed to

meet exactly the above mentioned re-

quirements. Provided the buffer pool

contents do not change, the serialization

operations in Natural’s buffer pool man-

agement can be skipped. To enforce the

inalterability of such a buffer pool, any

request which ends up in a structural

change of the memory layout is rejected

by the buffer pool manager.

Dropping the serialization operations

reduces the system time, as well as the

stall time. Stall time is the time one

Natural process, trying to perform a buffer

pool operation, has to wait for another

Natural process performing a buffer pool

operation. The reduction of system time

consumption benefits all processes running

on a machine, while the decrement in the

stall time improves the throughput of all

Natural processes.

The read-only buffer pool is from the

application’s point of view and is very

similar to an update-capable buffer pool.

status QuoAtomicity is not always an option running

applications performing concurrent opera-

tions. In many cases, concurrent processing

does not need to be serialized in order to

avoid data corruption. In particular, if

processes sharing data only need read

access to data, then precautions to avoid

data corruption due to concurrent updates

do not need to be taken.

Against this background the idea of a read-

only buffer pool was born. The main task

of Natural’s buffer pool is to reduce the

number of system file access operations.

The buffer pool manager concurrently loads

and stores Natural objects into a storage

segment shared by several Natural pro-

cesses and returns addresses of executable

code and constants held in a Natural object

to Natural’s runtime. Any request from

Natural’s runtime to get the address of an

object is serialized. While an object is

located and eventually loaded into the

buffer pool, any other process requesting a

service from the buffer pool has to wait

until the operation to locate and load an

object has finished, with, or without, success.

In a steady state, the change in the num-

ber of program loads per unit of time is

quite a small figure. In its optimum case it

is zero. If this figure is zero, all objects

needed by a Natural application are

situated in memory used by the buffer

pool. In this case, changes in the memory

structure maintained by Natural’s buffer

pool manager do not occur.

leveraging natural’S read-only Buffer pool feature tO dElivEr A HigH-PErfOrmAncE SOA PrOductiOn EnvirOnmEntBy Martin Hugentobler, R&D Specialist, Natural Open Systems, Software AG

this article explains how to improve performance and reduce resource requirements for natural applications running in open

systems production environments. it also describes how to optimize and tune your production environment to deliver a high

performance soa production environment. the basic concepts of a Read-only buffer pool and how to configure the buffer pool

to achieve optimal performance are introduced.

Any request from Natural’s runtime to load

an object is answered with either the

address of that object because it was

found in memory or with error NAT0082.

An update-capable buffer pool returns

error NAT0082 only if the object requested

was not found in the system file.

The differences with an update-capable

buffer pool are seen mainly on an adminis-

trative level. The start up procedure of an

update-capable buffer pool allocates storage

and semaphores in the size and amount

defined by the system administrator. Data

is loaded on request by Natural’s buffer

pool manager without any additional

interaction. If necessary, unneeded data is

deleted and replaced by requested data.

A read-only buffer pool requires prepara-

tory work. All objects that the read-only

buffer pool shall hold must be registered in

a preload list. During start up of a read-

only buffer pool, storage is allocated in the

size defined by the system administrator.

The previously worked out preload list is

read and an attempt is made to load

objects described in that preload list into

the buffer pool. As soon as the preload list

has been processed with success, a Natural

session can attach to the read-only buffer

pool and execute an application.

The login procedure performed by each

Natural session using an update-capable

buffer pool is not required when accessing

a read-only buffer pool. Most of the

semaphores within an update-capable

the number of attempted locates did not

change since the last review), the applica-

tion can be changed to use a read-only

buffer pool only. If the contents of the

read-only buffer pool are shown to be

incomplete because of sporadic NAT0082

(“Objects not found”) errors, the read-only

buffer pool can be exchanged in flight by

an enhanced read-only buffer pool.

summaRy To summarize, a read-only buffer pool can

improve the overall performance and reduce

resource requirements of a computing

system that includes Natural applications

running in Open Systems. The essential

advantages of using a read-only buffer

pool are:

An unlimited number of users may use a

read-only buffer pool

Under UNIX, a read-only buffer pool does not use any semaphores

In a Windows environment few sema-phores are used to serialize start up and shutdown processing of a read-only buffer pool

Using a read-only buffer pool, a perfor-mance gain and a throughput increment is achieved due to the reduction of:

System time Stall time

As a read-only buffer pool has no update

capabilities, it should only be run in a

carefully set up environment where error

NAT0082 (“Object not found”) is either

tolerable or – even better – cannot occur

because all objects needed by a Natural

application have already been loaded into

the read-only buffer pool. Using the read-

only buffer pool feature in Natural helps

you optimize and fine-tune applications to

deliver high performance in SOA produc-

tion environments.

•

•

•

•

--

saG_

nat

spot

_Rea

d-on

lyBu

ffer

_iss

2-09

_30m

ar09

to find the Software Ag office nearest you, please visit: www.softwareag.com© 2009 Software Ag. All rights reserved. Software Ag and all Software Ag products are either trademarks or registered trademarks of Software Ag. Other product and company names mentioned herein may be the trademarks of their respective owners.

buffer pool, i.e. all semaphores used to

identify the users, maintain usage counts

and run cleanup procedures. These are

useless within a read-only buffer pool. This

means that an unlimited number of users

(Natural sessions) can access such a read-

only buffer pool.

The read-only concept bears intrinsic

disadvantages. These are:

The missing capability to load objects

once the read-only buffer pool has been

set up can disturb a production environ-

ment. How to circumvent this shortcom-

ing is described below.

Storage requirements can increase as all objects needed by an application have to be present in the buffer pool.

CATALOG / SAVE or STOW operations, as well as system file updates through SYSMAIN or SYSOBJH, have no effect on the contents of the read-only buffer pool; objects loaded into the read-only buffer pool will never be replaced.

extended concepts usinG a Read-only BuffeR pool To relieve the deficiencies of a read-only

buffer pool to update its contents at any

time and to allow a 7x24 operation of

Natural (or a Natural session) using a read-

only buffer pool, two additional buffer pool

types have been introduced:

An alternate buffer pool

A backup buffer pool

To each read-only buffer pool an alternate

buffer pool can be assigned. The alternate

buffer pool must be a read-only buffer pool

as well. Natural sessions can be forced to

detach from a read-only buffer pool and to

attach in flight to the alternate buffer pool

using the NATBPMON command “SWAP”.

This allows replacing an incomplete read-

only buffer pool with a new improved read-

only buffer pool without stopping the

execution of Natural. The obsolete read-

only buffer pool can then be shut down,

•

•

•

•

•

restarted with an improved preload list, and

put into production again.

A backup buffer pool is an update-capable

buffer pool. A Natural session running with

a read-only buffer pool can be told to use

a backup buffer pool as secondary buffer

pool. If a call to locate an object in the

primary read-only buffer pool fails (be-

cause the object is not found in that buffer

pool) Natural’s buffer pool manager will

pass that call to the secondary (or backup)

buffer pool which will try to load that

object and allow Natural runtime to

execute that object in the secondary buffer

pool. The Natural application will not notice

the absence of an object in the primary

read-only buffer pool. However, the

number of sessions that can use such an

execution environment is limited to the

maximum number of users defined for the

backup buffer pool.

How to set up an enviRonment usinG a Read-only BuffeR pool Using a read-only buffer pool as the

primary buffer pool and a backup buffer

pool as the secondary buffer pool is a

method to change a production environ-

ment from using a read/write capable

buffer pool to only use a read-only buffer

pool and to allow an unlimited number of

users to access the read-only buffer pool.

As the complete extent of an application is

seldom known, a read-only buffer pool can

be set up with all objects known to be

used by the application. Natural can then

run using as the primary buffer pool, the

read-only buffer pool and as the secondary

buffer pool, the backup (a read/write

capable) buffer pool. The contents of the

secondary buffer pool show exactly those

objects that were not known to belong to

the application, i.e., those objects not found

by Natural in the primary read-only buffer

pool. The preload list(s) can be enhanced

by adding the contents of the secondary

(or backup) read/write capable buffer pool.

As soon as the secondary buffer pool is not

accessed any longer (for example, because


natural Spotlight

Programmers are often unaware of how MultiFetch works. How-

ever, they may have heard how much they can save by employing

MultiFetch. They seek out applications with a lot of READ’s and/or

FIND’s, and promptly modify READ’s and FIND’s to include Multi-

Fetch. This can lead to trouble. The following is an adaptation of a

real life experience.

When nOT TO MulTiFeTchRecently, I was teaching a class where the topic under discussion

was the new feature in Version 4 of Natural to ESCAPE TOP REPO-

SITION. I was comparing the code using this feature versus the

“old” approach of placing a READ loop within a “dummy” REPEAT

loop. Someone in the class wondered whether the new code

would solve a problem they had that necessitated the dummy

REPEAT loop code. I asked for a description of the problem. I will

simplify their description a bit to maintain just the portions rel-

evant to our discussion.

The Problem

We have an order file. There are many line items per order. Every

line item of every order is a separate record (it is not in our

purview to suggest a redesign with a PE). Line item numbers are

assigned serially. There is a super descriptor which concatenates

the order number and line number. Thus, we might have order

number B8752 with nineteen line items. Therefore, there will be

nineteen records, each with a separate line item.

There is an application which accepts an order number. It then

reads by the super-descriptor (in our example, the values of the

super would be B875201…B875219). It is quite possible that in

the process of reading the line items for an order, a new line item

(record) is created for the order. The line item number will be the

next one available (existing maximum plus one). In our example,

we might have read the record with super B875204 then created

a record with super B875220.

Consider a simple READ loop:

Assume there are 2000 records that are included in our specified

range. The READ loop will issue 2000 calls to Adabas. Each call to

Adabas will result in a record being read from the database, then

“stripped” (to extract the requested fields from the record) and

“decompressed” (padded out with trailing blanks or leading zeroes

for passage back to the calling program).

Suppose we now have:

Instead of 2000 calls to Adabas, there will be 20 calls to Adabas.

Each call will read 100 records, each of which will be stripped and

decompressed and returned to your Natural program in the Record

Buffer, from which they are placed in a MultiFetch buffer. Note

that MultiFetch does not save record reads (the same 2000

records will be read, stripped, and decompressed). It does, how-

ever, save Adabas calls. Actually, in this example, we will save

99% of the original 2000 Adabas calls. Adabas calls are expensive

(assuming you are not a DBA, just ask your DBA about the cost of

Adabas calls).

USing natUral’S MUltiFetch FeatUre tO imprOvE pErfOrmAncE in SOA EnvirOnmEntSBy Steve Robinson, Publisher of Inside Natural, Developer of “Simply Natural”, Presenter of Natural Seminars, and President, S.L. Robinson and Associates, Inc., U.S.

There have been many enhancements to natural version 4. One of the most important new features, when performance is

critical, is MultiFetch. Many programmers today are using MultiFetch without really understanding what it is and what it can do

for them. This lack of understanding leads to problems, one of which we will discuss here. First, however, i will provide a brief

discussion on why MultiFetch is such an important performance tool for natural applications in SOA environments.

READ PRODUCTS BY PROD-CODE STARTING FROM ‘B’ TO ‘BZ9999’:::END-READ

READ MULTI-FETCH OF 100 PRODUCTS BY PROD-CODE STARTING FROM ‘B’ TO ‘BZ9999’

2

And here are the JONES records.

Okay, as we can see above, there are nine JONES records.

Here is a slight variation from the previous program:

Note we have a MULTI-FETCH of six for our READ. Also note that

when we get to ROBERT JONES, the third JONES (see output

above), we will STORE a new record with the FIRST-NAME of IS

THIS THERE.

Let’s discuss what the effect of the MULTI-FETCH is.

The program calls Adabas which returns six records. If you look above at the output from MULT01, these are the records for VIRGINIA through MARTHA JONES.

Natural will process the first six records using the data from the MultiFetch buffer. When we get to ROBERT JONES, we create our new JONES record.

After processing MARTHA JONES, our program calls Adabas again. Adabas places six records in its record buffer for return to Natural. The six records will be the remaining original JONES records (LAUREL, KEVIN, and GREGORY), the new JONES record (IS THIS THERE) and two additional records (with last names JOPER and JOUSSELIN). If I had used TO, rather than ENDING AT, the two additional records would not have been read (This can be VERY important when using MultiFetch).

•

•

•

Originally they had simple code such as:

Sometimes, when this organization reached the end of an order,

they would see the new line item record, which is what they

wanted to see. However, the problem was that at other times,

they did not see the new record. Up until six months ago, they

always saw the new line item record.

So, put your thinking caps on...What might have caused the

change six months ago?

A MultiFetch “Gotcha”!

As we discussed above, MultiFetch “reads ahead” in order to

reduce Adabas calls. We will demonstrate the potential problem

using the familiar Employees file. Here is a simple program that

displays the JONES records from our file (yes, I could have used

the new option TO, rather than ENDING AT; this would not have

affected the scenario that will unfold).

READ ORDER-VIEW BY ORDER-LINE-NUMBER STARTING FROM #ORDER-LINE-ONE IF ORDER-NUMBER NE #ORDER-NUMBER ESCAPE BOTTOM IMMEDIATE END-IF :::: IF some condition ::::::::::: STORE new line item record END TRANSACTION END-IF ::::: END-READ

> > + Program MULT01 Lib XSTRO 0010 DEFINE DATA LOCAL 0020 1 MYVIEW VIEW OF EMPLOYEES 0030 2 NAME 0040 2 FIRST-NAME 0050 END-DEFINE 0060 * 0070 INCLUDE AATITLER 0080 * 0090 READ MYVIEW BY NAME 0100 STARTING FROM ‘JONES’ 0110 ENDING AT ‘JONES’ 0120 DISPLAY NAME FIRST-NAME 0130 END-READ 0140 * 0150 END

MORE PAGE # 1 DATE: Feb 02, 2009 PROGRAM: MULT01 LIBRARY: XSTRO NAME FIRST-NAME -------------------- -------------------- JONES VIRGINIA JONES MARSHA JONES ROBERT JONES LILLY JONES EDWARD JONES MARTHA JONES LAUREL JONES KEVIN JONES GREGORY

> > + Program MULT02 Lib XSTRO 0010 DEFINE DATA LOCAL 0020 1 MYVIEW VIEW OF EMPLOYEES 0030 2 NAME 0040 2 FIRST-NAME 0050 END-DEFINE 0060 * 0070 INCLUDE AATITLER 0080 * 0090 READ MULTI-FETCH OF 6 MYVIEW BY NAME 0100 STARTING FROM ‘JONES’ 0110 ENDING AT ‘JONES’ 0120 DISPLAY NAME FIRST-NAME 0130 IF FIRST-NAME = ‘ROBERT’ 0140 MOVE ‘JONES’ TO NAME 0150 MOVE ‘IS THIS THERE’ TO FIRST-NAME 0160 STORE MYVIEW 0170 END-IF 0180 END-READ 0190 BACKOUT TRANSACTION 0200 END

3

SuMMAryThere are many variations of the problem we have just discussed.

It is important, when you consider using MultiFetch, that you also

consider the possible implications of record updates (STORE,

DELETE, UPDATE) in your program AND other programs.

MultiFetch is an important tool in enhancing the performance of

Natural applications in SOA environments. Understanding how to

properly use MultiFetch and avoid the problem we discussed in

this article will help you continue to fine tune your Natural appli-

cations to meet the needs of your SOA.

Our output is shown below.

I made one minor change to our program, as shown below:

Let’s discuss what happens. The processing of the first six records

is the same, EXCEPT, while processing ROBERT we did not create

our extra record.

After processing MARTHA, our Natural program calls Adabas and

reads six records into the MultiFetch buffer; namely, the last three

JONES records (LAUREL, KEVIN, and GREGORY) and three more

records with last names JOPER, JOUSSELIN, and JUBE.

While processing the record for KEVIN, we STORE our new

JONES record.

NOTE: creating the new JONES record does NOT modify the

MultiFetch buffer. I think you now realize what will happen.

After processing GREGORY JONES, the next record in the MultiFetch

buffer has a last name of JOPER. We will therefore exit our READ

loop, without ever having seen the new JONES record, as

shown below.

MORE PAGE # 1 DATE: Feb 02, 2009 PROGRAM: MULT02 LIBRARY: XSTRO NAME FIRST-NAME -------------------- -------------------- JONES VIRGINIA JONES MARSHA JONES ROBERT JONES LILLY JONES EDWARD JONES MARTHA JONES LAUREL JONES KEVIN JONES GREGORY JONES IS THIS THERE

0130 IF FIRST-NAME = ‘KEVIN’

MORE PAGE # 1 DATE: Feb 02, 2009 PROGRAM: MULT03 LIBRARY: XSTRO NAME FIRST-NAME -------------------- -------------------- JONES VIRGINIA JONES MARSHA JONES ROBERT JONES LILLY JONES EDWARD JONES MARTHA JONES LAUREL JONES KEVIN JONES GREGORY

SAG_

nAT

Spot

_Mul

ti-Fe

tch_

iss2

-09_

31M

ar09


Reprinted with permission of Steve Robinson, President, S.L. Robinson and Associates, Inc., 28 Teal Drive, Langhorne, PA 19047, U.S.; Phone: 215-741-0820; Email: [email protected]. This article is an excerpt from an Inside Natural article that appeared in May 2008 (page 25). If you would like to read the entire Inside Natural article on MultiFetch and your company does not subscribe to Inside Natural, please go to the Software AG Technical Forums: http://tech.forums.softwareag.com/ If you are not registered at the technical forums, you will see a message that says Hello Guest, and you will also see a box that says Register. Click on that box and sign up as a registered reader of the Forum. There is no fee for this. You must be a registered reader to download attachments, although you can read postings without registering. Click on Natural General. Then click on Inside Natural. Finally, click on MultiFetch Article. The PDF for the article can be downloaded to your PC. If you have just registered for the Forum for the first time, after reading the article, peruse the site a bit. You will discover that there is a wealth of information for many Software AG products available at this site.


AdabasSpotlight

An Out-DAteD ApprOAch tO IntegrAtIOnThe reason for major problems and headaches when it comes to integrating new software

with existing IT systems is very much down to the traditional approach to software integration.

Take a typical scenario where some existing, monolithic business logic on a core platform

needs to be reused as part of a Microsoft Visual Basic application. The traditional method

of dealing with this would involve the following steps:

1. Designing and agreeing on an interface that will be used to enable the VB client and

the business logic to communicate.

2. Installing a messaging system, such as MQ Series, to enable the VB client to communicate with the business logic.

3. Ensuring customer server code enables the acceptance of messages from the VB client to invoke the business logic and return the response to the VB client. (While in theory, it is a simple enough exercise to handle messages from one client, the reality is that this code must be in a position to handle requests from a multitude of clients at the same time, thus making this logic infinitely more complex than a normal ‘batch type’ application.)

4. Writing and testing the VB client, but only when the above has been completed.

These steps characterize projects that are generally high in both risk and cost. This has driven the search for an alternative. Today that search is over, with the avail-ability of Adabas SOA Gateway.

Why is it integration problematic?By John Power, CEO, Risaris

the IntegrAtIOn chAllengeWhen it comes to technology projects

there is one stark statistic that should

make you take notice. Organizations

are finding up to 70% of the cost of

any software project can be soaked

up by integration with existing it

assets, according to a leading analyst

firm. Even more worrying is the fact

most of these ‘integration’ projects

go over budget, are not delivered on

time, and many even fail.

medium and large-size organizations

generally adopted software platforms

(such as the ibm mainframe systems)

in the past for good reasons that still

hold true today. Over the years they

have developed multiple applications

to represent the data and business

logic that have become the core

assets of their business.

Why is integration so problematic and how can organizations significantly reduce the cost, complexity and risk associated with

integration projects? this article looks at the traditional approach to integration and contrasts it with a new approach that

dramatically reduces the time, complexity and cost of integration projects.

Custom Interface

MQ Messaging

Custom Interface

Custom Service Logic

MQ Messaging

Business LogicScreen Logic

SImplIfyIng IntegrAtIOnAdabas SOA Gateway removes a massive degree of the effort and risk associated with

traditional integration.

So forget the traditional approach and imagine utilizing the following streamlined,

effective and efficient steps when it comes to your integration project:

1. Install Adabas SOA Gateway.

2. Use a configuration wizard to wrap and make business logic available in minutes.

3. Write and test the VB client application against a real server.

This straightforward, no-fuss approach offers the following major advantages:

Significant reduction in cost due to less custom code.

Risk is limited or abolished, as the logic is made available immediately.

Software does not need to be installed on the client system.

Both unit and integration testing can take place immediately.

Communication between client and server may be secured with the standard SSL protocol.

ADAbAS SOA gAteWAy explAIneDSo how is it possible to simplify the integration and application modernization challenge?

Given the Adabas SOA Gateway installation is a once-off event on a given platform, the

steps required to wrap a single piece of business logic are easy:

1. The structure(s) identifying the inputs and outputs to the business logic is identified

and imported into an Eclipse-based tool.

2. The fields in the structure are marked for ‘input only’, ‘output only’, or ‘input and output’.

3. The definitions are exported to the Adabas SOA Gateway Server.

4. The service is published and is now available to the client.

•

•

•

•

•

2

Business Logic

Screen Logic

AdabasSOA Gateway

AdabasSOA Gateway

AccountsApplication

AcceSSIng DAtA the trADItIOnAl WAyThere are also occasions when an integration effort requires access directly to data in an

existing database. As with the exposure of business logic, getting access to the data in

the traditional way is expensive, time consuming and fraught with difficulties.

Assuming a Java client running on Windows wishes to access some core data, the following

would generally be the traditional approach:

1. Designing and agreeing on an interface that will be used to enable the Java client to

talk to a custom data server.

2. Installation of a messaging system, such as MQ Series, to enable the Java client to communicate with the custom server.

3. Enabling custom server code to accept messages from the Java client, to access the database and return the response to the Java client. (As with the previous example, this custom code must be in a position to handle requests from a multitude of clients at the same time thus making this logic infinitely more complex than a normal ‘batch type’ application.)

4. Writing and testing the Java logic, but after the above steps have been completed.

hOW IS thAt SImplIfIeD by the uSe Of ADAbAS SOA gAteWAy?

1. The structure of the database table or file can be determined from the database and

imported into an Eclipse-based tool.

2. The definitions are exported to the Adabas SOA Gateway Server.

3. The service is published and is now available to the client.

As shown in the diagram, Adabas SOA Gateway eliminates the need for writing any code

on the database side.

3

Custom Inteface

MQ Messaging

Custom Interface

Custom Data Access Application

MQ Messaging

Existing Database

z/OS

TM

AdabasSOA Gateway

TM

eASy AcceSS tO cOre DAtA ASSetSUsing Adabas SOA Gateway gives equivalent integration characteristics to business logic

integration, as in the earlier example, while offering the following benefits:

Integration with existing database and business logic assets can be achieved in hours instead of weeks or months.

Services may be reused again and again.

Unit testing can be simply done with off-the-shelf tools.

Integration testing is less time consuming as it clarifies where information is being sent and what information is being returned.

Projects can be delivered on time and within agreed budgets.

Integration costs are reduced by 35% plus.

Programmers can focus on creating valuable business applications instead of spending up to 70% of their time working out how to get to the legacy information.

Organizations adopting Adabas SOA Gateway for their IT integration projects can rest

assured they will no longer be one of those organizations wasting their software budgets

on time-consuming, hard-to-manage integration problems.

Reprinted with permission of Rísarís Limited, 6 The Mill Buildings, The Maltings, Bray, Co Wicklow, Ireland; Phone: +353(1)2768040; Fax: + 353 404 66464; Email: [email protected].

•

•

•

•

•

•

•

SAg_

ADAS

pot_

Inte

grat

ionp

robl

em_I

ss2-

09_1

7mar

09



webmethods Spotlight

capabilities of the product, but its service-

centric architecture was there from the

start – “webMethods B2B provides the

secure, scalable and robust service-based

infrastructure needed to leverage XML

vocabularies for the purpose of binding

business processes together over the

Internet.”

A mere seven months later, webMethods

B2B 3.0 was released. It included FLOW,

“a process-oriented language developed

by webMethods for visually linking B2B

services between business systems.” This

seamless mix of document orientation

(common in B2B products) and service

orientation (allowing basic process orches-

tration) was touted as webMethods’

competitive differentiator.

Let’s dispense with the history lesson and

take a look at what constitutes a service in

webMethods ESB Platform.

A service is essentially a piece of processing

logic that takes some input data, does

something with that data, and returns output

to the caller. Here are some examples of

simple services:

Take two strings as input and return a

single string consisting of the concatena-

tion of the inputs.

Validate an XML document against

its schema.

Transform an EDI document into an

XML format.

•

•

•

Firstly, let’s not confuse Service-oriented

Architecture (SOA) with Web services. Web

services and the WS* standards are emerg-

ing as the de-facto protocols for imple-

menting SOA, but the basic concepts of

SOA are much more generic:

Technology abstraction

Inter-operability

Loose coupling

Reusable services

Network-accessibility

When webMethods began as a company

back in the 1990s, it had the vision to use

the web to integrate business processes

across company boundaries using standards-

based services to wrap internal systems

and exchange data using agreed formats.

It submitted a proposal as early as 1997 to

the World Wide Web Consortium (W3C, the

standards body that oversees most web-

based standards) for Web Interface Defini-

tion Language (WIDL), “a Meta-language

that implements a service-based architec-

ture over the document-based resources of

the World Wide Web.” Sound familiar?

WIDL was a precursor to the Web Services

Description Language (WSDL), which was

drafted four years later.

In its early years, webMethods developed

the B2B Integration Server. Its first notable

release was version 2.1, launched with much

fanfare at the Gartner ITxpo conference in

March 1999. The press release focused

heavily on the business-to-business (B2B)

•

•

•

•

•

10 yEArS Of SOA with thE webMethodS eSb platforMBy Jonathan Heywood, Product Manager, webMethods ESB Platform, Software AG

“Hang on a minute!”, I hear you think, “SOA has only been around for about five years, and even the earliest Web service

standards were not drafted until 2001. So how can you claim 10 years of SOA?” Well…let me enlighten you…

Service-oriented architecture

(wikipedia)

in computing, service-oriented

architecture (Soa) provides methods

for systems development and integra-

tion where systems group functionality

around business processes and pack-

age these as interoperable services.

An SOA infrastructure allows different

applications to exchange data with

one another as they participate in

business processes. Service-orientation

aims at a loose coupling of services

with operating systems, programming

languages and other technologies

that underlie applications. SOA

separates functions into distinct units,

or services, which developers make

accessible over a network in order

that users can combine and reuse

them in the production of business

applications. these services commu-

nicate with each other by passing

data from one service to another, or

by coordinating an activity between

two or more services.

http://en.wikipedia.org/wiki/

Service-oriented_architecture

Nowadays, there is a lot of focus on the

aspects of SOA that make it work in a

large organization, such as governance,

security, process orchestration and compos-

ite applications. And this is where the

webMethods suite really comes into its

own. The tight integration across all the

products allows companies to leverage

even more value from their webMethods

service assets through governance (with

CentraSite), process orchestration and

monitoring (with webMethods BPMS) and

composite applications (with webMethods

Composite Application Framework).

In 2003, the webMethods B2B Server name

was changed to webMethods Integration

Server to reflect more EAI-like usage

patterns. As the market for EAI and ESB

continues to evolve, we have seen the

dawn of the next generation of our product,

webMethods Enterprise Service Bus Platform

(ESB). The webMethods ESB Platform

stresses its role in SOA enablement, integra-

tion and orchestration. The product has

evolved, but the core foundation has

remained the same. Our strong leadership

position in the Forrester Wave™ for Enter-

prise Service Buses1 (complimentary copies

of the Forrester Wave and other Waves

may be downloaded from the Software AG

website at http://www.softwareag.com/

awards) and other analyst rankings are

proof that webMethods hit the nail on the

head all those years ago. In the webMethods

ESB Platform everything is, and always has

been, a Service.

1 The Forrester Wave™: Enterprise Service Buses, Q1 2009, Forrester Research, Inc., January 2009.

SAG_

WM

Spot

_ESB

Plat

form

_Iss

2-09

_12M

ar09


FLOW

Java

C/C++

Adapter

XSLT

.NET

Implementation

HTTP(s)FTP

SOAPJMS

webMethods BrokerScheduler

E-mailBPM Step

Java clientC/C++ client

VB clientInvoke from FLOW

Adapter notification

Invoke Method

ESBService

Services may also interact with an external

resource, such as a database or packaged

application. Examples of these services

might include:

Read a series of inventory transactions

from a flat file.

Look up the SAP customer number for a

given DUNS ID in a database.

Create a sales order in SAP using a

BAPI call.

And, of course, a service may consist of a

series of other services to provide a more

high-level, business-like function:

Place order – consisting of…

Transform EDI document to XML

Validate XML

Lookup SAP customer number

Create sales order in SAP

What webMethods ESB Platform does so

successfully is separate the implementation

of a service from the method of invocation.

Pretty much any service, however it is

implemented, can be invoked using a wide

range of protocols (Figure 1).

•

•

•

•

-

-

-

-

You can build a service in Java and invoke

it from a C++ client. You can have an

incoming e-mail trigger a .NET assembly.

And you can configure a received JMS

message to be forwarded to SAP as an

IDOC. The possibilities are endless. The

webMethods ESB Platform allows

Software AG to add more implementation

choices and more invocation methods in

the future. If a company has a service they

developed with webMethods B2B Server

in 2000 (before the days of Web services),

then they can enable that service to be

called as a Web service today with just a

few clicks.

With the intuitive IDE webMethods Devel-

oper (now moving to the Eclipse-based

webMethods Designer), even the most

complex of services and integrations can

be built without ever writing a single line

of code. Java services are typically only

needed for low-level technical utility

functions where FLOW would be too

cumbersome or inefficient. For the vast

majority of webMethods ESB Platform

customers, well over 95% of their code

base is FLOW.

FIGurE 1: ESB Service Abstracts Implementation from Invoke Method



actually realized ROI from their SOA efforts,

according to a recent survey¹.

So if the promise of SOA is business agility,

but the present reality (for many) is a small

pilot project, just a handful of services in

production or a mythical ROI – one wonders –

what makes this paradigm shift any differ-

ent than the ones that came before it?

The reality is that there is no “one-size-fits-

all” enterprise SOA solution; implementing

SOA is not so easy. While SOA raises expec-

tations and possibilities, it also increases

interdependencies and organizational

complexities (Figure 1). For example, now

we want to promote not just reuse, but

reuse enterprise-wide; yet obtaining enter-

prise-wide agreement can be a challenge.

1 “Best Practices for SOA Governance” User Survey, Software AG, May 2008

Our purpose here centers on bringing

clarity to SOA, SOA Governance and some

related subjects, as well as to show how a

modular and integrated approach can help

manage SOA complexities and fast-track

business agility.

To cut through some of the technical

jargon surrounding SOA and SOA Gover-

nance, we begin our discussion using a

business-level abstraction of both: in the

larger sense an SOA is about realizing

business agility and SOA Governance

facilitates this by enabling the acceleration

of business change in a controlled manner.

Interestingly enough SOA, in contrast to

previous IT technology paradigms, has the

attention of both “ends” of the enterprise –

business and IT. However, despite this

interest and time in existence, only about

one-third of the SOA adopters to-date have

SoA AnD SoA goVErnAnCE: GOinG bEyOnd thE hyPEBy Justin Vaughan-Brown, Senior Director Communities, Software AG

Despite millions of web references for Service-oriented Architecture (SOA), over a decade in existence and the fact that more

than two-thirds of enterprises today are “using or planning to use it,” there isn’t one commonly accepted definition for SOA.

SOA Governance is a related term that shares a similar lack of a singular definition. In spite of the confusion, one thing is clear:

SOA and SOA Governance are rather complex topics.

FIGure 1: Interdependence Creates Complexity

Service-oriented Architecture (SoA)

aims to deliver business agility by

using services (small ad-hoc modules)

that can be quickly built, assembled

and employed to meet dynamic

business needs. An SOA is supported

by an it infrastructure, development

methods, organizational processes

and integration capabilities all geared

towards loosely coupled services. An

SOA is like a giant lEGO set: the

blocks are different sizes, shapes

and colors; they are combined in a

predictable and uniform way; yet

they are completely flexible, so you

can quickly create many different

things again and again. Just as lEGO

can create buildings, cars, people

and even art, an SOA can reuse and

adapt existing technologies to meet

organizational demands.

SoA governance is the art of ensur-

ing that the enterprise is creating

the right lEGO blocks, combining

them in the right ways and doing it

consistently across the enterprise to

effectively realize the business

objectives. Early application of SOA

Governance lays the foundation for

success of the SOA initiative.

Serv

ICeS

Automated

Manual

Redundant

Customers

Mainframe

Hr

CrM

Finance

Third-party

Logistics

erP

Partners

Manual

New expectations of visibility and inter-

operability are running up against familiar

territory: complex infrastructures, a business

playing field that is under constant change

and enterprise divisions that may not want

to collaborate. Plus the challenges of

delivering information are still far different

than the challenges of using it to drive

business competitiveness.

Yet despite the complexities and constant

change, some organizations have been able

to transform their information silos into the

holy grail of “alignment of business and IT.”

While no two SOA implementations or

strategies are exactly alike, companies

successful with SOA do seem to share some

key commonalities; a foundation for SOA

success, if you will. These range from using

an SOA road map and starting with SOA

Governance early on, to ensuring that the

SOA initiative actively involves the busi-

ness side and follows an approach that

suits an add-as-you-go mentality.

Of these, SOA Governance is emerging as

one of the most important to get an SOA

initiative off to the right start, deliver

business value quicker and improve agility.

Implementing SOA without governance

can quickly lead to issues, and ultimately

project failure (See 10 Dangers of an

Ungoverned SOA). SOA Governance helps

navigate the complexities introduced with

an “SOA jungle,” provides a holistic enter-

prise view, manages business changes and

provides measurements for compliance

and success. SOA Governance helps ensure

that SOA meets the organizational business

drivers, such as measurable ROI, greater IT

and business alignment, real-time business

visibility, reduced risks, improved quality

and business and regulatory compliance.

Beyond getting an SOA initiative off to a

good start though, SOA Governance is

essential to achieving SOA’s potential for

long-term success. This is because SOA

Governance encompasses all SOA activities

throughout the lifecycle, from the initial

definition through creation and execution.

Using a structured approach helps imple-

ment SOA Governance effectively across

the enterprise. The Governance Reference

Framework² (Figure 2) classifies the recom-

mended elements for effective implemen-

tation of SOA Governance and management

of SOA Assets into three groups:

Organizational elements relate to

people; what roles and structures are

needed to define, enforce and monitor

SOA governance policies.

Norms relate to policies, procedures and

processes; what standards are needed to

govern the activities surrounding SOA.

Technology relates to the tools; techno-

logies that support SOA Governance to

define, enforce and monitor the norms.

The methods that the Governance Reference

Framework provides to measure and guide

the SOA Governance plan can be adapted

to suit the organization’s needs. In addition,

it helps an enterprise transition and fine-

tune its organizational structure for more

effective SOA Governance. This can be, for

example, by establishing an SOA Compe-

tency Center (Figure 3) to gain the needed

skills for SOA within the organization.

2 Approach to Service-Oriented Architecture (SOA), Deployment Accelerator”, Software AG, October 2007

•

•

•

10 DANGerS OF AN uNGOverNeD SOA

1. modeling process has no visibility of existing services and the processes they impact

2 Services may be accessed by those not entitled to do so

3. no awareness of the impact of changes made to one service has upon another related one

4. Absence of quality assurance processes before a service is deployed

5. lack of holistic view of how it and business are interlinked

6. Poor understanding of service deployment, consumption or downtime

7. Policy enforcement is manual, unstructured, and sporadic

8. no overall view of existing services means they are recreated again, not reused

9. Absence of lifecycle management creates version control issues

10. lack of responsibility and ownership regarding service creation and consumption

2

FIGure 2: Governance reference Framework

NOrMS ¬ policies

¬ procedures

¬ processes

OrGANIzATIONAL eLeMeNTS

TeCHNOLOGy

SOAASSeTS

The Governance Reference Framework also

provides a set or catalog of norms that a

company can use to jump-start its SOA

Governance initiative. These norms help

guide how the SOA actors perform their

activities to best serve the needs of the

company. Technology is the third funda-

mental element; these are the tools that

facilitate effective SOA Governance. The

right tools allow you to plan, design, manage

and govern SOA infrastructures that support

the enterprise’s objectives across all aspects

of the SOA lifecycle.

TOOLS CAN HeLP CrOSS THe rOI LINeIn fact, the choice of SOA Governance tools

and when an organization implements them

can often mean the difference between

success and failure of the SOA initiative. An

SOA is by nature complex, often crossing

multiple departments, external groups,

customers and partners. Just one service

that delivers customer information, for

example, could be consumed by the

customer (to update their information),

finance (to validate and track the customer’s

bill) and logistics (to ship the customer’s

order.) In each case, there may be different

policies surrounding the use of that service.

Tools are an essential part of these pro-

cesses, without them an organization

cannot manage and govern their SOA.

Many companies start off their SOA initia-

tives with the “management by Excel”

approach. They list their small but growing

catalog of services in an Excel spreadsheet,

a virtual registry or “yellow pages”. How-

ever, this approach is quite inadequate for

the complex, dynamic nature of an SOA.

exCeL IS yeT ANOTHer SILOBesides the obvious downside of yet

another manually maintained spreadsheet,

Excel is not interconnected with the systems

that are used to develop, deploy and run

elements related to SOA. As services move

through the lifecycle, at each step of the

process, the Excel sheet would need to be

updated; and as services are being con-

sumed, what then? How can an organiza-

tion ever hope to measure if a service met

the defined SLA or enforce a policy if the

information is trapped in a spreadsheet?

Using Excel or other unintegrated technolo-

gies limits the enterprise’s ability to grow

and adapt their SOA; plus these fail to

provide a holistic enterprise SOA view.

Rather it is better to start off with a small

set of flexible tools specifically designed

for the purpose of SOA, and add on as the

organization’s needs change. That way the

organization has tools that facilitate the

natural evolution of SOA; a “think big, start

small” approach.

LONG-TerM SOA FLexIbILITyFlexible, modular SOA and SOA Governance

tools have the biggest organizational impact.

With them you can grow and adapt SOA as

the organizational needs change over time.

Modular and automated toolsets allow you

to rapidly implement a customized, best-

of-breed SOA Governance solution; this in

turn promotes business agility, collaboration

and reuse. Interoperability, best practices

and open standards-based plug-in architec-

tures combine for a long term approach

that helps maintain SOA flexibility.

FIGure 3: SOA Competency CenterTM

helping you design and implement your SOA

SOA LIFeCyCLe ServICeS

SOA

MAT

urIT

y AS

SeSS

MeNT

SOA DISCOvery SOA reADINeSS ASSeSSMeN

T

Discovery Phase

Optimization Phase

Assessment Phase

Measure-ment Phase Planning

& Design Phase

execution Phase

SoA MEthoDology

leading analysts confirm that no

single solution or technology will be

able to meet the diverse SOA Gover-

nance requirements. Enterprises will

need the support of a good SOA

ecosystem, built from multiple ven-

dors with a registry that unifies them.

3

how to AChiEVE MAxiMuM buSinESS Agility with SoA – KEy pointS

As you have seen in this article, there are many facets of SOA Governance and a

wide range of integrations possible across the SOA lifecycle. Summarized below are

some of the key aspects in order to achieve maximum business agility with an SOA:

Consider the need for SOA Governance before you embark on your SOA initiative.

Think of the Governance Reference Framework – and consider your organization, its norms (policies, procedures and processes) and the technology tools that can help support SOA Governance.

A registry/repository should be at the heart of your technology tools, recording your services, their lifecycle stages, helping to enforce policies and acting as a command center for governing SOA.

Use a designed-for-purpose tool – not Excel as a quick fix or interim solution.

CentraSite, the market leading SOA registry/repository is a tool ideally suited for the command center role.

The registry and repository should be open and capable of integrating with other best-in-class solutions to provide comprehensive end-to-end SOA Governance. In addition, how do registry/repositories vendors approach integration with existing tools in your specific IT environment?

A great way to build up your understanding of an SOA registry/repository is to download the free Community Edition of CentraSite at www.centrasite.com.

•

•

•

•

•

•

•

SAG_

WM

Spot

_SOA

Gov_

Iss2

-09_

17M

ar09




Brings structure, scale and speed to

SOA initiatives

Guides reuse, automates SOA processes

and simplifies complexities and

interdependencies

Enables enterprise SOA Governance with

easy-to-use and automated end-to-end

lifecycle management

CentraSite is pre-loaded with best practice

policies to accelerate SOA adoption and

lower project risks, and includes a structured

approach and service automation delivered

out-of-the-box. This includes Design and

Change Time Policies, such as Metadata

Validation, WS-I Compliance Check, WSDL

Validation, Asset Certification and Approval

Workflow; as well as Runtime Policies,

such as WS-Security, Monitoring and Alerts,

Routing and SLAs.

•

•

•

This visibility is not limited to services

either; all artifacts related to an SOA can

be centrally stored and accessed, no matter

whether they are related to planning,

design, development or runtime. This

promotes reliable communication and

interoperability among diverse users and

applications, especially enterprise-wide

and on a global-level. A central registry/

repository drives not only reuse but also

provides the ability to efficiently govern

across the entire lifecycle.

The CentraSite1 registry/repository is

recognized by top analysts as the market’s

leading SOA Governance and Lifecycle

Management platform. CentraSite is the

foundation for enterprise SOA Governance

initiatives because it:

CentraSite: OpEn, flExiblE And ScAlAblEBy Daniel Adelhardt, Senior Product Manager, Software AG

The flexibility and openness of the CentraSite

design ensures that business and SOA

objectives will continue to be met over the

long-term. CentraSite employs an open

standards-based plug-in architecture that

enables a modular and best-of-breed SOA

Governance approach (See diagram 1).

Enterprises seeking to improve business

agility using SOA Governance are no longer

required to:

Replace proven tools

Use a single vendor’s product stack from

end-to-end

Have their governance processes man-

dated by a certain vendor’s implementation

of governance

Struggle with manual synchronization or

a lack of interconnection between the

SOA Governance domains

While there continues to be a lot of discus-

sion surrounding emerging SOA standards,

SOA standards are not fully mature yet.

CentraSite architecture is based on an

open-standards approach and supports the

commonly-accepted SOA standards (See

SOA Governance Standards on next page).

That means that as best practices, tech-

nologies and solutions for SOA Governance

evolve, they can easily be interconnected

and implemented with CentraSite as a

flexible, powerful command center.

1 CentraSite is a registered trade name of Software AG and Fujitsu. More about CentraSite on www.softwareag.com/centrasite

•

•

•

•

Effective SOA Governance starts with a central registry/repository to act as a “collaboration hub” for all SOA-related efforts –

a view which has long been supported by leading analysts. An SOA registry/repository facilitates coordination because it provides

enterprise-wide visibility. For example, users can find all available services plus those under development or in planning phases.

Federation

. . . . . .

JAXR

Lifecycle Management

UDDI

Versioning

XQuery

WS Interface for Import

WebDAV

SmartPolicies

ActiveLifecycle

Backup

HighAvailability

Security

SystemManagement

Eclipse Plugins Web-based UI

CentraSite™ Data Store

DIAGRAM 1: CentraSite Architecture Overview

CentraSite provides an easy way to begin

using an SOA registry/repository with the

free of charge CentraSite Community

Edition2. Organizations with SOA initiatives,

consultants, system integrators and software

companies can start their SOA Governance

initiatives with a product that offers UDDI v3

search using predefined metadata models,

a JAXR interface to stored instances of

artifacts, WebDAV access to the SOA reposi-

tory, predefined reporting modules and both

a Web-based interface as well as an Eclipse

Registry Browser.

CentraSite also manages metadata gener-

ated from integration software, Web

Service descriptions, application-specific

data (e.g., XSLT, forms, etc.) and in general

serves as a central store for documents in

native XML and non-XML formats. WebDAV

is used for storing and retrieving develop-

ment artifacts in the CentraSite repository,

such as process definitions in XPDL, models,

sequences and more.

An implementation of the Java API for XML

Registries (JAXR) is included, to interact

with the CentraSite registry. The CentraSite

registry/repository can be accessed using a

browser-based interface (CentraSite Control)

or an Eclipse-based interface. Services and

Web Services definitions can be accessed

via WebDAV, UDDI, JAXR and the XQuery

API for Java (XQJ).

The Eclipse Reporting UI allows you to

define reports, based on predefined and

customized reports. You can visualize the

results with CentraSite Control or by using

Eclipse. The Eclipse Registry Browser

leverages the basic and advanced search

abilities, browses on stored SOA assets to

provide data in the tree/folder view and

provides an analysis on the lineage chain

of object associations.

In addition, besides the functionality

CentraSite provides to an SOA, its extensi-

bility and standard-based architecture sets

the foundation for a wide-range of modular

tools from a range of different vendors

that increase SOA Governance transparency

and control. Since SOA is exceedingly

complex to manage and crosses the enter-

prise, no one company or vendor can claim

to know it all, nor effectively span the SOA

Governance space.

2 Download the Community Edition of CentraSite at www.centrasite.org

CEntRASItE’S OPEn DESIGn FACILItAtES:

Soa Challenges and objectives

SOA lifecycle management

Open standards-based

One source for all SOA data

Standard models

increase reuse and user adoption

Extensibility

CentraSite

manages all aspects of the SOA lifecycle

Architecture is based on commonly adopted SOA standards

Stores any metadata or SOA artifact

provides standard models that are easily extensible

user-friendly ui shows objects and relationships, allows for easy navigation and drill-down

• models are easily extensible • can integrate with related tools • ui can easily be extended

SOA GOVERnAnCE StAnDARDS

centraSite supports commonly-accepted SOA standards such as:

JAxR l0 and l1: Java Api for xml Registries

uddi v2 and v3: universal description, discovery and integration

SOAp 1.1 and 1.2: Simple Object Access protocol

ebxml: Electronic business using extensible markup language

WebdAV: Web-based distributed Authoring and Versioning

WSdl: Web Services description language

WS-basic profile 1.0 and 1.1

WS-policy 1.5 and WS-policy 1.5 Attachment: Web Services policy framework

Snmp v2 and v3: Simple network management protocol

Other:

data Store Access (xSlt , xpath, xQuery, xQJ, xpdl)

OOtb Eclipse

SOA management (Jmx, WS-Security)

federation (ldAp, uddi, cmdb)

Repository Artifacts (bpEl 1.1 & 2.0, WSdl, xml Schema, ScA)

•

•

•

•

•

•

•

•

•

•

•

•

•

•

•

SAG_

WM

Spot

_Cen

traS

ite-O

pen_

Iss2

-09_

17M

ar09




CommunitiesSpotlight

Business Intelligence, CMDB, SOA Testing

and SOA Management.

In the past, many of the integrations

between vendors featured a “black box”

approach – they were one-offs, designed

for a particular customer requirement with

little documentation available. Equally,

details of exactly how the integration was

achieved would remain in the heads of the

few technical people who built it.

CentraSite Community partners take an

entirely different perspective, with an open

standards-based architecture philosophy

that delivers proven integrations with best-

of-breed solutions that are repeatable,

transparent and robust. These Community

partnerships result in many benefits to

organizations, irrespective of their stage of

Since its creation in June 2006 by

Software AG and Fujitsu Software, the

CentraSite Community has won awards1

and grown into an ecosystem of over

50 partners in 11+ countries that provide

real-world SOA Governance solutions to

bridge the many domains of SOA.

CentraSite Community partners not only

recognize the diverse nature of IT environ-

ments, they are committed to developing

solutions that continue to support long-

term SOA strategies. Their complementary

leading and integrated technologies

address needs across the broad spectrum

of SOA: Define, Create, Run and Govern

(See diagram below). Interest in member-

ship comes from vendors in many different

sectors, such as Enterprise Architecture,

Enterprise Governance, Business Rules,

introducing ThE CEnTrASiTE COmmuniTyBy Gerd Schneider, Senior Vice President, Enterprise Transaction Systems and Communities, and Justin Vaughan-Brown, Senior Director Communities, Software AG

SOA adoption. These include:

Pre-packaged integrations that fast-track

implementations

Diverse areas of SOA can be brought

together seamlessly

No rip and replace demands – CentraSite

will integrate with any vendor offering

(competitive or not) using commonly

accepted industry standards

Broad range of expertise across the

SOA landscape

Vendors who are not yet part of the

Community can easily integrate with

CentraSite, based on the proven standards-

based approach.

1 SYS-CON Media 2007 SOA World Reader’s Choice Awards Best Web Services or XML Site: CentraSite Community Portal, CentraSite Community

•

•

•

•

The CentraSite Community is an SOA ecosystem comprising software vendors and consultancies whose technologies and

methodologies complement and integrate with the CentraSite registry/repository to deliver a comprehensive end-to-end SOA

Governance solution, from conceptual modeling through to resulting service deployment and monitoring.

Model and improve business processes

Enterprise Architecture, Enterprise Governance, CMDB

Enable existing systems, build and test applications

Business Rules, SOA Testing, Application Modernization

Execute applications, monitor service level agreements, enforce policies and secure access

Business Intelligence, SOA Management, Security

DEfinE

GOvErn

CrEATE run

Please Note: This logo has not been trapped.

SAG_

COM

Spot

_int

roCe

ntra

site

_iss

2-09

_12M

ar09

SOA EnAblEmEnT EdiTiOn | iSSuE 2, 2009 TECHniques Spotlight

Documents

Transcript of SOA EnAblEmEnT EdiTiOn | iSSuE 2, 2009 TECHniques Spotlight