Interoperability Through Service-Oriented Architectures (SOAs)

An ObjectWatch White PaperRoger Sessions

Version 1.00

Last Modified: July 30, 2004

ii

About Roger SessionsRoger Sessions is the author of Software Fortresses: Modeling Enterprise Architecturespublished by Addison-Wesley, five other books, and dozens of articles. He is the CEO ofObjectWatch and is a frequent and popular conference speaker. More than 50,000 peoplein more than 20 countries have attended Sessions’s workshops on building and designinghigh-end software architectures.

ObjectWatch services include:

The Architect Technology Advisory, a monthly architect advisory serviceavailable by subscription containing in-depth technical analysis of topics thatarchitects must understand to design good systems and protect those systems fromobsolescence.

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. Pastissues are available at www.objectwatch.com.

For more information on any of our services, contact beverly@objectwatch.com.

iii

AcknowledgementsThe writing of this white paper has been a momentous undertaking. It could not havebeen done without some financial support and I am grateful to Microsoft for helping todefray some of the expenses. I am also grateful to the employees of Qwest, Byron Healyof CommunityAmerica Credit Union (CACU), Dennis Crumb of Avista Corp., andPatrick Wright of Northwest Ohio Regional Information System (NORIS) for theirgenerous help in creating the case studies.

This white paper was written under a strict noninterference agreement that guaranteedthat editorial control would rest exclusively with ObjectWatch. The opinions expressedhere should be viewed as my opinions or those of named individuals and not those ofMicrosoft, Qwest, CACU, Avista Corp., NORIS, or any other company.

Much of the clip art is taken from clipart.com and is copyrighted material and used withpermission.

Legal NoticesObjectWatch® is a registered trademark of ObjectWatch, Inc., Austin, Texas. Othertrademarks are owned by their respective companies. This white paper is copyright©2004 by ObjectWatch. It may be freely copied as long as it is copied in its entirety and nochanges are made in any way, including changes to these legal notices.

iv

Table of ContentsPart 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............................................................ 54.1. Qwest’s IT Organization..................................................................................... 54.2. Qwest’s SOA Architecture................................................................................. 64.3. The Benefits ........................................................................................................ 8

5. CACU— An Example of Automated Workflow....................................................... 85.1. CACU’s IT Organization.................................................................................... 85.2. CACU’s SOA Architecture................................................................................. 95.3. The Benefits ........................................................................................................ 9

6. Case Study: Avista Corp.— An Example of Mainframe Connectivity ................... 106.1. Avista’s IT Organization................................................................................... 106.2. Avista’s Decision Process................................................................................. 106.3. Avista’s SOA Architecture............................................................................... 126.4. The Benefits ...................................................................................................... 13

7. NORIS— An Example of Mainframe Migration and Web Services Orchestration 137.1. About NORIS.................................................................................................... 137.2. NORIS’S IT Organization................................................................................ 137.3. NORIS’S SOA Architecture............................................................................. 147.4. The Benefits ...................................................................................................... 16

Part III: Analysis ............................................................................................................... 16

8. Lessons Learned From Case Studies ........................................................................ 168.1. Buy Your SOA Infrastructure........................................................................... 168.2. Legacy Apps: Rewrite or Wrap?....................................................................... 178.3. Leverage Existing Skills ................................................................................... 178.4. SOAs Scale Well and Are Reliable .................................................................. 178.5. SOAs Reduce Costs .......................................................................................... 18

9. Evaluating Microsoft SOA Technologies ................................................................. 199.1. A Standard Set of SOA Evaluation Criteria ..................................................... 199.2. Overall............................................................................................................... 209.3. Legacy Support ................................................................................................. 249.4. Extensibility ...................................................................................................... 259.5. Infrastructure..................................................................................................... 25

10. Conclusions........................................................................................................... 28

1

Part I: SOA Overview

1. Executive OverviewInteroperability is one of the key issues facing IT organizations. Service-orientedarchitectures (SOAs) based on Web service standards have emerged as the leadingindustrywide enabler for interoperability.

Companies that are embracing SOAs are finding huge benefits. Some of these benefitsare expected, such as increased revenue opportunities through collaboration, improveddecision making through shared data, and decreased personnel costs through automatedworkflow. But many of the benefits of SOAs are unexpected, such as dramaticimprovements in system reliability, huge reductions in development and deploymentcosts, migration of systems from expensive mainframe to inexpensive server clusters andimpressive improvements in time to market.

This white paper includes my interviews with companies that are successfully usingSOAs. From these interviews emerged many lessons that are applicable to any companyinterested in leveraging SOAs.

This white paper also provides a set of criteria for evaluating SOA technologies. I usethese criteria to specifically evaluate Microsoft’s SOA technologies, but these same criteria could be applied to any other SOA vendor. The specific Microsoft strengths thatemerge 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 anSOA successfully in a heterogeneous environment in which the strengths of manyplatforms can be realized.

2. Overview of White PaperThis white paper is divided into three main parts. Many readers will want to read all threeparts. 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 givenin section 9.1 useful for evaluating any SOA platform.

2

3. Service-Oriented Architectures (SOAs)Application interoperability is the single most important issue facing most enterprisesoftware architects. The use of SOAs based on Web service technologies is the bestapproach we have to interoperability. This is the message I hear over and over again inmy consulting engagements.

My analysis is backed up by a recent study by Jupiter Research1. It showed that whenchoosing a development platform, the top concern of IT decision makers wasinteroperability with existing applications. For 55 percent of the IT decision makers,SOAP (simple object access protocol) and WSDL (Web service definition language), theflagship 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 Webservice standards were defined. These systems, therefore, do not support Webservices.

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 yoursystems and those of other enterprises

