Interoperability Through Service-
  Oriented Architectures (SOAs)

        An ObjectWatch White Paper
About Roger Sessions
Roger Sessions is the author of Software Fortresses: Modeling Enterprise Architectures
published by A...
The writing of this white paper has been a momentous undertaking. It could not have
been done without som...
Table of Contents
Part I: SOA Overview.......................................................................................
Part I: SOA Overview

1.       Executive Overview
Interoperability is one of the key issues facing IT organizations. Servi...
3.      Service-Oriented Architectures (SOAs)
Application interoperability is the single most important issue facing most ...
Application 1

                                 6-1                                             2-1
systems and wrapping existing systems in such a way that these systems can work
Most people think of SOAs as bei...
 WSDL (Web service definition language) for letting a potential collaborator know
       what you are willing to do
include the following:

    Customer service employees staffing help desks are using rich client interfaces to
Application Zone (.NET or J2EE)
                                                        J2EE or .NET apps

critical business systems and business logic from unauthorized access. If a hacker
manages to subvert an ASP.NET applicati...
them where they made the most sense. CACU believed that the right place for the
mainframes was the financial host back-end...
6. Case Study: Avista Corp. — An Example of
Mainframe Connectivity
A o ecm ay ouig nn gao iA ia op w i ioe fh Wet
  nt ro ...
Whatever technology was chosen, it absolutely had to satisfy the following requirements:

    Be implemented with no disr...
component are automatically forwarded by COM-TI to the back-end CICS system.
Two factors favored HIS. First, it required n...
including data translation, compensatory transactions, and integration with many other

6.4. The Benefits
The state of the art when NORIS was first built can best be described a “vr ss m
other. Authorized users can quickly gather criminal histories, crime report information,
arrest reports, jail records, sta...
                                            Core Applications             Data
(or an insurance company, or...). You do not want to be in the infrastructure business.
Use packaged products, such as Vis...
There are three advantages to the server cluster architecture: scalability, reliability, and
To scale a cluster, you...
Server clusters are not only more reliable and easier to scale, they are also less expensive
than mainframes. Thus SOAs co...
9.2. Overall
The overall category included these criteria:
        Vendor commitment to open standards
        Cost of a...
 The Windows operating system includes a great deal of required infrastructure
      that you need to pay extra for in Li...
The Microsoft tools are especially good for building thin client applications. The NORIS
case study highlighted some highl...
9.2.4.         Security
The last time I did a serious analysis of the back-end security problems impacting Unix,
Linux, an...
9.2.7.        Reliability
All of the companies I interviewed believed that the .NET systems were highly reliable.
Only one...
9.4. Extensibility
In the area of extensibility, I included the following criteria:
        Rich clients
        Thin cl...
 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 ...
J2EE vendors often describe their API as vendor neutral. Actually, the leading J2EE
products all include large portions of...
J2EE means Java, period. .NET means C# (of course), but also COBOL, Visual Basic,
and many other languages.

10. Conclusio...
Upcoming SlideShare
Loading in …5

