Interoperability Through Service- Oriented Architectures (SOAs)
Interoperability Through Service-
Oriented Architectures (SOAs)
An ObjectWatch White Paper
Last Modified: July 30, 2004
About Roger Sessions
Roger Sessions is the author of Software Fortresses: Modeling Enterprise Architectures
published by Addison-Wesley, five other books, and dozens of articles. He is the CEO of
ObjectWatch and is a frequent and popular conference speaker. More than 50,000 people
im rt n 0 on i hv aedd es n’w rsos n u ding and designing
n oeh 2 cute ae tne Ss os okhp o bi
a rs t i s l
high-end software architectures.
ObjectWatch services include:
The Architect Technology Advisory, a monthly architect advisory service
available by subscription containing in-depth technical analysis of topics that
architects must understand to design good systems and protect those systems from
Architectural design sessions, proof of concepts, and expert implementations.
The ObjectWatch Quarterly Newsletter, a widely read, highly regarded, and often
hotly debated free newsletter on high-end enterprise software technologies. Past
issues are available at www.objectwatch.com.
For more information on any of our services, contact email@example.com.
Table of Contents
Part I: SOA Overview......................................................................................................... 1
1. Executive Overview.................................................................................................... 1
2. Overview of White Paper............................................................................................ 1
3. Service-Oriented Architectures (SOAs) ..................................................................... 2
Part II: Case Studies............................................................................................................ 5
4. Qwest — An Example of a Large-Scale SOA............................................................ 5
4.1. Q et I O gn ao ..................................................................................... 5
w ssT rai t n
4.2. Q et S AA cic r................................................................................. 6
w ss O r t t e
’ he u
4.3. The Benefits ........................................................................................................ 8
5. CACU — An Example of Automated Workflow....................................................... 8
5.1. C C ’I O gn ao .................................................................................... 8
A U sT rai t n zi
5.2. C C ’S AA cic r
A Us O r t t e h e u ................................................................................. 9
5.3. The Benefits ........................................................................................................ 9
6. Case Study: Avista Corp. — An Example of Mainframe Connectivity ................... 10
6.1. A ia I O gn ao................................................................................... 10
v t sT rai t n
6.2. A ia D c i Poes
v t s eio rcs................................................................................. 10
6.3. A ia S AA cic r............................................................................... 12
v ts O r t t e
s’ he u
6.4. The Benefits ...................................................................................................... 13
7. NORIS — An Example of Mainframe Migration and Web Services Orchestration 13
7.1. About NORIS.................................................................................................... 13
7.2. N RSSI O gn ao ................................................................................ 13
O I’ T rai t n zi
7.3. N RSSS AA cic r............................................................................. 14
O I’ O r t t e he u
7.4. The Benefits ...................................................................................................... 16
Part III: Analysis ............................................................................................................... 16
8. Lessons Learned From Case Studies ........................................................................ 16
8.1. Buy Your SOA Infrastructure........................................................................... 16
8.2. Legacy Apps: Rewrite or Wrap?....................................................................... 17
8.3. Leverage Existing Skills ................................................................................... 17
8.4. SOAs Scale Well and Are Reliable .................................................................. 17
8.5. SOAs Reduce Costs .......................................................................................... 18
9. Evaluating Microsoft SOA Technologies ................................................................. 19
9.1. A Standard Set of SOA Evaluation Criteria ..................................................... 19
9.2. Overall............................................................................................................... 20
9.3. Legacy Support ................................................................................................. 24
9.4. Extensibility ...................................................................................................... 25
9.5. Infrastructure..................................................................................................... 25
10. Conclusions........................................................................................................... 28
Part I: SOA Overview
1. Executive Overview
Interoperability is one of the key issues facing IT organizations. Service-oriented
architectures (SOAs) based on Web service standards have emerged as the leading
industrywide enabler for interoperability.
Companies that are embracing SOAs are finding huge benefits. Some of these benefits
are expected, such as increased revenue opportunities through collaboration, improved
decision making through shared data, and decreased personnel costs through automated
workflow. But many of the benefits of SOAs are unexpected, such as dramatic
improvements in system reliability, huge reductions in development and deployment
costs, migration of systems from expensive mainframe to inexpensive server clusters and
impressive improvements in time to market.
This white paper includes my interviews with companies that are successfully using
SOAs. From these interviews emerged many lessons that are applicable to any company
interested in leveraging SOAs.
This white paper also provides a set of criteria for evaluating SOA technologies. I use
t s c t itseicl ea a Mi oot S At ho g sbths sm
h e re ao pc i l vl t c sfs O e nl i ,ut e a e
e ir f ay u e r ’ c oe e
criteria could be applied to any other SOA vendor. The specific Microsoft strengths that
emerge from this evaluation are the following:
Low cost of acquisition
Tight integration of Web service standards into the programming tools
A strong collection of enterprise back-end technologies
Excellent support for interoperability with legacy systems
But this white paper is not about building an SOA with Microsoft. It is about building an
SOA successfully in a heterogeneous environment in which the strengths of many
platforms can be realized.
2. Overview of White Paper
This white paper is divided into three main parts. Many readers will want to read all three
parts. Others will want to pick and choose. The three parts are as follows:
Part I (where you are now) is an overview of service-oriented architectures
(SOAs) and why they are considered so important.
Part II is a set of case studies that shows how SOAs are used in the real world.
Part III is an analysis, including lessons learned and an evaluation of the
Microsoft SOA technologies. Many readers will find the evaluation criteria given
in section 9.1 useful for evaluating any SOA platform.
3. Service-Oriented Architectures (SOAs)
Application interoperability is the single most important issue facing most enterprise
software architects. The use of SOAs based on Web service technologies is the best
approach we have to interoperability. This is the message I hear over and over again in
my consulting engagements.
My analysis is backed up by a recent study by Jupiter Research1. It showed that when
choosing a development platform, the top concern of IT decision makers was
interoperability with existing applications. For 55 percent of the IT decision makers,
SOAP (simple object access protocol) and WSDL (Web service definition language), the
flagship Web service standards, were the most helpful in solving interoperability issues.
Actually achieving application interoperability is complicated by three factors:
Most systems were built before SOAs were understood and before any of the Web
service standards were defined. These systems, therefore, do not support Web
Systems run on different hardware and software platforms.
Systems that must interoperate are often built by different groups and
communication between these groups is often sparse.
There are four well-known reasons for embracing Web services:
Increased revenue opportunities through direct collaboration between your
systems and those of other enterprises
Improved decision-making through immediate availability of critical data across
Lowered personnel costs through workflow automation
Reduced complexity of interoperability
The pre-SOA approach to interoperability was to connect each application to each other
application in an ad-hoc fashion as shown in Figure 1.
In the SOA approach to interoperability, we build an SOA infrastructure with which
every system interoperates, as shown in Figure 2. With SOA style interoperability, each
application requires one, and only one, connection — a connection to the SOA
infrastructure. We can add a new application by simply connecting it to the infrastructure.
It can then interoperate with existing systems without further changes.
The SOA approach is not free. It requires carefully planning the SOA infrastructure.
However, the long-term benefits to the organization are immense. I will explore how
some organizations built and benefited from such architectures in upcoming sections.
Je l x t l “ t oe b i : o T cnl y ngrR tMi ootn I T cnl i fr
o Wio e a,I e pr it H w eho g Maae a
c . . n r a ly o s e c sfad t eho g so
r s oe
D vlp et Microsoft Monitor, MIC04-C02.
ee m n”
Application 6 Application 2
1-6 1-5 1-4 1-3 1-2
4-6 4-5 4-1 4-3 4-2
Application 5 Application 3
a-b = connection from
application A to
Application 4 application B
Figure 1. Pre-SOA Interoperability
Application 1 Application 2 Application 3 Application 4 Application 5 Application 6
SOAP Browser Workflow Utility Shared Data
Gateway Gateway Engine Services Services
Internet Gateways SOA Back-end Services
Figure 2. SOA Interoperability
A service-oriented architecture (SOA) is any software architecture that focuses
specifically on the problems of interoperability. It is an approach to developing new
systems and wrapping existing systems in such a way that these systems can work
Most people think of SOAs as being closely related to a set of standards collectively
referred to as Web services — services that are specifically related to interoperability
bten e rgnos yt sF rxm l ap ct n bi o IM’WeS hr
e e ht oeeu ss m . o ea p ,plaos u tn B s b pe
w e e e i i l e
can communicate with applicat n bi o Mi oot .E Fa e okhog t i
i s u tn c sfsN T r w r t uhh r
o l r ’ m r e
common support of Web services.
Heterogeneous communications require agreement on these technical issues (as shown in
How an application lets others know what it is willing to process
How requests to that application should be formatted
How requests should be sent and kept secure
How applications should prove their identity
How errors/successes will be communicated between applications
So what are the best choices for those agreements upon which interoperability is
dependent? There is widespread consensus within the industry that these agreements
should be based on Web service standards.
Advertisement of services Proof of identify
Coordination of results
Figure 3. Interoperability Agreements Between Two Applications
The most important and mature of the Web service family of standards are the following:
SOAP (originally known as simple object access protocol) for the message format
HTTP for synchronous SOAP delivery
WSDL (Web service definition language) for letting a potential collaborator know
what you are willing to do
UDDI (universal description, discovery, and integration) for coordinating
discovery of information about Web services
In addition to these, there are three standards that will soon be very important in
workflow coordination. They are:
Web Service-Transactions for coordinating results
Web Service-Security for identity-related issues
Web Service-Reliable Messaging
Perhaps even more important than the required agreements are those issues on which
applications do not need to agree. These include:
The hardware platform on which each runs (for example, Sun or Dell)
The operating system of each (for example, Linux or Windows Server)
The software infrastructure which provides each with a run-time environment
(WebSphere or .NET)
The language with which each was developed (Java or Visual Basic)
The tools used by each of the developers (Borland JBuilder or Visual Studio)
The Web-hosting environment (Apache or IIS)
The internal communications each uses within its own application (IIOP or .NET
The databases each uses to store data (DB2 or SQL Server)
It is these nonagreements that give you the ability to support existing systems and the
flexibility to choose from among the best-of-breed technologies for future projects. Your
ability to choose from among many technologies gives you bargaining strength with your
The bottom line is that you want enough agreements to ensure interoperability between
systems, but not so much that you stifle future technology/platform choices.
Part II: Case Studies
L t se o S A a poi n r l ee ttfu cm ai t a.
e se hw O s r rv i e bnfso oro pn so y
’ e dg a i e d
4. Qwest — An Example of a Large-Scale SOA
Qwest is a telecommunications company providing voice, Internet, data, and video
solutions to residential, business, and government customers nationwide. Qwest has
45,800 employees and transmits approximately 240 million calls every day.
4.1. Q e t I O g nz t n
w s’ T ra i i
Qwest has more than 1,000 business applications currently in production on many
different platforms. More than 120 of these applications are written in .NET and
supported by 40 development teams with more than 500 developers. Qwest clients
include the following:
Customer service employees staffing help desks are using rich client interfaces to
access Qwest applications.
Field technicians working in the field typically enter the system through wireless
general packet radio service (GPRS) and land-line modems.
Customers using browsers enter Qwest through a portal called MyQwest.com.
These portals are accessed by more than 20,000 customers per day.
Customers using voice recognition enter the Qwest system through their phone
and interface with a voice recognition system.
Outside (non-Qwest) applications represent additional revenue opportunities.
4.2. Q e t S AA c i cue
w s’ O rht tr
In order to simplify application development, Qwest has defined a standard operating
environment (SOE). The SOE is a set of components, services, and APIs that can be used
by any developer at Qwest. The SOE includes support for database access,
communications, security, and more. The SOE is maintained and evolved through a
partnership between Qwest Development and Operations teams.
The overall Qwest architecture is composed of a series of related zones, as shown in
Fgr4( l og, e dnta t mznst ss y w term.)
i e .At uht y o’cl h oe;h im o n
u h h le i
This zoned approach has several advantages:
It is very secure.
It readily accommodates heterogeneity.
It is highly scalable.
It is highly reliable.
Let me go through the four zones as shown in Figure 4 giving the highlights of each.
Application Zone (.NET or J2EE)
J2EE or .NET apps
Zone (IBZ - IIS)
Figure 4. Zone Relationships
The outside zone it a a u i o Q et i m d tcn o T ii l e m sy
sh r otd f w ssm eie ot l h n u s ot
e e se ’ a r. s c d l
browser clients entering the Qwest domain through HTTP but also outside applications
entering via SOAP.
The internet buffer zone (IBZ) is the area that accepts requests from clients living in the
outside zone. It is a self-contained security zone, meaning that it is protected by firewalls
and other security mechanisms, and is similar to what some companies call the
demilitarized zone. Requests from browser clients arrive via the Qwest portal called
MyQwest.com. These requests are processed by ASP.NET applications. Requests from
outside applications are processed by SOAP surrogates. Both the ASP.NET applications
and the SOAP surrogates share these characteristics:
They run on load-balanced server clusters.
They are running inside an IIS environment.
They contain no business logic. They only know how to receive requests and
interact with clients.
When they need business logic executed, they make a request to the application
If they want to store any data, such as session state, they do so in a data store that
is part of the IBZ.
The main advantage of the IBZ is security. Machines connected to the Internet are
inherently insecure. By creating an IBZ, Qwest has effectively protected its mission-
critical business systems and business logic from unauthorized access. If a hacker
manages to subvert an ASP.NET application, there is nothing in that zone that is critical.
Even if the hacker managed to wipe out every disk on the IBZ, Qwest could regenerate
the entire IBZ quickly.
The next zone is the application zone (AZ). The AZ houses applications that contain
mission-critical business logic. These systems can be built in either .NET or J2EE. At
Qwest, the J2EE systems are typically WebLogic on UNIX. The .NET systems are,
obviously, on Windows. Qwest allows individual groups to make their own technology
choices within supported SOEs and focuses its corporatewide policies on how those
applications will interact and what services the SOE will provide.
The AZ is its own security zone. It is protected from the IBZ by its own firewall and
security policies. If some outside hacker did manage to penetrate the defenses of the AZ,
serious damage could ensue, but this is made virtually impossible by the strict separation
enforced by the IBZ.
Applications within the AZ store their data in the data zone (DZ), which is closely
associated with the AZ. I think of the DZ as a separate zone mainly because it has such
specific hardware requirements. In order to access the DZ, the applications make use of
the database services that are part of the SOE that I discussed earlier.
Qwest has used this architecture to achieve a high degree of interoperability. Applications
are all able to communicate with each other through either the Message Bus or by using
SOAP. According to Qwest, interoperability between a .NET application and a J2EE
application is no more difficult than between two .NET applications or two J2EE
4.3. The Benefits
The main benefits Qwest has realized from its use of SOAs are these:
A high degree of interoperability between applications
Excellent scalability and reliability through the use of server clusters
Highly secure systems through use of the Internet buffer zone
5. CACU — An Example of Automated Workflow
C m ui A e c CeiU i (A U s r dn 90 n inwt Mi et
o m n y m r a r t n n C C )t t i14 ads o h d ss
t i d o ae e w ’
largest credit union with more than 110,000 members and assets exceeding $1 billion. Its
many products include online banking, CDs, IRAs, money market funds, consumer loans,
home equity loans, mortgages, credit cards, brokerage services, and insurance. The
project lead is Byron Healy, Senior Technical Architect, Information Services.
5.1. C C ’ I O g nz t n
A Us T ra i iao
CACU was originally a mainframe so. so C C ’oe t n r o to
hpMotf A U s pr i sa n w ao n
mainframes. The old mainframe processors burned out once a month or so. It was time
for an architectural makeover. Their goal was not to eliminate mainframes, but to use
them where they made the most sense. CACU believed that the right place for the
mainframes was the financial host back-end.
5.2. C C ’ S AA c i cue
A Us O rht tr
The SOA approach has allowed CACU to use many different applications, programming
platforms, and development technologies. Applications are allowed to use the tools they
need to use. Enterprisewide agreements are limited to SOA-style interoperability. The
agreement points across applications are:
BizTalk will be the standard for orchestrated workflow. BizTalk is a tool for
managing complex workflow. It includes the ability to translate data, manage
asynchronous communications, and coordinate error processing.
SOAP will be the standard for messaging format.
Byron believes the interoperability and reuse is achieved through packaging applications
as Web services. As many systems as possible, he says, should be made XML compliant,
and specifically, CU-XML (credit union XML, a set of XML definitions specifically for
credit unions) compliant.
By keeping their financial applications on the large UNIX boxes and moving select
applications and building new applications for server clusters, they received the benefits
of a new SOA-style architecture without having to pay the price of moving databases or
throwing out working mission-critical applications.
What makes all of this work is not just Web services and BizTalk, but also good
architecture, good business processes, close attention to technical infrastructure, and lots
of open communication. Byron recalls that back in the days of the mainframe systems,
the confidence in the IT organization was not strong. But by embracing the SOA
approach, the CACU IT organization has developed a reputation for building highly
r i l h h ualss m . cod go yo,T e a a ae aorb i t
ea e i l sb yt sA cri tB rn“ hy r m zd tu ait o
lb , g y e e n e ly
manage projectsWe a iptiee m j dc i it ogn ao. cnto
. prc a n vr a r eio n h rai t nIa’d
ti e y o sn e zi
justice to how much we have benefited. Our data systems are now state-of-the-art and
best-of-bedF r s n orr iui m m e , e a e a be cm ei .
r . o u ad u c d n n e br t vl hs en o pln ”
e et o sh u lg
The use of Web services has allowed CACU to build applications by putting together pre-
existing blocks of code. The use of Visual Studio and BizTalk has made the building of
t s ap ct n a es a dag g n dop gB rn os’ee t n o h sl
h e plaos s ay s r i ad rpi . yo dentvn h k f i e
e i i gn n i m f
as a por m rIpesdh w u dsr e i sla a “ t r o,o,vn oe
rga e f r e,e ol ec b h e s n i e a r ree m r
m . s d i m f ngt ”
l e ,s “r ad rpe” Wh ehr islt ne frh ocs nlehi l
i l a a da n dopr “ i t estlh ed o t cai at n a
ky g . l e i e e o c c
hayii ,o t m sprw j tr ad rp sy B rn
ev lt gfrh ota eu da n do, as yo.
fn e t s g ”
5.3. The Benefits
The main benefits CACU has realized from its use of SOAs are:
A high degree of interoperability between applications
Repackaging of back-end mainframe code as Web services
Greatly reduced cost of development
6. Case Study: Avista Corp. — An Example of
A o ecm ay ouig nn gao iA ia op w i ioe fh Wet
nt ro pn fcs o i er i s v tC r. h hs n o t
h n t tn s , c e ss ’
leading energy marketing and resource management companies. It was founded in 1889
and now has about 1,800 employees and reported $343 million in earnings in Q1-04. Its
primary market covers more than 30,000 square miles and it has 300,000 customers in
Washington, Idaho, Oregon, and California. Avista Corp. has been an industry leader in
Internet-based facility management, bill consolidation, and payment services. Dennis
Crumb is a RAD (rapid application development) Analyst for Avista, and he was (and
still is) the development lead.
6.1. A it’ I O g nz t n
vsas T ra i iao
Avista originally ran its business from an IBM mainframe. Client/server COBOL/CICS
programs ran everything from customer billing to figuring out how to get electricity to a
new address. The amount of code on the mainframe was massive, including
approximately 400 programs developed over a four- to five-year time period at a cost of
about $17 million.
Avista wanted to allow customers to view and pay bills over a browser and directly
manage their own account information. This would greatly reduce the need for human
intermediaries and would improve customer service.
6.2. A it’ D cso P o e s
vsas e iin rc s
How would Avista go from human-mediated CICS architecture to a customer-accessible
Internet architecture? There are two main approaches Avista could have chosen: rewrite
Avista could have rewritten its back-end CICS systems into ones based on newer
Internet-friendly technology platforms. Good candidate platforms would have been
IM’WeS hro Mi oot .E .
B s b pe r c sfsN T
e r ’
The second approach would have been to build software mediators. These mediators
could be Internet accessible on the customer side, and CICS compatible on the mainframe
side. For Avista, the complexity of the rewrite compelled them to a mediation approach.
The next question was: Which technology would they use as a basis for mediation?
Avista could not afford to forget about workflow. Mediation was typically not a simple
one-to-oe pr i .n t r od, a ut ew n do o o e s p ”f mt
n oe t nI o ew rsi cs m r at td sm “i l (o h
ao h f o e m e r e
ue s e pcv) pr i ,uh s a a i, aoe t n olr u eh
sr pr et eoe t nsc a py b l htpr i cu e i t
’ s i ao lt ao d qr e
coordination of multiple back-end systems on the mainframe side. In the old system, this
coordination was done by trained human operators. In the new system, that coordination
would be done through software.
Avista also wanted to open their systems to outside collaboration, such as direct
payments to be made by partner systems.
Whatever technology was chosen, it absolutely had to satisfy the following requirements:
Be implemented with no disruption to existing CICS systems running on IBM
Be compatible with DB2 on the mainframe
Be compatible with Oracle, which is used for local data storage
Be scalable to thousands of customers per day
Ye r pnei e t tr“rw e at t s na i ut df io o
id e os t sh a bo sr s”h t dr n sy e n i f
l s m a e -f , e a d d r i t n
which is 2 seconds
Provide high security
Provide high availability
Have tools for creating a compelling browser experience
Be extensible to other non-browser-based systems
I ad i tt s asl eeu e et t rw s stfehi ln e ae.
n dio oh e bo tr i m n , e a a eo t n a“i -to-hvs
tn e u qr sh e c c c ”
Low acquisition costs
Low training costs
Low development costs
Least possible changes to the mainframe system
Avista was approaching technical closure. They had decided on a mediated approach.
They had listed their must-haves and nice-to-haves. The only thing left was to choose the
mediation product(s). Oh yes, and of course, implement!
T e w rt e poutA ia os e d o m d t n IM’CC Tasco
hr e h e rdc v tcni r fr eii :B s IS r at n
e e r s s de ao n i
G t a,B s b pe MQ( s g Q ee ad c sfs I ( ot
a w yIM’WeS hr
e e Mes e uu) n Mi oot H S H s
a , r ’
Using WebSphere CICS Transaction Gateway for mediation would have been an obvious
choice, since it is the IBM standard technology for connecting to CICS. CICS is, of
course, also an IBM product. However, using WebSphere CICS Transaction Gateway
would have required a general commitment to IBM WebSphere, the IBM general
enterprise technology umbrella. Because of version incompatibilities with their CICS
version, this was not an option.
U i IM’WeS hr MQa t bs fr eii w sehi l ar t eT i
s g B s b pe
n e sh ai o m d t n a t n ay ta i . h
e s ao c c l t cv s
is a message queue technology that provides high-quality asynchronous transportation. It
runs on both the IBM mainframe and the Windows operating systems. There are many
possible ways this could have been used, but one would have been to have the browser
Web servers directly connected to the CICS machine through WebSphere MQ.
T e t r rdccni r frehi l eii w s c sfs I 20 ( ot
h o epoutos e d o t n am d t n a Mi oot H S 00 H s
h de c c ao r ’
Integration Service 2000). HIS is basically a collection of technologies that together
provide mainframe connectivity. The subset of HIS that Avista evaluated was COM-TI.
COM-TI works by projecting a CICS system onto a COM component hosted in a process
on a Windows operating system. The COM component presents a COM interface that is
functionally equivalent to the CICS interface. Method invocations to the COM
component are automatically forwarded by COM-TI to the back-end CICS system.
Two factors favored HIS. First, it required no changes on the mainframe. From the
eii CC ss m ’ e pcv, I ij tnt r IScet eodaa
x t g IS yt spr et eH S su ao eCC ln Scn,t
sn e s i s h i .
licensing cost of only $2,000 per server, it was a small fraction of the cost of a
WebSphere MQ solution. The ability to reuse their CICS systems without having to make
changes on the mainframe and the low cost of HIS were compelling, and Avista decided
to use HIS.
6.3. AvistasS AA c i cue
’ O rht tr
With HIS, the CICS components are made available as COM components, but this is only
part of the answer. COM components can be used by Microsoft technologies, but COM is
b n m as n i ut s na .It CC ss m w rti
y o en a “ dsy t dr ” fh IS yt s e onteroperate with a wide
n r a d e e e
variety of systems, including non-Microsoft systems, then something else needed to get
involved, specifically something that was a widely accepted industry standard. This, of
course, was SOAP.
Using SOAP on the client side of the mediator meant that the browser Web servers now
had to make SOAP requests of the CICS systems which were projected as HIS COM
components, which were wrapped with a SOAP interface. This architecture is shown in
Today, Avista manages workflow programmatically within the SOAP components.
Avista wants to get out of the workflow business. Their plan is to turn this over to another
Microsoft product, BizTalk 2004.
BizTalk 2004 is the latest release of BizTalk. Avista is planning on moving workflow
from code within the Web service components (which they had to write) to GUI based
BizTalk orchestrations (which BizTalk will coordinate). The old Web service
components that included workflow will then be replaced by new components that will
be very simple front-ends to BizTalk orchestrations.
COM Projection CICS Application
Figure 5. Avista Architecture
Using BizTalk will allow Avista to create highly sophisticated workflow orchestrations
including data translation, compensatory transactions, and integration with many other
6.4. The Benefits
The main benefits CACU has realized from its use of SOAs are these:
Reuse of the existing CICS $17 million investment without changes to mainframe
A high degree of interoperability between applications
A reduction of personnel costs through workflow automation
A reduced cost of development
7. NORIS — An Example of Mainframe Migration and
Web Services Orchestration
7.1. About NORIS
NORIS (Northwest Ohio Regional Information System) provides IT services to criminal
justice agencies in Northwest Ohio. It is dedicated to multi-jurisdictional data integration
and application cooperation among a range of software systems serving a variety of
criminal justice agencies. Clients of this system include federal, state and local law
enforcement, courts, and corrections agencies.
Patrick Wright is the director of NORIS. He is responsible for high-level architecture and
technical direction of the organization. Doug Kemp leads the team of programmers. Pat
has been working with NORIS for 20 years now and, in fact, many of the team members
have been with the project for more than a decade. Pat believes that one of the reasons
they have been able to build such a state-of-the-art system is because of the high degree
of specialized business experience of his staff.
7.2. N RSSIT Organization
NORIS was originally a series of mainframe applications. Data was stored in a
CODASYL database. CODASYL was one of the original database models developed
during the 1960s.
CODASYL databases had two major drawbacks. The first was that the data pointers
could be declared only when the schema was initially defined. The second was that the
traversal of the embedded data pointers had to be laboriously hand coded.
These two problems made it very difficult to make changes to either the data or to the
relationships between data once the data was initially defined. Define once, run forever
was the mantra of the CODASYL world.
So if NORIS was going to have a dynamic future, it had to be ported to a dynamic
database. And, as long as the data was going to need to move from one database to
another, one might as well reevaluate the whole architecture. For one thing, it was almost
the twenty-first century! Who needed a mainframe anymore?
The state of the art when NORIS was first built can best be described a “vr ss m
s ee yt y e
frt l” t i lr i lute yt w u hv be bi a a e e o
o ie .A y c c m n j i ss m ol ae en u ts sr s f
sf p a i a sc e d l i
independent applications, each an island unto itself with a huge amount of data
redundancy. In order to accomplish a simple function, such as following a court case,
data had to be entered repeatedly as workflow moved between the disparate applications.
The NORIS architects believed there was a better way. They believed that by building a
shared set of core applications, each accessing a common data repository, they could set
up a system where no single item of data needed to be entered redundantly. And once that
data was entered, it would appear the same regardless of the application from which it
w s cesd“ n r nev wfr e w shis gn
a acs .E t oc,i oe r a t rl a.
e e e v” e o
The rewrite of NORIS had the following goals:
To port to a relational database that supported dynamic redefinition of data and
data types not supported by CODASYL
To reduce the overall cost of running NORIS
To build an architecture that would allow a high degree of application
interoperability, including applications that had not yet been developed
To provide the standard enterprise requirements of high scalability, high
reliability, excellent performance, and iron-clad security
To build a system that could evolve as quickly as the constantly changing milieu
of the criminal justice system demanded
For business programming, NORIS had been using UNIFACE from Compuware.
UNIFACE is a platform neutral programming technology. They found that UNIFACE
allowed them to build complex business quickly. However, several factors favored new
development on Visual Studio. For one, platform neutrality had turned out to be a
nonissue, since they have heavily committed to the Windows platform for the future.
Secondarily, UNIFACE had a licensing model that charged on a per client basis, making
UNIFACE clients more expensive than Visual Studio clients (with no licensing cost on
the client side).
Because of the diminished importance of platform neutrality and because of the higher-
priced licensing model for UNIFACE, NORIS elected to use Visual Studio.NET for the
business logic of new applications.
NORIS also decided to use many other Microsoft products. On the browser side, they
found ASP.NET and the Visual Studio.NET environment unsurpassed. The tight
integration of Web services support and the awesome user interface capabilities are,
according to Pat, in a league of their own. On the database side, they are using SQL
Sre Mi oot i p m n t n fh r aoam dlF r orkflow, they have
e r c sfsm l eti o t e t nl oe o w
v, r ’ e ao e li .
been standardizing on BizTalk 2002 and will be porting to BizTalk 2004.
7.3. N RSSSOA Architecture
NORIS is now running its new implementation and supports a mind-boggling array of
applications. The applications are loosely coupled through data shared from a common
data repository. Once a user is logged on, each system works independently from the
other. Authorized users can quickly gather criminal histories, crime report information,
arrest reports, jail records, state, federal and local warrants and automobile records,
including picture images, from a variety of sources.
The NORIS suite of applications includes 11 core applications and 25 non-core
applications all using a loosely coupled integrated data repository. A small sample of
these applications includes:
Computer Records Management, which manages police crime reports
Jail Management, which manages information about inmates
Court Records Management, which manages information about criminal and civil
Warrant, which administers warrants, missing persons, attempt to locates, and
Digital Mugshot System, which stores and retrieves mug shots
A new application being deployed countywide allows patrol cars to create and browse
electronic incident reports. NORIS built an interface based on BizTalk 2002 that grabs
the reports from the County 911 system and validates them against national data
standards through BizTalk orchestrations, and stores them into the Computer Records
The overall architecture of this new application showing its relationship to existing
NORIS applications is shown in Figure 6.
As NORIS continues to expand, it needs to become integrated closer and closer into other
j te yt sA Ptas“ h ha o hm l d eui idti er i .I
u i ss m . s asy,T e er f o e n scrys a n gao ”n
sc e t a t a t tn
order to make this happen, the different systems need to agree on standard data formats.
Such an effort is under way. It is called the Global Justice XML Data Model (GJXDM)
and is organized by the U.S. Department of Justice. Pat is part of the group working on
implementing this standard in Ohio. This standard will soon define how NORIS
interoperates and cooperates with other justice systems of the future.
Since NORIS will need to interoperate with other systems using GJXDM, they need to be
using technologies that are closely aligned with XML, SOAP, and the other Web service
standards. One way to do this is to choose a vendor that is part of the Web service
standardization activity. The two companies that have been most closely associated with
these standards are IBM and Microsoft. Given the other constraints of NORIS (such as
keeping the costs as low as possible), Microsoft was the better of these two choices.
Core Applications Data
Access BizTalk Court
Figure 6. The Wireless Applications
7.4. The Benefits
The main benefits NORIS has realized from its use of SOAs are these:
The ability to collaborate with outside systems
Greatly reduced personnel costs through shared data
A huge reduction in development costs
Part III: Analysis
8. Lessons Learned From Case Studies
There are many interesting lessons we can learn from these case studies that are
independent of the Web services vendor.’ g t og t s oe y n.
Il oh uhh e n b oe
l r e
8.1. Buy Your SOA Infrastructure
SOA infrastructure (or a standard operating environment, as it is called in the Qwest
study) is the key enabler to interoperability. It is the glue that binds the various
applications together. The SOA infrastructure will run on some specific platform (such as
.NET or WebSphere), but it must be able to connect with any platform regardless of the
The infrastructure pieces should, wherever possible, be purchased, not written in-house.
The exceptions to this rule are business-specific services. Your business is running a bank
(or an insurance company, or...). You do not want to be in the infrastructure business.
Use packaged products, such as Visual Studio.NET, BizTalk, and messaging products.
8.2. Legacy Apps: Rewrite or Wrap?
Both CACU and Avista Corp. exemplify companies that wanted to continue using their
existing legacy applications. Both felt that the cost and disruption involved in rewriting
these applications would outweigh any benefit. In general, this is a common thread. Most
companies are not interested in throwing code away. Therefore, technologies that allow
existing mainframe applications to be SOAP-extended play an important role in their
overall SOA strategy.
But there are times when it makes better sense to let go of the old systems and rewrite
them from scratch. NORIS was a good example of this. One reason for rewriting is when
the application is tied to an archaic database. NORIS was originally built on an inflexible
CODASYL database, and no amount of wrapping would have given them the ability to
rapidly respond to constantly changing requirements.
8.3. Leverage Existing Skills
Whi Mi oot oe l gae r ic rr d y co m dt a i vr to
l c sfs pn a ug a h et ee i acm oa s wd a e f
e r ’ n ct u al e e iy
languages, Microsoft frequently touts C# as the programming language of choice. I was
cr u a thwC p y otnh r l ol Ion t t c sfsi t n n #
ui s so o # l s ui t e w r . fudh Mi oot f ao o C
o a e a d a r ’ xi
is not shared by many in the business world. Both Avista and CACU believed they saved
significant money by using Visual Basic rather than either C# or Java.
C C ’B rn el ep i w y e r e VsaB s . it hr ies acst
A U s yo H a xln h h pe r i l ai Fr, e s ay ceso
y as fs u c st e
VB programmers. Second, there is high productivity. Byron finds that a VB programmer
can go in front of .NET, use a language with which he or she is already familiar, and
“at etl otm eie .Ia cm s o no O .Wh e # a sm bnfs
cp ria si m d ty tl o e dw tR I“ i C hs o e ee t
u m a l” l l i
over VBf ma ee pr pr et et r db i o VsaB s frh ae g
ro dvl e s e pcv, ee ait f i l ai o t vr e
o ’ s i h a ly u c e a
person, as well as its simplicity, provides inherent value in the everyday demands of an
I ogn ao,sy B rn
T rai t n as yo.
8.4. SOAs Scale Well and Are Reliable
SOA-style services are almost always designed to be stateless, in that the services are not
expected to maintain memory of any request once that request has been processed.
The statelessness (or lack thereof) of a service is very important in determining the type
of machine on which it can run.2 Stateful services are typically run on large mainframes.
Only large mainframes can scale up to handle high workload for stateful services.
Stateless services, such as those found in SOA architectures, can be run on server clusters
rather than mainframes. In a server cluster architecture, requests are received by a router
that can choose from a number of identically configured machines to process the request.
For a ifr ai rdco t t i u o s tad e ec s r se oeSs os“ tro
n nom ln out no h s e fte n sr rl t s e R gr es n,Mae f
t i es a v ue, i ts
Sa ”The ObjectWatch Newsletter #13, available at www.objectwatch.com.
There are three advantages to the server cluster architecture: scalability, reliability, and
To scale a cluster, you just make another machine available to the router. This is less
costly and less disruptive than trying to upgrade a mainframe
Reliability comes from natural cluster redundancy. If one machine in the cluster goes
down, the remaining machines can continue processing requests. On a mainframe
architecture, there is typically no machine redundancy. If the machine goes down, your
system is down.
The third advantage of server clusters is cost. Avista is able to support 60-100 concurrent
clients (their maximum load) using two pairs of machines, each running in a clustered
setting. One cluster pair runs IIS and manages the browsers. The other runs HIS and
mediates calls to the mainframe. The machines are all inexpensive boxes, around $5,000
each. Even at maximum loads, the systems are running at well under 10 percent
u lao. v t s en Cu b a u t t ss mcu hnlt t e t
ti t nA ia D ni rm cl le h yt ol ad e i sh
iz i s’ s c as e e d e nm e
current maximum load before he would need to add another $5,000 machine to the
C C ’m v f mm i r e etc yt so e ec s retc yt s a
A U s oe r o a f m cn iss m t sr rl t cn iss m hs
na r e v ue r e
get i r sd vr lt it Fi r o t We srea s r eht yo cnt
r l n e e oe ls b i . aue fh
ay c a a a ly l s e b e rr o a t B rn a’v e r a
remember the last time the environment failed. Badly designed applications may fail, but
the infrastructure, the underlying Windows operating system, and the IIS SOAP
enablement has been perfectly reliable, according to Byron.
8.5. SOAs Reduce Costs
In addition to technical benefits, SOAs provide tangible business value in reduced overall
expenses. The case studies highlight two areas of cost savings: personnel costs and
8.5.1. Personnel costs
If you are like most companies, most of your data processing costs involve moving data
from one software system to another. After you adopt the SOA approach, the paper
shuffling will be gone. Workflow will be automated. When a sale has been made, a
workflow coordinating machine will automatically let the inventory system know what
has happened. When inventory gets low, the system itself will place the order. You will
see a huge reduction in data entry costs.
NORIS is a great example of a group that has greatly reduced its personnel costs through
its automated workflow. Pat estimates that the cost savings from the paperless warrant
system alone has saved N RSScustomers close to $600,000 per year.
8.5.2. Hardware costs
As I discussed earlier, SOAs are typically run on server clusters rather than mainframes.
Server clusters are not only more reliable and easier to scale, they are also less expensive
than mainframes. Thus SOAs coupled with server cluster platforms can have a significant
impact on overall hardware costs. NORIS was able to dramatically reduce its hardware
costs by going from a mainframe centric system to a server cluster centric system.
9. Evaluating Microsoft SOA Technologies
Now let’move from the general world of SOAs to the specific world of Microsoft. How
do Microsoft SOA technologies stack up against, for example, WebSphere?
9.1. A Standard Set of SOA Evaluation Criteria
Before we can evaluate Microsoft SOA technologies specifically, we need a standard set
of criteria that can be applied to any vendor. Based on the case studies and my many
discussions with companies, I have evolved my own set of criteria that I think are critical
for large enterprise systems. This set of criteria is divided into four main categories.
Table 1 shows the criteria organized in such a way that it can be applied to any SOA
Category Criteria Evaluation
Overall Vendor commitment to open standards
Cost of acquisition
Legacy Mainframe connectivity
Support Database connectivity
Packaged applications (e.g., SAP) connectivity
Extensibility Rich client support
Thin client support
Mobile client support
Web services collaboration
Infrastructure Back-end technologies (databases, workflow engines, etc)
Open language support
Table 1. SOA Evaluation Criteria
The overall category included these criteria:
Vendor commitment to open standards
Cost of acquisition
9.2.1. Vendor commitment to open standards
Microsoft gets high marks for both its leadership in the Web service standards
community and its incorporation of Web service standards into products. The Jupiter
Research3 study asked IT decision makers to rank the top vendors in terms of
interoperability and Microsoft ranked the highest of any vendor, with 72 percent ranking
Microsoft as tops in interoperability.
Virtually every major Web service standard was either developed or co-developed by
Microsoft. The starting point for the whole Web service revolution was SOAP. SOAP
was first championed as a platform-neutral standard by Microsoft at a time when every
J2EE company was embracing RMI/IIOP, a Java-only protocol based on the old CORBA
It is certainly true that IBM has also played an important role in bringing Web services to
the mainstream, but wt uMi oot v i a udrad g f e rgnos
i ot c sfs io r ne t i o ht oeeu
h r ’ sn y sn n e
interoperability, the entire industry today would still be trying to figure out how to make
9.2.2. Cost of acquisition
In my experience, the low acquisition costs are usually the clincher for those who choose
Microsoft technologies. I explored this issue in a previous white paper4 in which I
examined the cost differential between Linux and Windows solutions and created
spreadsheets for calculating that differential in actual projects.
While it is generally true that the up-front acquisition cost of the Linux operating system
is less than that of the Windows operating system, it does not follow that a full Linux
solution is cheaper than a full Windows solution. The most important factors driving up
the Linux cost are these:
Je l x t l“ t oe b i ; o T cnl y ngrR tMi ootn Its Technologies for
o Wio e a I e pr it H w eho g Maae a
c . , n r a ly o s e c sfad
D vlp et Microsoft Monitor, MIC04-C02.
ee m n”
Roger Sessions, Modeling Software Architectures and Platform Choices. Available at
www.objectwatch.com. Look for the white papers link.
The Windows operating system includes a great deal of required infrastructure
that you need to pay extra for in Linux. One such example is reliable
The additional components that are not included in either operating system are
typically much more expensive for Linux than they are for Windows. One such
example is workflow management.
JBoss, the most competitive of the open-source collaboration technologies, might
someday make Linux more cost competitive, but for most large enterprises, this is still
olau rps b i . cod go a nr“B st ho g hs o yt en
n ft e os it A cri t G r e J ose nl y a ntebe
y u i ly n t , c o
sufficiently proved in business-critical enterprise projects, nor does the vendor offer
support and account management tht ol caeg t m rel dr”
aw u hlneh a te e .
d l e k a s5
Some projects may be cheaper to implement on Linux than on Windows, but in my
experience, a majority of enterprise-caliber projects that need asynchronous messaging,
secure communications, industrial strength databases, and workflow coordination
(capabilities that are not part of standard Linux) will be less expensive to implement on
The compelling cost/value proposition of the Microsoft technologies was important in all
of my case studies.
For Avista, the huge cost differential between WebSphere MQ and Microsoft HIS was
t dc i f t i f o o H S T eo la w rad ota cs fr v t s
h ei n a o n a r f I. h t ahr a n sf r ot o A ia
e dg cr v t d e w e s s’
clustered HIS intermediary systems was about $14,000. My calculations from my
previous white paper show an IBM WebSphere/Linux solution would have cost them at
least ten times as much, primarily due to the high cost of WebSphere MQ.
NORIS saved considerable money moving from a mainframe database to SQL Server.
The mainframe database was running more than $650,000 annually for maintenance and
licensing. Their total hardware platform costs are now around $175,000 annually, an
almost 75 percent reduction in cost. In fact, their entire IT budget is now less than it was
in 1998, before they undertook the NORIS rewrite.
The bottom line is that when evaluating the cost of a proposed infrastructure, be sure to
include the costs of the entire software stack, the development tools, run-time licenses,
and tool productivity. Looking at the cost of, for example, only the operating system is
likely to lead to unpleasant cost surprises.
9.2.3. Productivity tools
The major differentiator between companies that support Web services is tools. Good
tools make a tremendous difference in the cost of developing and maintaining Web
service. A Ufudh Mi ootolu e i r i y pout eo c an We
sC C on t e c sft si “ c d l rdcv fr r t g b
r o t neb” i ei
services. NORIS credited this same tool suite for allowing a staff of 13 to maintain 36
Y N t e a “ g Q ar to E t pi A p ct n e e ,Q 4 Ma 1,04G r e
. as t l Mai uda fr n rre plao Sr r 2 0,
i ., c n e s i i vs ” y 020, a nr
The Microsoft tools are especially good for building thin client applications. The NORIS
case study highlighted some highly effective applications based on ASP.NET. Qwest
uses ASP.NET extensively to build an advanced customer portal.
A ia D niCu b xln w y ei sh Mi ootolspot e a that
v t s en rm ep i h h l e t
s’ s as k e c sft supr H sys
r o .
using ASP.NET and Visual Studio.NET greatly reduces the time Avista needs to create a
compelling UI. Dennis calculates that new UI functionality can be added in about three
days, including testing and incorporation of user feedback. Using HIS/Web services
makes incorporation of additional CICS functionality almost trivial. Dennis calculates a
typical wrapper can now be created in less than one day. All in all, he describes the
Microsoft tools for creating browser-bsd srn r cs s w ne u”
ae ue i e ae a “ odr l
Q et et pi a h etxett euao o t dvl ecm ui tb
w ss n rre r icepc h dct n fh ee pro m n yo e
’ e s ct s e i e o t
s p f d hn c sfs ihr ir esdWh eos wlb i l e it
i li w e Mi oot Wh eos se ae. ihr i en u dnh
m ie r ’ t e l t e l cd e
upcoming Visual Studio.NET 2005 release and will allow Qwest to directly embed the
infrastructure attributes and constraints of their standard operating environment (SOE)
into Visual Studio.NET, allowing developers to use the SOE by dragging, dropping, and
For Avista, teaching the browser servers to speak SOAP was probably the easiest part of
the whole project. This is because of the tight integration of Web services support into
VsaSuiN T Wh e ot a r edr“upr S A ,e f hv
i l t o E . i m sm j vnos spot O P vr e ae
u d. l o ” y w
integrated SOAP support into their tool set as well as Microsoft. When using SOAP or,
for that matter, any of the family of Web service standards, the important question is not
how well your vendor supports SOAP (most vendors will claim excellent SOAP support),
but how well your vendor hides the details of using SOAP from you. The less you know
about SOAP (other than the fact that it exists), the happier your life will be.
Microsoft has been one of the two industry leaders in the whole Web service movement,
the other being IBM. Thus it is no surprise that SOAP, WSDL, and the other Web service
standards are so tightly integrated into the Microsoft tool set. A programmer can make
use of Web services without having to know anything about how Web services actually
A C C ’B rn elsy, t Mi oot ola O Pcomponent looks like any
s A U s yo H a asi h c sfw r S A
y n e r d
other component. This makes it extremely easy to use SOAP components from any
system built in Visual Studio.NET. And Visual Studio.NET is just as happy to consume
WebSphere SOAP components as it is .NET SOAP components.
Byron says t t c sfs i aSui
h Mi oot Vs l t o
a r ’ u d .NET is a particularly good tool for creating
Web services because it automates much of the otherwise tedious work. Visual Studio is
Mi oot pi a dvl et l tVsaSui a b e i is py .E
c sfs r r ee pro . h i l t o We sr c si laN T
r ’ m y o o Wi u d, ve m
componn “xoe” i a i ut s na cm ui t n po cl O P
etepsd wt nn sy t dr o m n aos rt o S A .
h d r a d ci o ,
According to Byron, when a .NET component is exposed as a Web service, it suddenly
becomes usable in a large number of projects including those not using Microsoft
Visual Studio makes it easy to use systems packaged as Web services, whether or not
those services are developed in .NET. There is no need to hand code WSDL service
dsr t n. s yo sy, VsaSui iia aeo “r ad rp
ec p osA B rn asi i l t o ts m tr fda n do.
ii n u d, t g ”
The last time I did a serious analysis of the back-end security problems impacting Unix,
Linux, and Windows,6 I found that Windows security at the back-end was much better
than either Unix or Linux. I found fewer problems reported and faster security patch turn-
A recent study by @stake has exhaustively (360 pages worth of exhaustively!) examined
the security of .NET on Windows compared with WebSphere on Linux.7 This report
concluded that while it was possible to create secure solutions on both platforms, the
Windows platform is slightly better in two areas. The first is in conformance to security
best practices. The second is in how easy it is for administrators to implement secure
solutions. While the differences between the two platforms were not overwhelming, this
study showed that the .NET/Windows platform is at least as secure as WebSphere/Linux.
The case studies included in this white paper do not compare Linux to Windows security,
but all are unanimous that Windows is a highly secure back-end platform.
Web services themselves do not provide security. Security comes from secure
architectures and methodical procedures such as the building of firewalls, carefully
defining (and following) security policies, and diligently applying update patches. As
CACU s yo H a sy:T bnf f mt vl o oe ss m , ic tat t
’B rn el as“ o ee tr h a e f pn yt si s ri lh
y i o e u e t ic a
cm ai m ng sl scry etr te.
o pn s aae o d eui bspa i s
e i t cc ”
From a scalability perspective, the Qwest systems are the most demanding of my case
studies. And of all the systems within Qwest, the IBZ (Internet buffer zone) systems,
especially those managing the browser clients, have the most demanding scalability
requirements, servicing more than 20,000 clients a day. The fact that Qwest can handle
this workload on a collection of 40 $2K machines is a tribute not only to .NET, but also
tt c s r sreapoc ado w ss r ic r A cri t Q et
o h l t e e r prah n t Q et a h et e cod go w ss
e ued v ’ ct u. n ’
et pi a h et h m ci s ai u t IZa “a lbek g s et
n rre r ic t ah e m k g ph B r br y r i a w a”
e s ct ,e n n e e e an .
The case study with the most challenging response time is probably Avista. For Avista,
response time had to be a scary proposition. A typical Avista request goes through more
than 11 unique steps, including communications with a mainframe program over one
thousand miles away! Yet even with 60-100 browser clients hitting the machine at the
same time, response time is less than one second. This speaks well to the response time of
ASP.NET and HIS.
My analysis is available at www.objectwatch.com/issue_37.htm. Keep in mind that the data is dated.
Security Evaluation of Microsoft .NET Framework and IBM WebSphere by @stake, June 2003, available
All of the companies I interviewed believed that the .NET systems were highly reliable.
Only one reported any failures at all in the last two years, and this was due not to
ASP.NET, or .NET in general, but to a DNS name server.
9.3. Legacy Support
The legacy support category included these criteria:
Packaged applications (e.g., SAP) connectivity.
9.3.1. Mainframe connectivity
The Avista case study highlights an approach to mainframe connectivity called wrapping.
T e ue Mi oot H St ho g,n seicl , e O
hy sd c sfs I e nl yad pc i l t C M-TI part of that. This
r ’ c o f ay h
allowed them to expose CICS functionality by projecting it onto a COM component
living in an HIS server. This COM component was then wrapped with a SOAP layer that
could be made available to anybody. As Avista switches to HIS 2004, the SOAP
wrapping will be part of the product. However, even with creating their own SOAP
wrappers, they have been able to reuse millions of lines of CICS code for a very small
CACU also wanted to interoperate with their mainframe applications. They wrapped the
mainframe applications with SOAP interfaces and coordinated communications through
BizTalk. Once these components were SOAP-enabled, they could be accessed using the
built-in SOAP functionality of Visual Studio.
9.3.2. Database connectivity
Database connectivity is good in .NET. While one of the case studies (NORIS) is using
SQL Server exclusively, most have a mix of databases at the back-end. Qwest is using
Oracle, DB2, and a bit of SQL Server. Both CACU and Avista are using traditional
9.3.3. Packaged applications connectivity
Most packaged apps today are embracing Web services as their programmatic interface.
Many of these are running happily on the Microsoft platform. SAP is a classic example of
a large, back-end, mission-critical package ss m A cri tS Ps b i,
d yt . cod go A ’We se
e n t
“ rt n 0 0 S Pi tli su o Mi oot no s more than all other
Moeh 4, 0 A n aao rn n c sfWi w —
a 0 s lt n r d
platforms combined. Almost two-thirds of all new SAP installations are deployed on
Mi oot no s 8
c sfWi w .
r d ”
In the area of extensibility, I included the following criteria:
Web service collaboration
I have already discussed the use of Microsoft technologies in each of these areas with the
exception of mobile clients. Rich clients are used extensively in NORIS. Thin clients are
used extensively in all of the case studies, as is Web service collaboration. I personally
hv n epr ne i Mi oot m b e ln t ho g s n nn o t cs
ae o xe ec wt c sfs oi cete nl i ad oe fh ae
i h r ’ l i c oe e
studies discussed this area. But in the areas of rich, thin, and collaborative clients, it is
clear that Microsoft is an industry leader.
The infrastructure category included these criteria:
Open language support
9.5.1. Back-end technologies
Microsoft has an array of enterprise-caliber, back-end technology products. A small
sample of these products includes:
Host Integration Server, a technology to interoperate mainframe operating
BizTalk Server, a technology to coordinate workflow throughout the enterprise
SQL Server, one of the most advanced enterprise databases products in the market
Looking specifically at the database market, Windows seems to have a strong lead
against Linux. A recent Wall Street Journal article quoted Gartner as pegging the Linux
database market at $300 million and the SQL Server Windows database market at $1.32
billion.9 That means that the size of the SQL Server market alone on Windows is greater
than four times the combined market of all databases on Linux.
SQL Server also seems to be doing well against even non-Linux technologies. According
to Wall Street Journal article, while IBM is still the top database vendor, IBM is suffering
Ma eo r c,G r eSy IM H l T p ptn 03 a bs Sl , The Wall Street Journal,
r l Pi e“ a nr asB
cl n t e o S o I 20 D t ae a s
d a e”
May 26, 2004.
Slight sales gains of only 4.9 percent over the previous year, less than half of the
sl gi o Mi oot S LSre
a s a s f c sfs Q e r
e n r ’ v
Particularly poor sales on Linux, the non-Windows market that is getting most of
If we look at market share as opposed to actual sales, the numbers are even more
surprising. IBM actually stayed flat from the previous year. Oracle did even worse: it lost
market share. Microsoft was the only one of the three to actually gain market share, and,
perhaps not by coincidence, gained almost exactly the same amount that Oracle lost.
SQL Server has been well tested in my case studies and been proven to be an enterprise
C C ’bs esn lgnest e i Mi oot Q Sre Muh fh hd en
A U s ui si ei c is r n c sfS L e r c o t s a be
n tl e od r v. i
stored in Oracle databases. Compared to Oracle, Byron finds SQL Server less expensive
to buy and easier to administer. Fine-t n g r li B rn as“ cnt t
u i O a es yo sy,a os n
rn c , a
n h a ”I cn at e as Q Sreiv t l sl
i t r .n ot s h sy S L e rs iu l e -tuning.
gm e r , v r ay f
NORIS stores almost everything in SQL Server. The total data stored in NORIS exceeds
one terabyte. The system supports 2,200 users, 800 desktops and 300 police cruisers with
wireless access. At any given time, there may be 300-400 concurrent clients hitting
NORIS applications, all supported by a back-end SQL Server database.
SQL Server performs much better than the old NORIS CODYSYL database. In the old
days, the CODYSYL mainframe database would get sluggish at 200-300 IOs per second.
Their SQL Server 6.5 runs 7000-8000 IOs per second quite happily. That is a thirty-fold
improvement in IO at one fourth the annual cost. This is particularly remarkable given
that they are running on an old version of SQL Server. The current release (SQL Server
20) a m c btr e om neA cri t N RSs aWr h wt20
00 hs uh eepr r ac. cod go O I’Pt i t i 0-300
t f n g, h
people banging away at the sys m t r pnei e f t i lr sco i“ sa
t , e e os t o ay c t nat ns a np
e h s m pa a i
o t f gr E e wl cr sa hshtr e e ii s fo s n ue tt e 4
fh i e” vn i a er e t t vr m lo o rw ad sdoa 2
en . d d c a a s ln k
hours are now completed within a minute or so.
C C ’B rn el blvshth aaaito bc-end infrastructure
A U s yo H a eee t t vib i f ak
y i a e l ly
components distinguishes Windows from Linux. He says that Linux has grown through
cultural and stylistic differences that have diluted its evolution. He thinks that the tool
availability is much weaker and the infrastructure support is nonexistent when compared
with Microsoft. To build enterprise level code for Java/Linux, one requires orders of
magnitude more coding than for .NET/Windows. This requires a lot of highly trained
(and expensive) coders, more expensive development costs, and more expensive
m i eac cs . A U s h ooh is p :hibs ess u d g ol c s
a t ne ot C C ’pi spysi l t r ui sibi i w r l s
nn s l m e e n ln d a
banking applications, not world class infrastructures. They will make their money
building what they know how to build best.
9.5.2. Vendor neutrality
Some people argue that Microsoft is not vendor neutral. In fact, Microsoft not only works
well in heterogeneous environments, it has been the industry leader in heterogeneous
interoperability, especially for Web service standards, for many years now.
J2EE vendors often describe their API as vendor neutral. Actually, the leading J2EE
products all include large portions of vendor specific API and this vendor specificity is
only getting worse. According to Gartner:
By 2007, nonstandard [J2EE] application programming interfaces will represent
up to 40 percent of the programming model of the leading [J2EE] EAS products
(0.7 probability), up from 15 percent in 2004.10
Historically, Microsoft and most of the rest of the industry have taken different
approaches to interoperability. Microsoft has approached interoperability through
standards related to communications. Most of the rest of the industry has, until recently,
embraced a philosophy I call interoperability through portability.
The philosophy of interoperability through portability assumes that if one can get all of
oe ss m trn n h sm p t r , oe plaos i b alti e pr e
n’ yt so u o t a e lf m t s ap ct n wl e b on r e t
s e e ao h i i l e to a
through the standard communications protocol of that platform. For J2EE, that protocol is
called RMI/IIOP. The philosophy of interoperability through portability characterized
the CORBA technologies of the mid-1990s and, of course, its direct offshoot, J2EE.
At this point, it is clear that interoperability through portability has been a failure. As the
Gartner quote shows, large portions of a typical J2EE application make use of
nonstandard APIs that effectively make portability an unattainable goal. Today, getting
two different J2EE platforms to interoperate is almost impossible without using Web
services that, ironically, were first proposed not by the J2EE community, but by
9.5.3. Open language support
Microsoft frequently seems to prefer C# as a programming language. Most of the
development community sees C# as a Java derivative and no easier (or more difficult) to
learn than Java.
H w vrMi oot oe l gaer e ok fN Tacm oa s ayagae
o ee c sfs pna ug f m w r o .E co m dt m n l ugs
, r ’ n a e n
bs e C . w o t m si pr n “t rl gae a VsaB s ad O O ,
ei s #T o fh otm ot to e a ugs r i l ai n C B L
d e a h” n e u c
the later offered by third parties. Depending on existing skills, these languages can be
much easier to learn than either C# or Java. As I have already discussed, both CACU and
Avista found major cost advantages to using Visual Basic as their language of choice for
.NET. Presumably, they would have had similar reservations about using Java as they did
Although the J2EE framework could theoretically accommodate non-Java languages, in
practice, there is little if any enterprise work done with any J2EE platform that is not in
Java. I looked at this issue in one of my ObjectWatch newsletters.11 For better or worse,
Y. Natis et l“ g Q ar to E t pi A p ct n e e ,Q 4 Ma 1,04G r e
. ,Mai uda fr n rre plao Sr r 2 0,
a c n e s i i vs ” y 020, a nr
R gr es n,IJv L nug N u a ” ObjectWatch Newsletter #32, available at
oe Ss os“ aa agae et l The
i s r?
J2EE means Java, period. .NET means C# (of course), but also COBOL, Visual Basic,
and many other languages.
It is clear that companies that are embracing service-oriented architectures (SOAs) are
finding that they are paying off big time. Some of the payoff is expected, such as system-
to-system interoperability. Some of the payoff is unexpected, such as dramatic
improvements in reliability. Given the highly favorable cost/benefit ratio, it is likely that
SOAs will be here for a long time.
It is also clear that Microsoft is an industry leader in service-oriented architectures, not
only in the Web service standards that define interoperability, but in the back-end support
technologies that make up the overall SOA infrastructure. These include SQL Server,
BizTalk, and HIS, among many others.
On the client side, there is no question that Microsoft technologies are highly advanced.
ASP.NET for thin clients, Windows Forms for rich clients, and Visual Studio.NET for
exposing functionality as Web services all set the bar in their areas.
Microsoft is certainly not the perfect solution for every problem. This is the reason we
must stay focused on not just interoperability, but specifically on heterogeneous
interoperability. But there are clearly a large number of problems for which Microsoft
technologies offer a compelling value proposition of advanced capabilities, including
highly productive tools and excellent support for heterogeneous interoperability. Perhaps
most important, Microsoft technologies do all of this at a cost far lower than any other