Improved decision-making through immediate availability of critical data acrossthe enterprise

Lowered personnel costs through workflow automation Reduced complexity of interoperability

The pre-SOA approach to interoperability was to connect each application to each otherapplication in an ad-hoc fashion as shown in Figure 1.

In the SOA approach to interoperability, we build an SOA infrastructure with whichevery system interoperates, as shown in Figure 2. With SOA style interoperability, eachapplication requires one, and only one, connection— a connection to the SOAinfrastructure. 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 howsome organizations built and benefited from such architectures in upcoming sections.

1 Joe Wilcox et. al., “Interoperability: How Technology Managers Rate Microsoft and Its Technologies for Development,” Microsoft Monitor, MIC04-C02.

3

Application 4

Application 2

Application 1

Application 3

Key

a-b = connection fromapplication A toapplication B

Application 5

Application 6

1-21-21-61-6 1-31-31-41-41-51-5

4-24-24-64-6 4-34-34-14-14-54-5

6-16-1

6-56-5

6-46-4

6-36-3

6-26-2

2-12-1

2-62-6

2-52-5

2-42-4

2-32-3

5-65-6

5-45-4

5-35-3

5-25-2

5-15-1

3-23-2

3-13-1

3-43-4

3-53-5

3-63-6

Figure 1. Pre-SOA Interoperability

SOA Messaging

WorkflowEngine

UtilityServices

Business Applications

Shared DataServices

Application 4Application 2Application 1 Application 3

SOAPGateway

BrowserGateway

SOA Back-end ServicesInternet Gateways SO

AIn

fras

truc

ture

Application 5 Application 6

Figure 2. SOA Interoperability

A service-oriented architecture (SOA) is any software architecture that focusesspecifically on the problems of interoperability. It is an approach to developing new

4

systems and wrapping existing systems in such a way that these systems can worktogether.

Most people think of SOAs as being closely related to a set of standards collectivelyreferred to as Web services— services that are specifically related to interoperabilitybetween heterogeneous systems. For example, applications built on IBM’s WebSphere can communicate with applications built on Microsoft’s .NET Framework through their common support of Web services.

Heterogeneous communications require agreement on these technical issues (as shown inFigure 3):

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 isdependent? There is widespread consensus within the industry that these agreementsshould be based on Web service standards.

Coordination of results

Communicationsprotocol

Message format

Proof of identifyAdvertisement of services

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

5

WSDL (Web service definition language) for letting a potential collaborator knowwhat you are willing to do

UDDI (universal description, discovery, and integration) for coordinatingdiscovery of information about Web services

In addition to these, there are three standards that will soon be very important inworkflow 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 whichapplications 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

remoting) 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 theflexibility to choose from among the best-of-breed technologies for future projects. Yourability to choose from among many technologies gives you bargaining strength with yourvendors.

The bottom line is that you want enough agreements to ensure interoperability betweensystems, but not so much that you stifle future technology/platform choices.

Part II: Case StudiesLet’s see how SOAs are providing real benefits to four companies today.

4. Qwest — An Example of a Large-Scale SOAQwest is a telecommunications company providing voice, Internet, data, and videosolutions to residential, business, and government customers nationwide. Qwest has45,800 employees and transmits approximately 240 million calls every day.

4.1. Qwest’s IT Organization

Qwest has more than 1,000 business applications currently in production on manydifferent platforms. More than 120 of these applications are written in .NET andsupported by 40 development teams with more than 500 developers. Qwest clients

6

include the following:

Customer service employees staffing help desks are using rich client interfaces toaccess Qwest applications.

Field technicians working in the field typically enter the system through wirelessgeneral 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 phoneand interface with a voice recognition system.

Outside (non-Qwest) applications represent additional revenue opportunities.

4.2. Qwest’s SOA Architecture

In order to simplify application development, Qwest has defined a standard operatingenvironment (SOE). The SOE is a set of components, services, and APIs that can be usedby any developer at Qwest. The SOE includes support for database access,communications, security, and more. The SOE is maintained and evolved through apartnership between Qwest Development and Operations teams.

The overall Qwest architecture is composed of a series of related zones, as shown inFigure 4. (Although, they don’t call them zones; this is my ownterm.)

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.

7

Internet BufferZone (IBZ - IIS)

Application Zone (.NET or J2EE)

Data Zone(DB2, Oracle)

Dat

abas

eS

ervi

ces

SO

AP/

Mes

sage

Bus

KEY

securityzone

securityzone

IBZ data

SOAPSurrogate

ASP.NET

hardwarebalancedcluster

OutsideApp

BrowserClient

HTTP

SOAP

J2EE or .NET apps

Business data

Outside Zone

Figure 4. Zone Relationships

The outside zone is the area outside of Qwest’s immediate control. This includes mostly browser clients entering the Qwest domain through HTTP but also outside applicationsentering via SOAP.

The internet buffer zone (IBZ) is the area that accepts requests from clients living in theoutside zone. It is a self-contained security zone, meaning that it is protected by firewallsand other security mechanisms, and is similar to what some companies call thedemilitarized zone. Requests from browser clients arrive via the Qwest portal calledMyQwest.com. These requests are processed by ASP.NET applications. Requests fromoutside applications are processed by SOAP surrogates. Both the ASP.NET applicationsand 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

zone. 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 areinherently insecure. By creating an IBZ, Qwest has effectively protected its mission-

8

critical business systems and business logic from unauthorized access. If a hackermanages 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 regeneratethe entire IBZ quickly.

