Columns
Service-oriented Architectures: Tool time for service-oriented architectures
- By Alan Radding
- January 1, 2006
Download the pdf version of this Special Report.
"Can companies use their
old tools for SOA? Probably,
but to get the most benefit
and [take advantage of] the
new thinking, you really
want to consider new tools,"
says Ted Farrell, VP and
chief architect for Oracle's
app dev tool group.
When it comes to SOAs,
deciding what tools are required
is more complicated
than it appears. Developers
will continue to use their
Java IDE, C++ and other
tools, that's for sure.
What's new is how app dev
for SOA expands the idea
of who builds apps.
"With SOA, you want to
let everyone contribute to
the development," Farrell
says. "In addition to the
low-level programmers,
you want the high-level
business users and even
the system administrators."
It's these folks who will
need different kinds of
tools to support a new way
of thinking about apps and
how they're built.
Programmers will continue
to build the low-level
plumbing and code required
to process data and
move information. While a
different type of developer,
one who is more like a
business analyst, assembles
apps by calling services
and defining rules and policies
to support a business
process, without touching
or even understanding the
plumbing underneath.
New look at tools
SOAs will also put greater
focus on deployment tools.
Today orgs build new apps
for each business need. In
an SOA environment, services
will be combined, assembled
and deployed--
possibly at run time--to
meet changing business
needs. Ideally, a small set
of functional services will
be continuously reassembled
and deployed, requiring
only minimal amounts
of new code.
App managers can
meet their SOA dev needs
with an array of tools. The
hot SOA market is attracting
companies, from established
players retrofitting
their existing tools,
to upstarts that didn't exist
6 months ago. The challenge
is figuring out which
of your existing tools can
continue to do the job and
what new tools you need.
New code of conduct
SOA for many developers
is simply the latest take on
the old concept of invoking
specific app functionality
over the network. It is CORBA
or component-based
development couched in
the terminology of services
and supported by a better
defined and more widely
embraced set of standards
and interfaces, with XML,
SOAP and WSDL allowing
otherwise incompatible
pieces to work together.
The functionality often
exists in legacy apps. This
functionality needs to be
broken out and wrapped up
in the appropriate SOA interfaces.
The new app consists
of services calling other
services and exchanging
data in XML format. All this
activity is orchestrated according
to business process
rules and policies. The services
can be reused any number
of times as they are
recombined with other services
and orchestrated under
different policies, depending
on the intended use.
SOA doesn't care how
the functionality of the service
actually works as long as it can be invoked in a standard
way. It can be built using any technology as long
as it can be wrapped in the
appropriate SOA interface.
That's why developers don't
need special tools to build
SOA services. "You don't
need to replace your existing
tools," says Michael
O'Rourke, VP at BuildForge.
"You can keep using your
IDE. Where you need new
tools is to tie all the pieces
together so they can share."
Tying services together
Learning curve for testing apps
Testing apps for deployment in an SOAenvironment calls for special tools.
“All existing testing tools were designed for the stand-alone silo environment. That was simple: load it up and see how it behaves. Basically you test for known cases,” observes Dan Foody, CTO at Actional.
In an SOAenvironment, testing apps for deployment gets much trickier because things are more dynamic. Not only does usage and volume fluctuate, but apps consisting of new combinations of services keep getting added to the mix. “In SOA, you don’t know all the use cases. Publishing the service is just the start, not the finish,” he says.
Further, SOAservices must interact with many combinations of services. Developers could easily find themselves testing services they built in combination with services they didn’t build and don’t know anything about.
Of course, developers will continue to do unit testing with their regular test tools. That will tell them if the service’s code does what it is intended to do under test scenarios. However, traditional unit testing can’t tell them what will happen when unknown services start calling for the service under unexpected conditions, or when it calls unknown services.
Complicating the testing of services is the lack of a user interface. Web services typically are lengthy, cryptic XMLdocuments consisting of tags and schemas and imported schemas and messages. They don’t have a user interface.
Meeting of the minds
Thomas Consulting Group does custom development for a number of clients in the financial services industry and has been using Web services for several years. “Two years ago, tools for testing Web services were embryonic,” says Tom Igielski, president. “We tried to work with the various testing vendors back then, but they simply couldn’t digest the code. They would blow up on the schemas and the WSDLs.”
Then the company found Mindreef. “Mindreef did 80 to 85 percent of what we needed, and it was cheap,” Igielski recalls. At $99 a seat, he gives the tool to each developer to do unit testing for the service that developer created. “Mindreef populates all the elements of the schema to make it work and gives us the results in English,” he explains. “Then, we just have to package the results and send it to the QA group. It really helps increase productivity.” Mindreef adds a browser user interface and uses color coding to make it easier to understand testing.
Mindreef recently released a Web services lifecycle collaboration platform for orgs building Web services and SOAs. Mindreef Coral, as the new platform is named, addresses the challenges of SOA collaboration by supplying teams with servers that can be linked together. Each Mindreef Coral server acts as a hub, housing Web service data and containing XMLaware tools that allow team members to govern, test, diagnose and support Web services collaboratively.
In addition to Mindreef, Thomas Consulting uses Mercury Interactive for load and performance testing and XMLSpy, an IDE for XMLdocument development and validation.
Alan Radding
and coordinating them is
often referred to as orchestration. "With SOA, business
policies and business
processes become big issues,"
says Robin Bloor,
partner, Hurwitz & Associates,
a research and consulting
firm. "You need tools
that will let business people
create the business policies
based on business processes
and tie them together to
make the application. It is a
new approach to handling
business activity. With SOA
you specify the workflow,
not workflow as we used to
do it, but more like process
flow." These kinds of tools
will allow business users to
specify the apps in terms of
policies and processes without
having to write code.
Speaking the same lingo
Processia, a consulting firm,
is involved in a large project
that calls for it to integrate
major legacy packaged
apps including an ERP
system and a PLM system
which predate Web services
and SOA. But it doesn't
matter. "The applications
were not built as Web
services, so we are wrapping
them as Web services,"
explains Scott Liu, the consultant
leading the effort.
Web services alone are
not enough to ensure
seamless integration. To
make the system function
smoothly, the team turned
to Business Process Execution
Language "to translate
the business processes into
something the systems can
use to perform the task," Liu
explains. BPEL provides a
formal specification of business
processes and business
interaction protocols that
extend the Web services interaction
model and enable
it to support business transactions.
In the process, it
defines an interoperable integration
model for automated
process integration.
The Processia developers
turned to a BPEL tool
from Active Endpoints to
provide the business
process translation and orchestration
that would enable
the Web services to
take data from one system,
process it, then pass it to
the next step in the process.
All kinds of tools
With SOA such a hot topic,
vendors are slapping the
SOA label onto almost
every development and
deployment tool they offer.
Often vendors are doing
little more than adding
support for XML and other
SOA standards. In other
cases, new companies are
rushing to market with
tools that address specific
SOA issues, such as management, policy and business
process. Even the
established players in the
market, Actional, Amber-
Point, Infravio and Systinet,
are relatively young and
small. At the other end of
the scale, the app dev tool
heavyweights such as IBM
and Oracle are bringing
out SOA toolsets.
"If you have some sort of
integration middleware, you
are already a step ahead,"
says Steve Craggs, president
of Saint Consulting
and vice chairman of the Integration
Consortium, a
non-profit organization that
aims to influence the integration
industry.
Who, what, when
and where
The basic SOA toolkit,
according to Craggs, starts
with the registry or services
repository. This is where
the reusable services and
the accompanying metadata
describing when, where
and how to use the service
are stored. UDDI (universal
description, discovery and
integration) is the accepted
industry standard for services
registries.
Infravio and Systinet are
the most visible registry
tool providers. These vendors
enhance the core
UDDI standard with a variety
of features that make it
easy for developers to find
services and figure out
how they should be used.
They also pack the registry
with additional information
about service contracts
and business policies.
Although Craggs puts
the registry first, it's only
needed if the intent is to
reuse services. Liu's client,
for example, does not intend
to reuse the integration
services he is building because
it's a one-time effort.
An org may create a
homegrown repository
using something as simple
as Microsoft Excel or a
commercial configuration
management system, says
David Butler, VP of product
strategy at Systinet. The
result will not be a UDDIcompatible
directory, "but
it will work at the early
stage of an SOA effort if
you don't care to be
100-percent standardscompliant,"
he points out.
You also don't need a
registry if you only build a
handful of services, he adds.
Michael Burnett, principal
architect at Blueprint
Technologies, is building
reusable services for the
NASA-sponsored ECHO
project using Microsoft's
Visual Studio and tools
from Eclipse. For the registry,
the company opted
for Systinet. "We use the
registry to publish, find and
bind," Burnett says. "Those
are the fundamental interactions
you want from the
registry. I guess we could
roll our own using an XML
database, but there is value
in adopting something
UDDI-compliant."
By going with a standards-
based registry, Blueprint's
compliant tools can
interoperate. "It also saves
me from having to think of
everything on my own,"
Burnett explains. "It's all
there in the tool."
Mediate and then operate
After the registry, orgs
need some kind of integration
middleware, gateways
and adapters. Typically,
this tool set consists of
messaging-oriented middleware
or EAI technology. "You need this for your
existing components,"
Craggs notes. Increasingly,
companies are looking at
ESB technology for this
functionality.
Mediation services encompass
a large range of
SOA tools. "These are the
tools you use for the transformation
of data and for
the enrichment of data,"
Craggs says. He also puts
business process, BPEL
and orchestration tools in
this category.
After mediation services,
orgs need to look at
operational tools. These
address such issues as
governance, security, management
and performance tuning. These tools help
developers define rules at
a high level for such things
as security or governance,
then actively monitor SOA
activity as services are invoked
and run. For example,
a developer might define
a rule that allows
employee Social Security
numbers to be used within
the company but not go
past the firewall. Governance,
management and
security tools let you do
this centrally across all
services all the time, even
as they are reused in different
circumstances.
Starwood Hotels and
Resorts Worldwide is
following an SOA strategy
to move from mainframe
systems inherited from its
mergers to a new open
systems environment. The
goal is to eliminate the
mainframes. The result will
be a complex SOA environment
that Starwood
expects to handle high
volumes. "We will probably
end up with hundreds of
services," says Israel Del
Rio, the hotel's senior VP
of technology solutions.
The company opted for
Actional's SOA management
tools. "We have to
manage a very complex
services environment,"
Del Rio says. "We will need
something that will let us
redirect services as
needed, do load balancing,
apply policies and do
versioning of services."
Part ofActional's appeal is
its ability to follow transactions
end to end, even
as they disappear into
traditional systems. It also
provides DelRio with the
ability to monitor and
govern the SOA.
Starwood's SOA tool
stack consists of OpenView
for alerting and monitoring,
Introscope to view Java
app performance and identify
bottlenecks in the J2EE
environment, MQ for messaging
and Systinet as the
repository. Actional provides
the mediation services
layer. Starwood's developers
built the services
using their standard IDEs,
SOAP, WebSphere development
tools and WSDL.
There is no single tool
or tool family for developing
apps in an SOA environment. "Most companies
today are adopting a best-of-
breed approach and
combining tools as needed," Craggs concludes.
By complying with SOA
standards, this approach
should not present problems,
he says. In addition,
the SOA tool rush will
accelerate as Eclipse, IBM
and several other vendors
start releasing new tools.