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.
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
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.
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
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
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.
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
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
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
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
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
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.
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.
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
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
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
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
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.
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
TECHniquesSOA EnAblEmEnt EditiOn | iSSuE 2, 2009
webmethods Spotlight
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
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
webmethods Spotlight
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
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.
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
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
Top Related