The next zone is the application zone (AZ). The AZ houses applications that containmission-critical business logic. These systems can be built in either .NET or J2EE. AtQwest, the J2EE systems are typically WebLogic on UNIX. The .NET systems are,obviously, on Windows. Qwest allows individual groups to make their own technologychoices within supported SOEs and focuses its corporatewide policies on how thoseapplications 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 andsecurity 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 separationenforced by the IBZ.

Applications within the AZ store their data in the data zone (DZ), which is closelyassociated with the AZ. I think of the DZ as a separate zone mainly because it has suchspecific hardware requirements. In order to access the DZ, the applications make use ofthe database services that are part of the SOE that I discussed earlier.

Qwest has used this architecture to achieve a high degree of interoperability. Applicationsare all able to communicate with each other through either the Message Bus or by usingSOAP. According to Qwest, interoperability between a .NET application and a J2EEapplication is no more difficult than between two .NET applications or two J2EEapplications.

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 WorkflowCommunityAmerica Credit Union (CACU) started in 1940 and is now the Midwest’s largest credit union with more than 110,000 members and assets exceeding $1 billion. Itsmany products include online banking, CDs, IRAs, money market funds, consumer loans,home equity loans, mortgages, credit cards, brokerage services, and insurance. Theproject lead is Byron Healy, Senior Technical Architect, Information Services.

5.1. CACU’s IT Organization

CACU was originally a mainframe shop. Most of CACU’s operations ran on two mainframes. The old mainframe processors burned out once a month or so. It was timefor an architectural makeover. Their goal was not to eliminate mainframes, but to use

9

them where they made the most sense. CACU believed that the right place for themainframes was the financial host back-end.

5.2. CACU’s SOA Architecture

The SOA approach has allowed CACU to use many different applications, programmingplatforms, and development technologies. Applications are allowed to use the tools theyneed to use. Enterprisewide agreements are limited to SOA-style interoperability. Theagreement points across applications are:

BizTalk will be the standard for orchestrated workflow. BizTalk is a tool formanaging complex workflow. It includes the ability to translate data, manageasynchronous communications, and coordinate error processing.

SOAP will be the standard for messaging format.

Byron believes the interoperability and reuse is achieved through packaging applicationsas 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 forcredit unions) compliant.

By keeping their financial applications on the large UNIX boxes and moving selectapplications and building new applications for server clusters, they received the benefitsof a new SOA-style architecture without having to pay the price of moving databases orthrowing out working mission-critical applications.

What makes all of this work is not just Web services and BizTalk, but also goodarchitecture, good business processes, close attention to technical infrastructure, and lotsof 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 SOAapproach, the CACU IT organization has developed a reputation for building highlyreliable, highly usable systems. According to Byron, “They are amazed at our ability to manage projects. We participate in every major decision in the organization. I can’t do justice to how much we have benefited. Our data systems are now state-of-the-art andbest-of-breed. For us and our credit union members, the value has been compelling.”

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 ofthese applications as easy as dragging and dropping. Byron doesn’t even think of himself as aprogrammer. If pressed, he would describe himself as an “integrator,” or, even more likely, as a “drag and dropper.” “While there is still the need for the occasional technical heavy lifting, for the most part we just drag and drop,” says Byron.

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

10

6. Case Study: Avista Corp. — An Example ofMainframe ConnectivityAnother company focusing on integration is Avista Corp., which is one of the West’s leading energy marketing and resource management companies. It was founded in 1889and now has about 1,800 employees and reported $343 million in earnings in Q1-04. Itsprimary market covers more than 30,000 square miles and it has 300,000 customers inWashington, Idaho, Oregon, and California. Avista Corp. has been an industry leader inInternet-based facility management, bill consolidation, and payment services. DennisCrumb is a RAD (rapid application development) Analyst for Avista, and he was (andstill is) the development lead.

6.1. Avista’s IT Organization

Avista originally ran its business from an IBM mainframe. Client/server COBOL/CICSprograms ran everything from customer billing to figuring out how to get electricity to anew address. The amount of code on the mainframe was massive, includingapproximately 400 programs developed over a four- to five-year time period at a cost ofabout $17 million.

Avista wanted to allow customers to view and pay bills over a browser and directlymanage their own account information. This would greatly reduce the need for humanintermediaries and would improve customer service.

6.2. Avista’s Decision Process

How would Avista go from human-mediated CICS architecture to a customer-accessibleInternet architecture? There are two main approaches Avista could have chosen: rewriteor mediate.

Avista could have rewritten its back-end CICS systems into ones based on newerInternet-friendly technology platforms. Good candidate platforms would have beenIBM’s WebSphere or Microsoft’s .NET.

The second approach would have been to build software mediators. These mediatorscould be Internet accessible on the customer side, and CICS compatible on the mainframeside. 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 simpleone-to-one operation. In other words, if a customer wanted to do some “simple” (from the user’s perspective) operation, such as pay a bill, that operation could require the coordination of multiple back-end systems on the mainframe side. In the old system, thiscoordination was done by trained human operators. In the new system, that coordinationwould be done through software.

Avista also wanted to open their systems to outside collaboration, such as directpayments to be made by partner systems.

11

Whatever technology was chosen, it absolutely had to satisfy the following requirements:

Be implemented with no disruption to existing CICS systems running on IBMmainframes

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 Yield response times that are “browser-fast,” the standard industry definition of

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

In addition to these absolute requirements, there was a set of technical “nice-to-haves.” These included:

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 themediation product(s). Oh yes, and of course, implement!

There were three products Avista considered for mediation: IBM’s CICS Transaction Gateway, IBM’s WebSphere MQ (Message Queue), and Microsoft’s HIS (Host Integration Service).