Interoperability Through Service- Oriented Architectures (SOAs)


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Interoperability Through Service- Oriented Architectures (SOAs)

  1. 1. Interoperability Through Service- Oriented Architectures (SOAs) An ObjectWatch White Paper Roger Sessions Version 1.00 Last Modified: July 30, 2004
  2. 2. 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 obsolescence.  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 For more information on any of our services, contact ii
  3. 3. Acknowledgements The writing of this white paper has been a momentous undertaking. It could not have been done without some financial support and I am grateful to Microsoft for helping to defray some of the expenses. I am also grateful to the employees of Qwest, Byron Healy of CommunityAmerica Credit Union (CACU), Dennis Crumb of Avista Corp., and Patrick Wright of Northwest Ohio Regional Information System (NORIS) for their generous help in creating the case studies. This white paper was written under a strict noninterference agreement that guaranteed that editorial control would rest exclusively with ObjectWatch. The opinions expressed here should be viewed as my opinions or those of named individuals and not those of Microsoft, Qwest, CACU, Avista Corp., NORIS, or any other company. Much of the clip art is taken from and is copyrighted material and used with permission. Legal Notices ObjectWatch® is a registered trademark of ObjectWatch, Inc., Austin, Texas. Other trademarks 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 no changes are made in any way, including changes to these legal notices. iii
  4. 4. 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 ’ zi 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 s’ zi 6.2. A ia D c i Poes v t s eio rcs................................................................................. 10 s’ sn 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 iv
  5. 5. 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. 1
  6. 6. 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 services.  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 the enterprise  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. 1 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” o , 2
  7. 7. Application 1 6-1 2-1 Application 6 Application 2 6-5 2-6 1-6 1-5 1-4 1-3 1-2 6-4 2-5 6-3 2-4 6-2 2-3 5-6 3-2 5-4 3-1 5-3 3-4 4-6 4-5 4-1 4-3 4-2 5-2 3-5 Application 5 Application 3 5-1 3-6 Key a-b = connection from application A to Application 4 application B Figure 1. Pre-SOA Interoperability Business Applications Application 1 Application 2 Application 3 Application 4 Application 5 Application 6 SOA Messaging SOA Infrastructure 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 3
  8. 8. systems and wrapping existing systems in such a way that these systems can work together. 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 Figure 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 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 Communications protocol Message format 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 4
  9. 9.  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 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 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 vendors. 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 s ao 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 5
  10. 10. 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 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 s e 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. 6
  11. 11. Application Zone (.NET or J2EE) J2EE or .NET apps Internet Buffer Outside Zone Zone (IBZ - IIS) Data Zone (DB2, Oracle) SOAP/Message Bus HTTP Database Services ASP.NET Browser Client IBZ data Business data SOAP SOAP Outside Surrogate App KEY hardware security balanced zone cluster security zone 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 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 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 are inherently insecure. By creating an IBZ, Qwest has effectively protected its mission- 7
  12. 12. 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 applications. 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 8
  13. 13. 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 e 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 9
  14. 14. 6. Case Study: Avista Corp. — An Example of Mainframe Connectivity 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 or mediate. 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. 10
  15. 15. Whatever technology was chosen, it absolutely had to satisfy the following requirements:  Be implemented with no disruption to existing CICS systems running on IBM mainframes  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 ” 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 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 ’ Integration Service). 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 11
  16. 16. 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 e 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 Figure 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 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. SOAP Wrapper COM Projection CICS Application Internet Browser HIS Server Server Mainframe Figure 5. Avista Architecture Using BizTalk will allow Avista to create highly sophisticated workflow orchestrations 12
  17. 17. including data translation, compensatory transactions, and integration with many other technologies. 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 O I’ 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? 13
  18. 18. 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 O I’ 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 14
  19. 19. 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 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 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 Management application. 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. 15
  20. 20. Unified Core Applications Data Police Repository Records Management Wanted Persons SQLServer Wireless Access BizTalk Court Criminal Traffic Stolen Vehicles etc. 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 vendor. 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 16
  21. 21. (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. zi ” 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. 2 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 te, t 17
  22. 22. There are three advantages to the server cluster architecture: scalability, reliability, and cost. 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 cluster. 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 hardware costs. 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. O I’ 8.5.2. Hardware costs As I discussed earlier, SOAs are typically run on server clusters rather than mainframes. 18
  23. 23. 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 s 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 vendor. Vendor: Category Criteria Evaluation Overall Vendor commitment to open standards Cost of acquisition Productivity tools Security Scalability Performance Reliability 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) Vendor neutrality Open language support Table 1. SOA Evaluation Criteria 19
  24. 24. 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 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 IIOP protocol. 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 RMI/IIOP work! 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: 3 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 r D vlp et Microsoft Monitor, MIC04-C02. ee m n” o , 4 Roger Sessions, Modeling Software Architectures and Platform Choices. Available at Look for the white papers link. 20
  25. 25.  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 asynchronous messaging.  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 Windows. 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 mission-critical applications. 5 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 t Research (M-22-8073) 21
  26. 26. 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 tf f. 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 consulting wizards. 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 work. 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 technologies. 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 ” 22
  27. 27. 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 better than 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!) 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 ” 9.2.5. Scalability 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 . 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 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. 6 My analysis is available at Keep in mind that the data is dated. 7 Security Evaluation of Microsoft .NET Framework and IBM WebSphere by @stake, June 2003, available at 23
  28. 28. 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 to ASP.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. 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 incremental cost. 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 mainframe 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 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 ” 8 24
  29. 29. 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 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. 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 small sample of these products includes:  Host Integration Server, a technology to interoperate mainframe operating systems  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 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 two problems: 9 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. 25
  30. 30.  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 the attention 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 caliber database. 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. 26
  31. 31. 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 Microsoft. 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 C#. 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, 10 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 t Research (M-22-8073). 11 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? 27
  32. 32. J2EE means Java, period. .NET means C# (of course), but also COBOL, Visual Basic, and many other languages. 10. Conclusions 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 alternative today. 28