Using WebSphere CICS Transaction Gateway for mediation would have been an obviouschoice, since it is the IBM standard technology for connecting to CICS. CICS is, ofcourse, also an IBM product. However, using WebSphere CICS Transaction Gatewaywould have required a general commitment to IBM WebSphere, the IBM generalenterprise technology umbrella. Because of version incompatibilities with their CICSversion, this was not an option.

Using IBM’s WebSphere MQ as the basis for mediation was technically attractive. This is a message queue technology that provides high-quality asynchronous transportation. Itruns on both the IBM mainframe and the Windows operating systems. There are manypossible ways this could have been used, but one would have been to have the browserWeb servers directly connected to the CICS machine through WebSphere MQ.

The other product considered for technical mediation was Microsoft’s HIS 2000 (Host Integration Service 2000). HIS is basically a collection of technologies that togetherprovide 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 processon a Windows operating system. The COM component presents a COM interface that isfunctionally equivalent to the CICS interface. Method invocations to the COM

12

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 theexisting CICS systems’ perspective, HIS is just another CICS client. Second, at a licensing cost of only $2,000 per server, it was a small fraction of the cost of aWebSphere MQ solution. The ability to reuse their CICS systems without having to makechanges on the mainframe and the low cost of HIS were compelling, and Avista decidedto use HIS.

6.3. Avista’s SOA Architecture

With HIS, the CICS components are made available as COM components, but this is onlypart of the answer. COM components can be used by Microsoft technologies, but COM isby no means an “industry standard.” If the CICS systems were to interoperate with a widevariety of systems, including non-Microsoft systems, then something else needed to getinvolved, specifically something that was a widely accepted industry standard. This, ofcourse, was SOAP.

Using SOAP on the client side of the mediator meant that the browser Web servers nowhad to make SOAP requests of the CICS systems which were projected as HIS COMcomponents, which were wrapped with a SOAP interface. This architecture is shown inFigure 5.

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 anotherMicrosoft product, BizTalk 2004.

BizTalk 2004 is the latest release of BizTalk. Avista is planning on moving workflowfrom code within the Web service components (which they had to write) to GUI basedBizTalk orchestrations (which BizTalk will coordinate). The old Web servicecomponents that included workflow will then be replaced by new components that willbe very simple front-ends to BizTalk orchestrations.

BrowserServer

Inte

rnet

HISServer

Mainframe

CICS ApplicationCOM Projection

SOAP Wrapper

Figure 5. Avista Architecture

Using BizTalk will allow Avista to create highly sophisticated workflow orchestrations

13

including data translation, compensatory transactions, and integration with many othertechnologies.

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 andWeb Services Orchestration

7.1. About NORIS

NORIS (Northwest Ohio Regional Information System) provides IT services to criminaljustice agencies in Northwest Ohio. It is dedicated to multi-jurisdictional data integrationand application cooperation among a range of software systems serving a variety ofcriminal justice agencies. Clients of this system include federal, state and local lawenforcement, courts, and corrections agencies.

Patrick Wright is the director of NORIS. He is responsible for high-level architecture andtechnical direction of the organization. Doug Kemp leads the team of programmers. Pathas been working with NORIS for 20 years now and, in fact, many of the team membershave been with the project for more than a decade. Pat believes that one of the reasonsthey have been able to build such a state-of-the-art system is because of the high degreeof specialized business experience of his staff.

7.2. NORIS’SIT Organization

NORIS was originally a series of mainframe applications. Data was stored in aCODASYL database. CODASYL was one of the original database models developedduring the 1960s.

CODASYL databases had two major drawbacks. The first was that the data pointerscould be declared only when the schema was initially defined. The second was that thetraversal 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 therelationships between data once the data was initially defined. Define once, run foreverwas the mantra of the CODASYL world.

So if NORIS was going to have a dynamic future, it had to be ported to a dynamicdatabase. And, as long as the data was going to need to move from one database toanother, one might as well reevaluate the whole architecture. For one thing, it was almostthe twenty-first century! Who needed a mainframe anymore?

14

The state of the art when NORIS was first built can best be described as “every system for itself.” A typical criminal justice system would have been built as a series of independent applications, each an island unto itself with a huge amount of dataredundancy. 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 ashared set of core applications, each accessing a common data repository, they could setup a system where no single item of data needed to be entered redundantly. And once thatdata was entered, it would appear the same regardless of the application from which itwas accessed. “Enter once, view forever” was their slogan.

The rewrite of NORIS had the following goals:

To port to a relational database that supported dynamic redefinition of data anddata 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 UNIFACEallowed them to build complex business quickly. However, several factors favored newdevelopment on Visual Studio. For one, platform neutrality had turned out to be anonissue, 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, makingUNIFACE clients more expensive than Visual Studio clients (with no licensing cost onthe 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 thebusiness logic of new applications.

NORIS also decided to use many other Microsoft products. On the browser side, theyfound ASP.NET and the Visual Studio.NET environment unsurpassed. The tightintegration 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 SQLServer, Microsoft’s implementation of the relational model. For workflow, they havebeen standardizing on BizTalk 2002 and will be porting to BizTalk 2004.

7.3. NORIS’SSOA Architecture

NORIS is now running its new implementation and supports a mind-boggling array ofapplications. The applications are loosely coupled through data shared from a commondata repository. Once a user is logged on, each system works independently from the

15

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-coreapplications all using a loosely coupled integrated data repository. A small sample ofthese 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

court cases Warrant, which administers warrants, missing persons, attempt to locates, and

protection orders Digital Mugshot System, which stores and retrieves mug shots

A new application being deployed countywide allows patrol cars to create and browseelectronic incident reports. NORIS built an interface based on BizTalk 2002 that grabsthe reports from the County 911 system and validates them against national datastandards through BizTalk orchestrations, and stores them into the Computer RecordsManagement application.

The overall architecture of this new application showing its relationship to existingNORIS applications is shown in Figure 6.

As NORIS continues to expand, it needs to become integrated closer and closer into otherjustice systems. As Pat says, “The heart of homeland security is data integration.” In 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 onimplementing this standard in Ohio. This standard will soon define how NORISinteroperates and cooperates with other justice systems of the future.

Since NORIS will need to interoperate with other systems using GJXDM, they need to beusing technologies that are closely aligned with XML, SOAP, and the other Web servicestandards. One way to do this is to choose a vendor that is part of the Web servicestandardization activity. The two companies that have been most closely associated withthese standards are IBM and Microsoft. Given the other constraints of NORIS (such askeeping the costs as low as possible), Microsoft was the better of these two choices.

16

SQLServer

BizTalk

WirelessAccess

Core ApplicationsUnifiedDataRepository

etc.

PoliceRecordsManagement

Stolen Vehicles

CourtCriminalTraffic

WantedPersons

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 StudiesThere are many interesting lessons we can learn from these case studies that areindependent of the Web services vendor. I’ll go through these one by one.

8.1. Buy Your SOA Infrastructure

SOA infrastructure (or a standard operating environment, as it is called in the Qweststudy) is the key enabler to interoperability. It is the glue that binds the variousapplications 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 thevendor.

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

17

(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 theirexisting legacy applications. Both felt that the cost and disruption involved in rewritingthese applications would outweigh any benefit. In general, this is a common thread. Mostcompanies are not interested in throwing code away. Therefore, technologies that allowexisting mainframe applications to be SOAP-extended play an important role in theiroverall SOA strategy.

But there are times when it makes better sense to let go of the old systems and rewritethem from scratch. NORIS was a good example of this. One reason for rewriting is whenthe application is tied to an archaic database. NORIS was originally built on an inflexibleCODASYL database, and no amount of wrapping would have given them the ability torapidly respond to constantly changing requirements.

8.3. Leverage Existing Skills

While Microsoft’s open language architecture readily accommodates a wide variety of languages, Microsoft frequently touts C# as the programming language of choice. I wascurious as to how C# plays out in the real world. I found that Microsoft’s fixation on C#is not shared by many in the business world. Both Avista and CACU believed they savedsignificant money by using Visual Basic rather than either C# or Java.

CACU’s Byron Healy explains why he prefers Visual Basic. First, there is easy access to VB programmers. Second, there is high productivity. Byron finds that a VB programmercan go in front of .NET, use a language with which he or she is already familiar, and“capture it almost immediately.” It all comes down to ROI. “While C# has some benefits over VB from a developer’s perspective, the readability of Visual Basic for the average person, as well as its simplicity, provides inherent value in the everyday demands of anIT organization,” says Byron.

8.4. SOAs Scale Well and Are Reliable

SOA-style services are almost always designed to be stateless, in that the services are notexpected 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 typeof 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 clustersrather than mainframes. In a server cluster architecture, requests are received by a routerthat can choose from a number of identically configured machines to process the request.

2 For an informal introduction to the issue of state and server clusters, see Roger Sessions, “Matters of State”, The ObjectWatch Newsletter #13, available at www.objectwatch.com.

18

There are three advantages to the server cluster architecture: scalability, reliability, andcost.

To scale a cluster, you just make another machine available to the router. This is lesscostly and less disruptive than trying to upgrade a mainframe

Reliability comes from natural cluster redundancy. If one machine in the cluster goesdown, the remaining machines can continue processing requests. On a mainframearchitecture, there is typically no machine redundancy. If the machine goes down, yoursystem is down.

The third advantage of server clusters is cost. Avista is able to support 60-100 concurrentclients (their maximum load) using two pairs of machines, each running in a clusteredsetting. One cluster pair runs IIS and manages the browsers. The other runs HIS andmediates calls to the mainframe. The machines are all inexpensive boxes, around $5,000each. Even at maximum loads, the systems are running at well under 10 percentutilization. Avista’s Dennis Crumb calculates the system could handle ten times the current maximum load before he would need to add another $5,000 machine to thecluster.

CACU’s move from mainframe centric systems to server cluster centric systems has greatly increased overall stability. Failures of the Web server are so rare that Byron can’t remember the last time the environment failed. Badly designed applications may fail, butthe infrastructure, the underlying Windows operating system, and the IIS SOAPenablement has been perfectly reliable, according to Byron.

8.5. SOAs Reduce Costs

In addition to technical benefits, SOAs provide tangible business value in reduced overallexpenses. The case studies highlight two areas of cost savings: personnel costs andhardware costs.

8.5.1. Personnel costs

If you are like most companies, most of your data processing costs involve moving datafrom one software system to another. After you adopt the SOA approach, the papershuffling will be gone. Workflow will be automated. When a sale has been made, aworkflow coordinating machine will automatically let the inventory system know whathas happened. When inventory gets low, the system itself will place the order. You willsee a huge reduction in data entry costs.

NORIS is a great example of a group that has greatly reduced its personnel costs throughits automated workflow. Pat estimates that the cost savings from the paperless warrantsystem alone has savedNORIS’Scustomers 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.

19

Server clusters are not only more reliable and easier to scale, they are also less expensivethan mainframes. Thus SOAs coupled with server cluster platforms can have a significantimpact on overall hardware costs. NORIS was able to dramatically reduce its hardwarecosts by going from a mainframe centric system to a server cluster centric system.

9. Evaluating Microsoft SOA TechnologiesNow let’s move from the general world of SOAs to the specific world of Microsoft. Howdo 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 setof criteria that can be applied to any vendor. Based on the case studies and my manydiscussions with companies, I have evolved my own set of criteria that I think are criticalfor 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 SOAvendor.

Vendor:

Category Criteria Evaluation

Vendor commitment to open standards

Cost of acquisition

Productivity tools

Security

Scalability

Performance

Overall

Reliability

Mainframe connectivity

Database connectivity

Legacy

Support

Packaged applications (e.g., SAP) connectivity

Rich client support

Thin client support

Mobile client support

Extensibility

Web services collaboration

Back-end technologies (databases, workflow engines, etc)

Vendor neutrality

Infrastructure

Open language support

Table 1. SOA Evaluation Criteria

20

9.2. Overall

The overall category included these criteria:

Vendor commitment to open standards Cost of acquisition Productivity tools Security Scalability Performance Reliability

9.2.1. Vendor commitment to open standards

Microsoft gets high marks for both its leadership in the Web service standardscommunity and its incorporation of Web service standards into products. The JupiterResearch3 study asked IT decision makers to rank the top vendors in terms ofinteroperability and Microsoft ranked the highest of any vendor, with 72 percent rankingMicrosoft as tops in interoperability.

Virtually every major Web service standard was either developed or co-developed byMicrosoft. The starting point for the whole Web service revolution was SOAP. SOAPwas first championed as a platform-neutral standard by Microsoft at a time when everyJ2EE company was embracing RMI/IIOP, a Java-only protocol based on the old CORBAIIOP protocol.

It is certainly true that IBM has also played an important role in bringing Web services tothe mainstream, but without Microsoft’s visionary understanding of heterogeneous interoperability, the entire industry today would still be trying to figure out how to makeRMI/IIOP work!

9.2.2. Cost of acquisition

In my experience, the low acquisition costs are usually the clincher for those who chooseMicrosoft technologies. I explored this issue in a previous white paper4 in which Iexamined the cost differential between Linux and Windows solutions and createdspreadsheets for calculating that differential in actual projects.

While it is generally true that the up-front acquisition cost of the Linux operating systemis less than that of the Windows operating system, it does not follow that a full Linuxsolution is cheaper than a full Windows solution. The most important factors driving upthe Linux cost are these:

3 Joe Wilcox et. al, “Interoperability; How Technology Managers Rate Microsoft and Its Technologies forDevelopment,” Microsoft Monitor, MIC04-C02.

4 Roger Sessions, Modeling Software Architectures and Platform Choices. Available atwww.objectwatch.com. Look for the white papers link.

21

The Windows operating system includes a great deal of required infrastructurethat you need to pay extra for in Linux. One such example is reliableasynchronous messaging.

The additional components that are not included in either operating system aretypically much more expensive for Linux than they are for Windows. One suchexample is workflow management.

JBoss, the most competitive of the open-source collaboration technologies, mightsomeday make Linux more cost competitive, but for most large enterprises, this is stillonly a future possibility. According to Gartner, “JBoss technology has not yet been sufficiently proved in business-critical enterprise projects, nor does the vendor offersupport and account management that would challenge the market leaders.”5

Some projects may be cheaper to implement on Linux than on Windows, but in myexperience, 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 onWindows.

The compelling cost/value proposition of the Microsoft technologies was important in allof my case studies.

For Avista, the huge cost differential between WebSphere MQ and Microsoft HIS wasthe deciding factor in favor of HIS. The total hardware and software costs for Avista’s clustered HIS intermediary systems was about $14,000. My calculations from myprevious white paper show an IBM WebSphere/Linux solution would have cost them atleast 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 andlicensing. Their total hardware platform costs are now around $175,000 annually, analmost 75 percent reduction in cost. In fact, their entire IT budget is now less than it wasin 1998, before they undertook the NORIS rewrite.

The bottom line is that when evaluating the cost of a proposed infrastructure, be sure toinclude 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 islikely to lead to unpleasant cost surprises.

9.2.3. Productivity tools

The major differentiator between companies that support Web services is tools. Goodtools make a tremendous difference in the cost of developing and maintaining Webservices. CACU found the Microsoft tool suite “incredibly” productive for creating Web services. NORIS credited this same tool suite for allowing a staff of 13 to maintain 36mission-critical applications.

5 Y. Natis et. al, “Magic Quadrant for Enterprise Application Servers, 2Q04,” May 10, 2004, Gartner Research (M-22-8073)

22

The Microsoft tools are especially good for building thin client applications. The NORIScase study highlighted some highly effective applications based on ASP.NET. Qwestuses ASP.NET extensively to build an advanced customer portal.

Avista’s Dennis Crumb explains why he likes the Microsoft tools support. He says thatusing ASP.NET and Visual Studio.NET greatly reduces the time Avista needs to create acompelling UI. Dennis calculates that new UI functionality can be added in about threedays, including testing and incorporation of user feedback. Using HIS/Web servicesmakes incorporation of additional CICS functionality almost trivial. Dennis calculates atypical wrapper can now be created in less than one day. All in all, he describes theMicrosoft tools for creating browser-based user interfaces as “wonderful.”

Qwest’s enterprise architect expects the education of the developer community to be simplified when Microsoft’s Whitehorse is released. Whitehorse will be included in the upcoming Visual Studio.NET 2005 release and will allow Qwest to directly embed theinfrastructure attributes and constraints of their standard operating environment (SOE)into Visual Studio.NET, allowing developers to use the SOE by dragging, dropping, andconsulting wizards.

For Avista, teaching the browser servers to speak SOAP was probably the easiest part ofthe whole project. This is because of the tight integration of Web services support intoVisual Studio.NET. While most major vendors “support” SOAP, very few have 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 nothow 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 knowabout 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 servicestandards are so tightly integrated into the Microsoft tool set. A programmer can makeuse of Web services without having to know anything about how Web services actuallywork.

As CACU’s Byron Healy says, in the Microsoft world a SOAPcomponent looks like anyother component. This makes it extremely easy to use SOAP components from anysystem built in Visual Studio.NET. And Visual Studio.NET is just as happy to consumeWebSphere SOAP components as it is .NET SOAP components.

Byron says that Microsoft’s Visual Studio.NET is a particularly good tool for creatingWeb services because it automates much of the otherwise tedious work. Visual Studio isMicrosoft’s primary developer tool. With Visual Studio, a Web service is simply a .NET component “exposed” with an industry standard communications protocol, SOAP. According to Byron, when a .NET component is exposed as a Web service, it suddenlybecomes usable in a large number of projects including those not using Microsofttechnologies.

Visual Studio makes it easy to use systems packaged as Web services, whether or notthose services are developed in .NET. There is no need to hand code WSDL servicedescriptions. As Byron says, in Visual Studio, it is a matter of “drag and drop.”

23

9.2.4. Security

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 betterthan either Unix or Linux. I found fewer problems reported and faster security patch turn-around.

A recent study by @stake has exhaustively (360 pages worth of exhaustively!) examinedthe security of .NET on Windows compared with WebSphere on Linux.7 This reportconcluded that while it was possible to create secure solutions on both platforms, theWindows platform is slightly better in two areas. The first is in conformance to securitybest practices. The second is in how easy it is for administrators to implement securesolutions. While the differences between the two platforms were not overwhelming, thisstudy 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 securearchitectures and methodical procedures such as the building of firewalls, carefullydefining (and following) security policies, and diligently applying update patches. AsCACU’s Byron Healy says: “To benefit from the value of open systems, it is critical that companies manage solid security best practices.”

9.2.5. Scalability

From a scalability perspective, the Qwest systems are the most demanding of my casestudies. And of all the systems within Qwest, the IBZ (Internet buffer zone) systems,especially those managing the browser clients, have the most demanding scalabilityrequirements, servicing more than 20,000 clients a day. The fact that Qwest can handlethis workload on a collection of 40 $2K machines is a tribute not only to .NET, but alsoto the clustered server approach and to Qwest’s architecture. According to Qwest’s enterprise architect, the machines making up the IBZ are “barely breaking a sweat.”

9.2.6. Performance

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 morethan 11 unique steps, including communications with a mainframe program over onethousand miles away! Yet even with 60-100 browser clients hitting the machine at thesame time, response time is less than one second. This speaks well to the response time ofASP.NET and HIS.

6 My analysis is available at www.objectwatch.com/issue_37.htm. Keep in mind that the data is dated.

7 Security Evaluation of Microsoft .NET Framework and IBM WebSphere by @stake, June 2003, availableat http://www.atstake.com/research/reports.

24

9.2.7. Reliability

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 toASP.NET, or .NET in general, but to a DNS name server.

9.3. Legacy Support

The legacy support category included these criteria:

Mainframe connectivity Database connectivity Packaged applications (e.g., SAP) connectivity.

9.3.1. Mainframe connectivity

The Avista case study highlights an approach to mainframe connectivity called wrapping.They used Microsoft’s HIS technology, and specifically, the COM-TI part of that. Thisallowed them to expose CICS functionality by projecting it onto a COM componentliving in an HIS server. This COM component was then wrapped with a SOAP layer thatcould be made available to anybody. As Avista switches to HIS 2004, the SOAPwrapping will be part of the product. However, even with creating their own SOAPwrappers, they have been able to reuse millions of lines of CICS code for a very smallincremental cost.

CACU also wanted to interoperate with their mainframe applications. They wrapped themainframe applications with SOAP interfaces and coordinated communications throughBizTalk. Once these components were SOAP-enabled, they could be accessed using thebuilt-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 usingSQL Server exclusively, most have a mix of databases at the back-end. Qwest is usingOracle, DB2, and a bit of SQL Server. Both CACU and Avista are using traditionalmainframe databases.

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 ofa large, back-end, mission-critical packaged system. According to SAP’s Web site, “More than 40,000 SAP installations run on Microsoft Windows — more than all otherplatforms combined. Almost two-thirds of all new SAP installations are deployed onMicrosoft Windows.”8

8 www.sap.com/company/press/press.asp?pressID=2799&query=microsoft

25

9.4. Extensibility

In the area of extensibility, I included the following criteria:

Rich clients Thin clients Mobile clients Web service collaboration

I have already discussed the use of Microsoft technologies in each of these areas with theexception of mobile clients. Rich clients are used extensively in NORIS. Thin clients areused extensively in all of the case studies, as is Web service collaboration. I personallyhave no experience with Microsoft’s mobile client technologies and none of the case studies discussed this area. But in the areas of rich, thin, and collaborative clients, it isclear that Microsoft is an industry leader.

9.5. Infrastructure

The infrastructure category included these criteria:

Back-end technologies Vendor neutrality Open language support

9.5.1. Back-end technologies

Microsoft has an array of enterprise-caliber, back-end technology products. A smallsample of these products includes:

Host Integration Server, a technology to interoperate mainframe operatingsystems

BizTalk Server, a technology to coordinate workflow throughout the enterprise SQL Server, one of the most advanced enterprise databases products in the market

today

Looking specifically at the database market, Windows seems to have a strong leadagainst Linux. A recent Wall Street Journal article quoted Gartner as pegging the Linuxdatabase market at $300 million and the SQL Server Windows database market at $1.32billion.9 That means that the size of the SQL Server market alone on Windows is greaterthan four times the combined market of all databases on Linux.

SQL Server also seems to be doing well against even non-Linux technologies. Accordingto Wall Street Journal article, while IBM is still the top database vendor, IBM is sufferingtwo problems:

9 Marcello Prince, “Gartner Says IBM Held Top Spot In 2003 Database Sales,” The Wall Street Journal,May 26, 2004.

26

Slight sales gains of only 4.9 percent over the previous year, less than half of thesales gains of Microsoft’s SQL Server

Particularly poor sales on Linux, the non-Windows market that is getting most ofthe attention

If we look at market share as opposed to actual sales, the numbers are even moresurprising. IBM actually stayed flat from the previous year. Oracle did even worse: it lostmarket 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 enterprisecaliber database.

CACU’s business intelligence is stored in Microsoft SQL Server. Much of this had been stored in Oracle databases. Compared to Oracle, Byron finds SQL Server less expensiveto buy and easier to administer. Fine-turning Oracle is, Byron says, “a constant nightmare”. In contrast, he says SQL Server is virtually self-tuning.

NORIS stores almost everything in SQL Server. The total data stored in NORIS exceedsone terabyte. The system supports 2,200 users, 800 desktops and 300 police cruisers withwireless access. At any given time, there may be 300-400 concurrent clients hittingNORIS applications, all supported by a back-end SQL Server database.

SQL Server performs much better than the old NORIS CODYSYL database. In the olddays, 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-foldimprovement in IO at one fourth the annual cost. This is particularly remarkable giventhat they are running on an old version of SQL Server. The current release (SQL Server2000) has much better performance. According to NORIS’s Pat Wright, with 200-300people banging away at the system, the response time of a typical transaction is “a snap of the finger.” Even wild card searches that traverse millions of rows and used to take 24 hours are now completed within a minute or so.

CACU’s Byron Healy believes that the availability of back-end infrastructurecomponents distinguishes Windows from Linux. He says that Linux has grown throughcultural and stylistic differences that have diluted its evolution. He thinks that the toolavailability is much weaker and the infrastructure support is nonexistent when comparedwith Microsoft. To build enterprise level code for Java/Linux, one requires orders ofmagnitude more coding than for .NET/Windows. This requires a lot of highly trained(and expensive) coders, more expensive development costs, and more expensivemaintenance costs. CACU’s philosophy is simple: their business is building world class banking applications, not world class infrastructures. They will make their moneybuilding 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 workswell in heterogeneous environments, it has been the industry leader in heterogeneousinteroperability, especially for Web service standards, for many years now.

27

J2EE vendors often describe their API as vendor neutral. Actually, the leading J2EEproducts all include large portions of vendor specific API and this vendor specificity isonly getting worse. According to Gartner:

By 2007, nonstandard [J2EE] application programming interfaces will representup 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 differentapproaches to interoperability. Microsoft has approached interoperability throughstandards 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 ofone’s systems to run on the same platform, those applications will be able to interoperate through the standard communications protocol of that platform. For J2EE, that protocol iscalled RMI/IIOP. The philosophy of interoperability through portability characterizedthe 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 theGartner quote shows, large portions of a typical J2EE application make use ofnonstandard APIs that effectively make portability an unattainable goal. Today, gettingtwo different J2EE platforms to interoperate is almost impossible without using Webservices that, ironically, were first proposed not by the J2EE community, but byMicrosoft.

9.5.3. Open language support

Microsoft frequently seems to prefer C# as a programming language. Most of thedevelopment community sees C# as a Java derivative and no easier (or more difficult) tolearn than Java.

However, Microsoft’s open language framework of .NET accommodates many languages besides C#. Two of the most important “other” languages are Visual Basic and COBOL, the later offered by third parties. Depending on existing skills, these languages can bemuch easier to learn than either C# or Java. As I have already discussed, both CACU andAvista 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 didC#.

Although the J2EE framework could theoretically accommodate non-Java languages, inpractice, there is little if any enterprise work done with any J2EE platform that is not inJava. I looked at this issue in one of my ObjectWatch newsletters.11 For better or worse,

10 Y. Natis et. al, “Magic Quadrant for Enterprise Application Servers, 2Q04,” May 10, 2004, Gartner Research (M-22-8073).

11 Roger Sessions, “Is Java Language Neutral?” The ObjectWatch Newsletter #32, available atwww.objectwatch.com.

28

J2EE means Java, period. .NET means C# (of course), but also COBOL, Visual Basic,and many other languages.

10. ConclusionsIt is clear that companies that are embracing service-oriented architectures (SOAs) arefinding 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 dramaticimprovements in reliability. Given the highly favorable cost/benefit ratio, it is likely thatSOAs will be here for a long time.

It is also clear that Microsoft is an industry leader in service-oriented architectures, notonly in the Web service standards that define interoperability, but in the back-end supporttechnologies 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 forexposing 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 wemust stay focused on not just interoperability, but specifically on heterogeneousinteroperability. But there are clearly a large number of problems for which Microsofttechnologies offer a compelling value proposition of advanced capabilities, includinghighly productive tools and excellent support for heterogeneous interoperability. Perhapsmost important, Microsoft technologies do all of this at a cost far lower than any otheralternative today.