Web services and service-oriented architecture: the savvy manager's guide [1 ed.] 9781558609068, 1558609067

Citation preview

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table Table ofof Contents Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Back Co ver Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide This book pr ovi des both practical l eader shi p and ar chi tectur al adv ice on how to pr epare an organization t o take adv antage For ewor d vi ces and ser vi ce- or iented architect ures, br idging the gap between t he dat a- cent ri c and the software engineeri ng of Web ser I ntrlds. oduction wor The aut hor begins w ith a high- level exam ple of how an av er age per son in an organization might int er act wit h a ser ient e,chi and thene ex Pa vicer t I -orSe r vied ce-ar O rchitect ie nt edurAr te ctur Ovplains er v i eweach of t he technologi es i n j argon- fr ee language. As t he book pr ogr esses, the author r eveals mor e technical detail in incr easing depth, and ex plores leader ship oppor tunit ies and pitfalls. This book Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e also includes a quick - r efer ence guide t o technologies, buzzwor ds, and acr onym s for those tim es when a m er e glossar y Chaption er 2won’t - I suffice. nfor m at ion Technology Used in Thi s Tri p definit Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices Feat ures For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques Onl y Web ser vices book to cover both dat a m anagem ent and software engineeri ng perspectiv es, excel lent r esour ce for Chapt er 5 - Growing I mpact of Web Serv ices all mem ber s of I T t eams. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise ChaptHighl er 6 y -illustr ated with a j ar gon- fr ee i nt r oduction anyone can r ead, that then leads i nt o incr easi ng technical details and Ar chitect ur es term inology. a set of leadership esOrand a suggest ed appli ChaptProv er 7 ides - St ar ti ng t o Adopt a pri Serncipl vi ceiented Ar chitectur e cation of those pr inciples for team s using this t echnology. ains quick - r efer ence to atechnologi es,iebuzzwor ds, eand Pa r t I Cont I - Ma na gi ng Cha nge N eeguide de d for Ser v i ce - Or nte d Ar chit ct uracr e onym s. Chapt er 8

- Change Wil l Happen Abo ut t h e Aut h o r Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent Douglas Barr y ng i s pr inci pal- O and founder of te Bar ryr es & Associates, I nc., consulting to For tune 1000 companies. He is al so a Pa r t I I I K. - Cr e a ti S er v i ce r ie nt ed Ar chi ctu book agazine , guest lectofurer , int on er nat Chaptauthor er 10 , -m Ar chitectcolum ur es atni st Each Stage Adopti forional Web speaker, Ser vices m entor , and consultant in soft war e ar chi tectur e, standar ds, and pr oduct select ion wi th a speci ali zati on in dat abases, systems integr ation, and obj ect technology. Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table Table ofof Contents Contents

Back Back Cov Cover er

Com m ents

Ta ble o f Con t en t s cur r ently no com m ents on this book. Ther e are Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Web Services and Service-Oriented Architectures—The ISBN:1558609067 by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Savvy Manager's Guide Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Douglas K. Barry and t he software engineer ing wor lds.

Senior Editor: Lothlórien Homet Table of Contents Back Cov er Com m ents Publishing Services Manager: Simon Crump TaEditorial ble o f Con t en t s Assistant: Corina Derman Web Ser vices and Ser vice-Graphic Or ientedWorld Ar chit Publishing ectur es—The Sav vy Manager 's Guide Project Management: Services Cover For ewor dDesign: Frances Baca Design Cover Image: Color Day Production / Getty Images I ntr oduction Text Pa r t I -Design: Se r vi ce-Frances O r ie nt ed Baca Ar chi Design te ctur e Ov er v i ew Technologies Typography Technical Chapt er 1 -Illustration: A Business Tr ip in the Not- ’N TooDistant Futur e Composition: Nancy Logan Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p Copyeditor: Graphic Chapt er 3 - Ser vice- OrWorld ientedPublishing Ar chi tecturServices es and Web Serv ices Proofreader:For Graphic World Publishing ces Affecti ng the AdoptionServices of Web Ser v ices and Other I ntegr ation Chapt er 4 Steve Indexer: Rath Techniques Printer: Maple-Vail BookofManufacturing Chapt er 5 The - Growing I mpact Web Serv ices Group Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - used by companies to distinguish their products are often claimed as trademarks or registered Designations Ar chitect ur es

trademarks. In all instances in which Morgan Kaufmann Publishers is aware of a claim, the product names appear in - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e initial capital or all capital letters. Readers, however, should contact the appropriate companies for more complete Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e information regarding trademarks and registration. Chapt er 7 Chapt er 8

- Change Wil l Happen

Chapt er 9 Kaufmann - Tips forPublishers Managing Change I ssues dur ing Developm ent Morgan Pa r t imprint I I I - Cr eofa tiElsevier ng S er v iScience ce - O r ie nt ed Ar chi te ctu r es An

Chapt er 10 Street, - Ar chitect es at Each Stage of Adopti on for Web Ser vices 340 Pine SixthurFloor Chapt 11 - Ar chitect ur al Opt ions San er Francisco, CA 94104-3205 Chapt er 12 - Mi ddl e- Tier Ar chitectur e www.mkp.com Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

©r t2003 by Elsevier Science (USA) Pa I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s All rights Chapt er 14reserved. - Addi tional Specification Details Printed in the United States of America

Chapt er 15 - Qui ck Reference Guide I ndex 07 06 05 04 03 5 4 3 2 1 List of Fi gures

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, mechanical, photocopying, or otherwise— without the prior written permission of the publisher. Library of Congress Control Number: 2002116250 ISBN: 1-55860-906-7 This book is printed on acid-free paper.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Foreword by Douglas K. Barr y

Overview

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Picture a world where and t he services software are engineer ubiquitous ing wor and lds. organically integrated into the way we think and work. A place

where both users and providers of information interact through a common focus on services. A world where Table of Contents Back Cov er industry Com m frameworks ents technology is implemented within that operate on a global scale, enabled by open, interoperable standards. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

To some, this vision may seem impossible to realize or at the very least, a long way off. However, those who follow the evolution of information and communications technology appreciate that the dream is quite surely within our I ntr oduction grasp. Indeed, the widespread benefits of Web services are easily achievable within the next two to five years. For ewor d

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1 Barry’s - A Business Tr ip in the Too- Distant Futur e Douglas Web Services andNotService-Oriented Architectures: The Savvy Manager’s Guide provides both a Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p road map and a how-to guide for transforming the possible into the actual. The book delivers a solid description of Chapt 3 services - Ser vice-are, Or iented Ar chican tectur and Web ices whaterWeb how they beesused, howServ service-oriented architectures are developed, and some detailed options For ces for Affecti successful ng theimplementation. Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques

Readers find veryIpractical to guide Chapt er 5 will - Growing mpact of steps Web Serv ices them in planning and justifying the use of Web services. The following summary statement insight intoesthe business-oriented approach the author takes to explain the expected Ser vice- provides Or iented Ar chi tectur and Beliefs about Enter pr ise benefits. “Service-oriented Ar chitect ur es architectures that use Web services will result in a blurring between internal and external services. be aconstructed using Ar a chitectur combination of those internal and external services. As time goes Chapt er 7 Architectures - St ar ti ng t o will Adopt Ser vi ce- Or iented e on, willnge become standardized it easier Pa r t Ithese I - Ma services na gi ng Cha N ee demore d for a Ser v i ce - Or iemaking nte d Ar chit e ct ur to e replace one ‘plug-compatible’ service with another. result will competition to create higher quality software in these services.” Chapt er 8 The - Change Wilbe l Happen Chapt er 6

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

It is important to appreciate, however, that two fundamental issues must be addressed before we can herald the brave, new world Barry describes.

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 11 -framework Ar chitect urfor al Opt ions A common Web service interactions based on open standards must occur. Chapt er 12 - Mi ddl e- Tier Ar chitectur e

An agreed ofisivocabularies and interactions for Toospecific industries Chapt er 13 -set Rev ting the Business Tr ip in the NotDistant Futur e or common functions must be adopted. Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

A common framework is essential to provide a sustainable foundation that will allow end-user companies to achieve the payback they require to invest widely in the service-oriented architecture. An interview with the CIO of a Fortune Chapt er 15 - Qui ck Reference Guide 50 corporation in 2003 provided this response to a question about his greatest concern over adoption of Web I ndex services. Chapt er 14 - Addi tional Specification Details

List of Fi gures

“One is fragmentation. There’s a sordid history in the technology world of everybody trying to get a little leverage over somebody else by developing proprietary extensions or vendor-specific add-ons to the core technology. In general, those have been bad, because they don’t end up being sustainable over time and that costs companies like us a lot of money.” The second highest priority that must be achieved is standard, open vocabularies and interactions (transactions). As Barry repeatedly points out, “Of course, for this [service-oriented scenario] to happen, there needs to be standardization of the types of messages and data exchanges needed with a CRM system.” Barry provides multiple examples of the type of standardization that must be realized in order for the scenarios depicted to be carried out seamlessly and efficiently. The real meat of Barry’s perspective is found in Part II—Managing Change Needed for a Service-Oriented Architecture. Here, Barry brings together interrelated issues for the organization, technology and the people involved in deploying service-oriented architecture. He also delves into the change options related to database systems, message routers, internal applications and the various architectural options. Web Services and Service-Oriented Architectures: The Savvy Manager’s Guide gives business managers muchneeded help in assessing the costs and benefits of adopting Web services standards and building their own serviceoriented architectures. Barry’s many years of work with technology standards consortia enables him to clearly explain why the widespread adoption of Web services is closely tied to the agreed use of common standard vocabularies and methods for inter-enterprise transactions. What will happen if Web services standards and common vocabularies are not developed and implemented in the near term? Certainly, the benefits of service-oriented architectures as outlined by Barry will be delayed or restricted to a few specialized areas or a handful of proprietary vendor installations. Software providers, seeking widespread markets for their Web service tools and application development platforms, won’t be the only ones at risk. I contend

that that the negative impact will be even more pervasive, and the biggest fallout will be felt by end-user companies, unable to achieve the cost reduction and service expansion benefits that a widespread deployment of standardsW eb would Services an d In Serthis viceO rien t ed Archit ect uuser re: Tcompanies h e Sa vvy Man er 's Gu id e based Web services enable. post-dot-com era, end areag expecting more liquidity and by Douglas K. Barr y longevity of their assets. If they are unable to achieve the expected benefits, they will likely abandon the ISBN:1558609067 technology Mor gan Kaufm ann Publ ishers ?2003 (245 pages) as just another over-hyped promise of software vendors. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

Clearly, the time advantage to forge a of common based interoperable standards andt he open now. Web serframework vices and ser vice-on or iented ar chitectur es, bri dging gapvocabularies bet ween the isdatacentr ic andService-Oriented t he software engineer ing wor lds.The Savvy Manager’s Guide puts these requirements into Web Services and Architectures: context and gives readers the information they need to advance this development and assure that the promises of Table of Contents Back Cov er Com m ents Web services remain within reach. Ta ble o f Con t en t s

Patrick J. Gannon Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide President For ewor d & CEO OASIS

I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Introduction by Douglas K. Barr y

ISBN:1558609067

Mor gan ann Publ ishers (245 pages) One of the toughest jobsKaufm for managers today?2003 is keeping up with the rapid changes in technology. The advent of Web Prov ides both pr actical leadermakes ship and chitectur al adv icebecause on how tthese o pr epar e an or ganization to t ak Services and service-oriented architectures thisarmore important, technologies are going toe advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic fundamentally change the way we build our internal systems—the information systems that support our and t he software engineer ing wor lds.

organizations—and how our internal systems interact with external systems. There has been nothing like this before inTable the software industry. WeCov are of building “plug-compatible” software components that will reduce the of Contents Back er on the Comcusp m ents costs of our software systems at the same time increasing the capabilities of the systems. Sure, you have heard that Ta ble o f Con t en t s promise more than once before. And more than once, the delivery fell short of the promise. But, as with such Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide promises, they will come true some day. That time is now. For ewor d

I ntr oduction This is a guide for the savvy manager who wants to capitalize on the wave of change that will occur with Web Pa r t I - Se rand vi ce-service-oriented O r ie nt ed Ar chi tearchitectures. ctur e Ov er v i ewThe changes Services

wrought by this technology will require both a grasp of the

Chapt technology er 1 - and A Business a way toTrdeal ip in with the NothowToothese Distant changes Futurwill e affect the people who build our systems in our

organizations. This book covers bothUsed issues. Managers at all levels of all organizations must be aware of the Chapt er 2 - I nfor m at ion Technology in Thi s Tri p changes areviceon Or theiented horizon and ways both Chapt er 3 that - Ser Ar chi tectur es to anddeal Webwith Serv ices sets of issues. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt This er is 4a nontechnical book on a technical subject. It assumes no prior knowledge of the technology. It is written with Techniques

a high-level at the beginning of Serv the book. Chapt er 5 - view Growing I mpact of Web ices As the book progresses, technical details are introduced and

explained. You can keep reading until you have enough understanding of the technology for your use. If you read

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 to Part through III, you will see some architectural options that you might consider when using Web Services and Ar chitect ur es

service-oriented IVceserves as aArreference Chapt er 7 - St ar architectures.Part ti ng t o Adopt a Ser vi Or iented chitectur e guide for the buzzwords and acronyms associated with this Pa r t I technology. I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Chapt er 8

- Change Wil l Happen

This book does not define a new methodology. Instead, it shows how aspects of a service-oriented architecture Tips for Managing Change I ssues dur ing Developm ent augment or- are compatible with most software architecture methodologies and frameworks.

Chapt er 9

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt 10 of - Ar chitect uris esto at give Eachyou Stage Adopti on for Web Ser vices The er intent this book an of opportunity to consider some ideas and advice that just might make it easier Chapt for your er 11 organization - Ar chitect to ur al realize Opt ions the potential benefits in Web Services and service-oriented architectures. Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Business Opportunities Addressed

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt WeberServices 14 - Addi and tional service-oriented Specification Details architectures can: Chapt er 15 - Qui ck Reference Guide I ndex

Expand your information technology options

List of Make Fi gures your information technology systems more flexible and responsive

Reduce development time Reduce maintenance costs. This book will make the case for why these promises will be fulfilled this time. Read through to the end of Part II to see why this technology will eliminate most technological barriers to creating “plug-compatible” software and why the biggest challenge for managers is handling the people issues related to this change.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Structure of This Book by Douglas K. Barr y

ISBN:1558609067

Part I (Chapters Mor 1 through 7) begins with a high-level of how an average person in an organization might gan Kaufm ann Publ ishers ?2003 (245example pages) interact with a service-oriented architecture based on Web Services. thet technologies is ganization then explained Prov ides both pr actical leader ship and ar chitectur al advEach ice onofhow o pr epar e an or to t akin e more detail. As Part I progresses, detail added in a ar “peeling ofes, thebrionion” affecting theic advantage of Web technical ser vices and ser is viceor iented chitectur dging approach. t he gap betForces ween the data- centr t he software engineer ing wortechniques lds. adoption of Weband Services and other integration are analyzed. The growing impact of Web Services is explored along with beliefs about enterprise architectures. Part I ends with the stages of adoption for serviceTable of Contents Back Cov er Com m ents oriented architectures. Ta ble o f Con t en t s

PartSer II (Chapters 8 and managing change for 'sa Guide service-oriented architecture. Because the Web vices and Ser vice-9) Ordeals ientedwith Ar chit ectur es—The Sav needed vy Manager

potential For ewor d change related to serviceoriented architectures will likely be far reaching in our organizations, management of this change is critical. This part discusses resistance to change, provides suggestions on how to overcome resistance, and provides tips for managing change issues during the development of service-oriented architectures. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew Although resistance to change is a huge issue to which whole books have been dedicated, the approach here is to Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e look specifically at resistance issues related to technology acceptance. I ntr oduction

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt 3 - Ser viceOr iented 13) Ar chi tectur es and Weband Serv ices of creating a service-oriented architecture. It provides Part er III(Chapters 10 through outlines the “nuts bolts” For ces Affecti ng thestage Adoption of Web for Ser Web v ices Services and Otheralong I ntegran ation possible architectures at each of adoption analysis of various architectural options. Chapt er 4 Techniques

Part er IV(Chapters 14 and 15) of is Web a compendium Chapt 5 - Growing I mpact Serv ices of software technology and terminology related to Web Services and service-oriented architectures. makes for aBeliefs quick about reference Ser viceOr iented ArThis chi tectur es and Enterguide. pr ise

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Part I: Service-Oriented Architecture Overview by Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Chapter 1: A Business Trip in the Not-Too-Distant Future

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Chapter 2: Information Technology Used in This Trip and t he software engineer ing wor lds.

Chapter 3: Service-Oriented Table of Contents Back Cov er Architectures Com m ents and Web Services Ta ble Chapter o f Con t en s 4:t Forces Affecting the Adoption of Web Services and Other Integration Techniques Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Chapter 5: Growing Impact of Web Services For ewor d I ntr oduction

Chapter 6: Service-Oriented Architectures and Beliefs about Enterprise Architectures

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

ChaptChapter er 1 - A in theaNotToo- Distant Futur e 7:Business Starting Tr toipAdopt Service-Oriented Architecture Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

The future ofFor software will involve some type of service-oriented architecture; this is an assumption in this book. With ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt sucheran4 architecture, we will see more packaged software—used either as an internal service or an external Techniques service— the Internet. Weices will connect these services together to create the information technology Chapt er 5 available - Growingover I mpact of Web Serv systems of the will less about custom software Serfuture. vice- OrThese iented systems Ar chi tectur esrequire and Beliefs Enter pr ise in organizations and more creativity in the Chapt er 6 - between the services. This is a natural evolution of software technology and will be explained further in connections Ar chitect ur es this book. Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

No crystal ball exists to tell us the services that will be available. Undoubtedly, there will many innovative services - Change Wil l Happen that we cannot envision at this time. For that reason, this book presents relatively straightforward data-centric and Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent distributed process approaches that will help you get your organization ready to take advantage of a service-oriented Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es architecture—in whatever form it takes. Chapt er 8

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt 11part - Ar ur al Opt ions with a story that illustrates how a service-oriented architecture and Web Services The er first ofchitect this book begins mighterbe planning and taking Chapt 12used - Mi for ddl eTier Ar chitectur e a business trip in the not-too-distant future. Following the story, the next

chapter outlines a ting high-level explanation theNottechnology andFutur related Chapt er 13 - Rev isi the Business Tr ip inofthe Too- Distant e standards involved in this trip. That leads to the ofum service-oriented and Chapter Pa r t Iintroduction V - Com pe ndi of Softw a r e Tearchitectures chnolog y for S er v iWeb ce - OrServices i e nte d Arin chit ect ur e s3.

This chapter also introduces an

important of this book: that Details adopting this technology will bring radical change to our systems and Chapt er 14 premise - Addi tional Specification organizations. InckChapter 4, forces Chapt er 15 - Qui Reference Guide affecting the adoption of Web Services and other system integration techniques are analyzed, along with an overview of how the impact of Web Services will change over time. In Chapter 5, the I ndex

focus List of Fishifts guresto a description of the growing impact of Web Services. The impact will likely start in small, simple efforts and grow to involve enterprise architectures and business-to-business applications. Chapter 6 covers beliefs and issues with enterprise architectural efforts and shows the advantages of using a service-oriented architecture within a wider enterprise architecture. The final chapter of Part I introduces steps in starting to adopt a service-oriented architecture along with a vision for the future of our information technology organizations.

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby1: A Business Trip in the Not-Too-Distant Future ISBN:1558609067 Douglas K. Barr y ganofKaufm ann Publ ishers (245 pages) This chapter is aMor story a business trip that ?2003 illustrates how a service-oriented architecture and Web Services might Prov ides both future. pr actical shipaand ar chitectur adv ice on how t oarchitecture pr epar e an or ganization t ak e be used in the not-too-distant It leader provides vision of how aal service-oriented might work intoan advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic organization. and t he software engineer ing wor lds.

Note The term Web Services can be confusing. It is, unfortunately, often used in many different ways. Back Cov er Com m ents Compounding this confusion is the term services, which has a different meaning than the term Web Ta ble o f Con t en t s In this book, the term Web Services refers to the technologies that allow for making Services. Web Ser vices and Ser vice-Services Or iented are Ar chit ectur es—The Savtogether vy Manager 's Guide connections. what you connect using Web Services. A service is the endpoint of a For ewor d connection. Also, a service has some type of underlying computer system that supports the connection I ntr oductionoffered. The combination of services—internal and external to an organization—make up a servicePa r t I - Se r vi ce- O r ie architecture. nt ed Ar chi te ctur e Ov less er v i ew oriented A term commonly used is composite application. A composite application is Chapt er 1 created - A Business by combining Tr ip in the services. Not- Too-Composite Distant Futur applications e are built using a service-oriented architecture. Table of Contents

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

- Ser vice- OrTrip iented Ar chi tectur es and Web Serv ices The Business

Chapt er 3 Chapt er 4

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Techniques This is the story of C. R. C. R. is short for Connected Representative. C. R. is about to take a business trip that will Chapt er 5 Growing I mpactfuture. of WebThis Servtrip icesis much like any business trip. It will involve flying to California from the occur in the not-too-distant Ser viceOr iented Ar chi tectur es Beliefs about Enter pr ise over 3 or 4 days. Midwest, a car, and visiting severaland customers in different cities Chapt er 6 renting Ar chitect ur es To start C. R.a uses his Or browser tochitectur see all the Chapt er 7 his- trip St arplanning, ti ng t o Adopt Ser vi ceiented Ar e possible customers he could visit within driving

distance ofnahis destination Pa r t I I - Ma gi ng Cha nge Ncity. ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Chapt er 8

- Change Wil l Happen

Although there are a few customers he knows that he wants to visit, he also wants to make sure he is keeping in - Tips for Managing Change I ssues dur ing Developm ent touch with as many customers as he can. Using his browser, he selects the three customers that he must visit. C. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es R. sorts the remaining customers by the number of problems reported in the previous 3 months and by the revenue Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices C. R.’s organization has received from these customers. Using this list, he identifies ten additional customers he Chapt er 11 - Ar chitect ur al Opt ions might see and they are listed in order of importance according to his chosen criteria. C. R. adds the dates he wants Chapt er 12 - Mi ddl e- Tier Ar chitectur e to leave and return and selects the “Submit” button and moves on to working on other things. Chapt er 9

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa I V -while Com pe ndi um of receives Softw a r e an Te chnolog y for S er vfrom i ce - Or i e nte d Ar chit e sthe Ar tlittle later, C. R. e-mail message his contact at ect oneurof

customers saying that dinner on

Chapt er 14would - Addibe tional Specification Details would need to meet an hour later than C. R. suggested. C. R. opens up Tuesday great, but the customer

his calendar on ck hisReference browser and adjusts the dinner time already on his calendar and replies to the e-mail message. Chapt er 15 - Qui Guide I ndex

Note I am going depart from the story here for a moment. You will note that C. R. did not originally set up the dinner time. This was done for him by the software system. We see how this was done later in this book.

List of Fi gures

As the day progresses, C. R. gets a few more e-mail messages and he updates his calendar accordingly. Within a few hours, he also receives information on his flights, car rental, and hotel reservations at three cities. C. R. again opens up his calendar on his browser just to check that everything looks okay. The arrangements are fine and he confirms the plans. At this point, his manager receives basic information about C. R.’s trip along with notes on her calendar about when he departs and returns. C. R.’s spouse also receives updates to her calendar that include the departure and return trips along with the hotels where C. R. will be staying and hotel phone numbers inserted in the appropriate days. This is something she likes to have handy when C. R. is traveling. The day before his trip, C. R. downloads what he needs to his cellular telephone/palmtop computer. This includes the itinerary showing his flights, car reservation, hotel reservations, hotel contact information, details on each customer, a summary of all contacts C. R.’s organization has had with each customer, driving instructions from each stop along the way, and maps. C. R. prints out the driving instructions and maps. He likes to have paper copies just in case his rental car does not have a Global Positioning System (GPS) driving assistant or the GPS doesn’t work properly. C. R. thinks it’s always nice to have a paper map and driving instructions. When C. R. arrives at his destination airport, he is pleased to see that his rental car has the GPS assistant that his car rental profile requests. He starts the car, and the GPS assistant is already programmed for his first destination that day—one of the customer sites. C. R.’s organization recently switched to this car rental company because they offered this feature. It beats having to punch in destination addresses every time. Note In this story, it was relatively recently that rental companies agreed on the data and the names to use when describing the data used to transmit itineraries for GPS assistants. C. R.’s organization switched to the new rental company because of this feature, because the new company provided almost the same rates as their previous car rental company.

On his way to his first customer visit, C. R. receives an instant text message on his cellular telephone indicating that someone at this customer just reported a significant problem with one of the products from C. R.’s organization. This W eb Services anhis d Ser viceO rien tWhile ed Archit ectcustomer’s u re: T h e Sa vvy Man er 's Gu e is good to know before going into first meeting. in the parking lotag before theidmeeting, C. R. calls ISBN:1558609067 by Douglas K. Barr y the representative who is working on the problem for any additional information before heading into his meeting. C. Mor gan his Kaufm ann Publ ishers ?2003on (245 R. was able to address customer’s concerns thepages) spot. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

Back out at the parking lot, of C.Web R. sees that and he has another instant message himt he that hisbet itinerary has changed advantage ser vices ser viceor iented ar chitectur es, telling bri dging gap ween the datacentr ic and that t he software engineer lds. on the third day and he should check ing his wor calendar. He takes out his palmtop and logs onto his online calendar, downloading what he needs. He sees that the last customer he wanted to see has canceled (an e-mail message Table of Contents Back Cov er Com m ents explains why) and that two different customers were added to his trip. This change also necessitated changing Tahotels. ble o f Con t en t s C. R.’s spouse and manager also received the updates to their calendars automatically. The hotel Thankfully, Web reservations Ser vices and have Ser been vice-changed Or iented Ar appropriately, chit ectur es—The too. Sav When vy Manager C. R. started 's Guide his car the following morning, the updated itinerary For ewor d was also downloaded to his car’s GPS assistant. I ntr oduction

Late that night, C. R. was looking over the customer visits for the next day and saw something puzzling in the summary of contacts for one of the customers. For some reason, the same problem appeared to be reported Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e multiple times. He used the monitor and keyboard in his hotel room to get more information on this contact from the Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p online repository that contained all contact information for his organization. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces ng the he Adoption Web Ser ices and Other I ntegr ation As C. withAffecti customers, makesofnotes on vhis palmtop about each of the meetings. At intervals, his Chapt er R. 4 meets Techniques palmtop transmits that meeting contact information and it is added to all the other contact information for each of the Chapt er 5 - Growing I mpact of Web Serv ices customers. Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

chitect urhave es Note By Ar now, you probably noticed that C. R.’s organization has very current and detailed information on Chapt er 7 every - St arcustomer ti ng t o Adopt a SerThey vi ce- Or iented Ar chitectur e contact. found that in their industry, this makes a big difference in how well the Pa r t I I - Maemployees na gi ng Cha nge ee detheir d forcustomers. a Ser v i ce - Or nte d Ar chit e ct ur eneed that the customer may have for additional can Nhelp It ie also identifies any Chapt er 8 products - ChangeorWil services. l HappenThis customer information comes from multiple sources, both internal and external R.’s Chapt er 9 to - C. Tips for organization. Managing Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

On the last day of his trip, C. R. receives an instant message in the morning that his flight that afternoon has been cancelled, but that the airline has arranged an alternate flight that will leave an hour later. C. R’s spouse also Chapt er 11 - Ar chitect ur al Opt ions receives an instant message with the same information. Both of their online calendars were updated to reflect the Chapt er 12 - Mi ddl e- Tier Ar chitectur e new arrival time that evening. C. R. also used his palmtop to check any last minute flight changes with his airline. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

A lot of technology involved behind scenes this story. Also, there obviously needs to be agreements and Morisgan Kaufm ann Publthe ishers ?2003in (245 pages) standards amongProv organizations to make this level of data interchange possible. the standards ides both pr actical leader ship and ar chitectur al adv ice on howThis t o prtechnology epar e an orand ganization to t ak e make it possible advantage for C. R. toofbe “connected” on ser hisvicebusiness trip.arThe nextes, chapter provides high-level explanation Web ser vices and or iented chitectur bri dging t he gapa bet ween the data- centr ic software that engineer ingthis worpossible. lds. of the technologyand andt he standards made Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby2: Information Technology Used in This TripISBN:1558609067 Douglas K. Barr y

Overview

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Chapter 2 provides andat he high-level softwareexplanation engineer ingofwor thelds. technology and standards used in the business trip described in

the previous chapter. Many services and supporting technologies came together in the business trip story. These Table of Contents Back Cov er Com m ents include online repositories, customer relationship management, online calendar services, travel agencies, car rental, and more. We examine each of these in this chapter. As you read this chapter, note that it is relatively easy to swap Ta ble o f Con t en t s out one service provider for another. This is because of standards Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager related 's Guideto data interchange. The result, as shown in this story, is that competition is related to either cost or innovation. For ewor d I ntr oduction

In this story, there is a tremendous amount of technology and data interchange going on behind the scene. Let’s look at some of the information technology used. Figure 2.1 shows the ways in which the various services Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e exchanged data in this story. The following sections of this chapter provide more information on the services and Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p data interchange shown in this figure. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 2.1: Services and data interchange for C. R.'s business trip.

W eb Services d Ser vice- O rien t ed Archit ectin u re:an T h eOnline Sa vvy Man ag er 's Gu id e Keeping Track of AllanCustomer Contacts Repository by Douglas K. Barr y

ISBN:1558609067

Remember that C. decided it was(245 important MorR.’s gan organization Kaufm ann Publ ishers ?2003 pages) to keep track of all customer contacts. They did this by [ 1]This repository is behind their firewall and is served by a cluster of application servers. using an online repository Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e Both the application serversofand are ser also fault tolerant. This means that they capable of the being advantage Webrepository ser vices and viceor iented ar chitectur es, bri dging t heare gap bet ween data- centr ic andall t he engineer worare lds. hardware and software failures. The application servers and accessible virtually thesoftware time even whening there repository are fault tolerant because the wide, internal use of customer contact data requires that they be accessible Table of Contents Back Cov er Com m ents all the time. Ta ble o f Con t en t s

C. R.’s organization did not always data in oneSav place. At one time, some customer contact information was in Web Ser vices and Ser viceOr iented Ar have chit ectur es—The vy Manager 's Guide their Customer Relationship Management (CRM) system, some in the accounting system, and still more was For ewor d

scattered in other internal systems and in such places as the representative personal records and in trip reports.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

C. R.’s organization had to decide what data should be in their online repository and develop such things as naming

Chapt er 1 - and A Business Tr ip in of theeach Not- item Too- Distant e conventions the meaning of data.Futur Fortunately, because of his organization’s work in Electronic Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p Data Interchange (EDI) and Web Services, a fair number of data elements were already established. [2] Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Using this online repository with a business intelligence (BI) package, allowed C. R. to determine which For ces Affecti ngalong the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques customers would be best for him to visit. The BI package also can be used to identify various patterns in customer contacts purchases. Chapt er 5 and - Growing I mpact of Web Serv ices Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 repository Onceerthe Ar chitectwas ur esestablished, it became relatively easy to use Web Services to connect to various online

calendar For C. viR.’s online service used Web Services to automatically add the Chapt er 7 services. - St ar ti ng t oexample, Adopt a Ser ce- Or ientedcalendar Ar chitectur e customer made a edata-centric Pa r t I I - Macontacts na gi ng Cha nge during N ee de dthe forbusiness a Ser v i cetrip. - Or ieThis nte dillustrates Ar chit e ct ur

approach that will be discussed further in Part III. (It is a data-centric approach because it is based on moving data to where the data might be Chapt er 8 - Change Wil l Happen needed.) Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent [ 1] this and figure, Pa r t For I I I -the Cr epurposes a ti ng S er vofi ce - O rstory ie nt ed Ar chi te ctuthe r esterm “repository” is used. In reality, this could easily be a collection of databases and it also might entail routing data to multiple locations. Data routing will be covered in Chapter 4. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions [2]

. Work on standards will be discussed later in this book. If you want to see a sampling of standards efforts by industry, a listing starts on page 191.

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h ean Sa vvy Man ag er 'sCRM Gu id e Service Obtaining Company Contact Information from External by Douglas K. Barr y

ISBN:1558609067

By creating a separate C. R.’s organization Mor ganonline Kaufmrepository, ann Publ ishers ?2003 (245 pages) also found it relatively easy to move from one CRM product to another when a new service provides more features better Thise was because Prov ides both pr actical leader ship and arCRM chitectur al advor icea on how price. t o pr epar an orpossible ganization to t ak e the data from theadvantage old, internal CRMser product wassertransmitted viaarWeb Services the repository. to a new of Web vices and vice- or iented chitectur es, brito dging t he gap bet Changing ween the datacentr ic and tthe he software engineer wor lds. CRM product meant same data could ing be transmitted, but in this case from the new, external CRM service. Table of Contents Back Comthere m entsneeded to be standardization of the types of messages and data Note Of course, for thisCov to er happen,

exchanges needed with a CRM system. For the sake of this story, we will assume that industry consortia Ta ble o f Con t en t s were to develop those standards. Information on industry consortia can be found on page 191. Web Ser vices andable Ser viceOr iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

Actually, C. R. did not know that the CRM his organization currently uses is provided as an outside service and was no longer behind his organization’s firewall. It didn’t matter to him, except that it seemed to be working fine. It did Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew matter to his organization, though. As it turned out, the organization changed to an external CRM because the Chapt er 1 service - A Business Tr ip inbetter the NotTooDistant and Futur e external had a much user interface could be used with a monthly service charge instead of buying Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p an upgrade to the aging, internal CRM product. The only requirement for the switch was that the new CRM service Chapt 3 - Ser viceOr iented Ar chiWeb tecturServices es and Web Servrepository ices coulderprovide the same data over to the as the old CRM product. Because an industry For ces Affecti ng the Adoption of Web Ser vthis iceswas and no Other I ntegr ation standards body had standardized most of that data, problem. In fact, the new CRM service sends more Chapt er 4 Techniques data than is needed. But because the data is sent as XML (see page 209), the extra data isn’t used for the online Chapt er 5 -There Growing of Web Serv ices repository. is noI mpact problem receiving the extra data. [3] [3]. As will beSer viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - shown later, XML uses a structure that effectively makes the messages longer. The longer messages Ar chitect ur es may present a problem for some highly time-critical applications. Nevertheless, for the majority of uses, advances in Chapt er 7 -speeds St ar ti ng t o Adopt a Ser vithe ce- Or iented Arneeded chitecturto e transmit XML messages. transmittal more than offset extra time I ntr oduction

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Online Calendar Services ISBN:1558609067

by Douglas K. Barr y

There were multiple online calendars involved in the example Mor gan Kaufm ann Publ ishers ?2003 (245 pages) of C. R.’s business trip: Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

C. R.’s calendar advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

C. R.’s spouse’s calendar Table of Contents

Back Cov er

C. R.’s manager’s calendar

Com m ents

Ta ble o f Con t en t s Web Ser The vices calendar and Ser for viceeach Or iented customer Ar chit visited. ectur es—The Sav vy Manager 's Guide For ewor d

Just to make it more complicated, let’s say each calendar is maintained by a different online service. They communicate with each other using Web Services and a standard set of data elements. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew I ntr oduction

ChaptNote er 1 The - A need Business Tr ip in the is NotToo- Distant Futur eEach industry has its own vocabulary that will need to be for standards critical to this story. Chapt er 2 standardized - I nfor m at ioninTechnology Used in Thi s Tri p to occur. Examples in such industry XML vocabularies can be XML for a story such as this Chapt er 3 found - Ser viceOr iented Ar chi tectur es and Web Serv ices starting on page 212. Chapt er 4

-

Chapt er 6

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Techniques C. R. has established a set of rules for business trips. These rules indicate what details about a trip will be sent to his manager’s calendar, his spouse’s calendar, each customer’s calendar, and to the online repository his Chapt er 5 - Growing I mpact of Web Serv ices organization Ser maintains. vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Eacherof7 the- online calendars receives information fromeC. R.’s calendar has a set of rules about what types of Chapt St ar ti ng t o Adopt that a Ser vi ce- Or iented Ar chitectur updates they will accept. Often, agent software enforces these Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit erules. ct ur e Software agents can use rules to monitor changes and report those changes using Web Services (see page 164). For example, a customer’s calendar agent Chapt er 8 - Change Wil l Happen will respond whether or not a specific time and date is a good time for a one-hour meeting with C. R. The customer’s Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent calendar, however, won’t disclose information about other items on the customer’s schedule to C. R.’s calendar. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Online calendars are most likely to communicate with other software agents. These could include travel, airline, and

Chapt 11 - Ar agents. chitect ur al Opt ions hotelersoftware Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services d Ser viceO rien t ed Archit ect u re: Tto h e Sa vvy Man ag er 's Gu id e Changing from One an Online Calendar Service Another ISBN:1558609067

by Douglas K. Barr y

C. R. found that Mor he has calendar frequently lately. He started out using one provided by his gan been Kaufmchanging ann Publ ishers ?2003services (245 pages) organization, butProv because of the standardization of data interchange, companies it possible toe ides both pr actical leader ship and ar chitectur al advseveral ice on how t o pr eparhave e an found or ganization to t ak lure people to change calendar services using or or other feature incentives. In C. R.’s case, hasthe switched advantage of Web ser vices and price ser viceiented ar chitectur es, bri dging t he gap bethe ween data- centr ic and software engineer ing wor primarily because het he prefers specific features thatlds. are offered. One that he particularly likes is the ability to set up rules to automatically perform functions such as informing his spouse of his schedule changes. Table of Contents

Back Cov er

Com m ents

standardization of data interchange makes most of the changes easy to do. C. R. does, however, still need to TaThe ble o f Con t en t s create a traveler profile timeArhe switches services. InManager part, the'scalendar services compete on the capabilities of Web Ser vices and Ser vice-each Or iented chit ectur es—The Sav vy Guide the profiles now that they all exchange data with other calendar services and other external services in the same For ewor d way.

I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

One real time saver that C. R.’s organization added when the calendar data interchange standard became available

Chapt - A Business ip in from the NotToo- Distant Futur was er the1 ability to acceptTrdata calendar services fore their online repository. This is how C. R. was able to add Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p contact information automatically from his business trip from his calendar service to the online repository. C. R.’s Chapt er 3 - Ser Or iented chi tectur esfrom and Web Serv ices service that uses the standard data interchange. [4] organization canviceaccept such Ar information any calendar [4]. Security is For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 - obviously an important concern with using Web Services. Information on security can be found on Techniques page 32. Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser viceArchit ectWhile u re: T h e on Sa vvy ManRoad ag er 's Gu id e Getting Updates on Clients toO rien Bet edVisited the by Douglas K. Barr y

ISBN:1558609067

One feature C. R. particularly about his ?2003 calendar Mor gan Kaufmlikes ann Publ ishers (245 service pages) is the ability to set up rules that determine how he is informed of changes to his schedule. For example, he has established a rule thatt any changes that occur within Prov ides both pr actical leader ship and ar chitectur al adv ice on how o pr epar e an or ganization to t ak5e days of a customer meetingofwill beser sent to and his cellular instant messaging. had centr a ic advantage Web vices ser vice-telephone or iented arvia chitectur es,text bri dging t he gapHe betcould ween have the dataand t he software engineer lds. the instant messages. voice message or e-mail message, but C.ing R. wor prefers Table of to Contents Back Cov ermessage Com mconcerning ents For C. R. receive the instant a very recent problem that a customer had, the online repository must have updated C. R.’s calendar in some way. Standardization of data interchange for calendar Ta ble o f Con t en t s services makes this possible. There was a time after C. R.’s organization Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guidehad set up the online repository when the standardization of calendar data interchange had not yet occurred. Back then, C. R. had to log into the repository For ewor d the night before each customer visit to check to see if anything had been recorded recently. Getting the instant I ntr oduction messages saves a lot of time and, in the case of our story, gave C. R. last minute information about a problem Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew encountered by the customer he was about to visit. Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Travel Agency Service by Douglas K. Barr y

ISBN:1558609067

The travel agency that R. uses a service external to his organization. It is entirely automated. C. R. has a travel Mor ganC. Kaufm ann is Publ ishers ?2003 (245 pages) profile that covers the usual items such as preferred airline seating, rental carhow (with preferred Prov ides both pr actical leader ship and ar chitectur al adv ice on to a prGPS epar eassistant), an or ganization to t ak e hotels, and so on. It also contains about R.’s calendar othert calendars mentioned. advantage of Web rules ser vices and updating ser vice- orC. iented ar chitecturand es, the bri dging he gap bet ween the data- centr ic and t he software engineer ing wor lds.

When setting up his trip, C. R. used the online repository to select both priority customers and those that would be Table of Contents Back Cov er Com m ents was sent to the travel agent from the repository when C. R. pressed nice to visit. The necessary contact information button. Tathe ble “Submit” o f Con t en ts Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

This travel agent can interact with the software agents that handle the calendars. In the story, there was one e-mail message that the travel agent could not handle concerning the change in a dinner time. That e-mail message was I ntr oduction passed along to C. R. When he looked at his online calendar to make the change in the dinner date, he also saw the Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew other arrangements already made for him by his automated travel agent. For ewor d

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt C. R.’s er 2travel - I nfor agent m atalso ion Technology sent the travel Used information in Thi s Tri pto the car rental company using Web Services. In turn, the rental

company the itinerary the es GPS his car. Some other systems might allow beaming an Chapt er 3 transmitted - Ser vice- Or iented Ar chito tectur andassistant Web Servinices itinerary fromFor a palmtop tongthe assistant in the ces Affecti theGPS Adoption of Web Sercar. v ices and Other I ntegr ation -

Chapt er 4

Techniques Finally, C. R. was on the one ices of his customers cancelled. This software travel agent contacted other Chapt er 5while - Growing I mpact of road, Web Serv

names that C. R.vicehadOroriginally and arranged new meetings, Ser iented Ar provided chi tectur es and Beliefs about Enter pr ise changed the hotel reservations, and informed Chapt both er C.6R.’s- spouse’s and his manager’s calendar of the change. Ar chitect urcalendar es Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

A characteristic of the travel service agent is that it always needs the latest information from multiple sources. This illustrates the distributed-process approach that will be discussed further in Part III. It is a distributed-process Chapt er 8 - Change Wil l Happen approach because the service depends on having the latest information processedat multiple locations distributed Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent through an Intranet or on the Internet. Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Car RentalWService ISBN:1558609067

by Douglas K. Barr y

In our story, C. R. liked GPS assistant when driving Mor gan using Kaufmaann Publ ishers ?2003 (245 pages) on business trips. The travel agent service can send the car rental serviceProv theides necessary information so that an beice downloaded from satellite at anyto time. both pr actical leader ship and aritinerary chitecturcan al adv on how t o pr eparthe e an or ganization t ak e This is how the GPS assistant in C. R.’s car received updated itinerary. also illustrates Web the Services can ic advantage of Web ser vices and ser vice-the or iented ar chitectur es,It bri dging t he gaphow bet ween data- centr and t he of software engineer ingjust worapplication lds. be extended to all sorts systems and not servers or enterprise-level systems. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Airlines and Hotel ISBN:1558609067

by Douglas K. Barr y

Data interchangeMor standardization an ishers important in this story and in the future of the technology used in gan Kaufm annisPubl ?2003theme (245 pages) organizations. The airlines and hotels in this story used data interchange asepar well. This includes allowing Prov ides both pr actical leader ship and ar chitectur al adv ice standards on how t o pr e an or ganization to t ak e C. R. to check the status ofofhis flights fromand his palmtop. one ar point, eaches,airline hadt aheproprietary waythe todatacheck thisic advantage Web ser vices ser vice- orAt iented chitectur bri dging gap bet ween centr and t he software engineer wor lds. made it possible for palmtops and cellular telephones to information. Standardization of such data ing interchange bundle the capability to check flight status in with their product. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Services asW eb Commodities ISBN:1558609067

by Douglas K. Barr y

As you may haveMor noticed, some services in this story treated as commodities: gan Kaufm ann Publ ishers ?2003 (245are pages) Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

The CRM service replaced anser internal service advantage of Web vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

C. R. changed calendar services frequently Table of Contents

Back Cov er

Com m ents

C. R.’s organization recently switched car rental companies.

Ta ble o f Con t en t s Web In the Serstory, vices and all these Ser viceservices Or iented provided Ar chit ectur some es—The type ofSav innovation vy Manager beyond 's Guide the basic, standard interchange of data.

This innovation is where some organizations will compete using Web Services. Others will compete on providing just For ewor d theoduction basics at a lower cost. I ntr Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Each of the services described in this are part of a larger service-oriented architecture that uses Web Mor gan Kaufm ann Publchapter ishers ?2003 (245 pages) Services. In fact,Prov it isides the both assembly of such services that makes al a service-oriented important pr actical leader ship and ar chitectur adv ice on how t o architecture. pr epar e an orAn ganization to idea t ak e in this chapter is that it will become toviceswap onearservice for another. This is because the ic advantage of Webrelatively ser vices easy and ser or out iented chitecturprovider es, bri dging t he gap bet ween the data-ofcentr and t hethat software engineer ing worin lds. XML-based standards are being developed various industry consortia. A second important idea is that Web Services will cause many services to be seen as commodities. This will result in competition in either cost or Table of Contents Back Cov er Com m ents innovation within the standards. The next chapter will explain service-oriented architectures and Web Services. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby3: Service-Oriented Architectures and Web Douglas K. Barr y ServicesMor gan Kaufm ann Publ ishers ?2003 (245 pages)

Overview

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Table of Contents Back Cov er m ents Service-oriented architectures are allCom about connections. This chapter describes those connections. It begins with an analogy to connections used in audio-video (AV) systems (specifically, services in a service-oriented architecture are Ta ble o f Con t en t s to AV components as Web Services are to the connections between AV components). Service-oriented Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide architectures then are explained in more detail. This is followed by a description of ways that organizations of any For ewor d size can use a service-oriented architecture and why most organizations likely will experience a blurring of internal I ntr oduction and external services. Then Web Services are explained along with the use of XML. (Web Services using XML are Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew the most common connections in a service-oriented architecture[.1]) The chapter wraps up with a summary of the Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e security and authorization specifications related to Web Services. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

ChaptNote er 3 More - Seroften vice- Or iented chi tectur es and Webpast Servto ices than not,Aryou can look to the find a pattern that will allow you to predict the future. I had For ces Affecti ng the Adoption of Web Ser v ices and Other systems I ntegr ation an epiphany of this sort concerning the future of software architecture when recently upgrading Chapt er 4 myTechniques AV system. The past in this case is the evolution of AV systems. Chapt er 5

- Growing I mpact of Web Serv ices

MySer AVvicesystem has components purchased Or iented Ar chi tectur es that and have Beliefsbeen about Enter pr iseover the years. I wanted to add a DVD player Chapt er 6 Ar chitect ur esThe system has the usual cable box, receiver, VCR, CD player, speakers, and television to my system. Chapt er 7 set. - StOne ar ti ng o Adopt a Ser vi ce- Or iented Ar chitectur oft the oldest components is the receivereand the DVD had connections that the receiver could Pa r t I I - Manot na gihandle, ng Cha nge N ee d for a and Ser voptical i ce - Or ie nte d Ar chit e ct e however, have the common three RCA such asde s-video connections. It ur did, Chapt er 8 connections. - Change WilIl decided Happen at that point to upgrade all of the connections in my AV system to RCA [2] Chapt er 9 connections. - Tips for Managing Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Figure 3.1 shows how I connected the components after adding the DVD. These components could be connected in different ways, depending on what you want to do. For example, you could set up your cable Chapt er 11 - Ar chitect ur al Opt ions connection to go through your VCR or split the signal so that you can watch one program and record Chapt er 12 - Mi ddl e- Tier Ar chitectur e another. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 3.1: Audio-visual components. Not long ago, we had monolithic hi-fi or stereo systems. Then the industry settled on the various components in a stereo system and later video was added. What does this have to do with software systems architecture? Well, it’s all in the connections. Web Services have provided an infrastructure for creating connections not unlike those we have with AV systems. And, just like AV systems, we will be able to assemble components in all sorts of ways because of those connections. [.1]. According to the W3C Web Services Architecture Work Group, a Web Service by definition uses XML. Although, in practice, there are exceptions. See page 30. [2]

Serious audiophiles will probably point out that an RCA connector is not necessarily the highest performing option available. In fact, that is why RCA connectors make for a good analogy to using XML in Web Services. XML is also not the highest performing connection available. Nevertheless, much like an RCA connector, XML is undergoing standardization in ways that using it for data connections will be as ubiquitous as the RCA connectors.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Service-Oriented Architecture Explained ISBN:1558609067

by Douglas K. Barr y

The business tripMor that R. took the ishers introductory story involved using multiple services, both inside and outside ganC.Kaufm anninPubl ?2003 (245 pages) his organization,Prov suchides as both travelpragency, online calendar, or CRMalservices. architectural point-ofactical leader ship and ar chitectur adv ice onFrom how a t osoftware pr epar e an or ganization to t ak e view, this is a service-oriented architecture. A service-oriented essentially collection services. advantage of Web ser vices and ser vice- or iented architecture ar chitectur es,is bri dging t heagap bet weenofthe data- centr ic and t he software ing wor lds.communication can involve either simple data passing or it could These services communicate withengineer each other. The involve two or more services coordinating some activity. Some means of connecting services to each other is Table of Contents Back Cov er Com m ents needed. Those connections are Web Services. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Services

For ewor d

I ntr If aoduction service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a Pa r t I - Sethat r vi cer ie nt ed Ar chiself-contained, te ctur e Ov er v i ew function isOwell-defined, and

does not depend on the context or state of other services. Over

Chapt 1 industry - A Business Tr ip in the on NotTooDistant Futur e time,erthe will standardize the capabilities of various services. Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p

The er analogy to AV components fitstectur well es here. is well defined: the industry has decided what are the basic Chapt 3 - Ser viceOr iented Ar chi andEach Web Serv ices

functions of a DVD player, a VCR, and so on. Each AV component is self-contained; you do not need a VCR, for

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 to- use a CD player. Finally, one AV component does not depend on another component. For example, the example, Techniques

television not need to be to Serv record Chapt er 5 does - Growing I mpact of on Web icesusing the VCR. True, if you play the recorded tape, you cannot see what is being played the television is notesturned on. Nevertheless, Serwhen vice- Or iented Ar chi tectur and Beliefs about Enter prthe ise VCR still does not need to know the context Chapt er 6 of the or state Artelevision. chitect ur es Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

The industry will define standard capabilities of CRM, Enterprise Resource Planning (ERP), and other services. These will become standard services and could, in some ways, be seen as commodities. [3]We may see these Chapt er 8 - Change Wil l Happen services come in various forms just as we see in buying AV components today. You can buy a DVD player bundled Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent with a VCR or buy each component separately. Nevertheless, over the next few years, the industry will standardize Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es the capabilities of various services much like the AV industry has standardized its components.[4] Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt 11 - this Ar chitect al software Opt ions development? It means fewer people writing software and more organizations Whaterdoes meanurfor Chapt buying er 12 software - Mi ddl rather e- Tierthe Ar chitectur building eit. Continuing with the AV analogy: I am old enough to have built my share of

Heathkit products for audio other (This was Chapt er 13electronics - Rev isi ting the Business Tr ip and in the Not-systems. Too- Distant Futur e much like building your own software.) But the Heathkit era pe forndi electronics is aover. I believe of- Or software development Pa r t I V - Com um of Softw r e TeYes, chnolog y for Sa erlot v i ce i e nte d Ar chit ect ur e s

will go the same way.

Chapt er 14 - Addi tional Specification Details

Connections

Chapt er 15 - Qui ck Reference Guide I ndex

Theoftechnology of Web Services is being presented as the connection technology of the future. That is probably a List Fi gures fair assessment. Web Services essentially use XML to create a robust connection. The use of XML moves us away from the fragility of fixed record layout connections that can fail if proper formats are not used. XML also allows for the sending of more data than might be used. With Web Services, the extra data will not cause a problem with the receiving service. Also, other existing connections are in use right now that won’t go away for some time. These include the EDI standards, CORBA, and DCOM to name a few. [5 ]Again, much like the connections in AV systems, we can mix and match these connections and upgrade when it makes sense. Connections such as Web Services are part of the inevitable evolution of interconnectedness. Consider how we can now exchange e-mail among disparate products. Although we could not do that at one time, we now take it for granted. This e-mail exchange is possible because of standards. Connections like Web Services (or the equivalent) will also be taken for granted some day because sets of standards will be developed. [6] Figure 3.2 illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined will be explained later in this chapter in the section that explains Web Services. A service provider can also be a service consumer. In the story of C. R.’s business trip, most of the service providers were also service consumers. For example, the travel agency service provided travel information, but to do that it needed to consume information from hotel services, car rental services, and calendar services.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Figure 3.2: Service-oriented architecture basics. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

[3]

As mentionedand previously, the standardization services will see competition in price or innovation. Continuing t he software engineer ing worof lds. with the AV analogy, this commodity approach is what we see with various AV components—competition on either Table Contents features. Back Cov er Com m ents price orofhigher-end Ta ble o f Con t en t s [4]

The industry bodies working on standards and the various standards can be found in Chapter 14.

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For d [5 ewor ]

EDI will be explained starting on page 65. CORBA and DCOM will be explained starting on page 45.

I ntr oduction

Pa [6]rThe t I - organizations Se r vi ce- O r ie ntworking ed Ar chi on te ctur Ov er v i ew thee standards

can be found starting on page 191. Also, be sure to also see the

Chapt er 1 of- standard A Business Tr ipvocabularies in the Not- TooDistant sampling XML starting onFutur pagee 212. Many industry groups are creating XML vocabularies Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p specific to their industry. Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services d Ser viceO rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Organizations of AnyanSize Can Use a Service-Oriented Architecture by Douglas K. Barr y

ISBN:1558609067

The use of a service-oriented is not limited to large organizations. In fact, this architecture represents an Mor gan Kaufmarchitecture ann Publ ishers ?2003 (245 pages) opportunity for small and medium sized organizations. Many services provided on some type of fee- for-use Prov ides both pr actical leader ship and ar chitectur al advwill ice be on how t o pr epar e an or ganization to t ak e basis, which will advantage make themofeconomical forand organizations of most any size. services might be provided atcentr no ic Web ser vices ser vice- or iented ar chitectur es,Other bri dging t he gap bet ween the dataand tof heC. software engineertrip, ing the wor lds. cost. In the example R.’s business travel agent service might charge for each use, whereas the external CRM service might charge a monthly fee for a certain number of users and the car rental and hotel services Table of Contents Back Cov er Com m ents might be free. Ta ble o f Con t en t s

TheSer receipt invoices a simple example how a small business Web vices of and Ser vice-illustrates Or iented Ar chit ectur es—The of Sav vy Manager 's Guide might benefit from a service. Right now, many come in by mail or via fax. A service could be created that receives invoices using Web Services. For eworinvoices d

The invoices might be held by the service until the accounting system that resides on the user’s PC connects to receive the invoices—again, using Web Services. The invoices would then automatically update the accounting Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew system on the PC. The analogy here would be to automated fax systems that currently exist to receive faxes which Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e can, in turn, be downloaded to a fax machine at a later time. In this way, any organization, regardless of size, could Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p take advantage of services for receiving invoices, making travel plans, coordinating calendars, trading commodities, Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices and so on. I ntr oduction

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Servicesand an d Ser vice- O rien t Services ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Blurring ofWInternal External by Douglas K. Barr y

ISBN:1558609067

In a service-oriented architecture, between internal and external services will become less apparent. Mor gan Kaufm ann the Publdistinction ishers ?2003 (245 pages) In our story, C. R.’s organization changed from an aging internal CRM product to tan service because Prov ides both pr actical leader ship and ar chitectur al adv ice on how o prexternal epar e anCRM or ganization to t ak e the external service was more economical and ser hadvicea better userarinterface. Because, this all CRM services advantage of Web ser vices and or iented chitectur es, bri dging in t he gapstory, bet ween the datacentr ic and t he software engineer ingone worservice lds. provide similar connections, changing from to another is not that major a change. (Much like swapping out one AV component for a new model. It might require upgrading some connections, but it is a relatively minor Table of Contents Back Cov er Com m ents headache for the benefits.) Ta ble o f Con t en t s

ThisSer willvices create dynamic where software will'scompete Web andaSer vice- Orenvironment iented Ar chit ectur es—The Sav vendors vy Manager Guide using features or innovations that are

independent of the connections. This could include user interfaces, automated software agents, rule-based systems, For ewor d or user profiles that allow for highly customized interactions.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Such market forces will affect internal development as well. It will be difficult for an internal development group in

Chapt 1 - A Business Tr ip in the NotDistant Futur e someerorganizations to compete with a Toosoftware vendor that can recoup development costs by having many more Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p could imagine. The external vendor can achieve better customers than any internal development organization Chapt er 3 at a - lower Ser viceOr iented Ar chi es and WebInternal Serv ices product cost because oftectur specialization. development organizations will therefore shift to doing For ces The Affecti ng the Adoption of will Web Serto v ices and Other ation less development. emphasis internally shift making all theI ntegr connections work properly and integrating new Chapt er 4 services thatTechniques might give an organization a competitive edge. An organization might also decide to provide a unique Chapt er 5that- can Growing I mpact of Web Serv ices service be sold to other organizations. Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Ar chitect ur eswill only buy vendor-provided products and services if the software is of sufficient quality. Of course, organizations Chapt er 7 - the St arreason ti ng t o why Adopt Ser vi ce- Or iented Ar chitectur e software is that it experienced poor quality, vendorSometimes anaorganization develops its own Pa r t I I - Masoftware. na gi ng Cha nge N ee de d for atoSer v i ce - Or in ie nte Ar chit e ct ur e will need to be prepared to provide very highprovided Vendors planning compete thisd environment Chapt quality er 8software - Change and Wil a high l Happen level of customer service. Being able to treat services as commodities will allow an organization to switch servicesChange easily ifI ssues it perceives that ent the quality of software is poor or that they are not Chapt er 9 - Tips for Managing dur ing either Developm receiving support any issues. Pa r t I I I - Crsufficient e a ti ng S er v i ce - O on r ie nt ed software-related Ar chi te ctu r es Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Web Services Explained ISBN:1558609067

by Douglas K. Barr y

Earlier, Web Services described the ?2003 connection technology of the future. The remainder of this chapter is Mor ganwere Kaufm ann Publas ishers (245 pages) devoted to explaining Web Services. First, defining Web Services Services Description Language Prov ides both pr actical leader ship and ar chitectur al using adv iceWeb on how t o pr epar e an or ganization to t ak e (WSDL) will be reviewed. will ser be vices followed whicharprovides of sending messages. Asdatapart of advantageThat of Web and by serSOAP, vice- or iented chitecturmeans es, bri dging t he gap bet ween the centr ic software engineer ing wor lds.be compared to fixed record message formats to show the the explanation, and XMLt he tagged message formats will resilience of XML as part of a Web Services. Of course, XML is not the only option. The end of this section will cover Table of Contents Back Cov er Com m ents options besides XML for Web Services. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Using the Web Services Description Language (WSDL)

For ewor d

I ntr oduction WSDL forms the basis for Web Services. Figure 3.3 illustrates the use of WSDL. At the left is a service provider. At Pa r t Iright - Se is r viaceO r ie nt ed Ar chi te ctur e steps Ov er v iinvolved ew the service consumer. The

in providing and consuming a service are:

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

Figure 3.3: Web Services basics.

Chapt er 15 - Qui ck Reference Guide

I ndex1. A service provider describes its service using WSDL. This definition is published to a directory of services. List of Fi gures The directory could use Universal Description, Discovery, and Integration (UDDI). Other forms of directories

can also be used. 2. A service consumer issues one or more queries to the directory to locate a service and determine how to communicate with that service. 3. Part of the WSDL provided by the service provider is passed to the service consumer. This tells the service consumer what the requests and responses are for the service provider. 4. The service consumer uses the WSDL to send a request to the service provider. 5. The service provider provides the expected response to the service consumer.

Using Universal Description, Discovery, and Integration(UDDI) The UDDI registry is intended to eventually serve as a means of “discovering” Web Services described using WSDL (see page 205). The idea is that the UDDI registry can be searched in various ways to obtain contact information and the Web Services available for various organizations. Even without the discovery portion, the UDDI registry is a way to keep up-to-date on the Web Services your organization currently uses. (An alternative to UDDI is the ebXML Registry, which is described on page 208.)

Using SOAP All the messages shown in Figure 3.3 are sent using SOAP (see page 205). (SOAP at one time stood for Simple Object Access Protocol. Now, the letters in the acronym have no particular meaning. [7] ) SOAP essentially provides the envelope for sending the Web Services messages. SOAP generally uses HTTP (see page 225), but other

means of connection may be used. HTTP is the familiar connection we all use for the Internet. In fact, it is the pervasiveness of HTTP connections that will help drive the adoption of Web Services. [8] W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Figure 3.4 provides more detail on ythe messages sent using Web Services. At the left of the figure is a fragment of ISBN:1558609067 by Douglas K. Barr the WSDL sent to the It shows a Customer that requires the customer’s account to object Mor gandirectory. Kaufm ann Publ ishers ?2003 (245InfoRequest pages) information. AlsoProv shown thepr CustomerInfoResponse provides aice series of items on the including ides is both actical leader ship and arthat chitectur al adv on how t o pr epar e ancustomer or ganization to t ak e name, telephone, and address items. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 3.4: Web Services messages. At the right of Figure 3.4, is a fragment of the WSDL being sent to the service consumer. This is the same fragment sent to the directory by the service provider. The service consumer uses this WSDL to create the service request shown above the arrow connecting the service consumer to the service provider. Upon receiving the request, the service provider returns a message using the format described in the original WSDL. That message appears at the bottom of Figure 3.4.

Using XML with WSDL WSDL uses XML to define messages. XML has a tagged message format. This is shown in Figure 3.5. The tag is highlighted in this figure. The value of city is Burnsville. And is the ending tag indicating the end of the value of city. Both the service provider and service consumer use these tags. In fact, the service provider could send the data shown at the bottom of Figure 3.5 in any order. The service consumer uses the tags and not the order of the data to get the data values.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise ChaptFigure er 6 - 3.5: Tagged messages. Ar chitect ur es Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

XML Tagged - Change Format Wil l Happen Compared to Fixed Record Formats

Chapt er 8 Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

The XML tagged format provides a level of resilience not available with fixed record formats commonly used before the advent of XML. For example, if a service provider adds an additional element not expected by a service Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices consumer, the XML tagged format allows processing to continue without any problems occurring. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 3.6 12 shows - Mi ddl eTier Ar chitectur Figure a service providere adding a new element “extension” for a telephone extension. The service Chapt er 13sends - Revthis isi ting the directory Business as Tr ipshown in the at NotFutur e At the bottom of the figure, the service provider to the theTooleftDistant of Figure 3.6. Pa r t I V - Com pe ndi um of Softw r e Te chnolog for S er v the i ce - Or i e nte d Ar chit ect ur e s provider is shown providing a aresponse that yincludes new element.

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Adding a new element. ChaptFigure er 13 - 3.6: Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Now,erit 14 is not uncommon for something to go wrong with our information systems. In this case, what went wrong is Chapt - Addi tional Specification Details that the service consumer did not query the directory to get the new definition. Let’s see what happens when XML tagged messages are used.

Chapt er 15 - Qui ck Reference Guide I ndex

List Fi gures consumer does not expect to receive the telephone extension. Nevertheless, because of the XML Theofservice

tagged messages, essentially nothing bad happens when extra data (the value of the phone extension) is passed back by the service provider. This is shown at the bottom of Figure 3.7. The tags are used to identify each of the data items and the service consumer uses the proper values. The extra telephone extension data is simply ignored. Although it might be nice to have the extension data, the good news is that no other data is received incorrectly.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Example the resilience provided by tagged ChaptFigure er 13 - 3.7: Rev isi ting theof Business Tr ip in the Not- TooDistant messages. Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

If a fixed was used and the same error occurred, there could be harm. Let’s look at this situation. Chapt er 14record - Addiformat tional Specification Details

Figure 3.8 shows a fixed record format that passes the same information on customers. The length of this record is 124 characters. Now, assume the EXTENSIONfield is added after the PHONEfield, but to keep the record length to I ndex 124 characters, the STREET2field is shortened by three characters. Chapt er 15 - Qui ck Reference Guide List of Fi gures

Figure 3.8: Record content changes without changing length of record. Figure 3.9 shows this change in the context of a directory. Just as in Figure 3.6, the service provider sends this to the directory as shown at the left of Figure 3.9. Assume the same error occurs as previously described. The service consumer does not query the directory to get the new definition. As a result, the service consumer is unaware that the response is going to contain a value for the telephone extension. Because the fixed record format assumes everything is based on position, whatever appears in a particular position is moved into a field in the service consumer.Figure 3.9 shows that both the EXTENSIONand STREET1fields are moved into the first street address in the service consumer.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Example of the fixed record messages. Pa r t I Figure V - Com3.9: pe ndi um of Softw a r ebrittleness Te chnologof y for S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

Figure 3.10 provides another way to view how this happened. In fixed record messaging, everything is positional. Since the service consumer was unaware of the record change, it moved “30113504 4th Ave S” into the STREET1 I ndex field shown at the bottom of Figure 3.10. Chapt er 15 - Qui ck Reference Guide List of Fi gures

Figure 3.10: How the wrong data can be copied using fixed records. The effect of an error like this is interesting. Obviously, if the service consumer sent postal mail to this address, it could not be delivered. Less obvious is the situation when a customer record does not have a phone extension. Then the first three spaces of the STREET1field in the service consumer would be spaces. If the service consumer sent postal mail to this address, it could then be delivered as long as the address was no longer than 17 characters. If the address line exceeded 17 characters then the last part of the address line would show up on the first part of the second address line. Often, that would mean it could be delivered as well. So, only some addresses would fail. Tracking down this type of error is often not easy. Certainly, more catastrophic errors can occur when changing the structure of fixed length records. There could be situations where the service consumer could even fail because the record layout coming from the service provider is not the layout expected. These types of errors occur all the time when exchanging data between systems, either internally or between an internal and an external system. Using the XML tagged format makes systems more resilient in the face of these types of error.

The downside of using XML is that the messages are much longer. XML messages are physically longer than fixed record messagesWbecause of the included tag information. So, there is a potential performance hit. With XML, you eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e are trading some resilience in your systems for some reduction in performance. Nevertheless, as transmission ISBN:1558609067 by Douglas K. Barr y speeds increase, this reduction in performance may not be noticed. Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

advantage XML of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Options Besides and t he software engineer ing wor lds.

It is possible to have Web Services without XML. If you look at the description of WSDL starting on page 207, you Table of Contents Cov er Com m ents will see the XML is notBack required. Some organizations might opt for a different message format. One reason to use Tasomething ble o f Conother t en t s than XML might be the need for extremely high performance. XML-based messages can become large and therefore notiented meetAr some high-performance requirements. If something other than XML is used, both Web Ser vices and Ser may vice- Or chit ectur es—The Sav vy Manager 's Guide the service provider and the service consumer must agree on the message formats. Within an organization that For ewor d should be relatively simple. Between organizations, this can be more difficult. And among all organizations within an I ntr oduction industry, could become That Pa r t I - Se rthis vi ceO r ie nt ed Ar chiintractable. te ctur e Ov er v i ewis why so many industry groups are converging on XML as the way to specify messages. In a sense, it is the least common denominator. Nevertheless, there are economic advantages to Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e having agreement on industry-wide vocabularies for the passing of service messages. A sampling of these Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p vocabularies can be found starting on page 212. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices [7] Starting with SOAP Version 1.2, SOAP is no longer is an acronym. Chapt er 4

-

[8]Other

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

protocols are taking advantage of SOAP. For an example, see Blocks Extensible Exchange Protocol - Growing I mpact of Web Serv ices (BEEP) on page 205 and ebXML on page 208.

Chapt er 5

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W ebAuthorization Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Security and by Douglas K. Barr y

ISBN:1558609067

At the time this book wasKaufm written, hot topic in Web Services was security and authorization. In fact, this is often Mor gan annthe Publ ishers ?2003 (245 pages) the reason cited Prov for not proceeding with any work related to WebalServices. thet osection the bulleted list, we ides both pr actical leader ship and ar chitectur adv ice onIn how pr eparafter e an or ganization to t ak e will see why this advantage is not necessary, first let’s look at security authorization. of Web but ser vices and ser viceor iented and ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Topics are listed below that relate to security and authorization. [9 ]These are being worked on in Organization for the Table of Contents Back Cov er Com Standards m ents Advancement of Structured Information (OASIS) and the World Wide Web Consortium (W3C).[10] (This meant to be reassuring in the breadth of work being done. Unfortunately, as a result, there is quite a bit of Talisting ble o f isCon t en t s jargon in the description. Don’t beArconcerned if the jargon not'smean Web Ser vices and Ser vice- Or iented chit ectur es—The Sav vy does Manager Guideanything to you at this time.) For ewor d

eXtensible Access Control Markup Language (XACML): provides fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew authorization based on classes of activities, and content introspection.

I ntr oduction Pa r t I

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er eXtensible 2 - I nforrights m at ionMarkup Technology Language Used in (XrML): Thi s Tri p a digital rights language designed for securely specifying and

managing and conditions associated withServ various Chapt er 3 - Serrights vice- Or iented Ar chi tectur es and Web ices resources including digital content as well as services. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Common XML Biometric Format (XCBF): a common set of secure XML encoding for the formats specified in Techniques

CBEFF, the Common Biometric Exchange File Format. Chapt er 5 - Growing I mpact of Web Serv ices Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - Provisioning Markup Language (SPML): an XML-based framework specification for exchanging Service Ar chitect ur es

user, resource, and service provisioning information. The SPML specification is being developed with - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e consideration of the following provisioning-related specifications: Active Digital Profile (ADPr), eXtensible I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Resource Provisioning Management (XRPM), and Information Technology Markup Language (ITML).

Chapt er 7 Pa r t

Chapt er 8

- Change Wil l Happen

Chapt er 9 - Tips for Managing Change I ssues dur ing Developm Security Assertion Markup Language (SAML): an XMLent framework for exchanging authentication and Pa r t I Iauthorization I - Cr e a ti ng Sinformation. er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

XML syntax used for representing signatures on digital content and procedures for Chapt er 11 Signature: - Ar chitect uran al XML Opt ions computing and verifying such signatures. Signatures provide for data integrity and authentication. Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

XML Encryption: a process for encrypting/decrypting digital content (including XML documents and portions thereof) and an XML syntax used to represent the encrypted content and information that enables an intended Chapt er 14 - Addi tional Specification Details recipient to decrypt it. Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 15 - Qui ck Reference Guide I ndex XML Key Management Specification (XKMS): a specification of XML application/protocol that allows a simple

to obtain key information (values, certificates, and management or trust data) from a Web service. List of client Fi gures It is reasonable to expect these specifications to change shape, merge, and possibly acquire new names and acronyms. You can find the latest information on the status of security and authorization at www.servicearchitecture. com. The fact that these specifications are in flux should not hold you back from experimenting with Web Services. Much can be done without having the specifications complete. Chapter 7 discusses the stages of adoption for Web Services. The first four of the five stages do not require much security and authorization because they involve internal systems. Of course, how internal systems are used affects the level of security and authorization needed. Nevertheless, nearly all organizations should be able to find some areas to experiment with Web Services that have low requirements for security and authorization. [9 ] Also see the discussion of firewalls starting on page 180. [10]

See page 191 for a description of these organizations and other organizations working on standards related to Web Services.

eb Services an d SerNotation vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Simplified WWeb Services by Douglas K. Barr y

ISBN:1558609067

For the remainder ofgan thisKaufm book,ann a simplified notation willpages) be used for Web Services. This is shown in Figure 3.11. In Mor Publ ishers ?2003 (245 the simplified notation, the directory is implicit in the rectangle labeled at the middle of this figure. Prov ides both pr actical leader ship and ar chitectur al adv “Web ice on Services” how t o pr epar e an or ganization to t ak e You could think of Web Services likeand the ser busvicein aorPC in which you plug various Other advantage of Webmuch ser vices iented ar chitectur es, bri dging circuit t he gapboards. bet ween the data- centr ic and t he software engineer ing the wor lds. middleware solutions appear similar and use same “bus” concept, as we will see in the next chapter. Table ofimportant Contents concept Back Cov er Com m ents architectures is that any service producer could also be a service Another in service-oriented Taconsumer. ble o f Con tThis en t sis why Figure 3.11 shows only services at the bottom of the figure under the Web Services bus. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 3.11: Simplified Web Services notation.

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

This chapter outlined service-oriented and Web Services along with ways that organizations of any Mor gan Kaufm ann Publarchitectures ishers ?2003 (245 pages) size can use such architectures. It showed the importance that XML will in the of eWeb is ethe Prov ides both pr actical leader ship and ar chitectur al adv iceplay on how t o use pr epar an orServices. ganizationXML to t ak default messageadvantage format for ofWSDL. WSDL describes services through Web Services. place wherecentr theic Web ser vices and ser viceor ientedavailable ar chitectur es, bri dging t he gap betThe ween the dataand t is hestored software ingsuch wor lds. description in WSDL is aengineer directory as UDDI directory. Directories such as UDDI will function for Web Services much like 411 or telephone directories function for the telephone system. Finally, SOAP is positioned to Table of Contents Back Cov er Com m ents become the default way to transmit WSDL among services and directories. The chapter ended with a summary of Tacurrent ble o f Con t en work ont ssecurity and authorization related to Web Services along with a caution that it is not necessary to Web Ser vice- Or iented chit ectur es—The Sav vy started Managerwith 's Guide waitSer forvices thoseand specifications to beAr complete before getting Web Services. For ewor d

The use of any technology, of course, must exist in the context of our organizations. Organizations have many forces that affect the adoption of new technology. The next chapter will delve into the forces affecting the adoption Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew Web Services. I ntr oduction Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby4: Forces Affecting the Adoption of Web Services ISBN:1558609067 Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) and Other Integration Techniques Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage ofcan Web vices and ser viceor iented chitecturand es, bri dging changes t he gap bet data- centr ic Change in any organization beser challenging. This applies to ar technical system asween well. the In this and t he software engineer ing wor lds. chapter, changes in the form of various integration techniques are covered. For each technique, the forces that help and hinder the changeBack are analyzed using a technique called force field analysis. Included in the force field analysis Table of Contents Cov er Com m ents are integration techniques such as adopting enterprise-wide standards, various types of middleware, data Ta ble o f Con t en t s warehousing, and message routing. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor Note d My first exposure to attempting enterprise integration came many years ago. I worked for a corporation I ntr oductionthat decided to standardize on what was called “basic business elements” or BBEs. Various departments

had serial numbers, Pa r t I - Se r vi ce-different O r ie nt ed definitions Ar chi te cturfor e Ov er v i ew

among other commonly used data elements. This was seen as

thing that to be expensive to the corporation. An analogy was made to a discovery that different Chapt er 1 a- bad A Business Tr iphad in the NotToo- Distant Futur e metal screws were being used build equipment in different departments when one type of screw Chapt er 2 sheet - I nfor m at ion Technology Used in Thi stoTri p be used almost universally. Buying, inventorying, and using one type of screw actually saved a Chapt er 3 could - Ser viceOr iented Ar chi tectur es and Web Serv ices

considerable amount money. ofThe reasoning, believe it or not,ation was that if using one type of sheet metal For ces Affecti ng theof Adoption Web Ser v ices and Other I ntegr Chapt er 4 screw across departments saves money, then using one serial number definition across departments Techniques also Isave Chapt er 5 should - Growing mpactmoney. of Web The Servintent ices was good, but of course, a lot of time and money was spent on Chapt er 6 Chapt er 7

defining these BBEs. analysis seemed go forever. In fact, the use of BBEs never went beyond the Ser viceOr iented Ar The chi tectur es and Beliefs to about Enter pr ise analysis stage. Ar chitect ur es - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Force Field Analysis Overview

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen Force a tool that can help us get a perspective on the forces at work when trying to make changes in Chapt er field 9 -analysis Tips for isManaging Change I ssues dur ing Developm ent

was developed by Kurt Lewin.[1]Figure 4.1 illustrates the concepts technique. any particular activity, goal or vision, which is shown by the large arrow at Chapt er 10 of- this Ar chitect ur es atFor Each Stage of Adopti on forthere Web is Seravices the top of the figure pointing to the right. There are driving and restraining forces that will impact whether this goal or Chapt er 11 - Ar chitect ur al Opt ions vision can be achieved. Driving forces, which help achieve the goal or vision, are shown as arrows pointing to the Chapt er 12 - Mi ddl e- Tier Ar chitectur e right in the same direction as the large arrow at the top. Restraining forces, which hinder goal achievement, are the Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e arrows pointing to the left, in the opposite direction as the large arrow at the top. At some point, driving and Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s restraining forces are in equilibrium. This is illustrated in the figure by the wide vertical line labeled “Status Quo.” Chapt er 14 - Addi tional Specification Details Driving forces move an organization from the status quo in the direction of the organization’s goal or vision. Chapt er 15 - Qui ck Reference Guide Restraining forces hold back this change from the status quo. These forces can be external or internal to an I ndex organization, or external or internal to the individuals in the organization. The relative strength of the driving or List of Fi gures restraining forces determines whether change occurs. organizations. This Pa r t I I I - Cr e a ti ng S erapproach v i ce - O r ieto nt analyzing ed Ar chi te change ctu r es

Figure 4.1: Force field analysis. Assume, for example, that you want to change a part of a system in an organization. An external organizational driving force could be the opportunity to electronically exchange purchase orders and invoices with a particular customer or supplier. An internal organizational driving force could be a reduction in operating costs. An internal organizational restraining force could be the development cost for making the change. Finally, an internal individual restraining force for some people in the company might be that the change to the system may result in fewer jobs in their part of the organization. Figure 4.2 illustrates this concept. Of course, there could be many other forces at work than those shown in Figure 4.2. The nature of the driving and

restraining forces could also vary by organization even if the organizations were attempting to carry out exactly the same tasks. In fact, they can vary among departments in the same organization. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Figure 4.2: Force field analysis for making a system change.

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Techniques Essentially, the purpose of this model is to make all the driving and restraining forces visible so that decisions Chapt er 5 Growingcan I mpact of Web Serv concerning change be made with theices best available information. There are various ways to use this model. If Ser viceOr iented Ar chi tectur es need and Beliefs about Enter pr ise you want to make change more likely, you to either strengthen the driving forces or weaken the restraining Chapt er 6 Ar chitect ur es forces. Weakening the restraining forces is sometimes the best approach. Strengthening the driving forces can Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e make the restraining forces get stronger. In Figure 4.2, promoting the electronic interchange capabilities of this Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e change will likely cause more concern about job loss that, in turn, could create various forms of resistance that can Chapt er 8 scuttle - Change Wil l Happen effectively efforts to change from the status quo. So, perhaps it is possible to assure people that jobs will not Chapt er 9 Tips for Managing Change I ssues Developm ent be lost, thus weakening this restraining force.dur Of ing course, this assurance and the resulting reduction in resistance Pa r t I I I Cr e a ti ng S er v i ce O r ie nt ed Ar chi te ctu r es would work only if it were actually true that jobs would not be lost. In the figures that follow, weakened restraining Chapt er will 10 be - Arshown chitectas ur es at Each Stage of Adopti on restraining for Web Serforce vices is fading away. Figure 4.2, for example, shows forces gray arrows to indicate the Chapt - Ar al Opt ions that er the11fear of chitect losingurjobs is weakened and less of a concern. [1] Lewin, Chapt er 12 Kurt, - Mi ddl e- Tier Ar chitectur e Science, Harper and Row, New York, 1951. Field Theory in Social Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Analysis ofWIntegration Techniques ISBN:1558609067

by Douglas K. Barr y

Common systemMor integration techniques are presented approximately in chronological order. Chronological order gan Kaufm ann Publ ishers ?2003 (245 pages) allows us to see Prov how,ides over time, advances in technology and standards diminished number of restraining both pr actical leader ship and ar chitectur al adv icehave on how t o pr eparthe e an or ganization to t ak e forces, making change more to occur. At the end,orWeb Services willes, be bri seen as thaving least the number advantage of likely Web ser vices and ser viceiented ar chitectur dging he gap the bet ween data-of centr ic t he software engineer wortechniques. lds. restraining forcesand compared to any of the ing other Using Web Services essentially represents the most recent advance in standards and technology. Table of Contents

Back Cov er

Com m ents

force presented here will highlight common driving and restraining forces. Every organization will, TaThe ble o f Confield t en tanalysis s of course, have consider that might be Manager unique to organization. Also, design issues such as Web Ser vices and additional Ser vice- Orforces iented to Ar chit ectur es—The Sav vy 's the Guide

“project For ewor d scope” or people issues such as “resistance to change” do not appear in these analyses, because they will require special discussion. These issues will be covered in Part II of this book on managing change.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Also, each analysis will include such driving forces as “reduced development time” and “reduced maintenance cost”

Chapt er 1 - driving A Business Tr ip in the Not- Too- Distant Futur e as universal forces. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services anEnterprise-Wide d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Analysis ofWAdopting Standards ISBN:1558609067

by Douglas K. Barr y

The most obvious way integrate systems any pages) organization is to establish some type of enterprise-wide Mor gantoKaufm ann Publ isherswithin ?2003 (245 standards. This section will cover the forces affecting the adoption of standard data element definitions andto the Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization t ak e adoption of standard, enterprise software. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Adopting Standard Element Definitions Table of Contents Back CovData er Com m ents TaThis ble ofirst f Con t en t s shown in Figure 4.3 relates to the vignette that opened this chapter. In the early 1980s, many large analysis Web Ser vices and Serrunning vice- Or iented Ar chit software ectur es—The vy was Manager Guide organizations were on custom and Sav there very'slittle use of packaged software. At the time, it For ewor d was believed that there would be opportunities to exchange data more easily, reduce development time, and I ntr oduction possibly reduce maintenance costs if all the custom software were to use the same data element definitions. These Pa r t I - Se r vi ce-are O r ie nt ed Ar te ctur eforces Ov er vin i ew opportunities shown aschidriving Figure

4.3. Restraining forces related to cost offset these driving forces

Chapt er 1 money. - A Business ip in the NotDistant Futur e of costs to developing the standard definitions and the FigureTr4.3 shows theToorestraining forces of saving costserrelated to changing the existingUsed systems. Chapt 2 - I nfor m at ion Technology in Thi s Tri p Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 4.3: Force field analysis for adopting standard data element definitions. There are additional restraining forces in this figure. In some cases, there were valid reasons that two different systems used different definitions for the same data element. For example, in the vignette opening this chapter, most of the differences related to serial numbers and how they were used among different departments. Also, in the early 1980s, there had been little progress in developing a standard set of data elements for industry. Therefore, the cost of developing a standard set for an organization was quite high because it involved starting with a clean sheet of paper. Even if this effort to change to standard data elements had been successful, the first merger or acquisition would likely cause a problem. The systems used by every other organization would have used different data elements. Finally, as the use of packaged software increased, the definitions used in those products would most likely be incompatible. With enough mergers or acquisitions and use of packaged software, you would be back at the starting point with incompatibility of data definitions. Note Times have changed since the early 1980s and so have attitudes toward standard data elements. Some industries can see advantages in having standard data elements so that data can easily be interchanged. Another advantage to standard data elements is that they lessen the integration efforts involved in mergers and acquisitions. A sampling of standard vocabularies by industry starts on page 212. So, it would be fair to say that the infrastructure provided by Web Services and XML has given a boost to the standardization efforts.

Adopting Standard, Enterprise-Wide Software In some organizations, there is great interest in establishing organization-wide software. This works sometimes. When it does, however, usually it is successful only for a short period. The appeal of adopting standard software is

obviously that everyone uses the same software. This means that the entire organization uses the same data definitions, semantics, and formats for exchanging data. Usually this works best for organizations that are small and ebsystems Services d SerItvicerien t ed Archit u re: T h e Saon vvy Man ag er 's software Gu id e putting a new setWof in an place. also Oworks if you areect standardizing non-systems such as a ISBN:1558609067 by Douglas K. Barr y particular word processor, spreadsheet, or an email system. Nevertheless, standardizing on systems software often Mor gan Kaufm ann Publ ishers ?2003 (245 pages) runs into problems, too. There are long-term restraining forces, such as mergers and acquisitions that can come into play. Even a new, Prov small idesorganization both pr acticalcan leader acquire ship and another ar chitectur company al adv that iceuses on how an entirely t o pr epar different e an or ganization system, and to t ak e advantage Web ser and ser or iented ar chitectur bri dgingenterprise-wide t he gap bet ween the data- centr ic integration problems begin.ofFigure 4.4vices provides theviceforce field analysis for es, standard, software. and t he software engineer ing wor lds.

Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Figure 4.4: Force field analysis for adopting standard, enterprise-wide software.

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

Change Wil l Happen Beside the -mergers and acquisitions restraining force, it is common in larger organizations that some departments

Chapt 9 - Tips for Managing dur ing haveerdifferent software needs. Change It is rareI ssues that you canDevelopm find “oneent size fits all” software. Another downside is that Pa r t I I I - Cr a ti ng S er vset i ce -ofOsoftware r ie nt ed Arsystems chi te ctu from r es adopting a ecomplete

a single vendor makes your organization dependent on that single

Chapt er 10 Ar chitect ur esmove at Each Stage ofthat Adopti on for Web Ser vices vendor. As-soon as you away from vendor’s products, you might be back into common integration issues. Chapt er 11 Ar chitect ur al that Opt ions Finally, for -organizations have existing systems, adopting standard software can mean a mass conversion to Chapt er 12software. - Mi ddl eTier often Ar chitectur e the new This is problematic and should be seen as a restraining force. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Note none of um the of restraining in this figure gray. Pa r t I Vthat - Com pe ndi Softw a r e forces Te chnolog y for S er vare i ce -shown Or i e ntein d Ar chit This ect urmeans es

that they will not diminish over

time er and remain restraining forces going forward into the foreseeable future. Chapt 14will - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide

There is, however, increasing recognition among software vendors that it is in their interest to create plug-compatible software components that can be used in assembling a service-oriented architecture. This plug-compatibility will be List of Fi gures achieved using Web Services. Using plug-compatible software will make it easier to “mix and match” vendor products when developing or modifying an enterprise architecture. I ndex

Of course, every example has a counter example. There are some industries where mergers and acquisitions are commonplace. You will see organizations in those industries adopting common, industry-wide software packages so that it will be easier for one organization to be acquired or merged with another organization. So, mergers and acquisitions can also be a driving force. This is represented in Figure 4.4 with a dashed line. Although, I have not seen any empirical data on this, my experience is that this is the exception rather than the rule. That is the reason for the dashed line because it is likely to not apply to all industries. Similarly, mergers and acquisitions could be a driving force for current efforts on developing industry-wide vocabularies for Web Services. [2] [2] See page 212 for a sampling of industry-wide vocabularies.

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Analysis ofWMiddleware Integration ISBN:1558609067

by Douglas K. Barr y

Middleware hidesMor the complexity theishers communication between two or more systems or services. This simplifies the gan Kaufm annofPubl ?2003 (245 pages) development of those systems and services and isolates the complexity communication them. Prov ides both pr actical leader ship and ar chitectur al adv iceofonthe how t o pr epar e an between or ganization to tThe ak e different systemsadvantage or services theand same or on differentes, hardware. thedatabasiccentr ic of can Web be seron vices ser hardware vice- or iented ar chitectur bri dging Figure t he gap4.5 betshows ween the and t he software engineer ing wor lds. middleware architecture. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

ChaptFigure er 10 - 4.5: Ar chitect es at Each Stage of Adopti on for Web Ser vices Basicurmiddleware architecture. Chapt er 11 - Ar chitect ur al Opt ions

InFigure the Chapt er 124.5, - Mi ddldifferent e- Tier Arsystems chitectur eand services each are running on different machines. These machines could be

in theersame or the different locations same organization. Chapt 13 - location Rev isi ting Business Tr ip in for thethe NotToo- Distant Futur e Alternatively, all three machines could belong to different organizations. Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

There has been significant work on middleware over the years. Some examples of middleware include:

Chapt er 15 - Qui ck Reference Guide I ndex Transaction processing (TP) monitors. A TP monitor ensures that transactions process completely or the

action is taken if an error occurs. They often employ load balancing because a transaction may be List of appropriate Fi gures forwarded to any of several servers. Remote Procedure Call (RPC). An RPC allows execution of program logic on a remote system by calling a local routine. Message-Oriented Middleware (MOM). MOM provides program- toprogram data exchange. Object Request Broker (ORB ). An ORB allows a system to request a service without knowing anything about what servers are available. The request is forwarded to the appropriate services with the results of the request returned to the requesting system. This section will examine adopting two forms of existing middleware and compare that to adopting Web Services as middleware. The two forms commonly used are the Object Management Group’s Common Object Request Broker Architecture (CORBA) specification and Microsoft’s Distributed Common Object Model (DCOM).

Adopting CORBA and DCOM CORBA and DCOM are middleware that provide a means for applications to communicate with each other. CORBA is a set of specifications developed through the Object Management Group (see page 222). Implementations of CORBA are referred to as ORBs orobject request brokers. DCOM comes from Microsoft (see page 223). CORBA and DCOM are interoperable through CORBA/DCOM bridges. Both CORBA and DCOM represent reasonably mature technology for creating interoperable, networked applications. Figure 4.6 shows that providing interoperable, networked applications are a driving force for adopting CORBA, DCOM, or in some cases both.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Figure 4.6: Ar chitect Forceurfield es analysis for adopting CORBA or DCOM.

CORBA and DCOM, however, the data Pa r t I I - Ma na gi ng Cha nge N ee deare d for a means Ser v i ce -to Orget ie nte d Arfrom chit eone ct ur eplace

to another. There are no specific requirements for the format of the data transmitted in the messages, which means that the transmitted data might Chapt er 8 - Change Wil l Happen not be workable when it arrives at its destination. The restraining forces related to data exist with either CORBA or Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent DCOM. These are: Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es Chapt er 10 - Arsemantics chitect ur esinatdata Eachsources Stage of Adopti on for Web Ser vices Different Chapt er 11 - Ar chitect ur al Opt ions

Semantic Chapt er 12 - Mi translation ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Lack of industry-standard definitions

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 in - Addi tionalstandards Specification Details [3] EDI,[4] and Web Services (see page 205) will mitigate all these Advances industry for XML, Chapt er 15 Qui ck Reference Guide restraining forces, which is why they are shown as gray arrows in Figure 4.6. In fact, using XML (see page 209) with I ndex CORBA or DCOM makes for a more flexible system because of the tagged record structure of XML. [5] This would List of mitigate Fi gures the restraining force related to the brittleness of fixed record formats. also

There is a perception in the industry that neither CORBA nor DCOM are that widely adopted and that using one or the other—or both—is too complex for many programmers. Whether the perceived lack of industry adoption or inherent complexity is actually true is irrelevant at this point. These perceptions are seen as restraining forces. In fact, they should be seen as the most significant restraining forces. Web Services have just the opposite perception—they are seen as easy to adopt widely by industry and easy for most programmers to use. Perception in this case might well be the reality. The very nature of creating interoperable, networked resources means that there could be a negative impact on operational systems when requests come in through CORBA or DCOM. Many operational systems have not been designed to receive ad hoc or unexpected processing requests. These requests sometimes can have a negative impact on the performance of those systems. So, the effect on operations systems can be a restraining force, but should be expected if up-to-the-moment processing is needed (see page 161). Finally, mergers and acquisitions could be an issue because it is entirely possible that the acquired systems do not use either CORBA or DCOM, and it is not a trivial task to retrofit systems to use either technology.

Adopting Web Services Using Web Services is the missing piece in the puzzle of how to create interoperable systems and services and benefits from the development of CORBA and DCOM. Web Services use of both XML and HTTP [6] on the Internet greatly reduces restraining forces that existed with preceding technologies. The perceived simplicity of Web Services has created a stampede of vendors incorporating Web Services into their products and services. Figure 4.7 shows the driving and restraining forces for adopting Web Services.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

field analysis adopting Services. Pa r t I Figure I - Ma na4.7: gi ngForce Cha nge N ee de d forfor a Ser v i ce - OrWeb ie nte d Ar chit e ct ur e Chapt er 8

- Change Wil l Happen

In addition -toTips the for same driving force of interoperable, networked applications shown for CORBA and DCOM, the Managing Change I ssues dur ing Developm ent driving forces in Figure 4.7 now include a driving force related to XML’s tagged format: reduced brittleness using Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es tags. The explosive growth of Web Services being used in products will also result in a significant growth of external Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices services that can be used by organizations of any size. The nature of services available will be covered in Chapter 5. Chapt er 11 - Ar chitect ur al Opt ions Similarly, there is an abundance of training and tools becoming available on Web Services. Chapt er 9

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt 13 - Revforces isi ting are the Business ip in the Not- TooDistant Futur e integration techniques. These include: The er restraining similar toTr those we have seen with earlier Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Different semantics in data sources Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex

Semantic translation

List of Fiis gures There a tremendous amount of work in various standards organizations to simplify the semantics and standardize

the semantic translation (see page 212). Those standards are evolving, which is why it is seen as a restraining force. Nevertheless, as time goes on, these restraining forces will weaken. Finally, mergers and acquisitions, which appeared as a restraining force for CORBA and DCOM, is shown in Figure 4.7 as a weakening restraining force for the adoption of Web service. The broad adoption of Web Services by product vendors over time increases the likelihood that an acquired company will be able to work with Web Services. Mergers and acquisitions also appear as a driving force. This is for those industries where mergers and acquisitions are commonplace. Mergers and acquisitions could, for example, be a driving force for current efforts on developing industry-wide vocabularies for Web Services (see page 212). The reason for the dashed line in Figure 4.7 is because this driving force is likely to not apply to all industries. Just as with CORBA and DCOM, you are left with the possible impact on operational systems, but this should be expected if up-to-the-moment processing is needed. As mentioned in that discussion many operational systems have not been designed to receive ad hoc or unexpected processing requests. These requests sometimes can have a negative impact on the performance of those systems. So, the effect on operations systems can be a restraining force, but should be expected if up-to-the-moment processing is needed.

Adopting Web Services Does Not Mean Abandoning CORBA or DCOM For organizations that have invested heavily in CORBA or DCOM, the adoption of Web Services does not mean you need to abandon CORBA or DCOM and convert existing systems. Recall that the middleware hides the complexity of the communication between two more systems or services. That hiding of complexity allows existing systems to participate in Web Services by altering the way the middleware works. Figure 4.8 is a high-level view of how Web Services can work with both CORBA and DCOM with each of the systems or services operating in a different organization. [7]

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Web ur Services interoperating withonCORBA DCOM. ChaptFigure er 10 - 4.8: Ar chitect es at Each Stage of Adopti for Weband Ser vices Chapt er 11 - Ar chitect ur al Opt ions [3]

A sample of industry-specific XML vocabularies are listed starting on page 212.

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt [4] The er 13 - Rev isi ting the Business Tr ipfor in EDI. the NotDistant on Futur e 208. ebXML Registry is an example It isToodiscussed page Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s [5] For Chapt er an 14 explanation - Addi tionalofSpecification the tagged Details record structure of XML and the brittleness of

fixed record formats, see page 26.

Chapt er 15 - Qui ck Reference Guide [6] One reason other protocols have failed to gain wide acceptance is the desire to use HTTP. The CORBA Internet I ndex

Inter-ORB Protocol (IIOP) is an example of a protocol that did not gain wide acceptance, in part for that reason. List of Fi gures [7]

Of course, a similar figure could be drawn for other forms of middleware. Web Services is helping to drive the interoperability of all forms of middleware.

eb Services an dComponents Ser vice- O rien t ed Archit ect ufor re: TIntegration h e Sa vvy Man ag er id e Analysis ofWAdditional Used in's aGuServiceISBN:1558609067 by Douglas K. Barr y Oriented Architecture Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Prov ides both pr actical leader shipused and in ar chitectur al adv ice onarchitecture. how t o pr epar e anare or ganization to t ak e Two additional techniques of integration can be a service-oriented They data warehousing advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and message routing. This section discusses those techniques and how they can be integrated with middleware and t he software engineer ing wor lds. such as CORBA, DCOM, and Web Services. Also, this section will show how efforts around Web Services will enhance data warehousing message Table of both Contents Back Cov er andCom m ents routing. Ta ble o f Con t en t s

Analysis of Data Warehousing

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

One of the oldest and most successful ways to integrate data from multiple systems is to extract that data from existing systems and load it into a single, central location to form an enterprise data warehouse (EDW). Using an Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew EDW can be complementary to using CORBA, DCOM, or Web Services. The analysis for this approach is shown in Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e Figure 4.9. I ntr oduction

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 4.9: Force field analysis for adopting an enterprise data warehouse. In this figure, the easier exchange of data as a driving force is replaced with easier access to enterprise-wide data. This data is loaded from existing systems using various techniques that extract, transform, and load the data in the EDW. Using extract, transform, and load (ETL) techniques means there is usually less impact on operational systems because the extracts of data from these systems could be done at a time convenient for the operational system. This lowered impact on operational systems is a significant driving force. Easier access to enterprise-wide data also allows the use of business intelligence (BI) software to find patterns or new business opportunities based on a wealth of data that could be stored in an EDW (see page 220). Most of the restraining forces are issues with the semantics or meaning of the data and the standardization of data definitions. Not surprisingly, these issues are similar to those involved with attempts at adopting standard data elements when existing data definitions are different. In this figure, the semantic translation is added to show the need to transform data can itself be a restraining force. Over time, however, these restraining forces have become weaker for two reasons: 1. A subset of our industry is devoted to the development of ETL software. This software generally simplifies the development the data extractions from existing systems, any semantic translation or transformation, and the loading of the data into the EDW. 2.

2. More industry standards have become available. Initially with efforts related to Electronic Data Interchange (EDI) and more recently with Web Services. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Additional restraining forcesK.include latency of by Douglas Barr y problems related to what data to store in the EDW, and the delay orISBN:1558609067 getting data into Mor the gan EDW. Theann issue what?2003 data (245 should be stored in an EDW will likely always remain a restraining Kaufm Publofishers pages) force. The strength thisboth restraining will vary byarorganization. The ort latency data is the resultto of Provof ides pr acticalforce leader ship and chitectur al adv ice delay on how o pr eparof e an or ganization t ak e [8]es, performing data advantage extracts at oftimes theviceoperational systems. Consequently, the bet very latest iscentr not ic Webconvenient ser vices andtoser or iented ar chitectur bri dging t he gap ween thedata datat heEDW. software engineer ing wor lds. this is no problem. Others, however, may find this a significant always available and in the To some organizations, restraining force. Table of Contents

Back Cov er

Com m ents

oft sdata also can be seen as a restraining force. Whenever data exists in more than one location, it is TaRedundancy ble o f Con t en possible thatand theSer data willOrhave different values for various reasons.'sThis could result, in part, from the latency of Web Ser vices viceiented Ar chit ectur es—The Sav vy Manager Guide

data mentioned earlier. For example, the value of an account balance may be updated by the operational system but For ewor d not forwarded to the EDW until some later date. At a given point in time, you could see two different values for the same account when looking at the EDW and the operational system. Often, the way to resolve redundancy issues is Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew to create a master database that all systems should use. I ntr oduction Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt 2 - issues I nfor m at ionpotentially Technology Used in Thi sforce, Tri p because much depends on the quality of the data available. If Dataerquality are a restraining Chapt - Ser viceOr iented tecturin es quality, and Web Servare icesoptions available for improving its quality. Changes could data er to3be stored in the EDW Ar is chi lacking there For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation be made Chapt er 4 to- improve data quality at the time it is entered. For existing data, the quality could be improved at the Techniques source. If that is not possible, the ETL software used to load data could be used to improve the quality of the data. Chapt er 5 - this Growing I mpact Web Serv(see ices page 222). This, of course, assumes the quality can be improved in Sometimes is called dataofcleansing Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise someerway Chapt 6 -that lends itself to programming. Data quality is a significant topic and you are encouraged to study it Ar chitect ur es

further if this is potentially a restraining force for your organization.

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma gi ng Cha nge N ee de d for aexchanges Ser v i ce - Or is ie nte d Ar chit e ct urissue e Finally, thenabrittleness of fixed record a maintenance

(see page 26). If the EDW is changed in

someerway, could create a need to change some or all the ETL programs. Because of the nature of fixed record Chapt 8 -it Change Wil l Happen exchanges, is always a chance notdur all ing ETLDevelopm programs Chapt er 9 - there Tips for Managing Changethat I ssues entwere updated and the wrong data is extracted. As a result, could failr es or Pa r t I I I the - Cr transform e a ti ng S er vand i ce -load O r ie portion nt ed Ar chi te ctu

the wrong portion of the record could be inappropriately

transformed loaded the EDW a vices corrupted EDW. This brittleness problem is being Chapt er 10 - and Ar chitect ur esinto at Each Stageresulting of Adoptiinonessentially for Web Ser addressed tagged record Chapt er 11 -byArthe chitect ur al Opt ionsstructure of XML (see page 26). The tagged structure significantly reduces that chance of corrupting theArdata in thee EDW and also presents the opportunity to reduce maintenance costs related to Chapt er 12 - Mi ddl e- Tier chitectur ETL er programs (see page So, Tr asipainrestraining force, the brittleness of fixed records will be reduced. Many of Chapt 13 - Rev isi ting the224). Business the Not- TooDistant Futur e

the restraining forces will be reduced because of efforts related to industry standards, XML, and Web Services as represented by the gray arrows in Figure 4.9. Chapt er 14 - Addi tional Specification Details Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt - Qui ck Reference Guide Use er of 15 an EDW can be coupled with the use of CORBA, DCOM, or Web Services as shown in Figure 4.10. I ndex List of Fi gures

Figure 4.10: Enterprise data warehouse co-existing with Web Services, CORBA, and DCOM.

Analysis of Application or Message Routing Often when integrating systems, there is also a need to propagate data among internal systems. For example, it is believable that if a customer’s address were changed in one internal system, you would want that change to appear as soon as possible in other internal systems. If each internal system were directly connected to the other internal systems shown at the bottom of Figure 2.1, you could have up to 15 interconnections. Some of those connections are shown in Figure 4.11. Of course, if you need

to propagate an update, such as a customer address, to multiple systems, you could end up in the situation shown inFigure 4.11. In this situation, every system potentially may need to communicate to other internal systems. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Figure 4.11: Some possible interconnections for internal systems. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt Architecturally, er 4 a good solution to this problem is to add a message router to internal systems as shown in Figure Techniques

4.12. Such routers have been around for some time. They are also known as application routers. This message - Growing I mpact of Web Serv ices router, however, would be based on Web Services. Also, a router could know which of the other internal systems Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er to 6 receive needs a certain type of updates. The individual internal systems would not need to know who receives Ar chitect ur es such updates. As a result, the number of interconnections is reduced as shown in Figure 4.12. Chapt er 5

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 4.12: Interconnections when using a message router. A message router usually needs to transform the data in some way to match the format of the data expected by the receiving system. Figure 4.13 shows examples of such transformations. Internal system A at the left is sending data in tagged XML format. Internal system B at the right expects a tagged XML format, but expects the tags to be different. For example, instead of the tag in system A, system B expects the data to be tagged with .The tags for phone and postal code data also are different. The message tag itself varies as well. At the left, the tag is and at the right, the tag is . Finally, System C expects a fixed record format. This fixed format is shown at the bottom of Figure 4.13. The message router needs to "know" how to make these transformations.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e ChaptFigure er 13 - 4.13: Rev isiTransformations ting the BusinessinTraipmessage in the Notrouter. Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

In some a tional message router is the flip side of EDW. Message routing disperses data where EDW collects data. Chapt er 14ways, - Addi Specification Details Nevertheless, the the two approaches are similar. The analysis for adopting a message router is shown Chapt er 15 - Qui ck analyses ReferenceofGuide inFigure 4.14. In this figure, a driving force is consistent enterprise-wide data in all applications. This means that customer data, for example, would be the same no matter what system used or managed that data. The impact on List of Fi gures operational systems is also lowered since any one system only needs to communicate with the message router and not all the other internal systems. I ndex

Figure 4.14: Force field analysis for adopting a message router. W eb Services an the d Ser vice- O rienthe t edsemantics Archit ector u re: T h e Saof vvy agand er 's the Gu id e Most of the restraining forces are issues with meaning theMan data standardization of ISBN:1558609067 data definitions that have been discussed earlier. Message routing, like EDW, needs to deal with semantic by Douglas K. Barr y translation and this shown asann a restraining force.(245 Over time, however, these restraining forces have become Moris gan Kaufm Publ ishers ?2003 pages) weaker as more Prov industry standards become available. ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Additional restraining forces include problems related and t he software engineer ing wor lds. to what data to route and the delay or latency of getting data updates distributed to various internal systems. The issues of what data to route and the delay of getting data Table ofdistributed Contents will Back Cov er Com m ents updates likely always remain a restraining force. Ta ble o f Con t en t s

Data quality issues similar to EDW can occur with message routing. Obviously, it can be potentially disastrous to route poor quality data. With message routing, however, you do not have the option of data cleansing used in For ewor d conjunction with ETL software. The quality of data needs to be improved at the source for existing data and at the I ntr oduction point of entry for new data. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1the- brittleness A BusinessofTrfixed ip in record the Not-exchanges Too- DistantisFutur e Finally, a maintenance issue.[9] If the format of the record going to the Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p message router is changed in some way, it could create a problem. Because of the nature of fixed record Chapt er 3 - there Ser viceOr ienteda Ar chi tectur es the andwrong Web Serv exchanges, is always chance that dataices is routed. This brittleness problem is being addressed by

the tagged record XML. The tagged significantly reduces For cesstructure Affecti ng of the Adoption of Web structure Ser v ices and Other I ntegr ation that chance of corrupting the data in the messageTechniques router and presents the opportunity to reduce maintenance costs related to message routing Chapt er 5 So, - Growing I mpact of force, Web Serv programs. as a restraining theices brittleness of fixed records will be reduced over time. Chapt er 4

Chapt er 6

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Web Services for packaged software provided by vendors will also reduce costs of development. The Ar adapters chitect ur es adapters Web with internally developed systems or packaged software. The arrow Chapt er 7 allow - St ar ti ng Services t o Adopt connections a Ser vi ce- Or iented Ar chitectur e depicting cost, however, Pa r t I I - Mathat na girestraining ng Cha nge force N ee deof d development for a Ser v i ce - Or ie nte d Ar chit eisct not ur e shown as gray since there are still other significant related to a message router. Nevertheless, many of the restraining forces will be Chapt er 8 development - Change Wil l costs Happen reduced of efforts related to industry standards, XML, and Web Services as represented by the gray Chapt er 9 because - Tips for Managing Change I ssues dur ing Developm ent arrows Pa r t I I I -inCrFigure e a ti ng4.14. S er v i ce - O r ie nt ed Ar chi te ctu r es Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

When a message router uses Web Services, it is depicted in this book as shown in Figure 4.15. Essentially, all the same data paths shown in Figures 4.11 and 4.12are retained. For the purposes of creating a readable figure, only Chapt er 12is shown - Mi ddl eTier Ar chitectur one line connecting to thee message router. This figure also shows two of the internal systems using an Chapt er 13 Rev isi ting the Business ip in the NotToo- systems Distant Futur adapter. This is meant to represent Tr that some internal mayeneed adapters that are not part of the internal Pa r t I V Com pe ndi um of Softw a r e Te chnolog y for S er v i ce Or i e nte Ar chit ectparty ur e s software vendors. system. These adapters could be written in-house or purchased dfrom third Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 4.15: A message router using Web Services. Just like EDW, message routing can also work with existing middleware solutions such as CORBA and DCOM. This is shown in Figure 4.16. The message router would have connections to Web Services that, in turn, would connect to CORBA and DCOM. As explained earlier, the message router would “know” what data should be routed and when, in some cases, the identifying tag might need to be changed for the receiver of the data.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Message withDistant Web Services, CORBA, and DCOM. ChaptFigure er 1 - 4.16: A Business Tr ip router in the used Not- TooFutur e Chapt er 2 [8]

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 4

-

For some organizations, this can be a certain time of day. For others who cannot stop their operational systems, it Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices may be necessary to provide small data extracts throughout the day. [9]

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

For an explanation of the brittleness of fixed formats, see page 26.

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser viceO rien t ed ArchitTogether ect u re: T h e Sain vvyaMan ag er 's Gu id e Putting AllWthe Integration Techniques Service-Oriented ISBN:1558609067 by Douglas K. Barr y Architecture Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Prov idesdata bothwarehousing, pr actical leader ship and ar chitectur ice together on how t oinpraepar e an or ganization to t ak e Middleware integration, and message routingalalladv work service-oriented architecture. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Figure 4.17 shows all these technologies as components of a service-oriented architecture. This is essentially a and t he software engineer ing wor lds. more detailed diagram of C. R.’s organization, which was described in Chapter 2. In Figure 2.1 at the bottom, you can seeofthe internal systems inerC. R.’s along with the online repository. The three internal systems at Table Contents Back Cov Comorganization m ents the left in Figure 2.1 relate to the three systems at the left in Figure 4.17; this time we add the detail of an adapter for Ta ble o f Con t en t s one of the internal systems. The three internal systems at the right in Figure 2.1 relate to the three systems at the Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide right in Figure 4.17; this time one system is CORBA based, a second uses Web Services directly, and a third is For ewor d DCOM-based. The online repository at the bottom, middle in Figure 2.1 is shown as a message router and a data I ntr oduction in Figure 4.17. Finally, Figure 4.17 shows that C. R.’s organization uses Web Services as the means of warehouse Pa r t I - Se r vi ce- O systems. r ie nt ed ArThis chi tedetail ctur e is Ovnot er v ishown ew interconnecting in Figure 2.1. Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I Figure I I - Cr e a 4.17: ti ng S Multiple er v i ce - components O r ie nt ed Ar chi oftesctu service-oriented r es

architecture

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

This chapter used force field analysis show?2003 how(245 various Mor gan Kaufm ann Publtoishers pages)forces drive or restrain the adoption of integration techniques. The Prov discussion showed that using Web Services reduces barriers to tintegration: ides both pr actical leader ship and ar chitectur al adv ice on how o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

There are far fewer restraining forcesing forwor adopting Web Services than for adopting enterprise-wide standard and t he software engineer lds. data element definitions or enterprisewide software. Table of Contents

Back Cov er

Com m ents

Within middleware, the restraining forces for adopting CORBA or DCOM are much stronger than restraining Ta ble o f Con t en t s forces for adopting Web Services. Also, adopting Web Services has more driving forces. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

For ewor d standardization efforts related to the use of XML by Web Services are assisting other integration The I ntr oduction techniques. This was shown in the weakening restraining forces for adopting an enterprise data warehouse Pa r t I and/or - Se r vi ceO r ie nt ed router. Ar chi te ctur e Ov er v i ew a message

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e Because themuse of Technology Web Services does not require abandoning CORBA or DCOM, there are no required Chapt er 2 - I nfor at ion Used in Thi s Tri p

changes to viceexisting CORBA DCOMbased systems. Chapt er 3 - Ser Or iented Ar chior tectur es and Web Serv icesThis further reduces barriers to the adoption of Web ServicesFor asces part of an integration strategy. Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation -

Chapt er 4

Techniques

The next chapter will cover how the impact of Web Services will grow over time. It uses one of the most significant - Growing I mpact of Web Serv ices integration efforts of all time, Electronic Data Interchange, to illustrate the growing impact of Web Services.

Chapt er 5

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby5: Growing Impact of Web Services Douglas K. Barr y

ISBN:1558609067

Mor gan ann Publto ishers ?2003 (245 pages) Using Web Services hasKaufm the potential impact software and systems at all levels. On a simple level, you can use idesaboth actical leader and arcustom chitecturportals. al adv iceOn onahow t o complex pr epar e an or ganization to t akcan e Web Services toProv create Webprsite feature orship to create more level, Web Services advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic serve as the basis for very sophisticated business-to-business software. As time goes on, it is entirely possible that and t he software engineer ing wor lds.

the use of Web Services will introduce revolutionary ways of using the Internet for commercial and personal uses. This chapter provides Back examples impact of Web Services in improving Web site and internal system Table of Contents Cov er of the Cominitial m ents connections. It then uses the example of Electronic Data Interchange (EDI) to show the possibilities that the growing Ta ble o f Con t en t s impact of Web Services can have on business-to-business connections. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

For ewor d A distinguishing characteristic of service-oriented architectures is their emphasis on the connections Note I ntr oductionbetween services using Web Services. These connections will eventually evolve into plug-compatible Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew services upon which we will build our

information technology systems. The assembly will be more like

Chapt er 1 making - A Business the desired Tr ip inconnections the Not- Too-among Distant AV Futur components e in a home entertainment system than mapping

an enterprise architecture. AV components, services could be assembled in multiple ways Chapt er 2 out - I nfor m at ion Technology UsedLike in Thi s Tri p oniented what Ar wechiwant toesget out of our And with a service-oriented architecture, you just Chapt er 3 depending - Ser vice- Or tectur and Web Servsystem. ices know thatAffecti something going toofbeWeb invented thatand either you always wished you had or something that you For ces ng theisAdoption Ser v ices Other I ntegr ation couldn’t Techniques have imagined. This might be the equivalent of a digital video recorder or a music file-sharing When it happens, youices want to have an approach that lets you take advantage of these new Chapt er 5 program. - Growing I mpact of Web Serv ideas and technologies will with a about service-oriented Ser viceOr iented Ar chithat tectur escome and Beliefs Enter pr ise architecture using Web Services. Chapt er 4

Chapt er 6

-

Ar chitect ur es

Initial Impact of Web Services

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8the- impact ChangeofWil l Happen Initially, Web Services on software and systems will be incremental. Web Services will be used to Chapt er 9 Tips for Managing I ssues ing Developm enhance existing software andChange systems. Thisdur is because Webent Services are about creating connections. So, Web Pa r t I I I - Cr e a ti S er v to i ceimprove - O r ie nt ed chi te ctu r es Services will bengused theArconnections

that a Web site uses, connections internal to organizations, or the

Chapt er 10 - used Ar chitect es at Each Stage of Adopti on for Web Ser vices connections by ur business-to-business software. Chapt er 11 - Ar chitect ur al Opt ions

Improving Web Site Connections

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V examples - Com pe ndi of Services Softw a r e include Te chnolog y for S er v as i ce -gadgets Or i e nte that d Ar chit es Early ofum Web such things canect beuradded

to a Web site or portal. Gadgets

include such things as Specification customizableDetails stock quotes, weather reports, and news feeds. Such gadgets have been Chapt er 14 - Addi tional available technology, Chapt er 15 using - Quiother ck Reference Guidebut Web Services essentially makes these gadgets better because they are more customizable. In fact, you can create your own sophisticated Web site for such things as selling books when, in I ndex reality, the actual bookstore is located on a different Web site. The content, shopping cart, and other bookstore List of Fi gures features come from the real bookstore Web site; the Web Services available from the bookstore Web site allow you customize your Web site to appear as if it is an actual bookstore Web site. Using gadgets in this way is illustrated in Figure 5.1. In this figure, each of the items that appear on the screen from the Web site came from a different Web site. Yet, the viewer is likely to be unaware of how these services are assembled on the Web site. Yes, it blurs where content comes from. But it also opens the opportunity for highly useful Web sites with sophisticated content from multiple sources.

Figure 5.1: Using external Web Services in a Website. W ebonServices Ser vice- O rien t ed Archit u re: Web T h e Sa vvy Man ag er 's Gu id epage 219) to Portals can expand this typean ofdincremental connectivity byect using Services adapters (see existing systems.byFor example, a medical records portal could include a patient’s medical history, scanned ISBN:1558609067 versions Douglas K. Barr y of paper documents, X-rays, and results. This is illustrated in Figure 5.2. The adapters allow Web Mor gan Kaufm annlaboratory Publ isherstest ?2003 (245 pages) Services connections withboth internally developed systems or packaged figure, systemstobelong Prov ides pr actical leader ship and ar chitectur al advsoftware. ice on howInt othis pr epar e anallorthe ganization t ak e advantageand of Web vices and before ser vice-Web or iented ar chitectur es, available. bri dging t he gapisbet ween thesystem data- centr ic to the same organization wereser developed Services became This why each t headapters software may engineer ing necessary wor lds. uses an adapter.and Such not be as systems are developed with Web Services in mind. In addition to using internal systems for a portal, it would also be possible to combine information from the Internet. Table of Contents Back Cov er Com m ents Perhaps for some patients, information on pollen count from a weather site on the Internet could be combined with Tathe ble medical o f Con t en ts records information on a customized portal. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details ChaptFigure er 15 - 5.2: Qui ck Using Reference Web Services Guide in medical portal. I ndex List of Fi gures

Improving Internal Connections Since nearly the beginning of the computer industry, developers have sought ways to share data among programs and systems. Early examples involved the sharing of punch cards and tapes. Now, we have generally progressed to more advanced ways to connect internal systems. Internal connections are often made using CORBA, DCOM, proprietary vendor solutions, or internally developed solutions. Web Services initially will be used to improve and standardize those internal connections. Using Web Services provides a standard connection between systems. The computer industry has virtually stampeded to incorporate Web Services into existing products and to create new products that make it easier to connect systems. This broad adoption makes Web Services the easiest standard to follow for connecting systems going forward. The use of Web Services can also improve the resilience of your internal connections. It is most likely that your current internal connections use some form of a fixed record layout for the messages sent between systems. The errors that can occur because of fixed record layouts was described in Chapter 3, starting on page 26. That description also showed how XML provides greater resilience in the face of simple programming errors. But you do not need to switch everything to Web Services all at once. Web Services can be adopted incrementally and used in conjunction with current means of connecting internal systems. In the last chapter, starting on page 43, the use of middleware as an integration technique was discussed. Figure 4.8 at the end of that chapter showed how Web Services could be used in conjunction with both CORBA and DCOM. This could apply to other proprietary vendor solutions and internally developed connections as well.

Improving Business-to-Business Connections

Web Services will enhance the existing specifications for business-to-business communication. For many larger organizations, this communication has been based on EDI specification. EDI is a good way to show how Web W eb Services an d Ser vice-connections. O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Services will enhance business-to-business by Douglas K. Barr y

ISBN:1558609067

Many of the issues to EDI to making any type of connection for the communication of data Morrelated gan Kaufm ann are Publsimilar ishers ?2003 (245 pages) between systemsProv or ides services. For this reason, the historical development of EDI covered some detail. This both pr actical leader ship and ar chitectur al adv ice on how will t o prbe epar e an orin ganization to t ak e will show how, eventually, Services simplify making connections make create serviceadvantage Web of Web ser viceswill and ser viceor iented ar chitectur and es, bri dgingit teasier he gaptobet ween a the data- centr ic and t he software engineer ing wor lds. oriented architecture. Table Contents Cov er Depending Com m entson how you determine its start, EDI began as early as the late 1960s. EDI hasofbeen around Back a long time. been TaThere ble o f have Con t en t s significant efforts on standards for EDI. Two standards efforts are in the INCITS (ANSI) ASC X12 committee and Nations/Electronic Data Interchange For Administration, Commerce, and Transport Web Ser vices andUnited Ser viceOr iented Ar chit ectur es—The Sav vy Manager 's Guide (UN/EDIFACT). There are additional standards efforts conducted by other organizations, often to meet the needs of For ewor d specific industries. Web Services can enhance these standards efforts by making EDI easier for organizations to I ntr oduction adopt. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew Chapt er 1 primarily - A Business Tr ip in the Not-have Too- Distant e Smaller organizations have felt little impact by EDI. Even To date, large organizations adoptedFutur EDI. Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p among the larger organizations, EDI is often used for simple transactions such as orders, invoices, and delivery Chapt er 3 There - SerisviceOr iented chi tectur es Web icessee later in this chapter. notices. much greaterArpotential forand EDI, as Serv we will For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques A Brief History of EDI Chapt er 5

- Growing I mpact of Web Serv ices

There have been many barriers to tectur the adoption of EDI.about WebEnter Services Ser viceOr iented Ar chi es and Beliefs pr ise will reduce those barriers, allowing EDI to be Chapt er 6 chitect ur es used by moreArorganizations and eventually in ways that are more extensive. A good way to understand the barriers Chapt 7 at- the St arhistory ti ng t o of Adopt Serwe vi ceOr iented Ar chitectur e is to er look EDI.aAs move through the history, the barriers will be discussed and towards the end of Pa r t I discussion, I - Ma na gi ngwe Cha nge N ee de dWeb for aServices Ser v i ce - Or nte d Ar chit e this will see why willieallow EDI toe ct beurused by more organizations. Chapt er 8

- Change Wil l Happen Figure theManaging initial form of EDII ssues data transmission. Using Chapt er 5.3 9 shows - Tips for Change dur ing Developm ent EDI involved the following steps: Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 5.3: Initial form of EDI data transmission. 1. Creating an export file from the sending system. 2. Running the export file through EDI translation software to create a transmission file. The EDI translation software might have been purchased software or software developed in-house. 3. Sending the transmission file to the receiving organization. The transmission file uses a fixed record format since that was the standard at the time. The network at the time was most likely a proprietary network. 4. Running the transmission file through different EDI translation software in the receiving organization to create an import file compatible with the receiving system. If a sending organization was participating with multiple receiving organizations, all aspects of the transmission process had to be worked out for every receiving organization. More organizations resulted in more complexity to keep the details of all connections synchronized. Relatively quickly, the need was seen to improve on this form of EDI data transmission. Value-Added Networks (VANs) were developed to simplify complexity of multiple data connections. Figure 5.4 illustrates EDI using VANs.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

EDI Or using Value-Added Networks ChaptFigure er 3 - 5.4: Ser viceiented Ar chi tectur es and Web(VANs). Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er provide 4 VANs functions such as message transmission, tracking, and in most cases, security. Using a VAN means Techniques

that er an5organization with Chapt - Growingneeds I mpacttoofonly Webdeal Serv icesthe VAN instead of connecting to every receiving organization. As such, the VAN acts as a broker, which simplifies using EDI for both sending and receiving organizations. As Figure 5.4

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6the-VANs usually used a proprietary network and continued to use fixed record formats since that was still shows, Ar chitect ur es

the standard. translation tochitectur be needed at both the sending and receiving organizations. Chapt er 7 - StEDI ar ti ng t o Adopt software a Ser vi ce-continued Or iented Ar e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

One major barrier to widespread use of VANs was the cost. EDI with VANs could cost in the vicinity of $100,000 or - Change Wil l Happen more per year. This was probably the main reason smaller organizations did not participate in EDI.

Chapt er 8 Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te EDI ctu r es CORBA and DCOM entered into use with in

an effort to reduce the cost of EDI and to further standardize

Chapt er 10 transmission. - Ar chitect ur es at Each Stage of DCOM Adopti onprovide for Webthe Ser vicesbrokering capabilities provided by VANs. In message Both CORBA and basic Chapt 11 - the Ar chitect al Opt ions someercase, VANsuradopted either CORBA or DCOM. At first, however, CORBA and DCOM were incompatible.

In fact, early versions of Ar the CORBA Chapt er 12 - Mi ddl e- Tier chitectur e specification did not allow for interoperability among CORBA vendors. With time,erhowever, became interoperable andTooCORBA/ Chapt 13 - RevCORBA isi ting the Business Tr ip in the NotDistantDCOM Futur ebridges became available to allow CORBA and DCOM bepe interoperable. Pa r t I V - to Com ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

Figure 5.5 shows the initial use of CORBA or DCOM. Using CORBA and DCOM for EDI at first involved a proprietary network and continued use of fixed record formats. The use of CORBA and DCOM simplified the I ndex development of EDI translation software because there was one of two standard transmission techniques. This List of Fi gures allowed development of more packaged EDI translation software. As a result, the cost of entry for using EDI went down, but it was still out of reach for smaller companies. Chapt er 15 - Qui ck Reference Guide

Figure 5.5: EDI initial use of CORBA or DCOM. One continuing problem with EDI was the use of fixed record formats. As shown on page 26 in Chapter 3, fixed record formats can create all sorts of processing problems which, in turn, increase maintenance costs, thereby driving up the costs of using EDI. XML was seen as a way to address this problem. The tagged structure of XML meant that the problem of sending the right data in the wrong record location—or sending the wrong data in the right

record location—could be reduced significantly. This reduced errors and maintenance costs. Figure 5.6 showsWEDI use of XML or DCOM. The connectivity this eb Services an dwith SerCORBA vice- O rien t ed Archit ectrise u re:ofTInternet h e Sa vvy Man ag er 'sbyGu id etime meant that proprietary networks could be in some cases. Adapters for CORBA or DCOM could be used toISBN:1558609067 transform by Douglas K. replaced Barr y the XML tagged Mor record intoPubl theishers fixed ?2003 record formats gan formats Kaufm ann (245 pages) that internal EDI translations software would need. This effectively changed of possible because of on differing record formats fromtoone Provthe idesproblem both pr actical leaderprocessing ship and arerrors chitectur al adv ice how t ofixed pr epar e an or ganization t ak e between organizations to one that ser is internal to ser anviceorganization. reason XML the the possibility of ic advantage of Web vices and or iented arThe chitectur es, isbrithat dging t heminimizes gap bet ween data- centr t he being software engineer ing those processingand errors propagated outwor to lds. EDI partner organizations. The resilience of XML’s tagged record format was explained in Chapter 3, starting on page 26. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Figure 5.6: EDI use of XML with CORBA or DCOM.

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I Vshortly - Com pe ndi XML um ofcame Softwon a r ethe Te chnolog y for S erbeing v i ce - Or i e nte d Ar chit ur estandards, s Very after scene and was considered forect EDI

Web Services also showed

Chapt er 14 - Addi Specification Details up. Because Webtional Services also used XML, the shifting of EDI standards to Web Services was an obvious Chapt er 15 Qui ck Reference Guide development. The initial immaturity of the Web Services specification restrained adoption, however. EDI needs both I ndex security and a transaction capability that were not in the initial Web Services specification. Nevertheless, the List of Fi gures electronic business using eXtensible Markup Language (ebXML) initiative has been established by the United

Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and OASIS [1]to research, develop, and pro mote global standards for the use of XML to facilitate the exchange of electronic business data. A major goal for ebXML is to produce standards that serve the same or similar purpose as EDI, including support for emerging industry-specific XML vocabularies.[2] Figure 5.7 shows EDI use of Web Services. At first glance it looks quite similar to the EDI use of CORBA or DCOM inFigure 5.6. One difference, however, is the adapter that appears to the right in Figure 5.7. This is a Web Services adapter used by the service that appears below the adapter in Figure 5.7. This Web Services adapter is designed to work with this service. As a result, the EDI translation software can be eliminated. This further reduces maintenance costs. The use of Web Services also reduces the cost of entry into EDI for smaller organizations.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Figure 5.7: EDI use of Web Services.

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Of course, the world cannot change overnight. EDI will be in transition for a while. This is primarily because of - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e existing installations of EDI that are presently working fine for many organizations. So, at first, industry-wide use of Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e EDI will use all of the transmission and brokering techniques described so far. Figure 5.8 depicts how EDI will work Chapt er 8 - Change Wil l Happen in the transition period. Eventually, however, the nearly universal use of Web Services and resulting costs saving will Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent drive EDI to a simpler model that will end up looking much like Figure 5.7. Chapt er 7

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 5.8: EDI in transition.

Analysis of EDI W eb Services d Ser vicerien t ed Archit ect u re: h e Sa vvy Man ag er 's Gu id ethe adoption of In Chapter 4, force field analysisanwas used toOcharacterize driving andTrestraining forces affecting ISBN:1558609067 by Douglas K. Barr y various types of integration techniques. This analysis can also be applied to EDI as well. Figure 5.9 shows the major Mor gan Kaufm ann Publ ishers ?2003 (245 pages) driving and restraining forces affecting the adoption of EDI. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Figure 5.9: Force field analysis for adopting Electronic Data Interchange(EDI).

Chapt er 11 - Ar chitect ur al Opt ions

Chapt 12 - Mi ddl e- Tier Ar chitectur The er increasing use of EDI, productesupport of EDI, industry-standard definitions for EDI, and the availability of Chapt er 13 Rev isiare tingall the Business Tr ipfor in the the adoption Not- Too- Distant e training and- tools driving forces of EDI.Futur For smaller organizations, often one of the strongest Pa r t I V - forces Com peis ndi umrequirement of Softw a r e to Teadopt chnolog y for S er v i ce Or i e nte dinArbusiness chit ect ur e s driving the EDI in order to- engage with

larger organizations.

Chapt er 14 - Addi tional Specification Details

XMLerand address many of the restraining forces related to EDI. These include: Chapt 15 Web - QuiServices ck Reference Guide I ndex

Different semantics in data sources

List of Fi gures

EDI or semantic translation Brittleness of fixed record exchanges (see page 26) Lack of industry-standard definitions Web Services will also address the issue of proprietary networks for EDI. Proprietary networks can go away with Web Services since Web Services use HTTP (see page 225), which is virtually available everywhere because of the growth of the Internet. Assuming widespread adoption of Web Services and the attendant service-oriented architectures, the lack of trading partners will be reduced as a restraining force. Finally, the perceived complexity of EDI will be reduced by the perceived simplicity of Web Services. When you look at Figure 5.9, the expansion and use of Web Services significantly reduces the strength of the restraining forces. These weakened restraining forces are shown in gray in the figure. Eventually, you are left with the impact EDI can have on operational systems, but this should be expected if up-to-the-moment processing is needed. [1] More organizations working on standards related to Web Services can be found on page 191. [2]

A sampling of industry-specific XML vocabularies can be found starting on page 212.

W ebUse Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Evolutionary ISBN:1558609067

by Douglas K. Barr y

Web Services and architectures seen as evolution in process. Changes to our systems will Morservice-oriented gan Kaufm ann Publ ishers ?2003can (245be pages) start out incrementally and grow as people gain experience and standards asprwell. Like any evolutionary Prov ides both pr actical leader ship and ar chitectur al adv ice onevolve how t o epar e an or ganization to t ak e process, there will also be competing forces. this case, therearwill be competing products, anddataways of ic advantage of Web ser vices andInser viceor iented chitectur es, bri dging t he gapstandards, bet ween the centr andto t he software engineer ing wor packaging services name a few. It will likely belds. messy at times. Nevertheless, the way to win in this messy process is to wade in and participate. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Creating a Web site feature or ann to aPubl custom portal how most organizations will get started with Web Services. Mor gan Kaufm ishers ?2003is (245 pages) Using Web Services for businesstobusiness transactions is also rapidly many organizations. Prov ides both pr actical leader ship and ar chitectur al adv ice ongaining how t oground pr epar einan or ganization to t ak e This chapter used the history of EDI representative ofiented the systems integration and tdata exchange anycentr ic advantage of Web seras vices and ser vice- or ar chitectur es, bri dging he gap bet weenissues the datasoftware engineer ing wor lds. have gone through stages of internal integration and data organization hasand hadt he to address. Many organizations exchange in much the same manner as described for EDI. But just as we have seen Web Services reducing the Table of Contents Back Cov er Com m ents complexity and increasing the packaged system solutions for EDI, various forms of enterprise architectures will Tabenefit ble o f Con t ensame ts in the way. The next chapter looks at service-oriented architectures and enterprise architectures. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby6: Service-Oriented Architectures and Beliefs ISBN:1558609067 Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) about Enterprise Architectures

Overview

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

of Contents architecture Back Cov er Com m ents ATable service-oriented can be part of a wider enterprise architecture. In this chapter, we will look at beliefs about enterprise architectures and how a service-oriented architecture helps resolve some issues related to those Ta ble o f Con t en t s beliefs. Beliefs about enterprise architectures have often been the reason Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guidethat many attempts at implementing such enterprise architectures have fallen short of expectations. Some common beliefs are reviewed. For ewor d I ntr oduction

This chapter does not define a new way of developing enterprise architectures. It shows how aspects of a serviceoriented architecture augment enterprise architecture methodologies and frameworks. An important point is how, Chapt er an 1 enterprise - A Business Tr ip in theframework, Not- Too- Distant Futur e within architectural certain beliefs can trip you up and how a service-oriented architecture Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p can mitigate the effect of those beliefs. At the end of this chapter, there is a summary of the advantages of using Chapt er 3 - Ser viceOr iented Ar chipart tectur Web Serv ices service-oriented architectures as of es anand enterprise architecture. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 4

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Techniques Note “Function follows form,” Chapt er 5 Said - Growing Louis Sullivan I mpact ofone Web warm Serv ices Evening in Or Chicago drinking beer. Ser viceiented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 chitect ur es HisArwife said, “Dear, Chapt er 7 I'm - Stsure ar ti ng t owhat Adoptyou a Ser vi ce- Or iented Ar chitectur e that meant Pa r t I I - MaIs nathat gi ngform Cha nge N ee represent de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e should function that should be followed.” Chapt er 8 Function. - ChangeSo Wilit's l Happen swallowed Chapt er 9 Sullivan - Tips for Managing Change I ssues dur ing Developm ent looked away Pa r t I I I - CrAnd e a ti ng S er v idimly ce - O rfar ie nt ed Ar chi te ctu r es Chapt er 10 And - Arsaid, chitect“Okay, ur es at Each Stage of Adopti on for Web Ser vices follows function, Chapt er 11 Form - Ar chitect ur al Opt ionsthen.” He said it again, Chapt er 12 - Mi ddl e- Tier Ar chitectur e spark Chapt er 13 A- three-word Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Of modern archPa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Itectural brilliance Chapt er 14 - Addi tional Specification Details That would dazzle millions. Chapt er 15 - Qui ck Reference Guide “Think I should write it down?” I ndex He asked with a frown. List of Fi gures “Oh yes,” she said, “and here's a pencil.” He did and soon was influential. [1] [1] Poem: “Mrs. Sullivan,” by Garrison Keillor ( We are still married, pg. 231, Viking Penguin, Inc.,1989. Used with Permission).

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Form Follows Function ISBN:1558609067

by Douglas K. Barr y

“Form ever follows is ann the building architectural dictum credited to Louis Sullivan, the famous architect of the Morfunction” gan Kaufm Publ ishers ?2003 (245 pages) Chicago School Prov of Architecture. This phrase, which has been used forice building applies equally to well ides both pr actical leader ship and ar chitectur al adv on howarchitecture, t o pr epar e an or ganization t akto e enterprise architecture. In this case, “form” is the enterprise architecture. “function” is bet theween needs the centr ic advantage of Web serthe vices and ser viceor iented ar chitectur es, The bri dging t he gap theofdataand t he software engineer ing wor lds. We will see that this dictum applies equally well to using Web organizations that should be met by this architecture. Services and a service-oriented architecture as part of an enterprise software architecture. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien Archit u re:Enterprise T h e Sa vvy Man ag er 's Gu id e Service-Oriented Architecture ast ed Part ofectan Architecture ISBN:1558609067

by Douglas K. Barr y

A service-oriented is aPubl partishers of an?2003 enterprise architecture and can be viewed as a “sub-architecture” of Morarchitecture gan Kaufm ann (245 pages) an enterprise architecture. Service-oriented architectures existedalbefore advent ofepar Web Services. Technologies Prov ides both pr actical leader ship and ar chitectur adv icethe on how t o pr e an or ganization to t ak e such as CORBAadvantage and DCOM the opportunity oriented architectures. Some of afforded Web ser vices and ser vice-to orcreate iented service ar chitectur es, bri dging t he gap bet weenorganizations the data- centr ic and town he software engineer ing wor lds. capability that afforded the opportunity to create servicealso developed their connection and messaging oriented architectures. Table of Contents

Back Cov er

Com m ents

TaYet, ble ousing f ConWeb t en t sServices with a service-oriented architecture differs from many preceding efforts at developing a

service-oriented architecture. A service-oriented architecture using 'sWeb Services provides a degree of flexibility not Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager Guide afforded For ewor d with previous attempts using CORBA and DCOM, for example. This flexibility makes service-oriented

architectures more responsive to organizational needs when trying to cope with the general chaos of business today. Being able to cope well with business chaos is an important “ function” of enterprise architectures. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew I ntr oduction

Chapt 1 - A Business Tr ip in the Not- TooFutur e One er difference with using Web Services forDistant a service-oriented architecture is that there is an unprecedented use of Chapt er 2 I nfor m at ion Technology Used in Thi s Tri Web Services connections in software products andp technologies. Returning to the AV system analogy, using Web Chapt er 3 is- the Serequivalent vice- Or iented Ar chi es and WebRCA Serv connectors. ices Services to all AVtectur products using Continuing the analogy, using CORBA or For ces Affecti ngcomponents the Adoptionused of Web Ser v ices and Othersome I ntegrused ationRCA connectors, and some used DCOM were as if some AV coaxial connectors, Chapt er 4 Techniques both. Actually, for the analogy to be complete, you would have to say many also used neither coaxial nor RCA Chapt er 5 - This Growing I mpact of Webwere Servmany ices software products that simply did not work with CORBA and DCOM. It connectors. is because there Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise is difficult Chapt er 6 to - build a comprehensive service-oriented architecture if there is spotty adherence to the way services can Ar chitect ur es

be connected. Using Web Services clears the way to build such a comprehensive service-oriented architecture.

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I using - Ma naWeb gi ng Services Cha nge Nmakes ee de d for a Sereasier v i ce - Orto ie adhere nte d Ar chit e ct ur e Also, it much to the “form

follows function” dictum. To that end,

Chapt designing er 8 service-oriented - Change Wil l Happen architectures will eventually be more like determining how to assemble an AV system that

will also some equipment. For example, if I wanted Chapt er 9 have - Tips for special Managing Change I ssues dur ing Developm entto upgrade my AV system so that it would be as flexible itacould would personal Pa r t I I I -as Cr e ti ng Sbe, er v iIce - O r ie add nt edaAr chi te ctu rcomputer es

(PC) to the system. Figure 6.1 shows such a system.

Assuming hasurenough diskStage space, I would store Chapt er 10 the - ArPC chitect es at Each of Adopti onbe forable WebtoSer vicesmusic from all my CDs, cassettes, and my older LPs.erIt 11 could also store music I obtained from the Internet via the telephone or high-speed connection. I could then Chapt - Ar chitect ur al Opt ions buy or software that would allow me to create various music programs that I could then route through the Chapt er build 12 - some Mi ddl eTier Ar chitectur e receiver. software might also provide ways toTooclassify myFutur music, Chapt er 13 That - Rev isi ting the Business Tr ip in the NotDistant e or to even share some of the music with others thepeInternet. I could ischit primarily Pa r t I V -on Com ndi um ofUsing Softw a a rPC, e Tewhat chnolog y for do S erwith v i ce -that Or i emusic nte d Ar ect ur e slimited to

my imagination. Nevertheless, I could still add other components such as a Digital Video Recorder or upgrade my receiver without Chapt er 14 - Addi tional Specification Details affecting existing components or my PC. Many medium-sized and larger organizations can create an analogous Chapt er 15 - Qui ck Reference Guide architecture for their internal systems and services. They will buy and assemble most of their services, and add I ndex value by developing a service or some part of a service that gives their organization a competitive edge. List of Fi gures

Figure 6.1: Audio-visual components with a personal computer. Just having Web Services for making connections, however, does not guarantee your organization will have a functional service-oriented architecture. There are design methods that should be used.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id eand Service-Oriented Architectures with Architectural Frameworks ISBN:1558609067 by Douglas K. Barr y Methodologies Mor gan Kaufm ann Publ ishers ?2003 (245 pages) [2] eSuch ides both prand actical leader shipfor and ar chitecturenterprise al adv ice on how t o pr epar an ormethodologies ganization to t ak e There are many Prov methodologies frameworks developing architectures. and advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic frameworks usually describe an enterprise architecture in views, abstractions, or models. A common high-level and t he software engineer ing wor lds. abstraction is a conceptual business model where business processes and work- flows are described. [3] A service orTable operational model isBack placed belowCom thembusiness model. This is where service functions or operations are defined of Contents Cov er ents to support the business model. Below the service or operational model is a system model that has logical data Ta ble o f Con t en t s models and application architectures to support the service functions or operations. Some frameworks have Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide additional models, but the important idea is that there are these layers or abstractions that aid in understanding an For ewor d enterprise architecture. Frameworks are an excellent way of taking a holistic view of an enterprise architecture.

I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te add ctur ecapabilities Ov er v i ew Service-oriented architectures

to layers or abstract models used in frameworks and methodologies.

Chapt In Part er 1III, an - Aarchitecture Business Tr ipwill in be thepresented Not- Too- Distant that supports Futur e the use of these abstract models. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

There are, however, common beliefs that can cause problems with the execution and understanding of any Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices methodology. We will examine some of those beliefs. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation [2] Probably Chapt er 4 - one of the best-known frameworks is the Zachman Framework for Enterprise Architecture. For more Techniques information the Zachman Chapt er 5 - on Growing I mpact framework, of Web Serv see ices www.zifa.com. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise [3] Some Chapt er 6 standards inurthis Ar chitect es area include the Business Process Execution Language for Web Services (BPEL4WS),

Business Process Modeling Language (BPML), Business Process Query Language (BPQL), and Business Process - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e Specification Schema (BPSS). See pages 220–221 for more information. Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Chapt er 7 Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Services an d Ser vice- O rien tto ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Beliefs thatW eb Can Cause Function Follow Form ISBN:1558609067

by Douglas K. Barr y

As in any humanMor endeavor, it is ourPubl beliefs that often gan Kaufm ann ishers ?2003 (245shape pages) the outcome. In the case of enterprise architecture, there are some common beliefs that have caused the implementation short of expectations. Prov ides both pr actical leader ship and ar chitectur al adv of icethe on architecture how t o pr epartoe fall an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Unfortunately, inand many these beliefsing can distort t hecases software engineer wor lds. an enterprise architecture to the point where “function follows form.” In other words, the form (or enterprise architecture) dictates what an information technology (IT) group can or Table of er Com m entsof the organization. cannot doContents to respond Back to theCov functional needs Ta ble o f Con t en t s

The following sections discuss some erroneous beliefs about enterprise architectures. These are provided so that you can be aware of the misconceptions when considering an enterprise architecture. Also, each section discusses For ewor d the ways in which a service-oriented architecture can offset the effect of the misconceptions. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Building Analogies - A Architecture Business Tr ip in the NotToo- Distant Futur e

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Belief

Creating an enterprise architecture is a lot like creating an architecture for a building.

For ces Affecti ng the Adoption Web Ser v ices and OtherofI ntegr ationarchitecture, it might seem odd that I Because already invoked the “formoffollows function” dictum building Chapt er 4 I have Techniques would see a problem with the belief that creating an enterprise architecture is like creating the architecture for a Chapt er 5 building.

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

chitect es is that it is taken far too literally. People would like to create the equivalent of a blueprint The problemAr with thisurbelief Chapt 7 - St ar ti ng t o AdoptA abuilding Ser vi ce-architecture Or iented Ar chitectur e for aerbuilding’s architecture. is a detailed endeavor to create a structure that is meant to Pa r t I I -for Mamany na gi ng Cha nge de d for Ser v i ce - Or ie nte d Ar chitare e ct ur e stand years. As Na ee result, thea drawings for a building tremendously detailed. Likewise, people would like Chapt to create er 8 similarly - Change detailed Wil l Happen “drawings” for enterprise architectures.

Well, I am positioned totetell Pa r t I I Iperhaps - Cr e a ti ng S eruniquely v i ce - O r ie nt ed Ar chi ctu you r es

that enterprise and building architectures simply cannot be compared. I have done both. As an undergraduate student, I studied building architecture and now, many years Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices later, I have practiced as an enterprise architect. Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 -architectures Mi ddl e- Tier Ar chitectur Enterprise need to bee far more flexible than building architectures. For a building architecture to be as Chapt er 13 - Rev isi ting the Business Tr ip in need the NotTooDistant Futur e the floor plan of any floor, change where the flexible as an enterprise architecture, you to be able to change Pa r t I V - Com peelevators ndi um of Softw a r eand Te chnolog for S erfloors, v i ce - Orand i e nte d Ar chit ect ur es stairwells and go, add removey whole expand and shrink

the footprint of the building. So, if

Chapt er about 14 - Addi tionalrigid Specification we go creating structuresDetails for our enterprise architectures, we end up forcing our functions to fit that form. Chapt er rigid 15 - structures Qui ck Reference Guide These can take several forms. I ndex

One rigid structure might be to create separate systems that use a “foundation” of a shared database. The List of such Fi gures

shared data model in such an enterprise architecture is often compared to the wiring or plumbing diagram in building architecture. Figure 6.2 depicts such a shared database architecture. In this figure, several different systems have direct access to a single database. The foundation of the database service is an agreed upon set of data elements to be used by all systems. What happens if an organization needs to make a significant change to its Customer Relationship Management (CRM) efforts? What if the change is too significant for the internal IT group to make right away? Furthermore, what if there is a commercial CRM package that supports the organization’s requirements? Deciding to buy the package causes the CRM data to be divorced from the rest of the database. This lack of data integration may hamper the decision making process of the organization. Deciding not to buy the package means the organization needs to limp along until the internal IT group can make the changes to the CRM system. Any delays may mean the organization lost an important opportunity in the marketplace. In this example, the form (or shared database enterprise architecture) dictates what an IT group can or cannot do to respond to the functional needs of the organization.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I Figure - Se r vi ceie nt ed Ar chi te cturarchitecture. e Ov er v i ew 6.2:O rShared database

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e Of course, enterprise architecture needs a sdesign Chapt er 2 -any I nfor m at ion Technology Used in Thi Tri p of some sort. It is important, however, to not let the analogy of

building restrict you might lookWeb at this design. Obviously, the analogy that I think works best is one Chapt er 3 architecture - Ser vice- Or ientedhow Ar chi tectur es and Serv ices of an AV system. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation -

Chapt er 4

Techniques One er aspect a service-oriented architecture Chapt 5 - of Growing I mpact of Web Serv ices is that each service must manage its own data. Figure 6.3 illustrates

this. Compare this figure to the previous one. Note that there is a disk underneath each service representing the

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 data er managed by theurservice. In addressing the example of replacing a CRM system described earlier, this Ar chitect es

architecture easier anOrorganization to respond to changing CRM needs. All the services in Figure Chapt er 7 - makes St ar ti ngit tmuch o Adopt a Serfor vi ceiented Ar chitectur e 6.3 notnawired thed underlying data Nevertheless, Pa r t Iare I - Ma gi ng together Cha nge Nby ee de for a Ser v i ce - Or model. ie nte d Ar chit e ct ur e

issues in how these services exchange data

neederto8 be -addressed. will be covered further in PartIII. Chapt Change WilThat l Happen Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 6.3: Each service manages its own data in a service-oriented architecture.

Strategic Information and Day-to-Day Operations Alignment Belief

It is important that an enterprise architecture be aligned with both strategic information requirements and day-to-day operational data requirements.

I have found this statement in multiple enterprise architecture plans. It sounds good. In fact, who could argue with it? Nevertheless, the effect on the development of an enterprise architecture can be disastrous. Anyone given this goal will obviously need to determine the strategic information requirements and the day-to-day operational data requirements. It is easy to get caught in “analysis paralysis” when doing this. I know. I have been there. Besides all the requirements and associated data needs that must be collected, this opens the opportunity for people to complicate matters by resisting the change in subtle ways. (We will cover that resistance in Part II of this book.) Between the mountain of analysis and the all-too-common mountain of resistance, nothing really happens. In this example, the form (or the analysis and resistance) holds back and sometimes dictates what an IT group can or cannot do to respond to the functional needs of the organization. Of course, you need to take into account the strategic information requirements and the day-to-day operational data requirements in an enterprise architecture. But frankly, you don’t need to get every single one of them documented. In fact, it might surprise you to find out that often existing software packages and services do already take into account most of these requirements. Strategic information requirements and operational data requirements do not vary that much among organizations. Nevertheless, where there is a special need in your organization, a service-

oriented architecture allows you to isolate the software development needed for that special need from the more common services used by many organizations. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Data Conflict Resolution Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Belief

ISBN:1558609067

ides pr actical leader ship and ar chitectur al contain adv ice on how t o pr epar e an or ganization to t ak e TheProv data in both an enterprise architecture model cannot homonyms, synonyms, or other data advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic definition conflicts. and t he software engineer ing wor lds.

This belief is often couched in terms of people Table of Contents Back Cov er Com m ents throughout an organization using terms such as “customer” or “account,” but when analyzed it becomes apparent that the terms “customer” and “account” mean different things to Tadifferent ble o f Con t en of t s the organization. parts Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Ofewor course, most people realize that a single interpretation of “customer” or “account” will not work because there are For d very good reasons for the different meanings in different parts of the organization. What some people are now I ntr oduction advocating, however, tochi resolve any Pa r t I - Se r vi ceO r ie nt edisAr te ctur e Ov conflicting er v i ew

meanings so that the enterprise architecture not only provides the

organization’s definition of customer, but also reflects the various definitions understood and used by every Chapt er 1 - A overall Business Tr ip in the Not- Too- Distant Futur e enterprise it is advocated Chapt er 2 element. - I nfor m atUsually, ion Technology Used in that Thi s there Tri p should be links between every enterprise architecture data

element every application data element thatWeb implements Chapt er 3 and - Ser viceOr iented Ar chi tectur es and Serv ices it. This is hard to argue against, but like the last belief, it results in “analysis paralysis” for many of the same reasons: a mountain of analysis and a possible mountain of

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 - As in the previous example, the form (or the analysis and resistance) holds back and sometimes dictates resistance. Techniques

whateran5 IT -group can Ior cannot do toServ respond Chapt Growing mpact of Web ices to the functional needs of the organization. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt Evenerif 6the-initial analysis was completed, what happens as soon as the organization acquires packaged software Ar chitect ur es

that uses a new definition of customer or account? Are all the links between every enterprise architecture data - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e element in the newly acquired software then linked with the master documentation? Very few organizations will Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e succeed in keeping this documentation up to date. Over time, it will be just as if no one had done the analysis in the Chapt er 8 - Change Wil l Happen first place. Documentation is important, but what is more important is realizing what the correct level of Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent documentation is for your organization. Chapt er 7

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Aritchitect ur es at to Each of deal Adopti on data for Web Ser vices Nevertheless, is important be Stage able to with definition conflicts. They naturally exist. The Universal Chapt er 11 Language - Ar chitecteffort ur al Opt ions Business described on page 213 is one approach that appears promising as part of Web Services. Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services d Ser viceO rien t ed ArchitArchitectural ect u re: T h e Sa vvy Man ag er 's Gu id e Common Issues withanMany Enterprise Efforts ISBN:1558609067

by Douglas K. Barr y

The overriding issue withKaufm mostann attempts at an?2003 enterprise architecture is an inherent lack of flexibility. Today’s Mor gan Publ ishers (245 pages) organizations need flexibility more than anything else. They needaltoadv beice flexible to tquickly move into new markets, Prov ides both pr actical leader ship and ar chitectur on how o pr epar e an or ganization to t ak e develop completely new marketing campaigns, change how they withes,their customers, organizations, advantage of Web ser vices and ser vice- or iented ar work chitectur bri dging t he gapacquire bet ween the data- centr ic and t he softwareand engineer wor lds. divest parts of the organization, so on.ingSome attempts at enterprise architectures have, as an unfortunate and unintended consequence, reduced that flexibility. This section will cover such issues as analysis paralysis, overTable of Contents Back Cov er Com m ents standardization, and rigidity in data definition. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Analysis Paralysis

For ewor d

I ntr Asoduction mentioned previously, analysis paralysis often means that enterprise architectural effort really does not get off the Pa r t I - SeIfr vi ce-analysis O r ie nt edisArcompleted, chi te ctur e Ov er v i ew ground. the it often ends

up tremendously complicated and is not used. Nevertheless,

Chapt er 1 - are A Business ip insoftware the Not- TooDistantare Futur e applications still builtTrand packages acquired. The result all too often, is an inflexible “architecture” Chapt that er does 2 not - I nfor serve m atthe ionorganization. Technology Used in Thi s Tri p Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Over-Standardization Techniques

Chapt er 4

Chapt 5 organization - Growing I reaches mpact of aWeb Servsize, ices there is simply a limit to the level of standardization that is possible. Onceeran certain Ser viceOr iented Ar chi tectur es and Beliefs about Enter prtoo ise many standards will either cause a lack of Different of the organizations have different needs. Imposing Chapt er 6 parts Ar chitect ur es

needed application development or will effectively cause a rebellion resulting in “stovepipe” development for

Chapt er 7 parts - St arofti ng Adopt a Serwhich vi ce- Orisiented Ar chitectur e particular thet oorganization effectively no integration. Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Rigidity- Tips in Data Definition for Managing Change I ssues dur ing Developm ent

Chapt er 9

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Making data definitions too rigid is one form of over-standardization. Frankly, most organizations are going to acquire more software than build software. This means accepting the data definitions in that software and coming up with a Chapt er 11 Ar work chitectwith ur althose Opt ions flexible way- to definitions. Requiring any specific data definitions in software packages essentially Chapt er 12 Mi ddl eTier Ar chitectur e that might have otherwise been helpful to the organization. precludes many software packages Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Architectures Ser vice- O rien t ed Archit ectWatered u re: T h e Sa vvy Man ag er 's Gu id e SometimesW Enterprise Get Down ISBN:1558609067

by Douglas K. Barr y

Sometimes, just Mor to be to say organization has an enterprise architecture, the needs of the architecture ganable Kaufm ann that Publan ishers ?2003 (245 pages) get watered down. Here is a set of statements that were shared al among documents Prov ides both pr actical leader ship and ar chitectur adv iceseveral on howenterprise t o pr epar earchitecture an or ganization to t ak e I have seen. Theyadvantage express the goalsser ofvices an enterprise architecture: of Web and ser viceor iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Adopt industry standards. Table of Contents

Back Cov er

Com m ents

Use commercial off-the-shelf software as much as possible.

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav Manager 's Guide Encapsulate legacy applications with interfaces thatvymeet industry standards. For ewor d

Use a data independent layer between applications and data to hide the structure of the underlying data. I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Again, who can argue with the statements? But there is no meat. For example, which industry standards or standard - A Business Tr ip in the Not- Too- Distant Futur e interfaces? An architecture needs to be specific but not rigid.

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice-Architecture O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Goals of a WService-Oriented Using Web Services ISBN:1558609067

by Douglas K. Barr y

The watered-down can be more ?2003 specific Morgoals gan Kaufm annmade Publ ishers (245when pages)considering a service-oriented architecture using Web Services. A specific, but not rigid set of goals could include: Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Adopt industry standards. These standards and t he software engineer ing wor lds.include Web Services and industry standard element definitions for XML. (The industry group specifying the standard element definitions could also be identified. [4]) Table of Contents

Back Cov er

Com m ents

Use commercial off-the-shelf software as much as possible. The software must provide Web Services Ta ble o f Con t en t s adapters. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

For ewor d Encapsulate legacy applications with interfaces that meet industry standards. Web Services must be I ntr oduction used for the interface. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Use independent layer between applications and data to hide the structure of the underlying Chapt er 1 a -data A Business Tr ip in the NotToo- Distant Futur e data. interaction must be through Web Chapt er 2 All - I nfor m at ion Technology Used in Thi sServices. Tri p

[4] A sampling of vocabularies by industry can be found starting on page 212. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb an d Ser vice- O rien tArchitectures ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Advantages ofServices Service-Oriented by Douglas K. Barr y

ISBN:1558609067

The main advantage for Kaufm using ann a service-oriented Mor gan Publ ishers ?2003architecture (245 pages) as part of an enterprise architecture is that it fits in with the general chaos of business. The “form” of an architecture must “function,” which generaltochaos Prov ides both pr actical leader ship and ar chitectur al follow adv ice the on how t o pr epar e anisorthis ganization t ak e of business. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

In today’s business environment there are many forces contributing to this chaos. Organizations are acquired and Table of Organizations Contents Back Cov er Com m ents New products need to be sold. Competition forces quick responses. divested. restructure themselves. could TaThis ble olist f Con t enbe t s nearly endless. I am sure you can think of additional forces that could add to the chaos of business. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

Historically, it is a struggle for the IT groups to respond to this business chaos. A service-oriented architecture provides a way to be more nimble in the responses. If a service-oriented architecture is designed properly, it will Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew approach the type of plug-compatibility that I have been alluding to with the AV examples that I have sprinkled Chapt er 1 this - part A Business Tr ip inJust the NotDistant Futur e if you want a better DVD player, you can buy one and through of the book. like Tooin your AV system, Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p incorporate it fairly quickly into your AV system. Similarly, if your organization needs a new CRM system to respond Chapt 3 - Ser viceOr iented Ar chiyou tectur es and ices one and, with relative ease, integrate it into your existing to anerunforeseen business need, should beWeb ableServ to buy For ces Affecti ng the Adoption of Web Ser v icesyou anddesign Other Iyour ntegrservice-oriented ation service-oriented architecture. The trick, however, is how architecture. Chapt er 4 I ntr oduction

Techniques

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

A service-oriented as part of an enterprise architecture: Morarchitecture gan Kaufm ann Publ ishers ?2003 (245 pages) Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

Permits youradvantage IT group of to be responsive to the ofchitectur your organization. Webmore ser vices and ser viceor needs iented ar es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Reduces development costs because you will be able to use more packaged software. Table of Contents

Back Cov er

Com m ents

Reduces maintenance costs because you will be using more packaged software.

Ta ble o f Con t en t s Web Ser Minimizes vices andthe Sercosts vice- Or ofiented integrating Ar chit systems ectur es—The because Sav vyofManager the broad 's Guide adoption of Web Services as an integration

technique. For ewor d I ntr oduction

Allows many smaller organizations to participate in Electronic Data Interchange (EDI).

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1 -you A Business Tr ip in the Not-aTooDistantservice-oriented Futur e Of course, cannot instantly have full-blown architecture. The next chapter discusses the Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p stages of adoption for Web Services and service-oriented architectures. Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby7: Starting to Adopt a Service-Oriented Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Architecture

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e seron vices ser vice- or iented of ar chitectur es, bri dgingarchitecture. t he gap bet ween the data- centr ic The remainder ofadvantage this book of willWeb focus theand “sub-architecture” a service-oriented This chapter and t he software engineer ing wor lds. provides an approach to adopting Web Services and service-oriented architectures along with a vision of the future using Aterthe end, case is made for getting started with Web Services sooner rather than Tablestandardized of Contents services. Back Cov Com maents later.

Ta ble o f Con t en t s

Web Ser vices and Ser viceiented Ar chit ectur es—The Sav vy Manager 's Guide Note Continuing withOrmy AV system analogy, the adoption of Web Services will be much like people treat their For ewor d music collections. You start out with your own CDs and perhaps some cassette tapes. Commonly people I ntr oductionmake copies for their own use. They might load the music onto a hard drive and burn their own CDs to use

incetheOcar Pa r t I - Se r vi r ie ntor edelsewhere. Ar chi te cturThis e Ovwould er v i ew be

analogous to your internal development of services. At some point,

a friend exchange This would be analogous to a limited exchange with an Chapt er 1 you - A and Business Tr ipmay in the Not- Too-burned Distant CDs. Futur e If you areUsed reallyininto Chapt er 2 external - I nfor mservice. at ion Technology Thi smusic Tri p exchange, however, you are likely to get involved with Internet file sharing some point. ThisWeb would beices analogous to integrated exchanges with external Chapt er 3 music - Ser viceOr ientedatAr chi tectur es and Serv

services—much like story ofofC.Web R.’sSer business trip. Many medium-sized and most larger organizations For ces Affecti ng thethe Adoption v ices and Other I ntegr ation Chapt er 4 will - go through these stages of adoption of a service-oriented architecture. ( Actually, this AV analogy does Techniques fully realize the of flexibility of ices a service-oriented architecture. To be as flexible as a service-oriented Chapt er 5 not - Growing I mpact Web Serv architecture, an AV Ar system would need to support an integrated music experience. For example, you start Ser vice- Or iented chi tectur es and Beliefs about Enter pr ise playing a CD, then a live band takes over to play a few bars, followed by a video of the band picking up the Ar chitect ur es at the sameatime of the text is streamed to your monitor showing the notes being Chapt er 7 tune, - St arall ti ng t o Adopt Ser vithe ce- score Or iented Ar chitectur e Pa r t I I - Maplayed.) na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Chapt er 6

Chapt er 8

- Change Wil l Happen

for Managing Change I ssues durLook ing Developm All Web- Tips Services Connections theent Same

Chapt er 9

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

By now, probably that of allAdopti the Web Services connections in the figures tend to look the same. In Chapt er 10you - Ar chitect urhave es atnoticed Each Stage on for Web Ser vices fact, er the protocols Chapt 11Web - ArServices chitect ur al Opt ions for connecting internal services are no different than the protocols needed for connecting to external services. This explains the blurring of internal and external services Chapt er 12 - internal Mi ddl e- services Tier Ar chitectur e

mentioned page 21 the in the story of R.’s With Web Chapt er 13 -onRev isi ting Business Tr C. ip in thebusiness Not- Too- trip. Distant Futur e Services and the pervasiveness of HTTP connections, it ndi willum become relatively easy toy connect andd external Pa r t I V - Com pe of Softw a r e Te chnolog for S er v iinternal ce - Or i e nte Ar chit ectservices ur e s

together into service-oriented architectures. The rest of this chapter will attempt to give a flavor of what might be possible with this level of Chapt er 14 - Addi tional Specification Details connectivity. Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e The ImpactW of Web Services ISBN:1558609067

by Douglas K. Barr y

The initial impactMor that Web Services willishers have?2003 is to (245 make existing forms of integration simpler. This will cause more gan Kaufm ann Publ pages) organizations to Prov be interested in the integration opportunities available with opportunities may ides both pr actical leader ship and ar chitectur al adv ice onWeb how Services. t o pr epar eThose an or ganization to t ak e occur within an organization between organizations. advantage oforWeb ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

The story of C. R.’s business trip illustrates some examples of what Web Services and a service-oriented Table of Contents Back m ents to connectivity and integration, we can expect that businesses will architecture could mean forCov all er of us.Com In addition Tafind ble opportunities o f Con t en t s to provide services such as Customer Relationship Management (CRM) and Enterprise Resource [1 ] Planning (ERP) subscription basis and es—The that theySav will integrated Web Ser vices and on SeraviceOr iented Ar chit ectur vybe Manager 's Guidewith internal systems. (This is the blurring ofewor internal and external services.) Automated agents that handle travel arrangements and help us manage calendars For d are also very likely. Also, devices that some might consider as nontraditional will be able to participate in Web I ntr oduction Services. The example in C. R.’s business trip is the GPS assistant automatically receiving itineraries. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew Chapt 1 - A Business Tr ip in the Not- TooFutur e will make using Web Services a requirement. The The er opportunity for integration presented byDistant Web Services Chapt er 2 I nfor m at ion Technology Used in Thi s Tri software products affected will range from desktop psystems to distributed enterprise systems. It is highly probable, Chapt er 3 - Ser Or iented Ar of chiall tectur es will and find Webit Serv ices for example, thatviceorganizations sizes economical to participate in a Web Services-based EDI system. For ces Affecti ng the Adoption of Websoftware Ser v ices packages. and Other IWith ntegrEDI ationbeing based on the interconnectivity of This will most likely be driven by the accounting Chapt er 4 Techniques the Internet because of Web Services, anyone’s accounting system should be able to participate. This could be Chapt er 5 to - other Growing I mpact of Web Serv ices as well. extended types of packaged software [1 ] With WebSer viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - Services, it is sometimes difficult to come up with the correct descriptive phrases. “ Integrated” is not Ar chitect ur es

exactly the best term since the services are provided in a seamless way at many locations on the Internet. Another

Chapt er 7might - Stbe ar ti ng t o Adopt a Ser vi ceOrnot iented Ar chitectur e immediately understand what is meant by “virtual.” phrase “virtually integrated,” but everyone would Pa r t I I - Ma nawe gi ng ngean N ee de d for a Ser v i ce -for Or the ie nte d Arof chit e ct ur e Eventually, willCha have agreed upon term type “integration”

allowed by Web Services. For now,

Chapt er 8 I -will Change Wilterm l Happen however, use the “integrated” in this book. Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an dDrive Ser vice-Adoption O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e The Internet Will Help by Douglas K. Barr y

ISBN:1558609067

The problem withMor predicting how will affect our systems is that the effect is not always gan Kaufm annservice-oriented Publ ishers ?2003 architectures (245 pages) immediately apparent. In some ways, it is fair to compare Web Services Internet in how affect many Prov ides both pr actical leader ship and ar chitectur al adv icetoonthe how t o pr epar e an itorwill ganization to t ak e things we all do. advantage For example, when Internet developing, not es, many peoplet he predicted such the uses as centr ic of Web serthe vices and serwas vice-first or iented ar chitectur bri dging gap bet ween dataand t he software of engineer ing wor lds.online, [2] or that grandparents would get personal computers to music file sharing, the explosion genealogy data exchange e-mail messages with their grandchildren. Web Services constitute a similar situation in that people will Table of Contents Back Cov er Com m ents think of all sorts of new and creative ways to use the capability. Ta ble o f Con t en t s

TheSer story of and C. R.’s business trip Ar is chit justectur one es—The vision ofSav how Services might change our world. It points out how Web vices Ser viceOr iented vy Web Manager 's Guide everything boils down to connections and services to make a service-oriented architecture that can be assembled For ewor d and reassembled much like an AV system.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Another way to look at C. R.’s business trip is to see the importance of the Internet in this service-oriented

Chapt er 1 - AThe Business Tr ip inofthe Not- TooDistant Futur e the world will make Web Services very enticing to architecture. prevalence HTTP connections all over Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p developers to create all sorts of creative services that in turn, will make adoption of a service-oriented architecture Chapt er 3 few - businesses Ser vice- Or iented Ar chi tectur es and Web Serv ices an offer can afford to refuse. [2] The use ofFor ces Affecti ng the Adoption increased of Web Serthe v ices and Other I ntegr ation the Internet has massively interest in genealogy. I know, this is one of my hobbies. In Chapt er 4 fact, I have aTechniques “hobby site” that helps you find family trees online. Take a look at www. familytreesearcher.com to see Chapt 5 -genealogy Growing Iinformation mpact of Web Serv icesavailable. how er much is actually Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services for an d Ser vice-Services O rien t ed Archit ect uServicere: T h e Sa vvy Man ag er 's Gu id e Stages of Adoption Web and Oriented Architectures ISBN:1558609067

by Douglas K. Barr y

Most organizations through the following stages of adoption for Web Services and service-oriented Morwill gango Kaufm ann Publ ishers ?2003 (245 pages) architectures: Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Experimentand with Web Services. Thisingis wor a period t he software engineer lds. to experiment with Web Services to become familiar with Web Services at a development level. The experimentation could involve adding external Web Services to a Web site Table of Contents Back Cov er Com m ents or portal, having an application server access a single existing system using Web Services, or adapting two existing systems to exchange data using Web Services. As a result of experimentation, you will have a better Ta ble o f Con t en t s understanding of the concepts of Web Services, development tools, and the effectiveness of various training Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide services. For ewor d I ntr oduction

1.

Adapt existing systems to use Web Services. This will make it easier to use Web Services to “plug into” legacy systems. Many vendors have tools that make this adaptation easier. Some of the - A Business Tr ip in the Not- Too- Distant Futur e advantages were described in “Improving Internal Connections” on page 63.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1 Chapt er 2 Chapt er 3

2.

- I nfor m at ion Technology Used in Thi s Tri p

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 5

Remove intersystem dependencies. These are along the line of shared databases that For ces Affecti ng the Adoption of Web Ser v ices dependencies and Other I ntegr ation Techniques can restrict the flexibility of a service-oriented architecture described in “Building Architecture Analogies” -onGrowing I mpact of Web Serv ices page 79.

Chapt er 6

-

Chapt er 4

3.

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Establish an internal service-oriented architecture. This will involve design to determine the appropriate boundaries of each service in your architecture. The techniques for this will be described in Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Part III.

Chapt er 7 Pa r t I I -

-

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t 4. I I I - Cr eExpand a ti ng S erthe v i ceinternal - O r ie nt ed service-oriented Ar chi te ctu r es

architecture to include external services. This actually could

at any time that itStage seems appropriate include external services. A simple early use would be to Chapt er 10 -occur Ar chitect ur es at Each of Adopti on for to Web Ser vices external services in a portal as illustrated in “Improving Web Site Connections” on page 62. Chapt er 11 -include Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Essentially, with these stages of adoption, internal data interchanges are simplified and your organization gains expertise in Web Services, which positions it for taking advantage of new internal and external services as part of a Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s service-oriented architecture. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W ebFuture Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Vision of the by Douglas K. Barr y

ISBN:1558609067

The effect of Web Services and service-oriented means we are going to have fewer people involved in Mor gan Kaufm ann Publ ishers ?2003architectures (245 pages) IT. The jobs in ITProv willides alsoboth generally change to creating architectures and realizing those byt ak e pr actical leader ship and ar chitectur al adv ice often on how t o pr epar e an architectures or ganization to making the connections to packaged time, the quality advantage of Web ser services. vices and At ser the vice-same or iented ar chitectur es, of brisoftware dging t hewill gapimprove. bet ween the data- centr ic and t he software engineer ing wor lds.

Industry will standardize on the capabilities of various services. An analogy was provided earlier to how the AV Table ofeventually Contents settled Back on Covthe er capabilities Com m entsof various AV components. The same will happen in every industry. As industry Tathis ble happens, o f Con t enitt swill become easier to buy services and hook them together. We will have fewer and fewer people building custom Web Ser vices and software. Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

Continuing with the AV analogy, when many television manufacturers were first starting to convert to printed circuit boards, Zenith ran a series of ads promoting the fact that they still had people in their manufacturing plants who Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew were hand-soldering electronic components for their television sets. Well, those handcrafted days are gone. Many of Chapt er 1 - A programming Business Tr ip jobs in thewill NotFutur e the traditional goToothe Distant same way. I ntr oduction

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Some find Ar that unique services Chapt er organizations 3 - Ser vice- may Or iented chithey tecturhave es and Web Serv ices that they can provide. IT staff will be needed to create those services. Nevertheless, there will be fewer jobs involving custom development. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4

-

Techniques Witherthe standardization of Serv services, Chapt 5 eventual - Growing I mpact of Web ices it will become easier to replace one packaged service with another.

(This would be replacing one AV receiver component with another that has more capabilities.) This should Sersimilar vice- Orto iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 - call to software vendors to improve the quality of their product. There will be fewer reasons for be a er clarion Ar chitect ur es organizations products if it iseeasy to swap in a service from a different vendor. PlugChapt er 7 - Stto arput ti ngup t o with Adoptinferior a Ser visoftware ce- Or iented Ar chitectur compatibility means cana be Pa r t I I - Ma na gi ng Chathat ngeservices N ee de d for Serreplaced v i ce - Or ieeasily. nte d Ar chit e ct ur e Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Why Get Started Now? ISBN:1558609067

by Douglas K. Barr y

There seems to Mor be an heldPubl by some there is no need to look at Web Services until you have another ganopinion Kaufm ann ishers that ?2003is(245 pages) organization as aProv partner for exchanging business data. Although may true verye small organizations, it eis ides both pr actical leader ship and ar chitectur al that adv ice onbe how t o for pr epar an or ganization to t ak not true for manyadvantage other organizations. Do not WebarServices simply exchanging data other of Web ser vices andassume ser vice-that or iented chitecturare es, bri dgingfor t he gap bet ween thewith datacentr ic and t he Services software engineer ingconnections. wor lds. organizations. No, Web are about And you can make those connections in your own organization. Table of Contents

Back Cov er

Com m ents

TaOf blecourse, o f Con tfor envery t s small organizations, you may need to wait until the vendors or your accounting system or contact

manager provide a way you toAr take advantage Web Web Ser vices and Ser vice-for Or iented chit ectur es—TheofSav vy Services. Manager 's Guide For ewor d

For medium sized to larger organizations, applying the concepts and standards of Web Services to your internal systems serves two purposes. First, it is a means to simplify your internal data interchanges. Second, it allows your Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew organization to gain expertise in Web Services. Should the opportunity present itself, your organization might then Chapt er 1to provide - A Business Tr ip in NotToo- Distant Futur e your organization might be able to take advantage of be able a service to the other organizations and/or Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p services provided by other organizations. I ntr oduction

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

The messageFor isces thatAffecti if younghave not prepared yourself, you won’t beI ready when the opportunity shows up. the Adoption of Web Ser v ices and Other ntegr ation

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Service-orientedMor architectures that Publ useishers Web Services result in a blurring between internal and external services. gan Kaufm ann ?2003 (245 will pages) Architectures willProv be ides constructed using a combination of those internal andonexternal services. goes on, these both pr actical leader ship and ar chitectur al adv ice how t o pr epar e anAs or time ganization to t ak e services will become more standardized making it viceeasier to replace one “ plug-compatible” service withthe another. The ic advantage of Web ser vices and ser or iented ar chitectur es, bri dging t he gap bet ween data- centr and t he software ing worsoftware lds. result will be competition to createengineer higher quality in these services. Contents of Back Cov er that Comare m ents ToTable takeofadvantage the services starting to become available, it is important to get started in the short term. The adoption of service-oriented architectures using Web Services, however, will be a big change for most Ta ble o f Con t en t s organizations. The next part of this book will examine some issues 's related Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager Guide to managing this change. For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Part II: Managing Change Needed for a Service-Oriented ISBN:1558609067 by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Architecture Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Chapter 8: Change Happen and t he Will software engineer ing wor lds.

Chapter 9: Tips for Managing Issues during Development Table of Contents Back Cov er Change Com m ents Ta ble o f Con t en t s Web Ser vices Ser vice- Or iented Ar chit ectur Sav vy Manager 's Guide Moving to a and service-oriented architecture willes—The be a significant change for many organizations. Such change must be For ewor d properly, which involves considering the organization as a whole, the technology to be used, and the managed I ntr people oduction involved in the change. Part II provides ideas to consider in managing the change needed to create a

service-oriented Pa r t I - Se r vi ce- O rarchitecture. ie nt ed Ar chi te ctur e Ov er v i ew Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby8: Change Will Happen Douglas K. Barr y

Overview

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic This chapter is about and t he managing softwarethe engineer change ingthat worwill lds. occur with adopting a service-oriented architecture that uses

Web Services. It shows that as the technical issues diminish, the remaining restraining forces are business issues, Table issues, of Contents Back Cov er Com chapter m ents primarily deals with change issues. These issues most often will design and change issues. This themselves in resistance to change. Forms of resistance are discussed as well as ways to overcome such Tamanifest ble o f Con t en t s resistance. To anchor these concepts resistance, I have included Web Ser vices and Ser viceOr iented Ar chitof ectur es—The Sav vy Manager 's some Guide of my own experiences with resistance to change. For ewor d I ntr oduction

At the end of this chapter, there is a worksheet for laying out change issues and responses to those issues. There is also a consolidated force field analysis for adopting a service-oriented architecture that builds on the analyses Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e covered in Chapter 4. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

ChaptNote er 3 After - Sercompleting vice- Or iented chi tectur es andwork, Web IServ myArundergraduate hadices a job as an analyst in a government agency. This was in a research For ces group Affecti ng of about the Adoption 40 people. of Web One Ser day v ices a senior and Other analyst I ntegr decided ation to move some of the desks around Chapt er 4 Techniques and, without discussing it with the people involved, went right ahead with the move. Orville, one of the Chapt er 5 older - Growing I mpact Web Serv analysts, wasofnot there atices the time. Orville came back to find his desk in a different spot. Finding out Ser viceOr iented Ar chi tectur es and Beliefs about pr ise who made the change, Orville ran screaming at theEnter senior analyst and literally pushed him against the wall. Chapt er 6 Ar chitect ur es As it turned out, Orville had an emotional problem that meant he did not deal with change well at all. The Chapt er 7 senior - St ar analyst, ti ng t o Adopt a Ser could vi ce- Orhave iented Ar chitectur however, avoided this econfrontation if only he had spoken with Orville before Pa r t I I - Mamaking na gi ng Cha N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e the nge changes.

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Change

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Not everyone who has with?2003 change emotional problems that make transitions worse. In fact, Mor ganproblems Kaufm anndealing Publ ishers (245has pages) most of us deal with change better than Orville did in this true story. Nevertheless, are ways to make any Prov ides both pr actical leader ship and ar chitectur al adv ice on how t othere pr epar e an or ganization to t ak e change easier foradvantage people and for the Thisorchapter deals withes, change related to Web Services andcentr ic of Web serorganization. vices and ser viceiented ar chitectur bri dging t he gap bet ween the datat he software worwith lds. that change. service-oriented and architectures andengineer ways toing deal Table Cov er Com m entsin the way we develop and maintain technical systems in our We are ofonContents the cusp ofBack a tremendous change change is already in progress and it will be a watershed for the software industry and software Taorganizations. ble o f Con t en tThis s development in general. The use Ar ofchit Web Services to be the missing puzzle piece in creating a complete Web Ser vices and Ser vice- Or iented ectur es—Theappears Sav vy Manager 's Guide picture of making a service-oriented architecture work. This manifests itself by the almost universal adoption of Web For ewor d Services by software vendors and by the rapid introduction of new products to make it easier to connect legacy I ntr oduction [1] systems to Web Services. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew [1] Of course, not every vendor is embracing Web Services. Some do not want their systems to be so open, Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e accessible, or replaceable. Market forces, however, are going to be irresistible and at some point vendors will need Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p to participate in Web Services in order to survive. Recall the analogy where Zenith was trying to counter the market Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices forces on page 90. It didn’t work. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vicerien t ed Archit ect u re: T h eArchitecture Sa vvy Man ag er 's Gu id e Costs Related to Adopting a OService-Oriented ISBN:1558609067

by Douglas K. Barr y

The stages of adoption a service-oriented architecture were discussed in Chapter 7. Each stage will lead to Mor gan of Kaufm ann Publ ishers ?2003 (245 pages) different changesProv occurring in organizations. The stages are repeated here, time ides both pr actical leader ship and ar chitectur al adv ice on but howthis t o pr eparwith e anaordiscussion ganization of to the t ak e types of costs that will likelyofoccur: advantage Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

1. Experiment with Web Services. This will usually involve only a few people on short projects in order to familiarBack withCov Web at a developmental level. The costs here will involve training, perhaps the Table become of Contents er Services Com m ents purchase of some software tools, and the time to experiment with using Web Services.

Ta ble o f Con t en t s

Web 2. Ser vices Ser vice-systems Or iented to Ar chit es—The Sav vy Manager 'son Guide Adaptand existing useectur Web Services. Depending your internal architectures, this stage may For ewor dmean more work for the IT group. It will mean acquiring or building Web Services adapters for existing

systems. That process will require additional expenditures in either training of internal personnel or bringing in I ntr oduction people work. Pa r t I - Se r vi ce-to O r do ie ntthe ed Ar chi te ctur e Ov er v i ew Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

3. Remove intersystem dependencies. If you have internal systems that should be separate services, but - I nfor m at ion Technology Used in Thi s Tri p share database structures or other infrastructure, you may need to invest in removing these dependencies. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices Additional costs may include analyses to determine other intersystem dependencies that might restrict the For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er construction 4 of a service-oriented architecture. Of course, you do not need to bother with removing these Techniques intersystem dependencies if they do not conflict with building a service-oriented architecture. Chapt er 2

Chapt er 5

- Growing I mpact of Web Serv ices

Ser viceiented Ar chi tectur es and Beliefs about Enter pr ise an Or internal service-oriented architecture. With intersystem dependencies removed, you can Chapt4.er Establish 6 Ar chitect ur es

now establish an internal service-oriented architecture. At this point, costs will start to go down. Initially, this is - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e because of the likely reduction in maintenance cost through the use of Web Services as the universal - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e connection technology.

Chapt er 7 Pa r t I I

Chapt er 8

- Change Wil l Happen

Chapt5.er Expand 9 - Tipsthe for internal Managing service-oriented Change I ssues dur architecture ing Developmto ent include external services. Once you have a Pa r t I I I service-oriented - Cr e a ti ng S er v i cearchitecture, - O r ie nt ed Aryou chi te can ctu start r es

looking for “plug-compatible” software that can further reduce your

is at Stage this point that you willWeb startSer tovices see a significant reduction in costs since this is Chapt er development 10 - Ar chitectcosts. ur es atIt Each of Adopti on for number of custom programming jobs starts to diminish. Chapter 7 covered the changing roles of IT Chapt er where 11 - Arthe chitect ur al Opt ions service-oriented architecture. It is at this stage that an organization will see those changes occur. Chapt er staff 12 - inMiaddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Figure 8.1 provides a general view of costs over time related to adopting Web Services and a service-oriented architecture. The various curves are only projections meant to show that timing of costs rising and falling will vary Chapt er 14 - Addi tional Specification Details based on the nature of an organization’s existing internal systems architecture. In other words, “one size won’t fit Chapt er 15 - Qui ck Reference Guide all.” Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

I ndex List of Fi gures

Figure 8.1: Costs over time related to adopting Web Services and a service-oriented architecture. Note While I was completing the final manuscript of this book, a friend who was not familiar with Web Services asked how anyone would make money using this technology. First, I discussed Web Services using the AV analogy. Then I said that one way to look at Web Services is that they are the connections between various services on the Internet much like cables are the connections between AV components. That made sense to him. So I said, there is obviously more money to be made on AV components than on the cables. The same is true for Web Services. There is more money to be made on the services provided using Web Services than on the Web Services technology itself. So, if anyone asks about the Return on Investment (ROI) for Web Services, it would be best to deflect the question. The real issue is the ROI on services that could be provided for a service-oriented architecture using Web Services.

That is where the innovation will occur and where the real opportunity exists for making money. Web Services are just the connections. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser viceO rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Technical Change Issues Diminishing by Douglas K. Barr y

ISBN:1558609067

As previously mentioned, thereann arePubl several issues Mor gan Kaufm isherskinds ?2003of (245 pages)related to change. The drive to use Web Services is reducing the technical change issues. In other words, the barriers change related technology are diminishing. Prov ides both pr actical leader ship and ar chitectur al to adv ice on how t o prtoepar e an or ganization to t ak e This makes moving to a service-oriented advantage of Web ser vicesarchitecture and ser vice-technically or iented areasier. chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Figure 8.2 shows how using Web Services affects adoption of a serviceoriented architecture overall. This figure Table of Contents Back Cov er forCom m ents combines the force field analyses three basic components of a service-oriented architecture: Web Services middleware (Figure 4.7), data warehousing (Figure 4.9), and message routing (Figure 4.14). The restraining forces Ta ble o f Con t en t s shown at the right represent the technical change all three components. The gray arrows represent the Web Ser vices and Ser vice- Or iented Ar chit ectur es—Theissues Sav vyfor Manager 's Guide technical restraining issues that will diminish as industry adopts and expands the use of Web Services. Why these For ewor d forces will diminish was discussed in Chapter 4. I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

The analysis in Figure 8.2 is interesting because it illustrates that as the technical restraining forces shown in gray

Chapt er 1 we - Aare Business ip in the NotToo-related DistanttoFutur e diminish, left withTrtechnical issues business and general design. The arrows at the top, right, Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p represent the business issues such as costs of development or concerns that a product or service doesn’t have all Chapt er 3 - that Ser viceOr iented Ar chi tectur es and Web ices right, represent the design issues. There are, of the features might be needed. The arrows at theServ bottom, For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation course, Chapt er 4 other - design issues, but these arrows are representative of basic design issues facing any effort to create a Techniques service-oriented architecture. Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 8.2: Force field analysis of technical issues related to adopting a service-oriented architecture. At the left of Figure 8.2 are the driving forces for adopting a service-oriented architecture using Web Services. The strength of these forces will vary by organization. Also, there very well might be additional driving forces for a particular organization. Nevertheless, by almost any measure, there are tremendous driving forces for the adoption of a service-oriented architecture. You may want to try adding technical driving and restraining forces to this figure that are specific to your organization. There is space at the bottom of Figure 8.2 to add technical driving and restraining forces.

Figure 8.2 illustrates that there are few industry-wide technical issues remaining that restrain the adoption of serviceoriented architecture and that those issues are diminishing over time. This is why you see the adoption of Web W eb vendors Servicesand an dthe Serintroduction vice- O rien tof ednew Archit ect u re:toTmake h e Sa it vvy Manto agconnect er 's Gu id e Services by software products easier legacy systems to ISBN:1558609067 by Douglas K. Barr y Web Services. Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

This is not to diminish theboth business andleader design issues. arealnot necessarily to solve, but they are to thet ak stuff Prov ides pr actical ship and arThey chitectur adv ice on how easy t o pr epar e an or ganization e of what developing an architecture is all about. Essentially, eacharorganization must decide if it bet makes advantage of Web ser vices and ser vice- or iented chitectur es, bri dging t he gap weenbusiness the data- centr ic t he software engineer ing wor lds. Web Services. If it does, then there are design issues that sense to create aand service-oriented architecture using need to be addressed. At this juncture in our industry, the common, industry-wide roadblocks are coming down. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ResistanceW to Change by Douglas K. Barr y

ISBN:1558609067

If it makes senseMor forgan yourKaufm organization to develop service-oriented architecture, what other restraining forces need ann Publ ishers ?2003 a (245 pages) to be considered? Probably the strongest is a general resistance to change. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Resistance is a common human response to wor change. and t he software engineer ing lds. This human resistance to change, however, may very well be the biggest hurdle to overcome in creating a service-oriented architecture. The previous section showed how the Table of Contents Backand Covwill er continue Com m ents use of Web Services has to reduce the technical restraining forces on the adoption of the technologies related to adopting service-oriented architectures. With the reduction in the technical restraining forces, Ta ble o f Con t en t s change is certainly going to happen. As the technical issues recede, human side of resistance to change is also Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's the Guide going to happen. For ewor d I ntr oduction

Figure 8.3 shows the analysis of driving and restraining forces related to change that affect the adoption of a service-oriented architecture. There are many more restraining forces that relate to resistance to change. Also, if my Chapt er of 1 the - future A Business Tr ip in the Toovision concerning theNotroles of Distant IT staff Futur in thee future is correct, some of the restraining forces simply will Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p be stronger. For example, the restraining force of feeling that jobs may be threatened is very real as an organization Chapt er 3through - Serthe vice-stages Or iented Ar chi tectur and Web Serv ices moves of adopting a es service-oriented architecture. You may want to try adding driving and For cestoAffecti ng thethat Adoption of WebtoSer v ices and Other I There ntegr ation restraining forces this figure are specific your organization. is space at the bottom of Figure 8.3 to Chapt er 4 Techniques add driving and restraining forces. [2] Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 8.3: Force field analysis of change issues related to adopting a service-oriented architecture. As a manager, be on the lookout for resistance. Where there is change, there will be resistance. The savvy manager is prepared for it and deals with it as it occurs. In reality, only about one fourth of people actually like change and look forward to it. Those are the people who are looking for variety and they are your advocates in a technological change. There are probably an equal number of folks who hate change; these folks may try to keep change from happening. In the middle are the “wait and see” folks. They are concerned about the impact of change to them, but they are willing to wait and see what happens. These are the people to focus some time on because you can win them to your side. Plenty of communication and participation can do wonders. The more employees can worry and wonder, the stronger their resistance becomes. It’s just human nature. William Bridges has written extensively on the topic of change in organizations for the past several decades. His work, particularly Managing Transitions, [3] is particularly helpful for the manager planning a technology change. His model views change as a series of events going from an ending, which is the way things used to be, to a beginning,

which is the way things will be in the future when the project is complete. Between the two is the neutral zone, which is a stage in which few things are the way they were and it’s not clear how they will be. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

It is in the neutralbyzone, according be ISBN:1558609067 Douglas K. Barr to y Bridges, where resistance can be found because it is a stage that can marked by confusion andKaufm uncertainty. the neutral zone there are no clear markers and no promises. The savvy Mor gan ann PublIn ishers ?2003 (245 pages) manager will be careful people whoarmay be inalthe neutral seldom to being Prov ideswhen both dealing pr acticalwith leader ship and chitectur adv ice on zone how t because o pr epar ethey an orare ganization t ak e difficult on purpose. They are unsure and may not realize their resistance. Sensitivity thedataneutral advantage of Web ser and vicesconcerned and ser viceor iented ar chitectur es, bri dging t he gap bet weentothe centr ic t he software engineer ing often wor lds. zone is importantand because the manager can help team members through this stage more quickly. [2] Yes, many of these same forces have existed for the adoption of any technology for many years. Nevertheless, I Table of Contents Back Cov er Com m ents think there is something seriously afoot with Web Services and that the expanding adoption of service-oriented Taarchitectures ble o f Con t enwill t s have a significant impact on IT organizations. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide [3]Managing Transitions: Making the Most of Change, William Bridges, 1991, Perseus Publishing, New York. For ewor d

I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Forms of Resistance ISBN:1558609067

by Douglas K. Barr y

Recognizing resistance take practice because many of its forms could easily be justified as a concern or a Mor gan can Kaufm annsome Publ ishers ?2003 (245 pages) request for information. We all want employees who care enoughalabout workt othat they areorwilling to want Prov ides both pr actical leader ship and ar chitectur adv icetheir on how pr epar e an ganization to tto ak e understand and state their concerns. As new presented, it should expected that would advantage of Web ser vices andprojects ser vice-are or iented ar chitectur es, bribe dging t he gap betemployees ween the datacentr ic and t heInsoftware ing wor lds. that a manager can do is communicate in many ways and many have many questions. fact, oneengineer of the best things times what the project entails. Some employees do better with written communication, some with group meetings, Table of Contents Back Cov er Com m ents and some with one-on-one casual conversations. All have their place in a plan for communicating change. Ta ble o f Con t en t s

When manager has communicated timeSav hasvypassed, team members may still be asking questions Web Seravices and Ser viceOr iented Ar chitplans ectur and es—The Managersome 's Guide orewor raising For d concerns. Sometimes team members may be raising new concerns on a regular basis. If you have

carefully considered the objections and found no grounds for the concern, this may well be a sign of resistance to change. Resistance to change in people can take many forms. Constant questioning with new concerns rising all the Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew time is a classic sign that resistance may be taking place. This also can take the shape of a form of confusion, in Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e which the team member just can’t quite get clear on how or why the project will be the way it is planned. Such a Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p team member is probably not doing this on purpose. It’s possible that this person is just not able to hear what is Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices being communicated because of some discomfort with it. This person may well be in the neutral zone and is just For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt tryingerto4 find - his or her way through it. I ntr oduction

Techniques

Chapt 5 - of Growing I mpact of include Web Serv ices or easy acceptance. People may be silent for many reasons but it is Otherer forms resistance may silence Ser viceOr iented Ar chi tectur es and Beliefs pr ise easyerto6assume that silence means acceptance. That about is not Enter always the case, so be on the lookout for it. Easy Chapt Ar chitect ur es

acceptance can also be misleading because it may mean that the person has not considered the ramifications of the

Chapt er 7 when - St ar ng she t o Adopt Ser viabout ce- Or iented chitectur e this person upon whom you were counting is no change; heti or does athink it, you Ar may find that Pa r t I I - on Ma board. na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e longer

Chapt er 8

- Change Wil l Happen The er following sections go into some detail on dur forms resistance. Chapt 9 - Tips for Managing Change I ssues ing of Developm ent These forms of resistance will also be referenced

inr tthe this Chapter 9,ctu and Pa I I I remainder - Cr e a ti ng of S er v i cechapter, - O r ie nt ed Ar chi te r esChapter

10.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Lack of Training/Understanding

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Sometimes are the resistant to change because they do not have Chapt er 13 - people Rev isi ting Business Tr ip in the Not- TooDistant Futur e the training to understand what the new project jobpewill become familiar and itsto Pa r t I V - or Com ndientail. um of Many Softw apeople r e Te chnolog y for S er v i with ce - Ortheir i e ntejob d Ar chitwant ect ur e

stay the same. It is particularly

challenging them if the change inDetails their job involves new technology. Almost everyone has a concern about not Chapt er 14 - for Addi tional Specification measuring inck a new environment Chapt er 15 -upQui Reference Guide and that may well be the situation here. I ndex

A second issue in this situation is communication. Sometimes people just aren’t getting the message that they need to hear. In a change situation, you can count on some people putting the most negative spin on any change. That’s just human nature. In a time of uncertainty, most people will fear for the worst. That’s why plenty of communication is of great importance. If people will need new training for the change, be sure they are reassured that they will get it.

List of Fi gures

Power of Internal “Expert” An internal expert can be a formidable ally in a change effort or a formidable roadblock. Such an expert knows the current system and possibly the previous systems in such a way that can be of great help. On the other hand, if this person is not on board for the change effort, he or she can raise all sorts of barriers. The most probable form of resistance will be in raising concerns about the quality of the new system and this person is likely to use the expert position in the organization to raise the level of recognition of the concern. It’s easy to overlook what an expert has to lose in a change situation. This person is going from being an acknowledged success to a situation that is new. Because of the newness, it is impossible to know whether this person will be able to retain expert status or even if he or she will be needed in the new situation. That may be a big risk for such a person. This is especially true in the situation where the current expert may not have the kind of training that will make moving to the new system possible.

Inertia—Why Change? Sometimes it’s difficult to effect change in a system just because it’s always been done a certain way or because the system is seen as working okay. This creates a sense of inertia. People who are part of the system ask why a change is needed. This can make it difficult when the new way of things will create a leap forward and will bring possibilities that haven’t been present before. Communicating the advantages of the new options may help, but when people are comfortable in the current situation, any change can be challenging and bring resistance into play.

Feeling that Job May Be Threatened W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Given the pace of technological change today, it is difficult for most people to stay knowledgeable on new ISBN:1558609067 by Douglas K. Barr y technology. This means that any change may feel threatening to many people. Many technology changes are put Mor gan Kaufm ann Publ ishers ?2003 (245 pages) into place so that staffing can be as lean as possible. That means that not everyone will have a job after the change Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e in technology occurs. Those people who have not kept their technical skills up may have reason to worry. Because advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic worry tends to beand contagious in an organization, t he software engineer ing wormost lds. everyone will be worrying. For some people, the outlet for this worry will be resistance. Table of Contents

Back Cov er

Com m ents

As the use of Web Services is more widely adopted, some jobs will really be threatened. We are on the cusp of Ta ble o f Con t en t s replacing custom coded systems with “plug-compatible” software. As a manager, you will need to keep this very Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide legitimate concern in mind when creating a service-oriented architecture. For ewor d

I ntr oduction

Not Invented Here

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Most people have pride in their work. It’s easy for managers to forget or not even know the blood, sweat, and tears - I nfor m at ion Technology Used in Thi s Tri p that went into a project that was completed some time ago. The people who worked on that project do remember. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices When they hear that the work that they did will be replaced, there’s always a sense of loss. In the excitement of For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation bringing Chapt er 4 in -the new, the organizational focus ignores the earlier contribution of the people and their project and Techniques focuses on the shortcomings of the old. This can lead to resistance on the part of those who have worked on the old Chapt er 5 - Growing I mpact of Web Serv ices system. Chapt er 2

Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Our Problems - St ar ti ng t oAre AdoptSpecial a Ser vi ce- Or iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

I’ve worked countless groups of people working on technology issues. Amazingly, almost all of them believed Chapt er 8 - with Change Wil l Happen

that the technical problems that they had to solve were quite complex and unusual. From my perception as an - Tips for Managing Change I ssues dur ing Developm ent outsider, those same problems struck me as fairly normal for the industry that they were in or the work that they Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es were doing. There were, of course, some twists that required attention, but those twists were not significant enough Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices to scuttle a project. Chapt er 9

Chapt er 11 - Ar chitect ur al Opt ions

Chapt - Mi ddl eTier Ar chitectur This er is 12 a common excuse used by etechnical people to avoid using an offthe- shelf program. On a rare occasion it Chapt - Rev ting often the Business in the of NotToo- Distant Futur may er be13 true, butisimost it is justTraipmeans resistance used byethose who want to keep things as they are or to Pa r t I V - Com pe ndi um of Softw a r eown. Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s develop something new on their

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W ebResistance Services an d Serto viceO rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Overcoming Change ISBN:1558609067

by Douglas K. Barr y

The first step in overcoming any kind ofishers resistance to change Mor gan Kaufm ann Publ ?2003 (245 pages) is to recognize it for what it is. Some resistance easily stops a project because it is never addressed. When the manager notices seems be happening ore Prov ides both pr actical leader ship and ar chitectur al adv ice onthat hownothing t o pr epar e an to or ganization to t ak that the project isadvantage far off theofschedule, it’s past to consider that resistance at play. Web ser vices and time ser viceor iented ar chitectur es, briis dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

The best bet is to anticipate resistance in advance, even before the project starts. This means that you can set Tableup of to Contents Back Com m and ents you will be in a good situation to address it as it arises. Some ideas things avoid some of Cov the er resistance here. Taare ble listed o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

The next sections discuss ways to overcome resistance to change. These will be used in the remainder of this chapter.

For ewor d

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Selecting the Right People - A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

One key to the success of any project is careful selection of people to work on the project. Selecting a person Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices because he or she has been around a long time isn’t generally a good reason for that person to be on the team. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Choosing because he or she doesn’t currently have a project is not a good reason either. The best Chapt er 4 someone Techniques approach is to identify what kind of skills and experience are needed on the project team. Then figure out which Chapt er 5 - Growing I mpact of Web Serv ices person in your organization can meet those standards. What isn’t available internally must be obtained externally Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 eitherer through a new hire or a contracting situation. Ar chitect ur es Chapt er 7 - staffing St ar ti ngfor t o aAdopt a Ser vi ce- Or chitectur Sometimes project is seen asiented a wayArto resolvee problem personnel situations. That’s not the route to Pa r t I I - Ma nayour gi ng project. Cha nge Although N ee de d for a Ser v i ceseen - Or ieany nte dresearch Ar chit e cton ur ethis, success on I’ve never

my experience tells me that a big factor in

Chapt 8 - Change Wilof l Happen failederprojects is a lack personnel with the skills and experience required. This is something that will hinder any Chapt er 9 Tips for Managing Change I ssues dur as ing successful Developm ent project. The outcome of any project can only be as the skills of the people who work on it. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

A Second Set of Eyes

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12practice - Mi ddlthat e- Tier chitectur Another canArbe great ehelp in limiting resistance is pairing team members together. There are many Chapt er 13 - Revthat isi ting Tr ip members. in the Not- TooDistant Futur e technical reasons to do this, but there are methodologies callthe for Business paired team There are excellent Pa r t I V - Com ndi um Softw aresistance r e Te chnolog for S er vCareful i ce - Or i eteam nte d Ar chit ect ur es reasons alsopethat will of address to ychange. selection means

that you are unlikely to have both

Chapt er 14 - Addi Specification Details people in the pairtional with the same issues. That means that neither person will be left stewing on his or her own. In Chapt er 15the - Qui ck Reference Guide addition, possibility that both people will be allowing the schedule to slip or participate in other resistant activities I ndex is less likely. List of Fi gures

Really Listen One of the best things that you can do with someone whom you think may be experiencing resistance is to listen. By that, I mean really listen and not try to talk the person out of his or her ideas. Most of the time, what we think is listening is actually thinking about how to answer the person’s objections. If you find yourself talking more than the other person, it means you aren’t really listening. If you find yourself explaining things, then you aren’t really listening. Some people think that just saying the same thing over and over will help improve understanding. When you find yourself doing this, it means that you don’t really understand what the person is saying. Sometimes what the person is saying is the problem is just the obvious surface of the real problem. It’s more effective to ask the other person questions to probe into what might be behind the resistance. Ask questions such as “what is your concern about that?” and follow up your questions with a summary such as “so, you are concerned that if we implement this change, _____ might happen and that would be a problem because of _____.” Let the person clarify your understanding until you both agree that you understand the other person’s point of view. If you listen in this way, you can even disagree but the person will feel that he or she has been heard. People don’t necessarily need agreement to feel that they’ve been heard.

Communicate at Many Levels An effective antidote to resistance is communication and plenty of it. It’s a human response to anticipate the bad things that may happen and a communication vacuum contributes to that. To deal with resistance issues, regular communication in many forms is helpful. People have different styles and it’s

helpful to provide communication in as many forms as possible so that each style gets its needs met. It also can be helpful establish when W eb to Services anad communication Ser vice- O rien t schedule ed Archit so ectthat u re:people T h e Sacan vvy anticipate Man ag er 's Gu idmore e communication will be available to ythen. In fact, any promises that are made must be met. Don’t over promise and ISBN:1558609067 by Douglas K. Barr then not meet the promises. That up?2003 a foundation Mor gan Kaufm ann just Publsets ishers (245 pages)for mistrust. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

And while you’readvantage at it, think of about the chain methods thatthe willdatabe centr ic Web communicating ser vices and serup viceor management iented ar chitectur es, as briwell. dgingFind t he gap bet ween reassuring to management and create a schedule that you can meet and that they can depend upon. This helps and t he software engineer ing wor lds. protect your project from rumor and innuendo. Table of Contents

Back Cov er

Com m ents

Seek Appropriate Avenues to Involve People

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Participation is another important part of avoiding resistance to change. The more people feel part of something, the For ewor d more they will support it. This can take a variety of forms including asking for people’s input and review. Be sure to I ntr oduction be forchi information sov that Pa r t clear I - Sein r viyour ce- O request r ie nt ed Ar te ctur e Ov er i ew

people really hear the request and believe it is really wanted. I’ve

seenersituations where management asked for inputFutur andegot none because employees either didn’t hear it or didn’t Chapt 1 - A Business Tr ip in the NotToo- Distant believe forion input is not a regular organization’s culture, you will need to ask in a variety of Chapt er 2it. If- asking I nfor m at Technology Used in part Thi s of Triyour p

ways. a casual request at the cooler creates a more believable request than a general statement Chapt er Sometimes 3 - Ser viceOr iented Ar chi tectur eswater and Web Serv ices in an open meeting. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation -

Chapt er 4

Techniques

Get Resistance Out in the Open

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Ar chitect es it is can bring it out into the open so that people can talk about it. Talking about it takes Naming resistance forurwhat Chapt - St ar t o Adopt a Ser vi ce- Or iented Ar chitectur e awayerits7 power toti ng disrupt. Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

It’s important to do this a neutral, non-threatening way. That means that pointing a finger and telling a person or Chapt er 8 - Change Wil in l Happen

group change is Inot andur option. That approach is quite likely to make things worse even if it is Chapt er that 9 they - Tipsare forresisting Managing Change ssues ing Developm ent true. better to Screate where people Pa r t I I It’s I - Cr e a ti ng er v i ce -a Osituation r ie nt ed Ar chi te ctu r es

can state their resistance on their own. Hold a team meeting and create a comfortable situation by stating something like, “I’m sure you have concerns about this change. I’ll bet that Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices the new architecture is a little hard to understand in such a short time. At least I know I’d feel that way.” Approaching Chapt er 11 - Ar chitect ur al Opt ions the issue in this way would make it possible to get the issue on the table for discussion. Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Some Resistance Scenarios ISBN:1558609067

by Douglas K. Barr y

This section includes scenarios that areishers from?2003 some(245 of pages) my own experiences with resistance to change (of course, Mor gan Kaufm ann Publ names and details have been altered). As you read the see certain emerging. Prov ides both pr actical leader ship and ar following chitectur alscenarios, adv ice on you how will t o pr epar e an orthemes ganization to t ak e The first is that resistance takeser many and is or not always immediately resistance. The centr ic advantage can of Web vicesforms and ser viceiented ar chitectur es, brirecognizable dging t he gapasbet ween the dataand t he software ingaware wor lds. second is that the resister is oftenengineer not even of the motivation for his or her behavior. Table of Contents

Back Cov er

Com m ents

But It’s So Complicated! Ta ble o f Con t en t s

Web Serput vices and Ser vice- Or iented Ar chit es—The Sav vythe Manager 's Guide As he a team together to replace anectur existing system, manager felt fortunate to be able to include a person For ewor d worked on the existing system for over a decade. Betty was a competent programmer and had a nearly who had I ntr oduction encyclopedic memory of why the existing system worked the way it did. She was also quite articulate and seemed Pa r t I interested - Se r vi ce- Oin r iehelping nt ed Arto chicreate te ctur ethe Ovreplacement er v i ew very

Chapt er 1

system.

- A Business Tr ip in the Not- Too- Distant Futur e

The er early how theUsed replacement should work went well. Betty was quite helpful in making Chapt 2 investigations - I nfor m at ion into Technology in Thi s Trisystem p sure er the had allOrthe details and idiosyncrasies documented. She was also very helpful went it came to Chapt 3 team - Ser viceiented Ar chi tectur es and Web Serv ices designing theFor data model the replacement system would use. ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation -

Chapt er 4

Techniques

Then something happened. As the team started to design how the software would work, Betty started to bring up - Growing I mpact of Web Serv ices new issues that should have been uncovered in the early investigations. Of course, it is understandable that some Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er would 6 - be overlooked but the number of these issues became overwhelming. Sometimes, these issues things Ar chitect ur es required considerable rework to change what was already completed. It seemed as if Betty waited until all the rework Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e was done before bringing up another issue. And unfortunately, sometimes these issues also required rework. Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Eventually, however, the team seemed to have a robust design and was able to answer many of Betty’s concerns Chapt er 8 - Change Wil l Happen on the spot. Chapt er 5

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I Ithings - Cr e astarted ti ng S erto v i ce - O ie ntweird. ed Ar chi te ctuteam r es Then get ar bit When

members would answer one of Betty’s concerns and show her

Chapt - Ar chitect ur esaccount at Each the Stage of Adopti on for Web vicesoften respond, “but it’s so complicated.” Betty how er the10design took into issue she raised, BettySer would Chapt 11 - Ar chitect ur al Opt ions was er apparently convinced that the existing system had to be more complicated than the replacement system would Chapt be. er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Because of her experience ona the existing had a huge following in Pa r t I V - Com pe ndi um of Softw r e Te chnologsystem, y for S erBetty v i ce - Or i e nte d Ar chit ect ur e s

this large organization. She was known and respected all the way up to the vice president level because she had worked with these people for over Chapt er 14 - Addi tional Specification Details ten years. This replacement system was also seen as critical to the organization’s future. So, when Betty started Chapt er 15 - Qui ck Reference Guide moving up the management chain with her lament, “but it’s so complicated,” people took notice. Management I ndex started to want to know why the group was doing this inferior design and became worried about the future of the List of Fi gures project. In fact, some vice presidents started to threaten cancellation of the project if the information technology (IT) group could not do a better job on this critical replacement system. A lot of money was still allocated to completing this project and they did not want to spend that much money on an inferior replacement. More and more time was spent on meetings with upper management. The system designers and analysts all had to attend numerous meetings. In those meetings, Betty brought up issue after issue concerning how much more complicated the existing system is compared to the proposed system. The dynamic was interesting. The issues Betty brought up were often in terms that management could understand. The explanation of how the proposed system would handle the issues often had to be in terms of data models and software architecture. Many people in management honestly did not understand the more technical explanations, so they were left with the impression that Betty might have a point. Time passed. Development slowed. Eventually, the project was canceled. Some time later, a packaged product was brought in to replace the existing system. But as you might expect, Betty at first thought the packaged product would work only later to discover that the packaged product needed much modification, because the existing system was so “complicated.” That project was also canceled.

Resistance Issues Lack of training/understanding Power of internal “expert” Inertia—why change? Feeling that job may be threatened

Our problems are special Every technical change has incredible the people the new systems. In fact, W eb Services an d Serimpact vice- Oon rien t ed Architinvolved ect u re: with T h e both Sa vvy Man agand er 's old Gu id e every change of by thisDouglas type has and losers. As development proceeds, people sometimes changeISBN:1558609067 camps. K. winners Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

In this scenario, Betty had worked hard over the years with the current system. She was incredibly bought into it and Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e very impressed with how well it worked andand howser important her role was. Because of her of ween experience, she advantage of Web ser vices vice- or iented ar chitectur es, bri dging t heyears gap bet the datacentr ic had created a strong network of personal advocates and t he software engineer ing wor lds. for her point of view. Initially, she may have been sure that no new system could possibly replace the system that she knew was very complicated, so she was willing to work on Table of to Contents Covshe er had Com m ents been on several committees in the past that had put the kibosh on the team replace it.Back In fact, already the existing system, and of course, the work that it had to do, was so complicated. In this Tareplacements ble o f Con t enbecause ts particular situation, she willing andSav cooperate on 'sthe team until it dawned on her that this Web Ser vices and Ser vice-was Or iented Arto chitparticipate ectur es—The vy Manager Guide replacement system might actually happen. Then she began to raise issue after issue. When this happened, it’s For ewor d apparent that on some level she had begun to feel challenged in her position as the resident expert. The rest is I ntr oduction history. She used all of her connections to stop this project. Upper management can be notoriously fearful of failure Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew and Betty’s concerns fed right into that. Sometimes it may seem that anybody can kill a project because of any Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e “issue” while it’s very hard to get enough people or the right people to back it. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Suggestions to Overcome Resistance

Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques Really listen Chapt er 5

- Growing I mpact of Web Serv ices

Communicate atOrmany Ser viceientedlevels Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es Seek Chapt er 7 appropriate - St ar ti ng t oavenues Adopt a to Serinvolve vi ce- Or people iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Get resistance out in the open

Chapt er 8

- Change Wil l Happen

Chapt 9 important - Tips for issue Managing Change I ssues ing Developm ent The er most in this scenario is todur recognize the people issues that come with change. This has Pa r t I I I - Cr e aboth ti ng S er v ithe ce - people O r ie nt ed Ar chi te ctu r es and implications with doing the work

management that has to support the work.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Technical generally approach others in the organization—and questions within the IT organization—from a Chapt er 11 people - Ar chitect ur al Opt ions technical technical Chapt er 12 perspective. - Mi ddl e- TierWhile Ar chitectur e questions must have technical answers, there are other issues at stake that, left unanswered, sink project. Tr Inipthis case, Betty’s issuesFutur weree not technical. They were personal. The closer Chapt er 13 - Rev isiwill ting theaBusiness in the NotToo- Distant implementation came, nearer she was toy losing Pa r t I V - Com pe ndi um ofthe Softw a r e Te chnolog for S erher v i cestanding - Or i e nte das Arthe chitresident ect ur e s

expert. So, naturally, the old system, her system, became more and more complicated and irreplaceable. From the start, listening to Betty was Chapt er 14 - Addi tional Specification Details important, but, beyond that, finding an important role for her in the new project was critical. Because she had Chapt er 15 - Qui ck Reference Guide connections in upper management, perhaps she could have served as communication person in the project and an I ndex implementation role for the replacement system would have been important. The new system would have required List of Fi gures training for employees, which might have been a good spot for her. Now, granted, finding the right role might be challenging and might require some coaching or mentoring to get her up to speed, but the alternative, in this case, was a failed project. A second issue in this case, is getting management on board. In this case, Betty was able to cancel a project through a whisper campaign to her old buddies in management. This indicates that management was not properly briefed or brought on board at the beginning of the project, nor was it kept on board during development. This is another situation where technical people may oversell the technical answer and not carefully communicate, on a regular basis, the information that can be understood. The very technical answers that can be so important and interesting to technical people may put off management that does not understand their significance. This means learning to go beyond the technology to what the technology will do for the organization. What are the outcomes that will make a difference to them? This should be the focus of technical/management discussions. When this occurs, a project will be less vulnerable to a whisper campaign.

Guerilla Tactics One of the best technical minds in the company, Nancy was given the responsibility of designing and implementing the integration of two systems critical to her organization. The integration was somewhat controversial, with some seeing it as necessary and others thinking it the wrong direction. Nancy stated that she was in favor of the integration and was given the responsibility for completing the project. She put together a small team and set to work on the problem. To many in the organization, this seemed to be about a 2-month project. Nancy concurred. At the 2-month point, the project was not done. Nancy assured everyone that it was well on its way. At 4 months, it was still not done. Again, Nancy said that it was being properly handled; there were just a few glitches. At 7 months, a contract was missed and the project was canceled.

Resistance Issues W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Power of internal “expert” by Douglas K. Barr y

ISBN:1558609067

gan Kaufm ann Publ ishers ?2003 (245 pages) Inertia—whyMor change? Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

What happened?advantage Turns outofthat really the fringes She some WebNancy ser vices andenjoyed ser vice-working or ientedon ar chitectur es, of britechnology. dging t he gap betfound ween the data- centr ic andthat t he seemed software to engineer wor lds. academic research fit this ing problem quite well. Her team enjoyed working on the fringes of technology as well. They put together quite an elegant plan that involved writing significant amounts of code. Never mind that Table of Contents Cov er Com m ents you could buy portionsBack of the solution. Hooking that into the full solution would be less elegant. Given her status in Tathe ble company, o f Con t enlittle t s oversight was maintained on any work she did. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

What really happened? Although she had stated that she supported the integration project, Nancy did not think it was the right direction for her company. She may not have even been aware that she was using her emphasis on I ntr oduction the elegant solution as a way to kill the project, but that’s what happened. Resistance is an emotional reaction that Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew can leave people unaware of the motivations for their actions. For ewor d

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p Suggestions to Overcome Resistance

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For cesright Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Selecting the people Chapt er 4 Techniques A second set of eyes Chapt er 5 - Growing I mpact of Web Serv ices

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 appropriate Seek to involve people Ar chitect uravenues es Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Get resistance out in the open

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8 brilliant, - Change Wil l Happen Managing creative people has been a challenge since management began. Harnessing that capability in a Chapt er 9 Tips for Managing Change I ssues dur ing Developm way that will benefit the organization can be overwhelming. In ent this particular case, Nancy either was not the right Pa r t I I I -for Cr ethe a ti ng er vshe i ce -was O r ienot nt edmanaged Ar chi te ctu r es person jobSor properly.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Selecting people for ions the tasks in a technology project may be the most critical decision, but it is often less Chapt er 11 the - Arright chitect ur al Opt

studied than the and software to be used. Nancy’s interest in the fringes of technology can be very helpful Chapt er 12 - Mi ddlhardware e- Tier Ar chitectur e

to a company, but in this case, it killed a critical, yet constrained, 2- month project. Her management should have foreseen this problem and could have either had someone else head the project or paired Nancy with someone who Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s could steer her brilliance in a more pragmatic direction. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Chapt er 14 - Addi tional Specification Details

Chapt er 15Nancy - Qui ck Guide Second, andReference her organization were unaware of her true feelings about this project. Managers need to be on I ndex the lookout for signs of resistance. When things just don’t add up, resistance may be in play. Managers need to List of Fi gures assess how things are going and be ready to make changes.

Nancy’s manager should have taken a closer look at the project on an ongoing basis. Checking in at 2 months, when the project was to have been completed, was too late. Using standard project management techniques, a detailed schedule should have been developed and checkpoints, perhaps on a weekly basis, should have been observed. Design walkthroughs, code reviews, or inspections might also have helped. Given Nancy’s interest in the fringe of technology and her possible resistance, these checkpoints should have been quite in depth. This would have flagged the slowing schedule early on and changes could have been made.

More Guerilla Tactics Todd had almost single-handedly built the company’s master record system. In fact, he had also been involved in the construction of two successive generations of the master record system. Like Betty, he had the respect of nearly everyone in the company. Only in this case, that respect was so high that he was seen as a system guru. Todd agreed that it was once again time to upgrade the master record system. The present system was not fast enough and cost too much to maintain. Todd saw this as an opportunity to improve on his previous designs. What Todd had built, however, was now available from numerous software vendors. Some of those vendors could legitimately show that their packaged software products could significantly outperform the system that Todd had designed. A technical review of the capabilities of the packaged software products showed, to most everyone’s satisfaction, that the software could perform as needed. But not for Todd. In meetings, he often brought up arcane issues. When asked to document them, he agreed. But it never happened and given his standing in the organization, his lack of follow-through was never mentioned. More meetings would bring more concerns. To everyone on the development team, it was becoming clear that Todd had never been satisfied with the master records systems he had designed and that he wanted one more chance to do it “right.” The packaged software option would take away his opportunity.

Todd and the CEO of the company were close friends and had been with the company from its start. Eventually, this relationship allowed Todd to recreate his master record system. It may not surprise you that the new system is still eb Services an d Ser O rienmore t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e not as fast as theWpackaged system andvicerequires maintenance.

Resistance

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Issues

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Not inventedadvantage here and t he software engineer ing wor lds.

Power of internal “expert” Table of Contents

Back Cov er

Com m ents

that Ta ble oFeeling f Con t en t s job may be threatened Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Our problems are special

For ewor d I ntr This oduction scenario illustrates a huge change that has already occurred in the software business. Not that many years Pa ago, r t I most - Se r viorganizations ce- O r ie nt ed Ar had chi te toctur relye on Ova ersystem v i ew

guru and a large staff inside the organization that could design

unique to meet thethe organization’s unique needs. Now many software vendors have products that can Chapt er 1applications - A Business Tr ip in Not- Too- Distant Futur e be used or be tweaked to meetUsed the organization’s needs. This is a huge opportunity for organizations to trim Chapt er 2 as- isI nfor m at ion Technology in Thi s Tri p the cost systems. Chapt er 3 of -new Ser viceOr iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt 4 - does, however, point out the significant people issues involved in this kind of change. The huge The er scenario Techniques

change is not only in the software but also in the staffing needs that organizations will have in this situation. Gurus, - Growing I mpact of Web Serv ices like Todd, just won’t be needed on an ongoing basis any more. They may be needed on the front-end design stage, Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 will- be it. but that Ar chitect ur es Chapt er 5

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

This shift has huge issues for organizations in a number of ways. As in the earlier case of Betty, Todd was bringing up arcane issues that seemed outside of the satisfactory technical reviews that were taking place. This should be a Chapt er 8 - Change Wil l Happen clue to management that resistance may be part of the picture. Todd may not be aware of his personal interest in Chapt er 9 - the Tipssystem, for Managing Change I ssues durthis ing is Developm entopportunity for the organization. redesigning but it does appear that a wasted Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Suggestions to Overcome Resistance Chapt er 11 - Ar chitect ur al Opt ions

Selecting right Chapt er 12 - Mithe ddl eTier people Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

A second set of eyes

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14resistance - Addi tional Get outSpecification in the open Details Chapt er 15 - Qui ck Reference Guide

The challenge for management is to find a way that Todd’s abilities can be used in a positive way, rather in the I ndex negative way that has emerged in this situation. If no answer can be found, it is probably better for Todd that he try List of Fi gures to move on before his technical skills become out of date. Although his relationship with the CEO might seem to make him invulnerable to change, a better point of view would be to use that relationship to help him find a fit where his skills would be of use.

The Elephant in the Room George was a vice president of benefits who saw his organization as excelling at providing specific internal services to their employees. He wanted a system that, as he described it, would be the “Cadillac of systems” to support those services. Having established himself as an internationally recognized expert in this area of internal services, he had convinced upper management to fund this effort. Early on, an outside consultant was brought in by the IT department to help define the needs of this internal system. It was clear to the consultant that there were several commercial systems on the market that would easily support the needs of these internal systems. The IT department told the consultant to not bring up this possibility because it was important to George to build his own system and George was a VP. In fact, George saw the organization eventually selling his “Cadillac” system to other organizations. Building such a system was more expensive than buying one on the market. No one in IT, however, ever brought up the idea of buying a commercial product rather than building one. While this system was being built, the organization’s income decreased significantly in areas independent of the development effort. As a result, it was determined that it did not make sense to spend this much money on such a fancy internal system. The project was canceled after already spending many times more money than a commercial product would have cost.

Resistance Issues Not invented here

Power of internal “expert” W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Our problems are special

ISBN:1558609067 by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Telling the truth about technology can be a politically painful event, especially when people in high places are the both pr actical ship and chitectur al with adv ice on how t o prof epar e an management. or ganization to t ak e people who needProv theides message. Many aleader manager has ar had to deal a “pet project” upper advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Suggestions to Overcome Resistance Table of Contents

Back Cov er

Communicate at many levels

Com m ents

Ta ble o f Con t en t s

Get resistance out in open Web Ser vices and Ser viceOrthe iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

This is a case when “managing up” would be a good idea. In this scenario, no one even raised the idea that commercially available software might work as well. Carefully planting the idea that this is possible could be done in Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew many ways so that the VP could get the message clearly. The VP’s need to have a special product might also have Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e been addressed on another project. I ntr oduction

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Issues Ser vice- O rien t ed Responses Archit ect u re: T h e Sa vvy Man ag er 's Gu id e WorksheetWfor Change and ISBN:1558609067

by Douglas K. Barr y

The resistance scenarios provide examples of change Mor gan Kaufm ann some Publ ishers ?2003 (245 pages) issues and the possible responses. Of course, you may Figure 8.4toprovides have other change issues in your organization that may benefit from different sorts responses. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o of pr epar e an or ganization t ak e a worksheet youadvantage can use toofthink restraining forces you may have added Figure possible responses Webabout ser vices and ser viceor iented ar chitectur es, bri to dging t he 8.3 gap and bet ween the datacentr ic and t he software engineer ing wor lds. you could consider. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I Figure I - Ma na8.4: gi ngChange Cha nge issues N ee de dand for responses a Ser v i ce - Or ie nte d Ar chit e ct ur e worksheet.

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d for Ser viceO rien t ed Archit ect u re: T h eOriented Sa vvy Man agArchitecture er 's Gu id e Consolidated Analysis Adopting a Serviceby Douglas K. Barr y

ISBN:1558609067

Figure 8.5 consolidates driving andishers restraining technical Mor gan the Kaufm ann Publ ?2003 (245 pages) forces from Figure 8.2 and the driving and restraining forces related to Prov change from Figure 8.3. The restraining technical forces that willt ofade away over time (the ones ides both pr actical leader ship and ar chitectur al adv ice on how pr epar e an or ganization to t ak e shown in gray in advantage Figure 8.2)ofhave removed figure. Figure 8.5 that using Web Services reduces Web been ser vices and serfrom vice-this or iented ar chitectur es,shows bri dging t he gap bet ween the datacentr ic and restraining t he softwarethe engineer ing of wor lds. the technical issues adoption service-oriented architectures and leaves us with business, design, and change issues. Business and design issues will always be with us. Change issues will form the biggest Table of Contents Back Cov er Com m ents obstacles to the adoption of service-oriented architectures. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 8.5: Force field analysis of adopting a service-oriented architecture.

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Web Services are rapidly removing many of the technical restraining forces related to adopting a service-oriented Mor gan Kaufm ann Publ ishers ?2003 (245 pages) architecture. At the same time, Web Services are adding technical driving forces adoption. As a result, Prov ides both pr actical leader ship and ar chitectur al adv ice on how ttoward o pr epar e an or ganization to t the ak e primary restraining forces within organizations of service-oriented architectures to dothe with advantage of Web ser vices and for seradoption vice- or iented ar chitectur es, bri dging t he gaphave bet ween data- centr ic t he software engineer ing wortolds. business issues,and design issues, and resistance change. Business and design issues are part of developing any architecture. Change issues, however, could trip up the adoption of a service-oriented architecture. Ways to identify Table of Contents Back Cov er Com m ents and overcome resistance were covered in this chapter along with scenarios of various forms of resistance. The next Tachapter ble o f Con en t s willt expand on dealing with resistance by providing some tips for managing change issues. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby9: Tips for Managing Change Issues during Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Development

Overview

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Table of Contents Back Cov er is aCom m entsactivity with many tasks to accomplish, usually with many restraints as Developing information systems complex with any Tawell. ble oAs f Con t en t s human endeavor, there are easy ways and hard ways to do anything. This chapter will provide tips on how to make development easier. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

The tips in this chapter come from my development and consulting experiences since the mid-1980s. They are not intended to be comprehensive. Nevertheless, these tips just might help you with managing change issues during Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew development. I ntr oduction Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

ChaptNote er 2 According - I nfor m atto iona Technology study by theUsed Standish in Thi sGroup, Tri p nearly a quarter of commercial software projects were

2000. Poor were cited as the primary reasons. The Chapt er 3 canceled - Ser vice-outright Or ientedin Ar chi tectur esplanning and Weband Servmanagement ices canceled projects firms $67ofbillion. Projects notOther canceled had overruns of $21 billion. Software For ces Affecti ng cost the Adoption Web Ser v ices and I ntegr ation Techniques related to repairing defects averages 80 percent of IT budgets.[1] maintenance [1] The Chapt er 5Standish - Growing Group, I mpact CHAOS of Web Report, Serv ices 2000. Chapt er 4

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Design as Little as Possible ISBN:1558609067

by Douglas K. Barr y

If you haven’t experienced “analysis paralysis,” you(245 arepages) a rare member of our profession. The design of a system Mor gan Kaufm ann Publ ishers ?2003 can sometimes seem as if it will go on forever. Based on my experience, internally and externally to to t ak e Prov ides both pr actical leader ship and ar chitectur al adv ice both on how t o pr epar e an or ganization organizations, the best tip Iofcan give isand to design asorlittle asarpossible. soundt he counterintuitive, butdatamostcentr of ic advantage Web seryou vices ser viceiented chitectur It es,may bri dging gap bet ween the and t he I software engineer ing wor the successful projects have seen are based onlds. as little design as possible. How do you do this? Two suggestions are to buy a system or buy a model. Either of these tips will narrow the amount of design that you must do. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s

Buy a System

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor you d When buy a software package, you are essentially leveraging a system that you can plug into your overall I ntr oduction Doing this will limit the design work needed. You can focus on the connections in your architecture and architecture. Pa r t Iunique - Se r viparts ce- O r of ie nt Aryou chi temust ctur edesign Ov er v ifor ew the it ed that

Chapt er 1

yourself.

- A Business Tr ip in the Not- Too- Distant Futur e

When be sureUsed theyincan in a service-oriented architecture. As Web Services are Chapt er considering 2 - I nfor mpackages, at ion Technology Thi sparticipate Tri p adopted industry, will also become increasingly possible to buy “plug-compatible” software Chapt er 3 throughout - Ser vice-our Or iented Ar chiittectur es and Web Serv ices components For thatces you can assemble into a service-oriented architecture. Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Chapt er 4

-

Techniques

The change issues you will likely encounter are:

Chapt er 5

- Growing I mpact of Web Serv ices

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Feeling Chapt er 6 - that jobs may be threatened. Yes, in many cases they might be. You will need to plan for this Ar chitect ur es

eventuality.

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I IOur - Maproblems na gi ng Cha ngespecial. N ee de d Yes, for a there Ser v i ce - Orprobably ie nte d Arsome chit e ct ur e are are special

problems, but should they be driving your

Chapt er development? 8 - ChangeInWil the l Happen rare case, I have seen this to be true. In most organizations, however, there aren’t special

problems andforif Managing you look at the problems in a way, Chapt er 9 - Tips Change I ssues dur ingdifferent Developm entit is possible to see how software packages can Pa r t I Iaddress I - Cr e a tithose ng S erproblems. v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Buy a Model

Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

If there are- good not buyTraipsoftware package, you don’t Chapt er 13 Rev isireasons ting the to Business in the NotToo- Distant Futur eneed to start with a clean sheet of paper. There are models for purchase that yare most segments Pa r t Idata V - Com pe ndiavailable um of Softw a r e Te chnolog forapplicable S er v i ce - Orto i e nte d Ar chit ect ur eofs

industry. Often these are referred to

as universal models. Universal Details data models can work with both data warehouses/master databases (see pages Chapt er 14 - data Addi tional Specification 50 and 133) middle-tier databases (see page 175). Chapt er 15 - or Quiwith ck Reference Guide I ndex

I cannot begin to tell you how many times I have seen people struggling to model the same data repeatedly. Frankly, how many different ways are there to model customers, employees, addresses, products, and so on? Yes, there are variations among companies. But, if you look at the universal data models, many of those variations are handled in elegant ways. In fact, usually very experienced data modelers develop the universal data models—often these folks are more experienced than any modelers you might find in your organization. Months—yes, months—of modeling efforts in an organization fall short of almost any universal model you might be able to purchase. And, if you need to add something to these models, it is usually a minor addition requiring minor modeling.

List of Fi gures

The change issues you will likely encounter are: Lack of training/understanding. The plain fact of the matter is that when confronted with a universal data model, many people don’t see how it will work. Often, it is because they are stuck in their paradigm of how the system should work, based on what they’ve experienced. They are simply trying to “map” the current system or their understanding of the current system, however limited it may be, to the universal data model. This is a stretch for many people. The best way to handle this is to bring in the developer of the universal model to explain how it will handle the needs of your systems. Power of the internal “expert.” Oh my goodness—bringing in a universal model can really threaten this person. Telling anyone that a purchased product will be better than something that this person, an expert after all, could put together, is a very difficult sell. You will need to plan for significant resistance here. The previous chapter provides some suggestions. Not invented here. It is really tough to realize that other people have actually addressed many of your modeling issues. Even worse is the possibility that someone else may have done a better job. Our problems are special. This might be true around the fringes of a universal data model. In a rare case, it might be true for the model itself. But, be sure to thoroughly search for universal data models before accepting your problems are truly special.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Write as Little Code an asd Ser Possible by Douglas K. Barr y

ISBN:1558609067

This sounds a bitMor facile, but it is true. Time and again, see people writing more code than necessary. Couple this gan Kaufm ann Publ ishers ?2003 (245 Ipages) [2] you want to with the fact thatProv on average, professional coders make 100 to 150 errors per thousand lines ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e anoforcode, ganization to t ak e write as little code as possible just ser to minimize errors. advantage of Web vices and the ser viceor iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Of course, buying systems and buying models will reduce the code you write. You should consider those options Table of Contents Back Covare er adopted Com m ents first. Again, as Web Services throughout our industry, it will become increasingly possible to buy “plugcompatible” software components that you can assemble into a service-oriented architecture. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

If you have to write code, take a serious look at the systems you have. How many times have you written the same code to validate a customer account? I know some managers who have been able to identify the relatively few I ntr oduction procedures they have that have been written repeatedly. Factor those out. You might save as much as 50 percent Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew on future development. Chapt er 1 - study A Business Tr ip in the Not- TooDistant by Futur e [2] Multiyear of 13,000 programs conducted Carnegie Mellon. For ewor d

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Reduce Project Scope by Douglas K. Barr y

ISBN:1558609067

[3] are emphasizing reduced project scope and reduced project times. Some of the newMor development methodologies gan Kaufm ann Publ ishers ?2003 (245 pages) It is so tempting Prov to create big projects. The manager to come ways scope of each ides both pr actical leader ship and has ar chitectur al up advwith ice on howtot ominimize pr epar e the an or ganization to t ak e project. Multiyearadvantage projects are unthinkable. Twelve-month projects should es, be looked skeptically. Thethe challenge to ic of Web ser vices and ser vice- or iented ar chitectur bri dgingatt he gap bet ween data- centr t he software lds. the manager is toand create projects engineer that caning be wor completed in less than 12 months.

Table oftoContents Back Cov er isCom m ents Related reducing project scope building a service-oriented architecture incrementally. Part III provides specific suggestions in this area. Ta ble o f Con t en t s [3] or extreme programming are currently being promoted. They are part of a WebVarious Ser vicesagile and programming Ser vice- Or iented Ar chit ectur es—The Sav techniques vy Manager 's Guide long line of efforts to improve the quality of programming at the same time reducing development time and cost. For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Use a Methodology by Douglas K. Barr y

ISBN:1558609067

In more than 10 Mor years consulting, I have rarely encountered companies that are really using any software ganofKaufm ann Publ ishersonly ?2003 (245 pages) methodology. Sure, they may say they are, but in reality they arealstill “shooting from the hip” when developing Prov ides both pr actical leader ship and ar chitectur adv ice on how t o pr epar e an or ganization to t ak e software. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Any methodology is better than no methodology. Yes, you can argue as to one being better than another, but the Table of of Contents Coviferyou truly Com m ents any methodology, you are going to be much better off than just plain fact the matterBack is that follow [4] lip service Tapaying ble o f Con t en t s to the methodology or simply not using one. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

To really take advantage of a methodology, invest in a tool that supports the methodology. Paper systems or drawing tools that are not integrated with the methodology are not very helpful. It also allows people to slide by on I ntr oduction the rigors of any particular methodology. Pa I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew [4]r tOne person who reviewed this manuscript commented that methodologies could be used as another form of Chapt er 1 - He A Business Tr how ip in entrenched the Not- Too-experts Distant Futur resistance. described in aneorganization can use methodologies as a covert means to Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p ensure a project gets nowhere because of “the demands of the methodology.” A variant of this would be using Chapt er 3 - Serinappropriate vice- Or iented for Ar chi es and Web Serv ices methodologies antectur organization, thereby slowing development. I guess you need to be ever vigilant For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation to resistance Chapt er 4 - issues. For ewor d

Techniques

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Use a Second Set ofanEyes by Douglas K. Barr y

ISBN:1558609067

Many methodologies involve having at ishers least one other person look at any particular piece of work. Using a “second Mor gan Kaufm ann Publ ?2003 (245 pages) set of eyes” is critical. The trick, however, is really using a second Have a big roomtofort ak code Prov ides both pr actical leader ship and ar chitectur al set adv of iceeyes. on how t o pryou eparbeen e an in or ganization e reviews where the programmer describes is going in the programes, andbrieveryone or ween less nods theircentr wayic advantage of Web ser viceswhat and ser vice- oron iented ar chitectur dging t hemore gap bet the dataand How t he software ing wor lds. through the review? good is engineer that really? Methodologies that require someone other than the author to describe what is going on in an architecture, design, program, and so on, are much more effective. It requires that person’s Table of Contents Back Cov er Com m ents second set of eyes to really look and that second mind to really understand. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Use Small WTeams by Douglas K. Barr y

ISBN:1558609067

For years, I haveMor been that people think of the communication issues in software development to be ganrecommending Kaufm ann Publ ishers ?2003 (245 pages) much like a dinner party. When you have a dinner party of sevenaloradv less, usually one to t ak e Prov ides both pr actical leader ship and ar chitectur ice it onishow t o prpossible epar e an to orhave ganization conversation. Asadvantage soon as you haveser eight more at the ar table, the es, dinner partytbreaks two conversations of Web vicesorand serpeople vice- or iented chitectur bri dging he gap into bet ween the data- centr ic and t he software ing wor lds. and no one hears everything that engineer was said. Table of Contents Back Cov er Comdevelopment. m ents This is often what happens in software Communication is critical. Use a small team. Put them together in a big room. Let them focus on development of their project; that means that the project is the only thing they are Ta ble o f Con t en t s doing. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

As stated at the Mor outset this chapter, these ?2003 tips came from my development and consulting experience since the gan of Kaufm ann Publ ishers (245 pages) mid-1980s. TheyProv are ides meant to improve your chances of being successful with your both pr actical leader ship and ar chitectur al adv ice on how t o development pr epar e an or efforts. ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

The next part of and the book providesengineer some suggestions t he software ing wor lds. for reducing the scope of projects related to creating serviceoriented architectures. It also provides specific suggestions for buying systems and reducing the code written. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Part III: Creating Service- Oriented Architectures by Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Chapter 10: Architectures at Each Stage of Adoption for Web Services

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Chapter 11: and Architectural Options t he software engineer ing wor lds. Chapter 12: Middle-Tier Architecture Table of Contents Back Cov er Com m ents

Ta ble Chapter o f Con t en t s Revisiting the Business Trip in the Not-Too-Distant Future 13: Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

In Part III, the focus shifts to the creation of service-oriented architectures. Referencing the stages of adoption for Web Services and service-oriented architectures, Chapter 10 illustrates possible architectures for each stage. In Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew addition to technical issues, staffing and change issues are covered for each stage as well. Several basic Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e architectural options for service-oriented architectures are introduced in Chapter 11. Using a middle-tier architecture Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p is one of the options covered. Middle-tier in-memory caching options along with the issues surrounding a middle-tier Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices application cache are reviewed in Chapter 12. This chapter also considers the advantages of middle-tier persistence For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation options. in Chapter 13, C. R.’s business trip from Chapter 1 is revisited with the details about the Web Chapt er 4 Finally, Techniques Services and service-oriented architectures used in the story, as well as some of the architectural options used. I ntr oduction

Chapt er 5

- Growing I mpact of Web Serv ices

Ser into vice-these Or iented Ar chi tectur es andthat Beliefs Enterwith pr ise Before architectures, note theyabout will work either Java application servers or .NET. You will Chapt er 6jumping Ar chitect ur es

not see any references to either environment, and the generic “application server” will be used instead.

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby10: Architectures at Each Stage of AdoptionISBN:1558609067 for Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Web Services

Overview

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Table of Contents Cov erarchitectures Com m entsto consider at each stage of adoption for Web Services and serviceThis chapter illustratesBack possible architectures. In addition to technical issues, staffing and change issues are covered for each stage of Taoriented ble o f Con t en t s adoption. The stages of used in this chapter were first introduced Web Ser vices and Ser vice- adoption Or iented Ar chit ectur es—The Sav vy Manager 's Guide in Chapter 7. For ewor d

Architectures will be introduced at each stage of adoption. This is not intended to replace other methodologies. Rather, practical suggestions are provided that can be used with design methodologies.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt 1 the - Alength Business Tr ip is in not the provided Not- Too- Distant Futur e of adoption. The time each stage may take is entirely Noteerthat of time for each stage Chapt dependent er 2 -on I nfor themorganization, at ion Technology its needs, Used in and Thiits s Tri culture. p Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser viceO rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Stage 1. Experiment with Web Services ISBN:1558609067

by Douglas K. Barr y

The best way to Mor get gan started with Web is to start with small projects that have a high chance of success. Kaufm ann PublServices ishers ?2003 (245 pages) Keeping the useProv of Web Services to something basic further enhances the success. a project ides both pr actical leader ship and ar chitectur al adv ice onchance how t o of pr epar e an orChoose ganization to t ak e that will be helpful, but not vital. Choose team likearto play with Andbet beween sure the to data- centr ic advantage of Web ser vices andmembers ser vice- orwho iented chitectur es, possibilities. bri dging t he gap and software engineer ing wor lds. communicate that thet he project is an experiment. Table of Contents

Back Cov er

Com m ents

Use an External Service Ta ble o f Con t en t s

Web Ser vices Serbasic vice- Or iented chitis ectur es—The Sav vy Manager Guide Probably theand most place to Ar start using an external service. 's They are many simple external services from For eworto d choose. For example, you could get weather or stock information or track packages. More examples of which I ntr oduction relatively simple external services can be found at www.xmethods.net. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Figure anthe external service. Chapt er 10.1 1 - illustrates A Businessusing Tr ip in Not- TooDistantSuch Futuran e experimental project would provide experience at using SOAP, Universal Description, Discovery, and Integration (UDDI) or other directories, and using Web Chapt er 2possibly - I nforusing m at ion Technology Used in Thi s Tri p Services Language (WSDL) and XML sending Chapt er 3 Description - Ser vice- Or iented Ar chi tectur es and Webfor Serv ices and receiving messages. For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List ofFigure Fi gures10.1: Using an external service.

Using an external service will help your organization try Web Services without a large outlay of time and money. It will give you an idea of how Web Services work and where you might want to try your hand at developing an internal service.

Develop an Internal Service Developing an internal service allows your organization to get more deeply into development. There are two options for developing an internal service. The first is to develop an entirely new service that uses Web Services. For most companies, a second option of developing a service that uses some existing system would provide experience more in line with how Web Services will be used internally. Figure 10.2 shows an internal portal accessing a mainframe or other internal system via Web Services. Examples of such access include obtaining customer contact information or internal employee telephone numbers.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

ChaptFigure er 5 - 10.2: Growing I mpact Web Serv Using Web ofServices in ices a portal with a mainframe system. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es the development of an adapter that transforms a SOAP message containing XML into an This experiment requires Chapt er 7 St ar ti ng t Adopt Seraccepted vi ce- Or iented Ar chitectur e system. This project builds on the experience of using existing record format othat cana be by the mainframe Pa r t I I - with Ma naan gi ng Cha nge N ee deand d foradds a Sercomplexity v i ce - Or ie nte Ar chit e ct ur an e SOAP external service byd developing

adapter. Of course, if your organization is

Chapt 8 -toChange Happen this would be an opportunity to buy a commercially available adapter for an moreerlikely buy all Wil its ladapters, Chapt er 9 Tips for Managing Change I ssues into dur ing existing system and incorporate that adapter thisDevelopm project. ent Nevertheless, even if your organization will most likely Pa r t I its I I -adapters, Cr e a ti ng building S er v i ce - aO simple r ie nt ed adapter Ar chi te ctu r esbe buy may

a good learning experience. Building an adapter will give your

Chapt developers er 10 - aAr deeper chitect ur understanding es at Each Stage of the of Adopti functions on for of purchased Web Ser vices adapters. Chapt er 11 - Ar chitect ur al Opt ions

Exchange Data between Existing Systems

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa t I V -organization Com pe ndi umis of Softw r e Te chnolog y for Sto erexchange v i ce - Or i e nte d Ar chit ect urexisting es Ifryour likely to ause Web Services data between

internal systems, then it would

Chapt be appropriate er 14 - Addi totional add an Specification experimental Details project that does just that. Figure 10.3 illustrates this exchange of data

between Chapt er 15internal - Qui cksystems. Reference Guide I ndex List of Fi gures

Figure 10.3: Using Web Services to exchange data between internal systems. This project uses the experience from the last experimental project of building or using a commercially available adapter. In this project, however, two internal systems exchange data. For example, both systems A and B may allow users to enter customer address and contact information. If one system updates this customer information, the other system should also receive the update. Another example might be that system A has the master account for customer information and system B may request system A to validate that a customer identification number is correct. Both systems A and B would need adapters. The development would require agreement on the semantics of the XML messages exchanged by the adapters. This would create the opportunity to investigate and possibly use the XML tags provided by standards efforts in your industry.

Develop a Simple Message Router W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Many organizations are also likely to use a message router in a service-oriented architecture. The message router ISBN:1558609067 bythe Douglas K. Barr y tag to see which systems might need to receive the data. Figure 10.4 will need to check XML message shows Mor gan Kaufm ann Publ ishers ?2003 (245 pages) the use of a message router. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.4: Using a simple message router with Web Services. An example similar to the last experimental project would be where both systems A and B may allow users to enter customer address and contact information. All three systems in Figure 10.4, however, would need to receive this information. A message router would be set up to receive all the customer updates and then route the updates to the appropriate systems. It also might be possible that system C uses a commercial adapter that uses different XML tags. This is shown in the XML message fragments in Figure 10.4. The message router would need to be capable of converting the XML tags in addition to routing the message. The intent of this experimental project is to gain appreciation of the issues related to message routing as well as experience in developing a message router. Even if your organization is likely to buy a commercial message router, it may be worthwhile to develop your own for this experiment. Much like writing your own adapters, building a simple router may be a good learning experience and building a router will give your developers a deeper understanding of the functions of purchased message routers. Nevertheless, don’t overcomplicate this experimental project. Limit the project to routing one or two messages.

Staffing in Stage 1 It is important to pick the right people to do this experimentation. Frankly, in most situations, it is risky to involve people who have never expressed much interest in trying something new. Instead, choose people who like to experiment and take risks. For many organizations, it would be good to bring in someone from outside the organization who is familiar with Web Services and service-oriented architectures to mentor developers through the experiment. The mentor would be a “second set of eyes” during this experimentation stage and would be a great source of information. Keep the experimentation team small. A few people would be appropriate for most organizations.

Likely Change Issues in Stage 1 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr The most likely change issues you ywill encounter in this stage are:

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Lack of training/understanding. This isship a rational concern.al People arehow going to epar need training on Webto t ak e Prov ides both pr actical leader and ar chitectur adv ice on t o pr e an or ganization advantage of Web ser vices and serYou vice-will or iented bri dging t training he gap bet data- centr Services and service-oriented architectures. need ar tochitectur find thees, appropriate forween thosethe involved in ic and t he software engineer ingbe wor lds. to dispel any misunderstandings concerning Web Services and the experimentation. Also, you need to ready service-oriented architectures.

Table of Contents

Back Cov er

Com m ents

Ta ble oInertia—why f Con t en t s change ? Be prepared to communicate on many levels and in many ways why you want this

experimentation to occur. BeAr available personal chats. Be prepared, Web Ser vices and Ser viceOr iented chit ectur for es—The Sav vy Manager 's Guide as well, to really listen to concerns expressed. For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed u re: T h e Sa vvy Man ag er 's Gu id e Stage 2. Adapt Existing Systems toArchit UseectWeb Services ISBN:1558609067

by Douglas K. Barr y

Once you have some experience using or ?2003 building look for some places in your existing systems where Mor gan Kaufm annat Publ ishers (245adapters, pages) using Web Services could save time and money in the short term. If your organization is like many others, you Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t might ak e have some type advantage of commonofdata is replicated, which could ar bechitectur an opportunity. Fort he example, havecentr ic Webthat ser vices and ser viceor iented es, bri dging gap betyou weenmight the dataanddata t he in software ing These wor lds.might be systems that were developed over time in separate common customer multipleengineer systems. departments or purchased software packages. They might be systems used by other organizations that your Table of Contents Back Cov er Com m ents organization has acquired over time. In any case, the systems are likely to be different, have replicated data, and in Tasome ble o fcases, Con t en ts inconsistent data. If there would be an advantage to creating more visibility of customers for such purposes asand cross-selling departments, creating new packages of products for specific customers, or simply Web Ser vices Ser vice- Oramong iented Ar chit ectur es—The Sav vy Manager 's Guide reducing For ewor d waste in misrouted or duplicated mail, this may by a worthwhile project to consider. I ntr oduction

This section will provide step-by-step suggestions for using Web Services with a customer master file. The same steps should apply to other types of master data.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Create Master Database Chapt er 3 -aSer vice- Or iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 people, For some the very idea of creating any type of master file is discouraging. Many of us have had the Techniques

experience failed efforts master Chapt er 5 - ofGrowing I mpacttoofcreate Web Serv ices files (see page 162). Here are some tips: Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 an - existing master file. You might already have a master file that is part of packaged software your Use Ar chitect ur es

organization already owns. It might make sense to adopt that as the master file. If you do not have a master file - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e in packaged software your organization owns, but are considering the purchase of packaged software, check to I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e see if the software being considered includes a master file.

Chapt er 7 Pa r t

Chapt er 8

- Change Wil l Happen

Chapt er 9 a- model. Tips forThis Managing ssues dur ing Many Developm ent can be purchased. Sometimes they are referred to Buy optionChange is oftenI overlooked. models Pa r t I Ias I -universal Cr e a ti ng data S er v imodels ce - O r ie(see nt ed page Ar chi te ctu r es 120). The

plain fact is that, although every organization is unique in some

Chapt er 10 most - Ar chitect es atis Each of Adopti for Web there Ser vices way, of theurdata prettyStage standard. Foronexample, are practical and flexible models for keeping basic Chapt er 11 - Arinformation chitect ur al Opt ions customer such as addresses and other contact information. Often, these models are simply better Chapt er than 12 any - Mione ddl eorganization Tier Ar chitectur might e build. Experienced modelers who have created models for many organizations

usually people who design you buy a model, you should resist any efforts to extensively Chapt er 13 - are Rev the isi ting the Business Tr ip these in the models. Not- Too-IfDistant Futur e modify theofnext tip.a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Pa r t I V - Comit. peSee ndi um Softw Chapt er 14 - Addi tional Specification Details

Don’t start a modeling project. A modeling project opens your organization to any number of restraining forces including: our problems are special, power of an internal expert, and lack of training and understanding. I ndex The lack of training and understanding is significant. Data modeling appears deceptively simple until you get into List of Fi gures it. Even if you are doing something as basic as a customer master, you can get yourself pretty knotted up in the options of data modeling. A modeling project also is an opportunity for people to add “bells and whistles” to a basic model. Starting a modeling project is essentially creating an environment for “analysis paralysis.” Chapt er 15 - Qui ck Reference Guide

Start small. Your master file does not need to be perfect. It simply needs to be useful or effective. Also, you can always add to your master file. So, if either a purchased master file or a purchased model have many fields you could populate, try to limit the master data to what might be most useful. Don’t make the project any larger than it needs to be. You can always add more data to the master file later. Figure 10.5 shows a customer master file at the left of the figure. At the right is an existing internal system, and existing applications are above the existing system. Those applications will remain unchanged in this process with one exception. Once customer master data from the existing system is moved to the master file, the existing applications may no longer update customer data. The reason for this will be explained in a little while.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I Figure - Se r vi ce10.5: O r ie Creating nt ed Ar chi a customer te ctur e Ovmaster er v i ew

Chapt er 1

database.

- A Business Tr ip in the Not- Too- Distant Futur e

Mosterorganizations have multiple sources ofThi customer Chapt 2 - I nfor m at ion Technology Used in s Tri p data in their existing systems. This process will start with one

existing system and then move on to others. To pick the first existing system, it might be one that is easy in some - Ser vice- Or iented Ar chi tectur es and Web Serv ices way. One way a system might be easy is that the data might be particularly accurate. Another way is that it might be For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt easyerto4purchase or develop a Web Services adapter for a system. Read through the rest of the steps in this stage Techniques to see the requirements for this adapter. Chapt er 5 - Growing I mpact of Web Serv ices Chapt er 3

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 a -master file is a good time to make sure the data you are using is the best possible. This process is often Creating Ar chitect ur es

called data cleansing. Data cleansing can become a large project in itself, depending on the existing system and the - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e number of existing systems that will be used for the customer master. You might consider purchasing an extract, Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e transform, and load (see page 224) software product if you expect to use many existing systems that will require Chapt er 8 - Change Wil l Happen significant data cleansing. Chapt er 7

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa I I I point, - Cr e a ti ng S er v i ce - O r ie data nt ed warehouse Ar chi te ctu r es Atr t this some enterprise (EDW)

advocates are thinking that I have oversimplified what needs

Chapt 10 - In Ara chitect ur Ieshave, at Each of Adoptithis on for Web Ser to beerdone. sense butStage only because master filevices is not an EDW. It is a small master file. It might grow Chapt er 11 - Arbut chitect Optentirely ions different project. At this point, the master file is meant to achieve a limited goal of into an EDW, thaturisalan

consolidating small amount of data—in this example, customer master data. Chapt er 12 - Miaddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Connect Components to Web Services

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

Chapt Figure er 10.6 15 - shows Qui ck Reference the three components Guide that are connected to Web Services. The first is the customer master

database that has just been populated. The second is the message router. And the third is the existing system using I ndex a Web Services adapter. The experiments performed in the last stage should help you decide if you want to build or List of Fi gures buy the message router and/or the adapter for your existing internal system.

Figure 10.6: Connect components to Web Services.

Routing Master W eb Services Database an d Ser viceUpdates O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

The experimentsMor with a portal stage one will help(245 with this next step. Figure 10.7 shows adding an internal portal gan Kaufm in ann Publ ishers ?2003 pages) to this architecture. The portal will allow the user to read data from the internal existing system as well as the Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e customer master. It will alsoofallow to the master. It would to you if this advantage Web updates ser vices and sercustomer vice- or iented ar chitectur es,be briup dging t he to gapdecide bet ween theportal data- centr ic should be expanded and tto healso software allowengineer updatesing to wor the lds. existing internal system. Doing so would require adding additional message capabilities to the adapter for the existing internal system. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.7: Routing master database updates. The customer master system would perform two actions. First, it would attempt to update the customer data with the incoming data. If the update should fail for some reason, the appropriate error message is returned. If the update is successful, then the data used for the update is passed to the message router. At this point in development, all customer master update capability in the existing applications needs to be disabled. Updates will come only from the customer master and through the message router. The existing system will have its customer data updated so that any existing applications needing to read that data from the existing system will continue to be able to do so. The only change is that these applications cannot update the customer master data that resides in the existing system. By restricting updates to the customer master file, it is, in theory, possible to maintain the quality of data and consistency of customer master data. This is preserving the work done in the data cleansing stage.

Add Additional Systems For each additional system, repeat the data cleansing and populating of customer master data. This might be an intensive process if you find inconsistencies among the data sources. Many of these inconsistencies will not be able to be resolved using programming. For example, if the same customer has two different addresses, it will be necessary for a person to determine if the addresses should be the same or if they represent two different locations of the same customer. Eventually, the architecture will look like Figure 10.8.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e ChaptFigure er 13 - 10.8: Rev isiUsing ting the a portal Business andTrmaster ip in the database. Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

You er might to have different portals Chapt 14 decide - Addi tional Specification Details for different departments that use different existing systems. This would allowertailoring ofck the portals toGuide best meet the needs of the particular department. Chapt 15 - Qui Reference I ndex

Keep in mind that the master database could evolve into a data warehouse or a data mart. There is no requirement

List Fi gures thatofan organization necessarily have a single data warehouse. A group of cooperating data marts might work just

as well or better. A lot depends on the needs of the organization.

Message Router Options Whether you build or buy a message router, there are options you should consider. These are shown in Figure 10.9.

Figure 10.9: Message router options. eb Services d Ser vicerien ed lower Architleft ectquadrant u re: T h e of Sa Figure vvy Man 10.9. ag erIt'sdoes Gu idnot e store messages The basic routerWincluded in thean figures so farOis in tthe and, should the machine it isK.running Also, ISBN:1558609067 by Douglas Barr y on fail, there is no secondary machine to take over to pass messages. any messages inMor transit might ann be lost the time failure. gan Kaufm Publat ishers ?2003of(245 pages) Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

A more sophisticated type of router in vicethe upper leftarquadrant. It stores messages. This means that centr a ic advantage of message Web ser vices andisser or iented chitectur es, bri dging t he gap bet ween the datamessage sent toand thet message router can ing be viewed he software engineer wor lds. as being sent once the message router acknowledges receipt of the message. Since the messages are stored in some way, even if this message router should fail, all messages Tableeventually of Contents Backon. Cov er Com m ents would be sent Nevertheless, like the last router, there is no secondary machine to take over to pass messages should the primary machine fail. This means that if the message router is unavailable, no messages will Ta ble o f Con t en t s be routed until it becomes available. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

The two right quadrants represent highly available message routers. This is achieved though application server clusters or some other means of one application taking over for another. The lower right message router, however, Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew runs the risk of a message getting lost at the moment one machine takes over for another. The upper right message Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e router takes care of this issue by replicating the data. This, however, might slow down messaging. Nevertheless, if it Chapt er 2 to- your I nforarchitecture m at ion Technology Used in Thi s Tri palways be available and never lose a message, you should is critical that a message router Chapt er 3 a -router Ser viceientedinAr chiupper tectur es andquadrant. Web Serv ices consider as Or shown the right I ntr oduction

Chapt er 4

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Database Options - Growing I mpact of Web Serv ices

Chapt er 5

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 message Mucher like there are basic options for databases that need to be considered. These are shown in Ar chitectrouters, ur es

Figure 10.10. - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.10: Database options. A basic database system is shown in the lower left quadrant. This is the database shown in the figures so far. As with any database system, it will protect all data that is successfully updated even if the machine on which it is running should fail. Nevertheless, this does not provide for a secondary machine to take over should the primary machine fail. It also does not provide options for load leveling through using more than one machine. Load leveling spreads activity or load across more than one machine. The lower right quadrant shows a database system that uses replication. It provides for a secondary machine to take over should the primary machine fail. The data is replicated which means, depending on the type of replication, data will be available on the secondary machine should it need to take over when the primary machine fails. (Replication options will be covered later in this chapter.) The two upper quadrants show distributed databases, which is one way to load level access to the database. Databases can be distributed in the same location or in separate geographical locations. It is really a design issue. Not every system would need a distributed database, which can add complexity to a system. Nevertheless, there are architectures that can benefit from distributed databases. The upper right quadrant shows a distributed database that also uses database replication at each node in the distributed database. This is one way to achieve both load leveling of database access and high availability through database replication. Much like a message router, if the availability of the data in a master database is critical to your organization, then

you should certainly consider database replication to make the database highly available. (By the way, the figure shows one replicated database in the right quadrant. Many products allow more than one replicated database if that W eb an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e should be needed for Services your architecture.) ISBN:1558609067

by Douglas K. Barr y

Similarly, if the master is Publ pushed on?2003 access Mor gandatabase Kaufm ann ishers (245 speed, pages) then distributing the data among multiple machines is an option for loadProv leveling this access. ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Failover Options for Message Routers and Databases Table of Contents

Back Cov er

Com m ents

The process of a secondary machine taking over for a primary machine is known as failover. Figure 10.11 shows Tathree ble o ftypes Con t of enfailover ts at the right. They apply to each of the message routers and databases at the left. The Web Ser vices for andtypes Ser viceOr ientedcan Ar chit ectur es—The Sav vy each Manager 's Guide terminology of failover vary. For this reason, term is also defined at the right of the figure. For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Types failoverTrfor available ChaptFigure er 13 - 10.11: Rev isi ting theof Business ip both in thehighly Not- TooDistantmessage Futur e routers and databases. Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

The er first forms of failover are acceptable for a service-oriented architecture, but the third form, application, is not Chapt 14two - Addi tional Specification Details in most cases. It would require applications that depend on a machine being available to detect the loss of the machine. This would mean, for example, that a message router would need to detect that the primary machine for a I ndex master database has failed and then route data to the secondary machine. Conversely, the machine handling the List of Fi gures master database would need to detect the loss of the primary machine for the message router and route data to the secondary machine. This detection of machine loss among disparate components of a service-oriented architecture is too intertwined. It would be as if a videocassette recorder (VCR) would need to detect whether a television is running before the VCR would start a videotape. Chapt er 15 - Qui ck Reference Guide

Replication Options for Message Routers and Databases Both message routers and databases could take advantage of replicated data. Four types of data replication are shown in Figure 10.12. The terminology for types of replication can vary. For this reason, each term is also defined at the right of the figure.

Figure 10.12: Types of database replication for both message routers that store messages and databases.

The only type of replication that will guarantee that no data is lost at time of failover is real-time replication. All the other forms can lose some data at failover time in one way or another. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

ISBN:1558609067 by Douglas K. Barr Real-time replication, however, hasy a cost. It can double the time it takes to update the stored data in either a Mor gan Kaufm ann Publ ishers ?2003 (245 pages) message router or a database. Nevertheless, if it is important to your architecture that no data be “lost” due to Prov ides both pr actical ship to and failover, then real-time replication is theleader only way go.ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer worwith lds. how the primary and secondary sites can be used. Some Other options concerning replication haveing to do systems allow only updates on the primary (sometimes called “master”) site. The secondary (or “slave” or “ Table of Contents Back Cov er Com m ents replicated”) site exists only to receive the secondary update. Other systems allow data to be updated on either the Taprimary ble o f Con t en t s or secondary site. The first master/ slave technique is simpler. The second technique may open up Web Ser vices and Ser vice- Or iented Ar chit ectur Sav vy Manager 's Guide architectural opportunities. A lot depends ones—The your organization’s needs to determine which would be more useful. For ewor d I ntr oduction

Putting the Options Together

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 10.13 1 - Aexpands Businessthe Tr iparchitecture in the Not- TooDistant Futur e Figure shown in Figure 10.8 to take advantage of some of the options for message Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p routers and databases. Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.13: Adding high-availability for the customer master and message router. The customer master in this figure is a replicated database that uses real-time replication, which increases the likelihood that it will be available at any point in time. The message router in this figure stores messages and also uses real-time replication. A receipt returned by the message router indicates that the message router guarantees delivery as long as the final destination service is available. A receipt would only be sent once the message was successfully stored and therefore, replicated in the message router. For many organizations, having highly available master databases and message routers will be sufficient because they may be the only single points of failure that the rest of the architecture uses. If a particular service should fail, for example, the users of that service would be affected, but not all services, as could be the case if either master database or the message router should be unavailable.

In summary, highly available master databases and message routers: Reduce the W risk any onean internal system nott ed being able toucomplete dependent on data eb of Services d Ser viceO rien Archit ect re: T h e Saprocessing vvy Man agthat er 'sisGu id e from anotherbysystem. ISBN:1558609067 Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Require using fewer adapters since each internal system needs only to have an adapter that works with the Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e message router. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Reduce the possible negative impact of requests for data that are outside the normal processing of the internal system. Table of Contents Back Cov er Com m ents Ta ble o f Con t en t s

Staffing in Stage 2

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

If you look back to Figure 8.1, you will see that costs start to increase significantly in stage 2. This is because more people are getting involved. You should have at least one, perhaps two or three people who have a reasonable Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew understanding of Web Services. They can form the core of this team along with a few new people. The entire team, Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e however, should be under seven people. (See the discussion on page 123.) This is also a good time to establish the Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p methodology that will be used going forward. I ntr oduction

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Chapt er 4

Likely Change TechniquesIssues in Stage 2

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

The most likely issuesAryou will encounter in this stage are:pr ise Serchange vice- Or iented chi tectur es and Beliefs about Enter Ar chitect ur es

Lack of training/understanding. This is still a rational concern. The new people will likely need training. Don’t Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e assume that the people who have been doing the experimentation are the right ones to do the training. It would Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e be best to have the training done professionally so that any bad habits that may have crept in aren’t passed Chapt er 8 - Change Wil l Happen along. Also, be ready to dispel any misunderstandings concerning Web Services and service-oriented Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent architectures. This will likely require communication in many ways on many levels, including upper management. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - of Ar chitect ur es at “expert.” Each StageBe of careful Adopti on foran Web Ser vices Power the internal that internal expert does not sink the project in this stage. It is Chapt er 11 - Ar that chitect ur al Opt ions important you select the right people and plan for a second set of eyes for each person involved. This may Chapt er 12 counter - Mi ddl the e- Tier Ar chitectur e if he or she is on the team. help internal expert Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Our problems special. will show if vyou model. It ect willurbe Pa r t I V - Com pe ndi umare of Softw a r e This Te chnolog y forup S er i ce - buy Or i e a nte d Ar chit e simportant

to get this resistance out in the open as soon as possible so that you can deal with it. Recall the “But It’s So Complicated!” scenario on Chapt er 14 - Addi tional Specification Details page 108. It could happen to you. Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Stage 3. Remove Intersystem Dependencies ISBN:1558609067

by Douglas K. Barr y

At this point, theMor architecture starting to position yourpages) organization for more flexibility. In a real sense, it is moving gan Kaufmisann Publ ishers ?2003 (245 towards the plug-compatibility mentioned in relation to the earlieralexamples AV t systems. Prov ides both pr actical leader ship and ar chitectur adv ice onofhow o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Positioning for Flexibility Table of Contents

Back Cov er

Com m ents

In the previous stage, you probably started removing some intersystem dependencies. For example: Ta ble o f Con t en t s

1. The portals separate the user interfaces from the underlying system. They also provide a familiar browser type interface for users. In theory, it would be possible to replace underlying systems with minimal impact on For ewor d the portal. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide I ntr oduction

Pa r t 2. I - Se r vi ce- O r ie nt ed Ar chi tedata ctur esuch Ov erthe v i ew Factoring out common customer

data in this example may reduce intersystem dependencies

Chapt er and 1 -then A Business ip in the Not- Too-one Distant Futur e another. Figure 10.14 shows one such possible situation make it Treasier to replace system with Chapt er where 2 - I nfor m at ion Technology Used in Thi s Tri p the only common data shared by multiple systems is customer contact data. When this shared Chapt er database 3 - Ser viceOr iented Ar chi tectur es Web Serv system was purchased or and developed, it ices may have been ideal to have the shared database. But just

like buying AV Adoption systems,ofyou may foration that compatibility. Over time, it may For cesmonolithic Affecti ng the Web Sersacrifice v ices andsomething Other I ntegr Techniques become desirable to replace one or more of these systems with a more advanced version—perhaps from a Chapt er different 5 - Growing I mpact of Webnot Serv ices vendor—that does use the common database structure. If each of the applications can update Ser viceOrthe iented Ar chi tectur es then and Beliefs about Enter pr ise as well as read customer data, it is possible to selectively replace any of these applications since Chapt er 6 Ar chitect ur es as a separate system. (This criterion will be explained in the next section on design each can be viewed Chapt er considerations.) 7 - St ar ti ng t o Moving Adopt a customer Ser vi ce- Orcontact iented Ardata chitectur e to a customer master database could do this. Of course, if Pa r t I I - more Ma na gi ng Cha ngeshared N ee dedatabase d for a Seris v iused ce - Or by ie nte d Arthan chit e ct ur eof the systems, then the systems cannot be data in the more one Chapt er replaced. 8 - Change Wil l Happenthat shared data might be the next candidate data to add to the master file in order Nevertheless, Chapt er that 9 -you Tipscan for move Managing yourChange organization I ssuesindur theingdirection Developm of ent plug-compatible software. Chapt er 4

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.14: Shared database architecture that can be viewed as separate systems. 3. The master database and the router make it easier to add or replace software. Now a system or service added to this architecture needs: A Web Services adapter that allows master data to be updated in its system—should it need the master data. A Web Services adapter in order that other applications can obtain data. This would include any portals. Of course, the router would also need to be updated in order to provide the appropriate data in a Web Services message that is “ understandable” to the new system or service. The master database and router are also replaceable since each has a set of Web Services interfaces.

Design Considerations W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e There are two overriding design considerations for intersystem dependencies: by Douglas K. Barr y

ISBN:1558609067

1. Factor out shared data. Shared data might represent an opportunity to reduce intersystem dependencies. Mor gan Kaufm ann Publ ishers ?2003 (245 pages) “Factoring out,” does not mean removing data from the existing systems. It means moving the control of that Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e data fromadvantage the existing a master but ar continuing to update existing system of system Web serto vices and serdatabase, vice- or iented chitectur es, bri dgingthe t hedata gap in betthe ween the datacentr ic using a router as software describedengineer in the last stage and t he ing wor lds.of adoption. 2. Each service is responsible formits own state. This means that a service maintains its own data. This data Table of Contents Back Cov er Com ents could come from a master database through Web Services or it could come from existing applications. No data is updated on the side. If you want services to be plug-compatible, all messages and updates must Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide come through the “front door,” so to speak.

Ta ble o f Con t en t s For ewor d

I ntr oduction Figure 10.15 provides a variant of a shared database system. Application A is responsible for updating customer Pa r t I - Seinformation r vi ce- O r ie ntamong ed Ar chi ctur e functions. Ov er v i ew contact itsteother

Application B reads this customer contact data, but does not update

Chapt er 1 - Application A Business B Tr ip in the Not- TooDistant Futur it. Because is dependent on Application Aeto update customer data, it is difficult to create a separate Chapt er 2out- ofI nfor m at ion Technology in Thi s Tri p of this intersystem dependency. Application B does not service Application B as it nowUsed stands because

maintain state Application A updates theices customer contact data. Chapt er 3 its- own Ser viceOrbecause iented Ar chi tectur es and Web Serv For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 10.15: Shared database architecture that cannot be viewed as separate systems. When faced with a situation like that of Figure 10.15, you have two choices: 1. Factor out the customer data and plan to eventually replace both Applications A and B at the same time. This, however, would only make sense if at least one other system also uses customer data. 2. Modify Application B so that it is responsible for maintaining its own state by updating customer data. This disentangles the intersystem dependency. So, primary activities in the stage are: 1. Determine applications that maintain data redundantly. 2. Factor out the redundantly maintained data into master databases, connect to message routers, and connect the applications to Web Services adapters. 3. Determine applications that use the same data from a shared database. 4. Determine if these applications should be separate systems. 5. For those applications that could be separate systems, determine if they maintain their own state. 6. For those that do maintain their own state, factor out the data into master databases, connect to message routers, and connect the applications to Web Services adapters. 7. For those that do not maintain their own state, decide if multiple applications form one service. If so, and other applications redundantly maintain the same data, then factor out the redundantly maintained data into

master databases, connect to message routers, and connect the applications to Web Services adapters. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Staffing in byStage 3 Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Much of this work should be able to be done with the team assembled for the last stage. By now, you should know Prov ides both prand actical leader it ship and to ar chitectur advstage. ice on If how pr epar e antime or ganization t ak e whether it is a functioning team whether is able move toalthis not,t onow is the to changetothe advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic team members. and t he software engineer ing wor lds. Table of Contents Cov er m ents Likely ChangeBack Issues inCom Stage 3 Ta ble o f Con t en t s

TheSer most likely youArwill in this stage are: 's Guide Web vices andchange Ser vice-issues Or iented chitencounter ectur es—The Sav vy Manager For ewor d

Lack of training/understanding. At this point, you must make sure that management has a good understanding of what is going on. It may look like you are “churning” systems for no reason if you don’t Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew communicate effectively what is going on. Be prepared to do this communication on many levels of the Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e organization. I ntr oduction

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Power internal If es youand had an Serv internal Chapt er 3 - of Serthe viceOr iented“expert.” Ar chi tectur Web ices “expert” on the team in the last stage, decide if it is an advantage or disadvantage to continue his or her involvement. may want to keep the “expert” involved, but For ces Affecti ng the Adoption of Web Ser v ices and Other IYou ntegr ation Chapt er 4 seek an Techniques appropriate avenue for his or her participation. Chapt er 5

- Growing I mpact of Web Serv ices

Inertia—why change? all levels of Enter the organization. Be sure to get this concern out in the Ser viceOr iented This Ar chimight tecturoccur es andat Beliefs about pr ise Chapt er 6 early open to avoid Ar chitect ur espossible guerilla tactics. Once it is out in the open, you need to listen carefully to any concerns. Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Stage 4. Establish ananInternal Service-Oriented Architecture ISBN:1558609067

by Douglas K. Barr y

By this time, yourMor organization has Publ the ishers experience withpages) Web Services that will allow you to establish a servicegan Kaufm ann ?2003 (245 oriented architecture. Your experience will allow you to: Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Determine ifand yout he should use a data-centric, architecture, or combine both approaches. software engineer ing wordistributed-process lds. These choices are discussed in detail in Chapter 11. Table of Contents

Back Cov er

Com m ents

Decide if a data warehouse, business intelligence software, or agents make sense for your architecture. These Ta ble o f Con t en t s are also discussed in Chapter 11. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

For ewor d Determine if your organization can take advantage of a middle-tier architecture. Middle-tier architectures are I ntr oduction introduced in Chapter 11. Details on middle-tier in-memory caching and middle-tier persistence options are in Pa r t I Chapter - Se r vi ceO r ie nt ed Ar chi te ctur e Ov er v i ew 12.

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p “Fire” Should Come after “Ready, Aim”

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation I have Chapt er waited 4 - until this point before suggesting that you establish an architecture, because the experiences of the Techniques first three stages are critical. An architecture based on experience is much more likely to succeed than one that is Chapt er 5 Serv ices based on justGrowing readingI mpact a bookoforWeb thinking about the technology. Without anchoring an architecture in what your Ser viceOr iented Ar chi tectur es are and capable Beliefs about Enter pr ise organization really needs and your people of accomplishing, then that architecture has a high likelihood Chapt er 6 Ar chitect ur es of failing to achieve its goals. Stages 1 through 3 are “ready, aim” with this stage being “fire.” Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Design- Considerations Change Wil l Happen

Chapt er 8 Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

There are three overriding design considerations when establishing a service-oriented architecture:

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

able to receive Chapt1.er Every 10 - Arservice chitect urmust es at be Each Stage of Adoptimessages on for Web multiple Ser vices times with no adverse effects. For example,

assume a service can receive updates to customer data. That service must be able to receive the same update more than once without affecting the data. The reason for this is that the sending service may, for Chapt er 12 - Mi ddl e- Tier Ar chitectur e various reasons, send data multiple times. This can happen when a system comes up after being down for a Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e period of time. It may have some type of checkpoint that is taken after some multiple of messages go out. If Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s the system goes down between checkpoints, some messages may need to be sent again to be sure they Chapt er 14 - Addi tional Specification Details went out. It can also happen through mistakes in programming, multiple data requests, or simply unforeseen Chapt er 15 - Qui ck Reference Guide actions. Chapt er 11 - Ar chitect ur al Opt ions

I ndex List of 2. Fi gures High-volume, high-speed messages should be sent within a service and lower volume, lower speed

messages should be sent between services. This is one of those “relative” design considerations. Web Services, no matter what, are going to run significantly slower than processing within a service. Try to keep the high-volume, high-speed messages within a service. Figure 10.16 illustrates keeping high-volume, highspeed messages within a service.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

-Figure Change 10.16: Wil l Happen Keeping high-volume, high-speed messages within a service.

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

3. Balancing the conflict between operational access and ad hoc access. It is common that the data structures that are best for ad hoc access are not the same as the data structures that are best for day-toChapt er 11 - Ar chitect ur al Opt ions day operational access. Balancing this conflict is a challenge when creating an architecture. This conflict is Chapt er quite 12 - apparent Mi ddl e- Tier Ar chitectur e both centralized master data and operational data as service to other when providing Chapt er departments 13 - Rev isi ting the Business Tr or ip in NotToo- Distant Futur over the Intranet to the other organizations over ethe Internet. The problem with ad hoc access is Pa r t I V -that Comyou pe ndi um of Softw a r e Te chnolog y for S er v i ce Or i e nte d ArThe chit ect ur e s may require data that is don’t know when it will come or how long it will take. access Chapt er consolidated 14 - Addi tional Specification Details from both master data and operational data. Yet, the users of the service expect Chapt er responsiveness 15 - Qui ck Reference Guide and that it be available all the time. Figure 10.17 illustrates this issue and provides a possible I ndex solution. A reasonable response is to establish a service-oriented architecture that takes advantage of the area shown as a cloud in Figure 10.17. This is referred to as the middle-tier and is introduced in Chapter 11 List of Fi gures and expanded upon in Chapter 12. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 -Figure Mi ddl e-10.17: Tier ArConflict chitecturbetween e ad hoc Internet/Intranet processing and internal processing. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

Staffing in Stage 4

Chapt er 15 - Qui ck Reference Guide I ndex By now, you should have an effective team of seven or fewer people who are very capable of taking on short-term List of Fi gures projects. Your methodology should also be well established. Depending on your organization, you might need to

establish one or more other teams of seven to deal with the work in this stage. The team members from the initial team could form the core of the new teams. This is a good time to have people in your organization self-select themselves into joining the additional teams. In this way, you are more likely to get the right people on the teams.

Tips for Dealing with Change Issues in Stage 4 The most likely change issues you will encounter in this stage are: Feeling that jobs may be threatened. The s*** will really hit the fan in this stage. For many organizations, it will be obvious that the size of IT staff will be starting to go down and jobs may genuinely be threatened. Be prepared to communicate openly about this as soon as possible so that people have time to make decisions. Not invented here. You are likely to be considering packaged software or systems in this stage. It is very human to resist this. Be sure to get this resistance out in the open and really listen to concerns in order to make sure any legitimate concerns are addressed. Our problems are special. This relates to the feeling that jobs may be threatened. Be sure to get these concerns out in the open to see if there is any real concern the special issues are being overlooked. Chances are very likely that the problems are not special. Be prepared to communicate this effectively. Be sure to keep management informed as the word spreads through the grapevine that “special issues” are being overlooked.

W eb Services d Ser vice- O rien t ed Archit ect u re: T h eArchitecture Sa vvy Man ag er 's to Gu idInclude e Stage 5. Expand thean Internal Service-Oriented ISBN:1558609067 by Douglas K. Barr y External Services Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Prov ides bothabout pr actical chitectur adv ice on howThere t o pr epar e an or too ganization to say t ak e If you jumped ahead to read this leader stage,ship youand are ar likely to bealdisappointed. really isn’t much to of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic about this stage.advantage If you have done your work, you are positioned to expand your internal service-oriented and t he software engineer ing wor lds. architecture to include external services. I have been discussing this “ plug-compatibility” throughout this book. At stage will be atBack the plug-compatibility stage. Table5,ofyou Contents Cov er Com m ents TaIn blethis o f stage, Con t enyou t s will have the choice of weaving together services from other organizations with services your Web Ser vices and Ser viceOr ientedThis Ar chit ectur es—The Sav vy 's Guide organization uniquely provides. is where you could, forManager example, integrate an external CRM service much like For ewor d described in the initial story about C. R.’s business trip. what was I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Staffing- AinBusiness Stage 5 Tr ip in the Not- Too- Distant Futur e

Chapt er 1

Chapt er 2 you - Iare nforsailing m at ionalong. Technology Used have in Thi several s Tri p teams involved with weaving together Web Services. The By now, You might Chapt 3 - Ser viceiented Ar chi to tectur and to Web Serv ices teamermembers’ skillsOrposition you be es ready change things quickly should there be a business need for For ces Affecti theservice-oriented Adoption of Webarchitecture Ser v ices andinOther I ntegr ation changing aspect of ng your a hurry. Chapt er 4 some Techniques Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Likely Change Issues in Stage 5 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

The most likely change issues you will encounter in this stage are:

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I INot - Ma na gi ng Cha nge As N eetime de d goes for a Ser i ce - Orand ie nte d Ar chit e ct ur eservices invented here. on,vmore more external

or services will be available so that you

Chapt er 8 purchase - Change Wil l Happensoftware that could replace internal custom-built services. Be prepared to continue to could packaged Chapt er 9 Tips for Managing Changeproper I ssuescommunication dur ing Developm address this resistance through ofent the advantages of these services to your Pa r t I Iorganization. I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Our Chapt er 11 problems - Ar chitectare ur alspecial. Opt ions This change issue is related to the last one. It is difficult for many people to realize that are not especial. The opportunity lies in weaving together “not-so-special” services into a Chapt er 12specific - Mi ddlproblems e- Tier Ar chitectur special architecture for your organization.

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Chapter 7 introduced theKaufm stages adoption Web and service-oriented architectures. This chapter Mor gan annofPubl ishers for ?2003 (245Services pages) showed possibleProv architectures to consider at each stage of adoption up tot o“plug-compatibility” of Web ides both pr actical leader ship and ar chitectur al advleading ice on how pr epar e an or ganization to t ak e Services in the final stage. of Tips onser staffing andser likely change issues for each stage were provided for dataeachcentr ic advantage Web vices and viceor iented ar chitectur es, bri dging t he also gap bet ween the and t he software engineer ing wor lds. stage of adoption. Tableare of Contents Back architectural Cov er Comoptions m ents to consider with Web Services. The next chapter will discuss dataThere some additional andtdistributed-process architectural options. Tacentric ble o f Con en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby11: Architectural Options Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufmfor ann Publ ishers ?2003architectures (245 pages) Several architectural options service-oriented are introduced in this chapter. All options are not Prov ides both pr acticalThe leader ship and of ar chitectur al adv ice how t o pr epar an or ganization t ak e of covered, because that isn’t possible. very nature Web Services willonencourage the edevelopment of alltosorts advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic interesting architectural options. So, by definition, there cannot be a complete list and any list that claims to be and t he software engineer ing wor lds.

complete will be out-of-date tomorrow. Nevertheless, there are basic options that can be considered. These options serve foundationBack to which additional options can be added. The two options that are covered are Tableas of aContents Cov er Com marchitectural ents data-centric and distributed-process architectures.

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Data-Centric Architecture

For ewor d

I ntr oduction

Up to this point, a data-centric architecture has been presented. It is “ datacentric” because it is based on moving data to where the data might be needed. This is done with the message router and populating data in the various Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e services. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt 3 - Ser viceiented Ar chiarchitecture tectur es and include: Web Serv ices The er advantages of aOr data-centric For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Chapt er 4

Data quality is controlled. There is one master copy of any data item, quality is controlled at that point, and Techniques every data Iitem is of a duplicate the master copy. The message router controls the design issue of Chapt er 5 -other Growing mpact Web Serv of ices redundancy of data. Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6

-

Ar chitect ur es

Effect operational systems is Or minimized. These emight be existing systems as well as new systems. The Chapt er 7 - on St ar ti ng t o Adopt a Ser vi ceiented Ar chitectur only impact that a data-centric architecture has occurs at the time of data update from the message router. This Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e is to be expected and is most likely to have minimal effect. Chapt er 8 - Change Wil l Happen Chapt er 9 components - Tips for Managing Change I ssues dur ing Developm ent only the master database and message router Few need to be highly available. Generally, Pa r t I Ineed I - Crto e a be ti nghighly S er v i available ce - O r ie ntin edaAr chi te ctu r es architecture. data-centric

Nevertheless, the specific needs of an organization

Chapt er 10 dictate - Ar chitect es atsystems Each Stage Adopti on forhighly Web Ser vices may that ur other andofservices are available. Chapt er 11 - Ar chitect ur al Opt ions

The er disadvantages of a Ar data-centric Chapt 12 - Mi ddl e- Tier chitectur e architecture include: Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Delays in getting data updates distributed. Because data is routed, there may be delays. Sometimes up-tothe-moment updates are needed. A data-centric architecture does not provide that.

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

Chapt er 15 - Quiwhat ck Reference Guide This is a design issue. It has to do with the factoring out of shared data Deciding data to route. I ndex introduced in the last chapter. The disadvantage is that the data needed to be routed needs to be determined List of relatively Fi gures early in the design of a data-centric architecture. Of course, additional data can always be routed.

Nevertheless, it is something that usually needs to be designed in early in the development of the architecture.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Distributed-Process Architecture ISBN:1558609067

by Douglas K. Barr y

One alternative to a gan data-centric is a distributed-process architecture. It is “distributed” because the Mor Kaufm annarchitecture Publ ishers ?2003 (245 pages) processing occurs at multiple locations. These locations are either where thehow “owning” system data or to t ak e Prov ides both pr actical leader ship and ar chitectur al adv ice on t o pr epar e an has or ganization processes requests. This section architecture to a data-centric architecture. It willic advantage of Web will ser compare vices and a serdistributed-process vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr and t in hewhich software engineer ing wor lds.architecture should be considered. also cover situations a distributed-process Table of Contents

Back Cov er

Com m ents

Comparison to the Data-Centric Architecture Ta ble o f Con t en t s Web Ser vices and Or iented Ar chitlook ecturat es—The Savrequest vy Manager 's Guide To compare the Ser twoviceapproaches, let’s a simple to obtain all customer information. Figure 11.1 shows For ewor d this request using a data-centric architecture. The data comes from one source: the customer master file. This is a I ntr oduction highly available service. The request does not impact other internal systems. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 11.1: A response to a request for all customer data comes from one highly available source. Figure 11.2 shows the same request without a customer master file. The data would come from multiple locations. The requestor would deal with duplicates and possible inconsistencies in the data. Also, if any one of the internal systems were not available, then all the customer information would not be returned. Finally, requests like this are the bane of operation system administrators. Such requests can slow down operational systems and, more often than not, come at unplanned times.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Figure 11.2: A response to a request for all customer data must come from multiple sources.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 11 - Ar chitect ur al Opt To deal with the availability ofions data, each of the internal systems could be made highly available much like the Chapt er 12 master - Mi ddlsystem e- Tier Arinchitectur customer Figure e11.1. Highly available internal systems are shown in Figure 11.3. Each system Chapt er need 13 - to Rev ting the Business Tr ip in Not-the TooDistant Futur e customer master service. would beisimade highly available to the match availability of the Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 11.3: Adding high-availability to a distributed-process-architecture. Obviously, for this type of request, a distributed-process architecture would be considerably more costly to provide a

highly available and complete response than a data-centric architecture. There are, however, good an reasons to consider a distributed-process W ebvery Services d Ser viceO rien t ed Archit ect u re: T h e architecture—particularly Sa vvy Man ag er 's Gu id e when you don’t have to deal withbydata redundancy ISBN:1558609067 Douglas K. Barr yand consistency issues. Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Prov ides bothaprDistributed-Process actical leader ship and ar chitecturArchitecture al adv ice on how t o pr epar e an or ganization to t ak e When to Consider

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

The time to consider a distributed-process architecture is those situations in which it is critical to have up-to-themoment data. For in the story of C. R. in Chapter 1, it would be important to have up-to- theTable ofprocessing Contents orBack Cov er example, Com m ents moment information on car rentals along with airline and hotel reservations. In other applications, the very latest data Taon blestock o f Con t en t smight be needed. In any case, if the data needs to be highly available, you will need to deploy the prices Web Ser vices and Ser viceOr ientedon Ar highly chit ectur es—The hardware Sav vy Manager 's Guide distributed-process architecture available and software. For ewor d I ntr oduction

Combining Data-Centric and Distributed-Process Architectures

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1 most - A Business Tr ip in the Not- Too- Distant Futur e In reality, service-oriented architectures will be a combination of data-centric and distributed-process Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p architectures. For example, when setting up C. R.’s trip, the travel agency service needed up-to-the-moment Chapt er 3 - for Servarious vice- Or iented Ar chi tectur es and Serv ices information reservations. To stay in Web business, services such as car rentals and airline reservations have Forup-to-the-moment ces Affecti ng the Adoption of master Web Serdatabase v ices and in Other I ntegr ation to provide this data. The C. R.’s organization, on the other hand, could have Chapt er 4 the arrival of Techniques updates delayed slightly with no impact on the organization. Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb ServicesData an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy ManBusiness ag er 's Gu id e Master Databases, Warehouses, Data Marts, and by Douglas K. Barr y IntelligenceMorSoftware gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

idesdatabase both pr actical leader ship chitectur adv ice on how t o prorganization. epar e an or ganization to t ak e One benefit of a Prov master is that it has alland sortsarof usefulalinformation for your These master Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic databases couldadvantage evolve intoofdata warehouses and/or data marts. The design and maintenance of these are big and t he software engineer ing wor lds. issues—issues beyond the scope of this book. Nevertheless, data warehouses and/or data marts can play an important role in service-oriented Table of Contents Back Cov er architectures. Com m ents TaMaster ble o f Con t en t s data warehouses, and data marts open up the opportunity to use business intelligence (BI) databases, Web Ser vices Ser viceOr ientedbig Ar chit ectur es—The Sav vythe Manager software. BI and software is another issue that is beyond scope'sofGuide this book. There are, however, significant For ewor d occurring with BI software in response to opportunities with Web Services. Some observations can be changes I ntr oduction made. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

BI software be used things determining Chapt er 1 - could A Business Tr ipfor in such the NotToo-as Distant Futur e patterns within your customer base and data mining.

Because also exists Used to create “clean” Chapt er 2 the - I opportunity nfor m at ion Technology in Thi s Tri p data in the master databases, data warehouses, and data marts, the value of this BI software to your organization may be quite high. - Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 3

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation One er option Chapt 4 - is to design databases that facilitate analysis by the appropriate types of BI packages. That may, Techniques

however, conflict with the design of the database needed for day-to-day operations. Operational database access - Growing I mpact of Web Serv ices may be slow when a database is designed for analysis. Another type of conflict may occur when it is desirable to run Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt BI analyses er 6 - concurrent with heavy operation data loads. There would be a potential problem if the BI analyses slow Ar chitect ur es down the operational data access. Chapt er 5

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - are Ma na gi ng Cha nge N ee de d for to a Ser ce - Or ie nte d Ar chitwould e ct ur ebe There several possible solutions thisv iconflict. This first

to create separate data marts that are

Chapt er 8 from - Change Wil l Happen extracts the master database. Using the BI packages with the data marts would mean that the analysis would Chapt er 9 Tips for Managing Change IThe ssues dur ing Developm entthe data marts would not have the latest not slow down the operational access. disadvantage is that Pa r t I I I - Cr e aOrganizational ti ng S er v i ce - O needs r ie nt edwill Ar chi te ctu whether r es information. dictate

that is an important concern. Also, this does not address the

Chapt er 10conflict - Ar chitect ur es at Each Stage of Adopti on formay WebbeSer vices potential where operational database access slow when a database is designed for analysis. Chapt er 11 - Ar chitect ur al Opt ions

A second would be to replicate and distribute the data in the master database. This is shown in Figure 11.4. Chapt er 12 solution - Mi ddl eTier Ar chitectur e The BI packages would work on the replicated database, thereby minimizing the impact of analysis on operational data access. It also allows the BI packages to receive the latest information since the replicated servers would be Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s updated at the same time or nearly the same time as the master server. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 11.4: Adding business intelligence software to distributed master databases.

There is a third solution that involves using a middle-tier architecture. That will be described in more detail in the next chapter. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Agents

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

The term agent is a gan broad termann to describe sorts(245 of pages) systems that can enhance an architecture. In the story about Mor Kaufm Publ ishersall?2003 C. R.’s businessProv trip,ides automated agents played a major in negotiating hishow travel plans C. R.toup-toboth pr actical leader ship and ar role chitectur al adv ice on t o pr epar and e an keeping or ganization t ak e date about customers he planned with other Web Services. The advantage of Web to servisit. vicesThese and seragents vice- or communicated iented ar chitectur es, each bri dging t heusing gap bet ween the datacentr ic and t heformats software ing the wordevelopment lds. XML-tagged message aidengineer in making of this communication easier. Table of Contents Backand Covas er time Com m ents Agents come in all forms goes on, they will become more sophisticated. On a relatively simple side, there are agents that can help us shop online. As XML and Web Services are adopted, these shopping agents can Ta ble o f Con t en t s become more intelligent. For example, without the XML-tagged formats, it is difficult for an agent to know if “blue” is Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide the color of the sweater or a brand name. It is similar to the problem with using a search engine right now. If I look For ewor d up my last name, Barry, on a search engine, I get people with that last name, people with “Barry” as a first name, I ntr oduction and company and college names that include “Barry.” An XML-tagged structure would allow a search engine to look Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew for last names of “Barry.” There would be a tag that identifies a last name. Similar identification will make it easier for Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e sophisticated shopping agents to be constructed. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt 3 - Ser vice-agents Or iented Ar chibe tectur Web Serv ices Moreersophisticated would ableestoand perform negotiations, monitor the status of systems, or monitor changes For ces Affecti ng or theother Adoption of Web Ser v ices and Other I ntegrsafe ationto assume that a master database is in the content of databases systems. For example, it is probably Chapt er 4 Techniques something that might be appropriate for an automated agent to monitor. Another agent might monitor an existing Chapt er 5system. - Growing I mpact of could Web Serv ices internal These agents communicate with each other using Web Services or they could communicate Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr iseServices. Figure 11.5 illustrates adding agents with other systems internal or external to the organization using Web Chapt er 6 Ar chitect ur es

to an internal service-oriented architecture.

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 11.5: Adding agents to a master database and internal systems. Agent software is undergoing dramatic change right now. Simple agent software has been around for some time. More advanced agents are likely to appear as XML is adopted more widely. The reason is that agent software can take advantage of the semantics provided by the tagged structure of XML (see page 26).

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

This chapter emphasized two basic architectural data-centric and process-centric architectures. In reality, Mor gan Kaufm ann Publ ishers ?2003options: (245 pages) nearly all service-oriented architectures will be a combination of both. these you will find Prov ides both pr actical leader ship and ar chitectur al advWithin ice on how t o architectures, pr epar e an or ganization to master t ak e databases, business intelligence and ser agent The next chapter will show how advantage of Websoftware, ser vices and vice-software. or iented ar chitectur es, bri dging t he gap betthese ween architectures the data- centr ic t hea software engineer wor lds. can be enhancedand with middle-tier that ising placed between the Internet or Intranet and internal systems and services. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby12: Middle-Tier Architecture Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers pages) A middle-tier architecture is a common way to?2003 build(245 Web Services using existing systems and databases. The Provwhere ides both pr acticalcan leader ship Instead and ar chitectur al adv ice on how t o pr epar e an orand ganization to t akae middle tier changes integration occur. of directly integrating existing systems databases, Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic new layer can beadvantage developedofso that the integration occurs in the middle tier. This is where you often find the use of and t he software engineer ing wor lds.

business objects. Business objects are a way of representing something in the business domain, including various attributes, behavior, relationships, constraints. Moving integration to the middle tier and using business objects Table of Contents Back Cov er and Com m ents is another solution to the conflict between ad hoc or analysis and operational access mentioned in the last chapter.

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar ectur the es—The Sav Manager Guide A discussion of business objects is chit outside scope ofvythis book. 's We will, however, cover the basics for a middleFor ewor d tier architecture that provide an infrastructure for business objects. The discussion includes some options and tips to I ntr oduction consider with such an architecture. Middle-tier caching, persistence, and firewalls are covered in this chapter. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

A Business Tr ip in the Not- Too- Distant Futur e Basics -for a Middle-Tier Architecture

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 12.1 3 - illustrates Ser vice- Orthe iented Ar chioftectur es and Web Serv ices The internal systems and services that we have Figure basics a middle-tier architecture. Forare ces at Affecti ng the Adoption of Web Sermake v ices and Other I ntegr ation covered so far the bottom of the figure. They up the enterprise information system tier or EIS tier. Chapt er 4 Techniques Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 12.1: Middle-tier architecture. Themiddle tier is above the EIS tier. The middle tier has a Web server that connects to the Internet or Intranet. The connections may be to services via Web Services external to subgroups in the organization or external to the organization. The connections may be to other Internet resources as well. An application server is below the Web server. Either a Java application server or a .NET server could be used. Any type of application server creates an infrastructure for deploying applications that are usually called components (components is definitely an overused term). These components come in different varieties for Java application servers and .NET. The components are written in object programming languages such as Java, C#, C++, and others.

Components used in applications servers in the middle tier are a common way to realize the high-level abstractions of business processes and work- flows that were discussed on page 78. Essentially the middle tier provides the W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e opportunity to view both internal systems and services and external services in a different way that might be more ISBN:1558609067 by Douglas K. Barr y consistent with the abstract models used in architecture frameworks. Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

An application server canboth have: Prov ides pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineerThis ing wor lds. be virtually anything. In the story of C. R.’s business trip, it could Access to external Web Services. could be travel agent services.

Table of Contents

Back Cov er

Com m ents

tot sother Internet resources. This also could be most anything: weather reports, currency converters, Ta ble oAccess f Con t en news feeds, and soOr on. Web Ser vices and Ser viceiented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

Access to internal Web Services. An example of an internal Web Service might be the validation of an account based on data input over the Internet/Intranet and data stored in the EIS-tier database.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1 - Adirectly Business ip in the system Not- Too-directly, Distant Futur e Access toTrinternal bypassing Web Services. Direct access to the EIS-tier database might example Used of thisinaccess. Chapt er 2 - I nfor m atbe ion an Technology Thi s Tri p Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 5

- Growing I mpact of Web Serv ices

Options with For a middle-tier architecture include: ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques 1. Middle-tier in-memory caching options 2. Middle-tier persistence options Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an dTier Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Caching inWthe Middle by Douglas K. Barr y

ISBN:1558609067

Caching is the retention of data, usually in an?2003 application or application server, to minimize network traffic flow and/or Mor gan Kaufm ann Publ ishers (245 pages) disk access. Data from the EIS-tier database is cached in the application server. application servers Prov ides both pr actical leader ship and ar chitectur al adv ice on how tCaching o pr epar einan or ganization to t akise an important aspectadvantage of any service-oriented architecture. application server, with its cache, the ic of Web ser vices and ser vice-The or iented ar chitectur es, bri dging t he gapgenerally bet ween resides the data-incentr t he software engineer wor 12.2. lds. The cache resides in memory on the application server and middle tier of an and architecture as shown in ing Figure retains data from the database in the EIS or bottom tier. The application server usually has a direct connection to Table of Contents Back Cov er Com m ents the database in the EIS tier. Such a direct connection is made for performance reasons. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Figure 12.2: Middle-tier in-memory data caching.

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

There are several ways that a cache could be populated:

Chapt er 14 - Addi tional Specification Details

1. On an as-needed basis. Aninstance moves into cache only when a program requests to read the values of the instance. (An instance could be a record, a row in a relational table, an object, or a portion of an XML I ndex document.) Chapt er 15 - Qui ck Reference Guide List of Fi gures

2. Fully populated at start time. All instances needed in the cache are populated when the system starts up. 3. A combination of the first two. An example is populating the cache with the most likely instances that are needed and then moving additional instances into cache when a program requests to read the values of the instance. Figure 12.3 shows various options for implementing in-memory caching. In the lower-left quadrant is a simple caching mechanism. There is one copy of the cache and should the machine on which the cache resides fail, the data that was cached becomes unavailable. Any data updates that were cached but not written to the database would be lost. Also, there is no opportunity for load leveling the activity against the cache since only one machine has the cache. Load leveling is important if the cache is accessed heavily.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

ChaptFigure er 10 - 12.3: Ar chitect ur es at Each Stage of Adopti on for Web Ser vices In-memory caching. Chapt er 11 - Ar chitect ur al Opt ions Chapt In the er upper 12 - left Mi ddl quadrant e- Tier Arof chitectur Figuree12.3, cache replication is added. This allows for duplicate copies of the cache to

existeron13separate This allows load leveling of accesses Chapt - Rev isimachines. ting the Business Tr ip infor the NotToo- Distant Futur e to the cache. Updates to either copy of the cache automatically replicated with the other copy. option improves Pa r t I V -are Com pe ndi um of Softw a r e Te chnolog y for S er v i ceAlthough - Or i e nte dthis Ar chit ect ur es

availability, it is not highly

available. running theDetails application server at the left should fail, then the connection to the database Chapt er 14 If- the Addimachine tional Specification has failed. to the database Chapt er 15 -Updates Qui ck Reference Guide then cannot be made. Nevertheless, reading of data already cached could continue and will be adequate only if the entire database is cached in memory. If only a portion of the database is I ndex cached at any one time, it is easy to imagine a request not being able to be filled if the primary connection to the List of Fi gures database is unavailable.

The right two quadrants of Figure 12.3 show options for making in-memory caching highly available. Both use application server clusters or some other means of one application server taking over for another. In the lower-right quadrant, the in-memory caches are not replicated. This means that should the primary machine fail, the secondary machine won’t have an exact copy of the cache that was in the primary machine. A data update in the primary inmemory cache could be lost because the secondary machine does not have a duplicate copy of the cache. This is reduced by the option in the upper-right quadrant. Here the cache is replicated. If a data update in the cache was replicated before the primary machine fails, it is then possible that update could be picked up by the secondary machine and sent to the database. (This would be subject to some restrictions on transactions.) Nevertheless, the option in the upper-right quadrant provides for the highest availability of an in-memory cache. It would be appropriate to consider this option when in-memory caching for high performance and high availability is important. The contents of a cache can be tables, objects, or XML. In any case, there are issues of keeping the contents of a cache synchronized with the underlying database. The next two sections cover these issues.

Caching Tables, Objects, or XML Typically, the data cached at the application server level is either in the form of tables, objects (Java, C#, C++, or other object programming languages), or in the form of XML. Also, the source of the data is typically a relational database.Figure 12.4 shows tables in a relational database at the bottom of the figure. In the application server at the top of the figure is an in-memory cache. The options of caching tables, objects, or XML are shown at the top of the figure.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction

Figure 12.4: Data caching in an application server.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Mapping Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption Web Ser ices and Other Iof ntegr ation When contains either objects orofXML, thevtransformation tables into objects or XML is called mapping. Chapt er the 4 cache Techniques

Mapping is the technique used to make one or more rows in database tables appear as programming language - Growing I mpact of Web Serv ices objects or XML. There are many considerations to take into account when mapping between a database and cache. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt If youerwould 6 - like more information on these considerations, see www.service-architecture.com. Chapt er 5

Ar chitect ur es

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Cache Synchronization

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

An additional issue that needs to be considered is that a cache used by an application may not be tightly integrated - Tips for Managing Change I ssues dur ing Developm ent with the underlying database. This problem is referred to as cache synchronization. It occurs after the data has been Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es placed in an application cache. When only one application is using the data, cache synchronization is not a problem. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices As soon as a second application accesses the database, however, the problem can occur. Chapt er 9

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 - of Mi ddl Tier Ar of chitectur e An example thee-impact a second application is shown Figure 12.5. In the example, a second application is Chapt er 13 the - Rev isi ting the Business Tr ip in is thebeing Not- Tooe accessing same database server that usedDistant by an Futur application that uses a cache with mapping. Pa r t I V - ComBpecan ndi um of Softw r e Tebeing chnolog y for er v i ce - Or i e nte d Ar chitAect ur e s Application change the adata used bySApplication A. Cache would

need to be synchronized in some

Chapt er 14 - Addi tional Specification manner to obtain the changed data.Details How the cache is implemented will have a big impact on the problem. The data Chapt 15 - Qui ck be Reference Guide with the data in the database when a cache is used by an application that is in theercache must synchronized

separate from the underlying database server. I ndex List of Fi gures

Figure 12.5: Cache synchronization issues for mapping.

If both applications used a replicated cache as described in the section on caching that starts on page 171, then the cache for Application A would have been updated at the same time that the database was updated. This would W ebsynchronization Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e eliminate the cache problem. by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb an d Ser viceO rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Persistence inServices the Middle Tier ISBN:1558609067

by Douglas K. Barr y

So far, we have Mor seen how a cache canishers be used in (245 the pages) middle tier. It is also possible to add persistence to the middle gan Kaufm ann Publ ?2003 tier. Adding persistence to the middle tier can make sense in situations that tooe much data to keep alle Prov ides both pr actical leader ship and ar chitectur al adv ice on either how t ohave pr epar an or ganization to t ak the data in memory or situations youand need protection ofchitectur persistence make sure be lost advantage of Webwhere ser vices serthe viceor iented ar es, britodging t he gapno betdata weenwould the datacentr ic and t heto software engineer ing worItlds. before it can be written the master database. can also be a way to boost performance of services provided by an application server when it needs to access data. Table of Contents

Back Cov er

Com m ents

design TaThe ble o f Con t of enthe t s middle-tier persistence should be such that it matches the needs of ad hoc data access. For example, in the of our beginning C. R.’s organization may only keep the most recent contact information Web Ser vices and case Ser viceOr iented Ar chitstory, ectur es—The Sav vy Manager 's Guide onewor onlyd their active customers using middle-tier persistence. For I ntr oduction

Figure 12.6 illustrates middle-tier persistence. The middle-tier persistence is provided by the database just below the application server. There are two primary reasons to consider middle-tier persistence:

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 12.6: Middle-tier persistence. 1. Persistent cache in the middle tier. The amount of data that needs to be cached for the database in the EIS tier is too much to keep in an inmemory cache. There might also be a need to protect the in-memory cache from machine failures. 2. Consolidated data in the middle tier. There may be data that is best consolidated in the middle tier. Middle-tier persistence, however, will require additional development. This section will also provide suggestions of how to reduce that development cost and give you an idea what kind of performance gain could be achieved as a result of that additional development. A persistent cache adds capabilities to the in-memory cache. These include: Expanded caching. An in-memory cache is limited by memory and the performance of virtual memory. A persistent cache offloads some of the in-memory requirements to disk.

Protected caching. An in-memory cache will disappear if the machine on which it resides should fail. A persistent cache protects the cache. W eb Services an dcontents Ser vice-of O the rienin-memory t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

Caching performance gain. This depends on your architectural requirements, but it is generally possible to Mor gan Kaufm ann Publ ishers ?2003 (245 pages) realize performance gains of 50 times or more using a persistent cache (see www.service-architecture.com).

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e of Web vices and or iented chitectur dging ttier he gap bet ween the data- centr ic All the examplesadvantage in this section willser assume thatser a vicedatabase willarbe used ines, thebrimiddle to provide the persistent and t he software engineer ing wor lds. cache. A database manager ensures that all transactions will be recorded properly and has recovery and backup capabilities, if needed.Back Cov er Table of Contents Com m ents Ta ble o f Con t en t s

Expanded Caching

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

Recall that there are several ways that a cache could be populated:

I ntr oduction

Onr vian An Pa r t 1. I - Se ce-as-needed O r ie nt ed Ar basis. chi te ctur e instance Ov er v i ew moves

into cache only when a program requests to read the values of the instance. Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p 2. Fully populated at start time. All instances needed in the cache are populated when the system starts up.

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

3. A combination For ces Affecti of ng thethe first Adoption two. An of example Web Ser vis ices populating and Otherthe I ntegr cache ation with the most likely instances that are Chapt er 4 Techniques needed and then moving an additional instance into cache when a program requests to read the values of the Chapt er instance. 5 - Growing I mpact of Web Serv ices Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

In any of these Ar chitect cases,urthe es cache size simply could be too large to efficiently keep in memory. A middle-tier database coulderact anarexpanded cache tovioffload someArofchitectur the datae cached in memory. Chapt 7 as - St ti ng t o Adopt a Ser ce- Or iented Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Using a middle-tier database as an expanded cache adds options when the underlying master database is updated. - Change Wil l Happen The updates could occur as they happen or at intervals, depending on the needs of the organization. For example, Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent one option would be to populate the middle-tier database from the master database at the beginning of a business Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es day. All updates could be kept in the middle-tier database. These updates could then be written to the master Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices database at the end of the day or at intervals during the day. Of course, you would need to take any cache Chapt er 11 - Ar chitect ur al Opt ions synchronization issues into account (see page 172). Chapt er 8

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Protected Caching

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

If all middle-tier cache updates are written to a middle-tier database, then the cached updates are not lost if the application server should fail. They can be recovered from the middle-tier database when the application server is I ndex restored. This, of course, would not be necessary if updates to the master record are made every time an update List of Fi gures occurs. That, itself, can create a performance hit to the middle tier as will be discussed in the next section. Chapt er 15 - Qui ck Reference Guide

Caching Performance Gain Tip The middle-tier database should use the same data model as the middle-tier application server cache to maximize performance. If the middle-tier database uses the same data model as the middle-tier cache, there is a good chance that performance will be significantly better than if updates were written to the EIS-tier master database as they happened. This performance gain is possible assuming: The EIS-tier database uses a traditional relational database structure. This is the most likely structure that the EIS-tier database will use. The application server uses a cache that matches the needs of the object program in the application server. This could be either an object or an XML cache. The middle-tier database uses the same data model as the cache. Given these assumptions, the time it takes to write an update to the EIStier database will most likely take longer than writing to the middle-tier database would take. As the complexity of the model used by the object program increases, the greater the difference in the time it takes to write the update to the middle-tier database versus the EIS-tier database. This is because the mapping complexity also increases between the data model in the cache and the relational model in the EIS-tier database. The mapping simply takes time and costs performance (see www.servicearchitecture.com). As a result, an update to a middle-tier database can be significantly faster and allow the

application to resume processing much sooner than if the update was to the EIS-tier database directly. Figure 12.7 shows the sequence of this processing. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex

Figure 12.7: Using a persistent cache in the middle tier.

List of architecture Fi gures This can speed up the processing of the application server, often by 50 times or more (see

www.service-architecture.com). Of course, you would have to take cache synchronization issues with this architecture into account (see page 172). If you change the assumptions so that the application server uses a cache that matches the underlying EIS-tier database instead of one that matches the objects used by the application server, then this level of performance gain cannot be achieved. The reason is that the mapping between the cache and the objects used by the application server would need to occur each time an object is read from the cache or written to the cache by the application server. This mapping is in your application server program rather than below the cache. A middle-tier database still might make sense for other reasons, but it would not help improve caching performance in the middle tier.

Consolidated Data in Middle Tier Consolidating data in the middle tier is another way to get a completely different view of systems and services. This opens up opportunities for the high-.level abstractions of business processes and workflows that were discussed earlier in this chapter. A few examples of middle-tier persistence could be online catalogs that take data from many internal sources, auction systems that need to provide high-speed access to the active auction items, or trading systems that need high-speed access to the items currently being traded or for only today’s and yesterday’s trades. Figure 12.8 illustrates using a middle-tier database to consolidate data. The sources of data vary from manual input to internal systems data external to the organization. Generally, a characteristic of using consolidated data in the middle tier is an emphasis on performance. The impact this can have on the architecture is similar to using a middletier database for a persistent cache.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

theBusiness middle-tier for consolidated data. ChaptFigure er 13 - 12.8: Rev isiUsing ting the Tr ipdatabase in the NotTooDistant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

It is also important that the middle-tier database use a data model that is similar to the one used by the cache in the application server. Because the data used by an application server is either object data or XML, it makes sense that Chapt er 15 - Qui ck Reference Guide the cache and the database support either XML or the objects. Chapt er 14 - Addi tional Specification Details I ndex

List of Fi gures

Middle-Tier Databases

There are many database options available for middle-tier persistence, because middle-tier databases essentially store temporary data. This is in contrast to EIS-tier databases that are often seen as databases of record, which are expected to last “forever.” When you are considering a database product for an EIS-tier database, it is reasonable to choose a relational database product from a well-known, established company. In contrast, middle-tier databases—because they are temporary—open up the possibilities of using technologies that might significantly improve performance and reduce development as well as maintenance costs. There are many issues to consider in selecting a middle-tier database. A discussion of those issues goes beyond the scope of this book. More information on middle-tier persistence can be found at www.service-architecture.com.

Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Middle-TierW eb Firewall Options by Douglas K. Barr y

ISBN:1558609067

One potential problem service-oriented is that the most common implementation of Web Services Mor ganwith Kaufm ann Publ ishersarchitecture ?2003 (245 pages) is to use SOAP. Prov SOAP uses HTTP. This means that you would have internal systems, ides both pr actical leader ship and ar chitectur al advHTTP ice on going how t odirectly pr epar einto an your or ganization to t ak e which could be aadvantage significantofsecurity Web serrisk. vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

One way to solve this problem is to use an application server in front of a firewall as shown near the top of Figure Table of Contents Cov ermessage” Com m ents 12.9. The potential forBack a “rogue moving through the application server is unlikely since the application server would need to create its own Web Services message to communicate with the internal Web Services or the Ta ble o f Con t en t s internal database. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 12.9: Adding firewalls to a middle-tier-architecture. This architecture also adds an XML firewall above the internal Web Services to allow only defined messages from the application server to internal services in the EIS tier. Specialized XML firewalls offer the promise of protecting internal systems when using Web Services. Traditional firewalls offer protection at the packet level and do not examine the contents of messages. XML firewalls, on the other hand, examine the contents of messages. This includes the SOAP headers and the XML content. They are designed to permit authorized content to pass through the firewall. [1] [1] Also see the discussion of Web Services security and authorization on page 32.

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

This chapter showed how much of Publ whatishers we covered inpages) this book can be put together using a middle-tier architecture Mor gan Kaufm ann ?2003 (245 instead of directly integrating existing systems and databases. This chapter to the Prov ides both pr actical leader ship and ar chitectur al adv ice on also how showed t o pr eparthat e anintegration or ganization to t ak e middle tier and using business objects is another to thearconflict between ad hoc firstic advantage of Web ser vices and sersolution vice- or iented chitectur es, bri dging t heand gap operational bet ween theaccess data- centr software engineer ing wor lds. raised in Chapterand 10.t he Laced through this chapter are ways to make the middle-tier architecture highly available. Being highly available would be an important concern for many services offered using Web Services. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby13: Revisiting the Business Trip in the Not-TooISBN:1558609067 Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Distant Future Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of trip Webinser vices and ser vicear chitectur es, bri dging t he bet ween the data- centr ic Let’s revisit C. R.’s business Chapter 1 and look or atiented the details for Web Services andgap service-oriented and t he software engineer ing wor lds. architectures along with some of the architectural options used in his story. As you read this chapter, page references to more onBack the topic placed within parentheses. Table of Contents Cov erare Com m ents Ta ble o f Con t en t s

The Business Trip

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

When C. R. sat down to set up his business trip, he used the portal Web site that appears near the center of Figure 13.1. He connected to the portal using a browser over Web Services. The portal had access to read internal Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew information in C. R.’s organization as well as access to services on the Internet using Web Services (see pages Chapt er 1 C. - AR. Business Tr ipthe in the Not- TooDistant Futur 128–129). accessed business intelligence (BI)e software for selecting the customers to visit over his Chapt er 2 I nfor m at ion Technology Used in Thi s Tri p organization’s Web Services (see page 162). The portal was designed to take the contact information from the Chapt er 3 -returned Ser vice-by Or iented chi tectur es and ices information along with other travel criteria C. R. messages the BI Ar software and passWeb theServ contact For Travel ces Affecti ng theservice Adoption of Web Ser vR. ices and Other ntegr ationbutton. provided to the Agency at the time C. selected theI “Submit” Chapt er 4 I ntr oduction

Techniques

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 13.1: Detail for services and data interchange for C. R.’s business trip. The messages from the portal are sent to the message router in the middle tier and then sent out to the Internet (see page 52). The portal also informed the internal Agent which customers C. R. would want to monitor (see page 164). The Travel Agency service took it from there, arranging the remainder of the trip and informing C. R. of any details that needed his attention. Eventually, his entire itinerary was sent to the portal. It is from this site that C. R. downloaded what he needed to his cellular telephone/palmtop. When C. R. downloaded to his cellular telephone/palmtop, the connection to the portal used Web Services. At this time, C. R. also used his cellular telephone/palmtop to command the portal to inform the internal Agent to start actively monitoring contact information on the list of customers he planned to visit. This also was a Web Services message. Monitoring by the internal Agent generated the instant text message informing C. R. that a significant problem had occurred. That message was sent through the middle-tier message router.

When C. R. was using the monitor and keyboard in his hotel room to get more information on a contact, he was using the middle-tier database at the left of Figure 13.1. This database contains all the recent customer contacts. It W ebdatabase Servicesserved an d Ser O rien t ed Archit ect u re: Tserver h e Sa vvy ag er 's Gu id e Note the two is a highly available byvicea highly available application (seeMan pages 167, 167). by Douglas K. Barr y firewalls are used. The top one secures the data in the middle tier. The bottom XML firewall protects theISBN:1558609067 internal gan Kaufm Publ ishers pages) systems and theMor internal Web ann Services (see ?2003 page (245 182). Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

The information in the middle-tier came the data ar warehouse witht specific items from advantage of Webdatabase ser vices and serfrom vice- or iented chitectur es,along bri dging he gap bet ween the additional data- centr ic andCORBA t he software engineer ing wor lds. systems that used and DCOM connected to the internal Web Services using adapters (see page 45). The data warehouse at C. R.’s organization evolved from a relatively simple master database and is now distributed and Table of Contents Back Cov er Com m ents replicated (see page 140). The agent works off one replicated node while the BI software uses another replicated Tanode. ble o fThis Con tallows en t s load leveling of the distributed primary nodes available for other processing. Also, to make sure all Web messages Ser vicesget andtransmitted, Ser vice- Or iented both message Ar chit ectur routers es—The are Sav also vy Manager highly available 's Guide and store messages for delayed transmission if the destination service is not available. For ewor d I ntr oduction

When, at intervals, C. R.’s palmtop transmits meeting contact information, it is in the form of Web Services messages that enter his organization through the middle tier at the left of Figure 13.1. First, it is stored in the middleChapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e tier database. Then, the contact information is updated in the data warehouse. This is the same process used with Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p contact information coming from the external Customer Relationship Management (CRM) service. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption Web Positioning Ser v ices andSystem Other I (GPS) ntegr ation The er scheduling changes, downloading of of Global data, hotel reservations, and calendar Chapt 4 updates wereTechniques all handled by the Travel Agency service using Web Services without any impact on C. R.’s internal Chapt er 5 - Growing I mpact of Web Serv ices systems. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Chapt er 6

-

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Ar chitectisurat esStage 5 in its adoption of Web Services (see pages 89, 154). It weaved an effective C. R.’s organization Chapt er 7 - St ar architecture ti ng t o Adopt from a Serexisting vi ce- Or iented Ar systems, chitectur e a new data warehouse, a new middle-tier architecture, a service-oriented internal Pa r t I I -for Maits na “connected gi ng Cha ngerepresentatives,” N ee de d for a Ser and v i ce -aOrseries ie nte dofArexternal chit e ct urservices e portal that interact using Web Services.

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Summary

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

This chapter tiesMor much the technology of Web and service-oriented architectures back to the story of C. gan of Kaufm ann Publ ishers ?2003Services (245 pages) R.’s business tripProv at the beginning of this book. It illustrates whatalwent on on “behind scenes” C. R.’sto t ak e ides both pr actical leader ship and ar chitectur adv ice how t othe pr epar e an during or ganization business trip. advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

The next part of this book goes into more background on the technologies available with Web Services. It also has a Table ofthat Contents Cov er Com mguide ents for these technologies. chapter serves asBack a quick reference Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Part IV: Compendium of Software Technology for ServiceISBN:1558609067 by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) Oriented Architectures Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Chapter 14: and Additional Specification t he software engineerDetails ing wor lds.

Chapter 15: QuickBack Reference Table of Contents Cov er Guide Com m ents Ta ble o f Con t en t s Web and Ser viceOr iented Aron chitsoftware ectur es—The Sav vy Manager 's Guide that can be used in a service-oriented PartSer IVvices provides more background technology and terminology For ewor d architecture. Chapter 14 provides additional details on specifications used in this book. Chapter 15 is a quick

reference I ntr oductionguide for software technology related to service-oriented architectures. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby14: Additional Specification Details Douglas K. Barr y

Overview

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic This chapter provides and t he additional software details engineer of ing some worof lds. the specifications discussed in this book. It starts out by providing

a brief background on each of the organizations working on specifications related to Web Services. Then a matrix is Table of that Contents Back Cov er specifications Com m ents and the organizations working on each specification. The latter part of provided shows the various provides details on important specifications: Tathe ble chapter o f Con t en ts Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Web Services specifications: The most relevant specifications directly related to Web Services are included in this section.

For ewor d

I ntr oduction

Pa r t I XML - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov v i ew specifications: XML plays aersignificant

role in Web Services. This section provides a brief background on

Chapt er 1 -of Athe Business Tr ip in the Not- Too- Distant Futur e many relevant XML specifications. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

XML Various have Chapt er 3 vocabularies: - Ser vice- Or iented Ar chiindustry tectur es groups and Web Servbeen ices developing the XML version of their respective vocabularies in order to take advantage of the XML For ces Affecti ng the Adoption of Web Ser v icesmessaging and Other Icapability ntegr ationof Web Services. This section Chapt er 4 providesTechniques a sampling of those vocabularies. Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Organizations Working onviceSpecifications ISBN:1558609067

by Douglas K. Barr y

This section provides a brief background on many of the important consortia and standards organizations working on Mor gan Kaufm ann Publ ishers ?2003 (245 pages) specifications related to Web Services. At one time, software standards approved the International Prov ides both pr actical leader ship and ar chitectur al adv iceneeded on how to t o be pr epar e an orby ganization to t ak e Organization for advantage Standardization or the last decade orcentr so, ic of Web(ISO) ser vices andAmerican ser vice- orNational iented arStandards chitectur es,Institute bri dging(ANSI). t he gapThe bet ween the dataandthe t herise software engineer ing wor lds. consortia developing standard specifications. The reasons for however, has seen in importance of industry this vary, but industry consortia now play an important role in the creation of standards. Table of Contents

Back Cov er

Com m ents

may that TaItble o f seem Con t en t s with all the consortia and traditional standards bodies, the specification setting may become a competitive That butes—The more often, find organizations working together. Some examples Web Ser vices process. and Ser viceOr does ientedhappen, Ar chit ectur Sav vyyou Manager 's Guide include: For ewor d

1. UDDI.org developed the initial release of Universal Description, Discovery, and Integration (UDDI) and then I ntr oduction turned to Organization forerthe Advancement Pa r t I - Se r vi ce-itOover r ie nt ed Ar chi te ctur e Ov v i ew Chapt er 1

of Structured Information Standards (OASIS).

- A Business Tr ip in the Not- Too- Distant Futur e

2. Blocks Extensible Exchange Protocol (BEEP) from The Internet Engineering Task Force (IETF) has a SOAP - I nfor m at ion Technology Used in Thi s Tri p mapping. SOAP is from World Wide Web Consortium (W3C).

Chapt er 2 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt3.er The 4 - adoption of W3C’s SOAP in the electronic business using eXtensible Markup Language (ebXML) Techniques transport specification. RosettaNet also announced its adoption of the ebXML transport. Chapt er 5

- Growing I mpact of Web Serv ices

4. ebXML Ser isvicesponsored Or ientedby ArUnited chi tectur Nations es and Centre Beliefs about for Trade Enter Facilitation pr ise and Electronic Business (UN/CEFACT) Chapt er 6 Ar chitect ur es has adopted specifications that resulted from this sponsorship. and OASIS. OASIS Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

the object-programming and Pa r t 5. I I - Microsoft Ma na gi ngdeveloped Cha nge N ee de C# d for a Ser v i ce - Or ie nte d language Ar chit e ct ur e

submitted it to ECMA. C# is now an ECMA

Chapt er standard. 8 - Change Wil l Happen Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

6. ContentGuard developed the eXtensible rights Markup Language (XrML) and contributed it as the base of a rights language in the Organization for the Advancement of Structured Information Standards (OASIS).

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 11to- the Ar chitect ur al Opt ions For links organizations included in this section or the latest information on relevant standards, go to Chapt er 12 - Mi ddl e- Tier Ar chitectur e www.service-architecture.com. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Business Process Management Initiative (BPMI.org)

Chapt er 14 - Addi tional Specification Details

Chapt 15 - Qui ck Reference Guide The er Business Process Management Initiative (BPMI.org) works on standards for the management of business I ndex processes that span multiple applications, corporate departments, and business partners. List of Fi gures

electronic business using eXtensible Markup Language (ebXML) ebXML, sponsored by UN/CEFACT and OASIS, is a modular suite of specifi- cations that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms, and define and register business processes.

ECMA ECMA is an international industry association dedicated to the standardization of information and communication systems. ECMA coordinates activities with the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

The InterNational Committee for Information Technology Standards (INCITS) The InterNational Committee for Information Technology Standards (INCITS) is the forum of choice for information technology developers, producers, and users for the creation and maintenance of formal de jure IT standards. INCITS is accredited by, and operates under rules approved by, the American National Standards Institute (ANSI).

The Internet Engineering Task Force (IETF) The Internet Engineering Task Force (IETF) is an international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

Java Community Process (JCP) W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067 by Douglas K. Barr y is an organization of international Java developers and licensees whose The Java Community Process (JCP) Mor gan Kaufm ann Publ ishers ?2003 (245 pages) charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits.Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Organization for the Advancement of Structured Information Standards Table of Contents Back Cov er Com m ents (OASIS)

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or ientedconsortium Ar chit ectur that es—The Savthe vy Manager 's Guide OASIS is a not-for-profit, global drives development, convergence, and adoption of e-business For ewor d standards. Members themselves set the OASIS technical agenda, using a lightweight, open process expressly I ntr oductionto promote industry consensus and unite disparate efforts. OASIS produces worldwide standards for designed Pa r t I - Se rWeb vi ce- Services, O r ie nt ed Ar chi te ctur e Ov er v i ew security, XML conformance, business

transactions, electronic publishing, topic maps, and

interoperability within and between marketplaces. Chapt er 1 - A Business Tr ip in the NotToo- Distant Futur e Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Ser vice- Or iented Ar chi tectur es (OMG) and Web Serv ices Object -Management Group

Chapt er 3 Chapt er 4

-

Chapt er 6

-

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

Techniques Group (OMG) is a not-for-profit consortium that produces and maintains computer industry The Object Management Chapt er 5 I mpact of Web Serv ices specificationsGrowing for interoperable enterprise applications. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

RosettaNet - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

RosettaNet is a self-funded, non-profit consortium of information technology, electronic components, and - Change Wil l Happen semiconductor manufacturing companies working to create and implement industry-wide, open e-business process Chapt er 9 Tips for Managingform Change I ssues dur ing Developm ent standards. -These standards a common e-business language, aligning processes between supply chain Pa r t I I I Cr e a ti ng S er v i ce O r ie nt ed Ar chi te ctu r es partners on a global basis. RosettaNet is a subsidiary of the Uniform Code Council (UCC). Chapt er 8

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

UN/CEFACT is the United Nations Centre Chapt er 14 - Addi tional Specification Details for Trade Facilitation and Electronic Business. It is open to participation

from Member States, intergovernmental organizations, and sectoral and industry associations recognized by the Economic and Social Council of the United Nations (ECOSOC). The Centre’s objective is to be “inclusive” and it I ndex actively encourages organizations to contribute and help develop its recommendations and standards. Within the List of Fi gures United Nations, UN/CEFACT is located in the Economic Commission for Europe (UN/ECE), which is part of the United Nations network of regional commissions. These regional commissions report to the highest United Nations body in the area of economics, trade, and development: ECOSOC. The mission of UN/CEFACT is to improve the ability of business, trade, and administrative organizations, from developed, developing, and transitional economies, to exchange products and relevant services effectively—and so contribute to the growth of global commerce. Chapt er 15 - Qui ck Reference Guide

World Wide Web Consortium (W3C) The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) and serves as a forum for information, commerce, communication, and collective understanding.

W eb Services an d Ser vice- O rien t ed Archit ect u re:Working T h e Sa vvy Man er 's Gu id e Matrix of Specifications and Organizations onagSpecifications ISBN:1558609067

by Douglas K. Barr y

This matrix is meant to be an easy reference guide(245 to see which organizations are working on specific specifications. Mor gan Kaufm ann Publ ishers ?2003 pages) The organizations are shown at the top. The specifications are categorized thet otype of specification at the Prov ides both pr actical leader ship and ar chitectur al adv ice on by how pr epar e an or ganization to left. t ak e The specifications can be found in ser thevices nextand fewser sections or in the quick reference guide Chapter 15. the data- centr ic advantage of Web vice- or iented ar chitectur es, bri dging t heingap bet ween and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Web Services Specifications ISBN:1558609067

by Douglas K. Barr y

This section contains theKaufm mostann relevant specifications Mor gan Publ ishers ?2003 (245 related pages) to Web Services. This is, by no means, the complete list. More specifications can be found in the quick reference guide Chapter 15. t o pr epar e an or ganization to t ak e Prov ides both pr actical leader ship and ar chitectur al in adv ice on how advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

SOAP

Table of Contents

Back Cov er

Com m ents

SOAP provides the envelope for sending Web Services messages over the Internet/Internet. The envelope contains Tatwo ble parts: o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

1. An optional header providing information on authentication, encoding of data, or how a recipient of a SOAP message should process the message.

For ewor d

I ntr oduction

Pa r t 2. I - Se r vibody ce- O r ie nt ed Ar chi tethe cturmessage. e Ov er v i ewThese The that contains

Chapt er 1

messages can be defined using the WSDL specification.

- A Business Tr ip in the Not- Too- Distant Futur e

SOAP uses but other as Simple Mail Transfer Protocol (SMTP) may be used. Chapt er commonly 2 - I nfor m at ionHTTP, Technology Usedprotocols in Thi s Trisuch p SOAP used complete documents orices to call a remote procedure. (SOAP at one time stood for Chapt er can 3 -be Ser vice-to Orexchange iented Ar chi tectur es and Web Serv

Simple Object Access Protocol. the of letters acronym have no particular meaning. [ 1])Figure 14.1 For ces Affecti ng the Now, Adoption Web in Serthe v ices and Other I ntegr ation Chapt er 4 provides a high-level view of the SOAP structure. For an example of how SOAP is used in Web Services, see page Techniques 22. er 5 Chapt

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Figure 14.1: High-level view of the SOAP structure.

Blocks Extensible Exchange Protocol (BEEP) BEEP from IETF defines a connection-oriented Internet protocol. A SOAP mapping for BEEP has been defined. SOAP messages inherit the additional qualities of service from BEEP for maintaining session context at the sender and the receiver. (SOAP itself does not maintain any context.) The context is used to create a connection that relates multiple messages as coming from the same source or intended for the same target. Security and transaction context can also be associated with a connection.

Universal Description, Discovery, and Integration (UDDI) Universal Description, Discovery, and Integration (UDDI) provides the defi- nition of a set of services supporting the description and discovery of (1) businesses, organizations, and other Web Services providers, (2) the Web Services

they make available, and (3) the technical interfaces which may be used to access those services. The idea is to “discover” organizations and the services that organizations offer, much like using a phone book or dialing W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e information. by Douglas K. Barr y

ISBN:1558609067

UDDI was first developed by UDDI.org and then transferred Mor gan Kaufm ann Publ ishers ?2003 (245 pages) to OASIS. UDDI.org was comprised of more than 300 business and technology leaders working together to enable companies applications quickly, easily, and Prov ides both pr actical leader ship and ar chitectur al adv iceand on how t o pr eparto e an or ganization to t ak e dynamically find,advantage and use Web Services. of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

UDDI is based on a common set of industry standards, including HTTP, XML, XML Schema, and SOAP. It provides of Contents er Com m ents anTable infrastructure for a Back WebCov Services-based software environment for both publicly available services and services only exposed internally within an organization. The UDDI Business Registry system consists of three directories: Ta ble o f Con t en t s Web 1. Ser vices Ser pages: vice- Or iented chit ectur es—The Manager 's Guide UDDIand white basic Ar information such asSav a vy company name, address, and phone numbers, as well as For ewor dother standard business identifiers like Dun & Bradstreet and tax numbers. I ntr oduction

2. UDDI yellow pages: detailed business data, organized by relevant business classifications. The UDDI version of the yellow pages classifies businesses according to the newer NAICS (North American Industry Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e Classification System) codes, as opposed to the SIC (Standard Industrial Classification) codes. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt 3 - Ser vice- Or iented Ar chi tecturaes and Web Serv UDDIergreen pages: information about company’s key ices business processes, such as operating platform, supported For ces Affecti ng the Adoption of Web Ser vrequirements, ices and Otherand I ntegr ation programs, purchasing methods, shipping and billing other higher-level business protocols. Chapt er 4 Techniques Chapt er 5example - Growing I mpact ices Services, see page 23. For an of how UDDIofisWeb usedServ in Web Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es

Web Services Description Language (WSDL) - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

WSDL is a format for describing a Web Services interface. It is a way to describe services and how they should be

Chapt er to 8 specific - Change Wil l Happen bound network addresses. WSDL has three parts: Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent

1. Definitions

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt2.er Operations 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

bindings Chapt3.er Service 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based upon some agreed upon XML vocabulary. This Chapt er 14 - Addi tional Specification Details agreement could be within an organization or between organizations. Vocabularies within an organization could be Chapt er 15 - Qui ck Reference Guide designed specifically for that organization. They may or may not be based on some industry-wide vocabulary. If data I ndex type and message definitions need to be used between organizations, then most likely an industry-wide vocabulary List gures For more on XML vocabularies, see page 212. willofbeFi used. Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

XML, however, is not required for definitions. The OMG Interface Definition Language (IDL), for example, could be used instead of XML. If a different definitional format were used, senders and receivers would need to agree on the format as well as the vocabulary. Nevertheless, over time, XMLbased vocabularies and messages are likely to dominate. Operations describe actions for the messages supported by a Web service. There are four types of operations: 1. One-way: Messages sent without a reply required 2. Request/response:The sender sends a message and the receiver sends a reply. 3. Solicit response: A request for a response. (The specific definition for this action is pending.) 4. Notification:Messages sent to multiple receivers. (The specific definition for this action is pending.) Operations are grouped into port types. Port types define a set of operations supported by the Web service. Service bindings connect port types to a port. A port is defined by associating a network address with a port type. A collection of ports defines a service. This binding is commonly created using SOAP, but other forms may be used. These other forms could include CORBA Internet Inter-ORB Protocol (IIOP), DCOM, .NET, Java Message Service (JMS), or WebSphere MQ (formerly MQSeries) to name a few. XML Namespaces are used to ensure uniqueness of the XML element names in the definitions, operations, and service bindings. Figure 14.2 shows the relationship of the basic parts of WSDL. For an example of how WSDL is used in Web Services, see page 22.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Figure 14.2: Parts of WSDL.

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

ebXML - Registry Techniques

Chapt er 4 Chapt er 5

- Growing I mpact of Web Serv ices

The ebXML Registry is similar to UDDI in that it allows businesses to find one another, to define trading-partner Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - and to exchange XML messages in support of business operations. The goal is to allow all these agreements, Ar chitect ur es activities to be performed automatically, without human intervention, over the Internet. The ebXML architecture has Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e many similarities to SOAP/WSDL/ UDDI, and some convergence is taking place with the adoption of SOAP in the Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e ebXML transport specification. RosettaNet also announced its adoption of the ebXML transport. The ebXML Chapt er 8 - Change Wil l Happen messaging specification is based on SOAP with Attachments, but does not use WSDL. ebXML does add security, Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent guaranteed messaging, and compliance with business process interaction specifications. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt 10 - initiative Ar chitect is ur es at Each Stage AdoptiNations on for Web Ser vices The er ebXML sponsored by theofUnited Centre for Trade Facilitation and Electronic Business Chapt er 11 - Ar chitect ur al Opt (UN/CEFACT) and OASIS toions research, develop, and promote global standards for the use of XML to facilitate the Chapt er 12 of - Mi ddl e- Tier business Ar chitectur e exchange electronic data. A major goal for ebXML is to produce standards that serve the same or Chapt similar er 13 purpose - Revas isi ting EDI,the including Business support Tr ip in for theemerging Not- Too- Distant industry-specific Futur e XML vocabularies. ebXML and Web Pa Services r t I V - Com hold pethe ndi um promise of Softw of realizing a r e Te chnolog the original y for Sgoals er v i ceof - OrEDI, i e ntemaking d Ar chititect simpler ur e s

and easier to exchange electronic

documents Internet. See page 65 for a discussion of why this is simpler. Chapt er 14 - over Addi the tional Specification Details [ 1] Starting with SOAP Version 1.2, SOAP no longer is an acronym standing for Simple Object Access Protocol. It is Chapt er 15 - Qui ck Reference Guide

simply “SOAP.” I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e XML Specifications ISBN:1558609067

by Douglas K. Barr y

XML shares common origins and ?2003 SGML. SGML Mor gan Kaufmwith ann HTML Publ ishers (245 pages) or “Standard Generalized Markup Language” was issued as an international standard (ISO 8879) in 1986. It was intended would assist Prov ides both pr actical leader ship and ar chitectur al adv icefor onsemantic how t o prmarkup epar e anthat or ganization to t ak e computer cataloging and indexing. SGML flexibility thatarhad not been was,the however, advantage of Web ser vices provided and ser viceor iented chitectur es, briavailable dging t hebefore. gap betItween data- centr ic very complex. and t he software engineer ing wor lds. Table1990, of Contents Back Covat er CERN Com developed m ents About Tim Berners-Lee a new, simpler language that could be used in place of SGML. Thus, HTML or “Hyper-Text Markup Language” was intended to be a simpler language that did not require Ta ble o f Con t en t s expensive authoring tools. HTML succeeded beyond anyone’s expectations Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide but it lacked a certain flexibility that developers wanted. Various groups made changes and added extensions until HTML’s roots had been mangled. For ewor d I ntr oduction

In the summer of 1996, a working group at W3C was formed to create a markup language that would combine the strength of SGML with the simplicity of HTML. The first official draft specification for XML was released in November Chapt er XML 1 - version A Business Tr ip in the Not- TooDistant Futur e in 1998. 1996. 1.0 became a W3C recommendation Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

The er basic the This terminology, however, might cause one to think of XML as only a Chapt 3 structure - Ser vice-of OrXML ientedis Ar chidocument. tectur es and Web Serv ices richer, more flexible HTML. It is richer and more flexible, but it can so much For ces Affecti ng the Adoption of Web Ser v ices and Otherbe I ntegr ation more as well. Chapt er 4

-

Techniques Thinking as a Idocument allows you Chapt er 5 of- XML Growing mpact of Web Serv icesto see how it can be used for presentation of data. This presentation can

be detailed and useful we will see from XML is constructed. Ser viceOras iented Ar chi tectur es the and way Beliefs about Enter pr ise

Chapt er 6

-

Ar chitect ur es

XML does, however, actually go beyond documents. It can be used for the communication of data as well. XML Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e uses a flexible tagged structure that makes it more robust than a fixed record format for communication. This is how Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e many Web Services specifications use XML. Chapt er 8

- Change Wil l Happen

Chapt er 9XML - Tips for Managing dur ing Developm ent same flexible tagged structure can be used when Finally, can also be used Change to defineI ssues the storage of data. The Pa r t I I I -data. Cr e a ti ng Siserhow v i ce -some O r ie ntdatabase ed Ar chi te ctu r es storing This management

products use XML.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

This er section aalbrief on many of the relevant XML specifications. Chapt 11 - provides Ar chitect ur Opt background ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

XML Schema

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

XMLerSchemas express shared vocabularies Chapt 14 - Addi tional Specification Details and allow machines to carry out rules made by people. They provide a means for defining the structure, content, and semantics of XML documents. Chapt er 15 - Qui ck Reference Guide I ndex

REgular LAnguage description for XML (RELAX)

List of Fi gures

REgular LAnguage description for XML (RELAX) is a specification for describing XML-based languages. It is standardized by INSTAC XML SWG of Japan. Under the auspices of the Japanese Standard Association (JSA), this committee develops Japanese national standards for XML. See RELAX NG.

RELAX NG The purpose of this committee is to create a specification for a schema language for XML based on TREX and RELAX. The key features of RELAX NG are that it does not change the information set of an XML document, and supports XML Namespaces, unordered content, and mixed content.

Tree Regular Expressions for XML (TREX) Tree Regular Expressions for XML (TREX) is a language for validating XML documents. TREX has been merged with RELAX to create RELAX NG. All future development of TREX will take place as part of the RELAX NG effort. See RELAX NG.

Schematron The Schematron is a language and toolkit for making assertions about patterns found in XML documents. It can be used as a friendly validation language and for automatically generating external annotation (links, RDF, perhaps Topic Maps). Because it uses paths rather than grammars, it can be used to assert constraints that cannot be expressed using XML Schemas. Schematron was developed at the Academia Sinica Computing Centre, ASCC.

eXtensible Stylesheet Language (XSL) W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e eXtensible Stylesheet Language (XSL) is a language for expressing stylesheets. It consists of three parts: XSL Douglas K. Barr y for transforming XML documents, the XML Path Language (XPath),ISBN:1558609067 Transformations by (XSLT): a language an Mor gan Kaufm ann Publ (245 pages) expression language used by XSLT to ishers access?2003 or refer to parts of an XML document. (XPath is also used by the Prov ides actical leader ship and Objects ar chitectur al adv icean on XML how tvocabulary o pr epar e an ganizationformatting to t ak e XLink specification). The both third pr part is XSL Formatting (XSL-FO): fororspecifying advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic semantics. An XSL stylesheet specifies the presentation of a class of XML documents by describing how an and t he software engineer ing wor lds. instance of the class is transformed into an XML document that uses the formatting vocabulary. Table of Contents

Back Cov er

Com m ents

XSL Formatting Objects (XSL-FO)

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

XSL Formatting Objects (XSL-FO), is a set of tools developers and Web designers use to specify the vocabulary and semantics for paginated presentation.

For ewor d

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

XML Linking Language (XLink) - A Business Tr ip in the NotToo- Distant Futur e

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 5

- Growing I mpact of Web Serv ices

XML Linking Language (XLink) allows elements to be inserted into XML documents to create and describe links Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices between resources. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4as well HTML, as more sophisticated links. Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise XML Namespaces -

Chapt er 6

Ar chitect ur es

Chapt An XML er 7 namespace - St ar ti ng is t o aAdopt collection a Ser vi ofcenames, Or iented identified Ar chitectur by ae URI, which are used in XML documents as element Pa types r t I I -and Ma na attribute gi ng Cha names. nge N ee XML de dNamespaces for a Ser v i ce -differ Or ie nte from d Arthe chit“namespaces” e ct ur e

conventionally used in computing

disciplines that theWil XML version has internal structure and is not, mathematically speaking, a set. Chapt er 8 -inChange l Happen Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

XML Path Language (XPath)

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt XMLerPath 11 Language - Ar chitect ur (XPath) al Opt ions is the result of an effort to provide a common syntax and semantics for functionality

shared between Transformations and XPointer. The primary purpose of XPath is to address parts of an XML Chapt er 12 - Mi ddlXSL e- Tier Ar chitectur e document. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

XML Pointer Language (XPointer)

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide

XML Pointer Language (XPointer) allows addressing the internal structures of XML documents. It allows for I ndex examination List of Fi gures of a hierarchical document structure and choice of its internal parts based on various properties, such as element types, attribute values, character content, and relative position.

XML Signature XML Signature is an XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures provide for data integrity and authentication.

XSL Transformations (XSLT) XSL Transformations (XSLT) is a language for transforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In addition to XSLT, XSL includes an XML vocabulary for specifying formatting. XSL specifies the styling of an XML document by using XSLT to describe how the document is transformed into another XML document that uses the formatting vocabulary. XSLT may be used independently of XSL. However, XSLT is not intended as a completely general-purpose XML transformation language. Rather it is designed primarily for the kinds of transformations that are needed when XSLT is used as part of XSL.

XQuery XQuery is designed to be a language in which queries are concise and easily understood. It is also flexible enough to query a broad spectrum of XML information sources, including both databases and documents.

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e XML Vocabularies by Douglas K. Barr y

ISBN:1558609067

Every industry group hasKaufm its own its(245 activity. Mor gan annvocabulary Publ ishers for ?2003 pages)Various industry groups have been developing the XML version of their respective vocabularies to take advantage of thealXML messaging Services. Prov ides both pr actical leader ship and ar chitectur adv ice on how t capability o pr epar e of an Web or ganization to This t ak e is XML used in theadvantage messagesofdefined used WSDL andorsent using SOAPes, or other protocols. Web ser vicesby and ser viceiented ar chitectur bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

First, an important development in XML vocabularies will be covered. This is the Universal Business Language Table Then of Contents Back Cov er Com m (UBL). a sampling of vocabularies is ents listed. By no means are all vocabularies listed here. This is meant to give a taste of all the work being done right now on XML vocabularies. The organizations working on each vocabulary is Ta ble o f Con t en t s shown in italics at the end of the description. Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

This is a dynamic area for Web Services. For an updated listing, go to www.service-architecture.com. Links for each of these vocabularies can also be found at that Web site.

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Universal Business Language - I nfor m at ion Technology Used in Thi s(UBL) Tri p

Chapt er 2 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

The Universal Business Language (UBL) in OASIS is an important development in the use of XML vocabularies. In For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation any human Chapt er 4 - language, the same word can mean different things for different industries. Conversely, different words Techniques sometimes can mean the same thing in different industries. The OASIS UBL Technical Committee’s charter is to Chapt er 5 - Growing I mpact of Web Serv ices define a common XML business document library. UBL will provide a set of XML building blocks and a framework Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt that er will6 enable trading partners to unambiguously identify and exchange business documents in specific contexts. Ar chitect ur es This is an effort to unite efforts underway by organizations and standards groups around the world. The OASIS UBL Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e Technical Committee intends to enhance and harmonize overlapping XML business libraries and similar Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e technologies to advance consensus on an international standard. OASIS

Accounting

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Small and medium-sized business XML (smbXML): XML specification for describing business transactions. smbXML is specifically designed for the needs of the small to medium-sized business community. NetLedger/Oracle

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Astronomy

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details

The Astronomical Instrument Markup Language (AIML): XML specification for the command and control astronomical instruments (e.g., telescopes, cameras, and spectrometers). Based on IML. NASA

Chapt er 15 - Qui ck Reference Guide I ndex

List of Fi gures Flexible Image Transport System Markup Language (FITSML): XML specification for astronomical data, such as

images, spectra, tables, and sky atlases. Based on the XDF. Goddard Space Flight Center/NASA

Chemistry Chem eStandards: XML specification for data exchange developed specifically for the buying, selling, and delivery of chemicals.Chemistry Industry Data eXchange (CIDX) Chemical Markup Language (CML): XML specification covering macromolecular sequences to inorganic molecules and quantum chemistry. xmlcml.org

Construction Architecture Description Markup Language (ADML): XML specification for architecture. ADML is based on ACME, an architecture description language. ADML adds to ACME a standardized representation the ability to define links to objects outside the architecture (such as rationale, designs, and components). The Open Group

Customer Information eXtensible Name Address Language (xNAL): XML specification for managing name and address data regardless of country of origin. It consists of two parts: xNL: eXtensible Name Language to define the name components, and xAL: eXtensible Address Language to define the address components. OASIS

Education

Schools Interoperability Framework (SIF): XML specification for ensuring that K-12 instructional and administrative software applications work together more effectively. Software& Information Industry Association W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y XML/Electronic Data Interchange (EDI) Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical and ar chitectur al adv icedifferent on how types t o pr epar e an (e.g., or ganization to t ak e XML/Electronic Data Interchange (EDI):leader XMLship specification to exchange of data an invoice, advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic healthcare claim,and or project status). It includes implementing EDI dictionaries and on-line repositories to business t he software engineer ing wor lds. language, rules, and objects. XML/EDI Group Table of Contents

Back Cov er

Com m ents

Finance

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

eXtensible Business Reporting Language (XBRL): XML specification that describes financial information for public For ewor d and private companies and other organizations. xbrl.org

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Financial Information eXchange (FIX): XML specification for the realtime electronic exchange of securities

Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e transactions. FIX Protocol Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Financial Markup Language (FpML): for swaps, derivatives, and structured financial Chapt er 3 products - Ser viceOr iented Ar chi tectur es and XML Web specification Serv ices products.fpml.org For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4

-

Techniques Interactive (IFX):Serv XML specification for electronic bill presentment and payment, business to Chapt er 5 -Financial Growing Exchange I mpact of Web ices

business payments, business tochi business (such as Enter balance and transaction reporting, remittance Ser vice- Or iented Ar tectur es banking and Beliefs about pr ise Chapt er 6 - automated teller machine communications, consumer to business payments, and consumer to information), Ar chitect ur es business IFX Chapt er 7 banking. - St ar ti ng t oForum Adopt a Ser vi ce- Or iented Ar chitectur e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

- Change Wil l Happen Government

Chapt er 8 Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Election Markup Pa r t I I I - Cr e a ti ng Language S er v i ce - O (EML): r ie nt ed XML Ar chispecification te ctu r es

for the structured interchange of data among hardware,

software, engage in any aspect providing election or voter services to public or private Chapt er 10 and - Arservice chitect urproviders es at Eachwho Stage of Adopti on for Web of Ser vices organizations. services for such elections include but are not limited to voter roll/membership Chapt er 11 - ArThe chitect ur al Optperformed ions maintenance (new registration, Chapt er 12 - Mi ddl e-voter Tier Ar chitectur e membership and dues collection, change of address tracking, etc.), citizen/ membership credentialing, redistricting, absentee/expatriate ballots, election calendaring, logistics Chapt er 13 - Rev isi ting the Business Tr ip requests in the Not-for TooDistant Futur e management place management), delivery Pa r t I V - Com pe(polling ndi um of Softw a r e Te chnologelection y for S ernotification, v i ce - Or i e nteballot d Ar chit ect ur eand s

tabulation, election results

reporting, and demographics. OASIS Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide

Healthcare

I ndex

List of Fi gures

Health Level 7 (HL7) Healthcare XML Format: XML specification for the exchange of clinical data and information. The purpose of the exchange of clinical data includes, but is not limited to: provision of clinical care, support of clinical and administrative research, execution of automated transaction oriented decision logic (medical logic modules), support of outcomes research, support of clinical trials, and to support data reporting to government and other authorized third parties. Health Level Seven

Human Resources HR-XML: XML specification designed to enable e-business and the automation of human resources-related data exchanges.HR-XML Consortium

Insurance ACORD XML for Life Insurance: XML specification based on the ACORD Life Data Model. ACORD ACORD XML for Property and Casualty Insurance: XML specification that addresses the real-time requirement by defining property and casualty transactions that include both request and response messages for personal lines, commercial lines, specialty lines, surety, claims, and accounting transactions. ACORD

Instruments Instrument Markup Language (IML): XML specification that applies to virtually any kind of instrument that can be controlled by a computer. The approach to instrument description and control apply to many domains, from medical instruments (e.g., microscopes) to printing presses to machine assembly lines. The concepts behind IML apply equally well to the description and control of instruments in general. NASA

Legal

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

by Douglas K. Barr y of specifications. They are shown below. OASIS LegalXML has many subcategories

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

LegalXML Electronic Court Filing: specifications thearuse of XML to ice create legalt odocuments to transmit Prov ides both pr actical leader shipfor and chitectur al adv on how pr epar e an and or ganization to tlegal ak e documents fromadvantage an attorney, or vices self-represented litigant court, from a dging court to attorney, or selfof party Web ser and ser vice- or ientedtoarachitectur es, bri t hean gap bet weenparty the datacentr ic andor t he engineer ingfrom wor lds. represented litigant tosoftware another court, and an attorney or other user to another attorney or other user of legal documents. Table of Contents

Back Cov er

Com m ents

open XML standards for the markup of contract documents to enable the efficient creation, TaLegalXML ble o f ConeContracts: t en t s maintenance, management, exchange, and es—The publication documents and contract terms. Web Ser vices and Ser vice- Or iented Ar chit ectur Sav of vy contract Manager 's Guide For ewor d

LegalXML eNotary: an agreed set of technical requirements to govern self-proving electronic legal information.

I ntr oduction Pa r t I - Se r viIntegrated ce- O r ie nt ed Ar chi teXML ctur especifications Ov er v i ew LegalXML Justice:

Chapt er 1

for exchanging data among justice system branches and agencies.

- A Business Tr ip in the Not- Too- Distant Futur e

LegalXML Documents: Chapt er 2 Legislative - I nfor m at ion TechnologyXML Usedstandards in Thi s Trifor p the markup of legislative documents and a system of simple

citation capability for non-legislative documents (e.g., newspaper articles). The primary goal is to allow the public to - Ser vice- Or iented Ar chi tectur es and Web Serv ices more easily participate in the democratic process by creating a more open, accessible, easier to parse, research, For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 and reference legislative documents. LegalXML Legal Transcripts: XML syntax for representing legal transcript Techniques documents either as stand-alone structured Chapt er 5 - Growing I mpact of Web Serv ices content or as part of other legal records. Chapt er 3

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Math

Pa MathML: r t I I - MaXML na gi ng specification Cha nge N ee for dedescribing d for a Ser v mathematical i ce - Or ie nte d notation Ar chit e ct and ur e

capturing both its structure and content. The

goal er of 8MathML is to Wil enable mathematics to be served, received, and processed on the Internet, just as HTML has Chapt - Change l Happen W3CI ssues dur ing Developm ent enabled functionality for text. Chapt er 9 this - Tips for Managing Change Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

OpenMath: XML specification for representing mathematical objects with their semantics, allowing them to be exchanged between computer programs, stored in databases, or published on the worldwide Web. There is a strong Chapt er 11 - Ar chitect ur al Opt ions relationship to the MathML recommendation from the Worldwide Web Consortium, and a large overlap between the Chapt er 12 - Mi ddl e- Tier Ar chitectur e two developer communities. MathML deals principally with the presentation of mathematical objects, while Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e OpenMath is solely concerned with their semantic meaning or content. While MathML does have some limited Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s facilities for dealing with content, it also allows semantic information encoded in OpenMath to be embedded inside a Chapt er 14structure. - Addi tional Specification Details MathML Thus, the two specifications may be seen as complementary. The OpenMath Society Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Chapt er 15 - Qui ck Reference Guide

Open Mathematical Documents (OMDoc): XML specification for representing the semantics and structure of various I ndex kinds mathematical documents, including articles, textbooks, interactive books, courses. OMDoc is an extension List of Fiofgures of the OpenMath and MathML standards, and in particular of the content part of MathML. mathweb.orgeXtensible Data Format (XDF): XML specification for general mathematical principles that can be used throughout the scientific disciplines. Astronomical Data Center (ADC) at Goddard Space Flight Center/NASA

News News Industry Text Format (NITF): XML specification for the content and structure of news articles. International Press Telecommunications Council Publishing Requirements for Industry Standard Markup (PRISM): XML specification for syndicating, aggregating, post-processing and multipurposing content from magazines, news, catalogs, books, and mainstream journals. IDEAlliance

Physics Common Data Format Markup Language (CDFML): XML specification that is a self-describing data abstraction for the storage and manipulation of multidimensional data in a discipline-independent fashion. One of the CDFML’s goals is, as a proof of concept, demonstrating the interoperability between CDF and Flexible Image Transport System (see FTSML) using XDF as the intermediary format. National Space Science Data Center’s (NSSDC)

Real Estate Mortgage Industry Standards Maintenance Organization (MISMO): XML specification for commercial mortgage origination data that provides both the content and format for borrowers and mortgage bankers to transmit data to lenders. Mortgage Industry Standards Maintenance Organization

Real Estate Transaction Markup Language (RETML): XML specification for exchanging real estate transaction information.rets-wg.org W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Telecommunications

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web Markup ser vices (TIM): and serXML vice-specification or iented ar chitectur es, bri dging t he gap bet Telecommunications Interchange for describing the structure of ween the data- centr ic and and t he software engineer ing wor lds. Alliance for Telecommunications Industry Solutions (ATIS) telecommunications other technical documents. Table of Contents

Travel Ta ble o f Con t en t s

Back Cov er

Com m ents

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

The OpenTravel Alliance (OTA): XML specification that serves as a common language for travel-related terminology

For ewor d and a mechanism for promoting the exchange of information across all travel industry segments. OpenTravel I ntr oduction Alliance Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter Wby15: Quick Reference Guide Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Highlights Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

This chapter serves and as t heasoftware quick reference engineer to ingvarious wor lds.technologies and concepts related to service-oriented architectures. For those entries that have related examples or more information in this book, there is a reference at Table Contents Com minformation. ents the endofwhere you canBack findCov theeradditional Ta ble o f Con t en t s

Because Web Services is a dynamic area, new and revised technologies and concepts will be occurring regularly. If you cannot find what you need in this guide or to get an updated reference list, go to www.service-architecture .com.

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

I ntr oduction

Adapters

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

The adapters allow Web Services connections with internally developed systems or packaged software. There can - I nfor m at ion Technology Used in Thi s Tri p also be adapters between Web Services and CORBA or DCOM. For examples, see page 53.

Chapt er 2 Chapt er 3 Chapt er 4

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Agents-

Chapt er 5

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

- Growing I mpact of Web Serv ices

Agents are active entities thatArwork with es Web On aEnter relatively Ser viceOr iented chi tectur andServices. Beliefs about pr ise simple side, there are agents that can help us Chapt er 6 shop online. Ar More sophisticated agents would be able to perform negotiations, monitor the status of systems, or chitect ur es monitor or other systems. These agents could communicate with each other Chapt er 7 changes - St ar tiinngthe t o content Adopt a of Serdatabases vi ce- Or iented Ar chitectur e using Services they communicate systems Pa r t I I -Web Ma na gi ng Chaor nge N eecould de d for a Ser v i ce - Orwith ie nteother d Ar chit e ct ur einternal or external to the organization using WeberServices. For examples, see page 164. Chapt 8 - Change Wil l Happen Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Application Server

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

An application isala Opt component-based product that resides in the middle-tier of an architecture. It provides Chapt er 11 - Ar server chitect ur ions middleware for Ar security and Chapt er 12 - services Mi ddl e- Tier chitectur e state maintenance, along with data access and persistence. The two commercial of applications are TooJavaDistant applications Chapt er 13 - categories Rev isi ting the Business Tr ipservers in the NotFutur e servers based on J2EE or subsequent specifications .NET. moreydiscussion, 167. Pa r t I V - Com peor ndiMicrosoft’s um of Softw a r e TeFor chnolog for S er v i ce -see Or i e page nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

Business Intelligence (BI)

Chapt er 15 - Qui ck Reference Guide I ndex

Business intelligence (BI) software is a broad area covering data mining, pattern finding, reporting, and event List of Fi gures detection among other possible functions. Often, BI is used with data marts and data warehouses, but that is not a mandatory requirement. For more discussion, see page 162.

Business Objects Business objects are a way of representing something in the business domain, including various attributes, behavior, relationships, and constraints. They are usually used in the middle tier of a multi-tier architecture. For more discussion of a middle-tier architecture, see page 167.

Business Process Execution Language for Web Services (BPEL4WS)

Overview

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y

Business Process Execution for Web Services (BPEL4WS) defines a notation for specifying business Mor gan KaufmLanguage ann Publ ishers ?2003 (245 pages) process behaviorProv based on Web Services. ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Business processes be described in two ways: and tcan he software engineer ing wor lds.

1. Executable business processes model actual behavior of a participant in a business interaction.

Table of Contents

Back Cov er

Com m ents

Ta ble2.o f Business Con t en t s protocols, in contrast, use process descriptions that specify the mutually visible message exchange

behavior the parties in theSav protocol, without revealing their internal behavior. The process Web Ser vices and of Sereach vice- of Or iented Ar chitinvolved ectur es—The vy Manager 's Guide For ewor ddescriptions for business protocols are called abstract processes. I ntr oduction

BPEL4WS is used to model the behavior of both executable and abstract processes.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Business Process Modeling Language (BPML) - I nfor m at ion Technology Used in Thi s Tri p

Chapt er 2 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 5

- Growing I mpact of Web Serv ices

The Business Process Modeling Language (BPML) is a meta-language for the modeling of business processes, just For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 is a - meta-language for the modeling of business data. BPML provides an abstracted execution model for as XML Techniques collaborative and transactional business processes based on the concept of a transactional finite-state machine. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Chapt er 6

Ar chitect ur es Business Process Query Language (BPQL)

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

The Query Language (BPQL) a management Pa r t I IBusiness - Ma na giProcess ng Cha nge N ee de d for a Ser v i ce - Oris ie nte d Ar chit e ct ur interface e

to a business process management

infrastructure that includes a process execution facility (process server) and a process deployment facility (process Chapt er 8 - Change Wil l Happen repository). Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Business Process Specification Schema (BPSS)

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

The er Business Chapt 12 - MiProcess ddl e- TierSpecification Ar chitectur e Schema (BPSS) is a standard framework by which business systems may be configured support of business consisting Chapt er 13 -toRev isi tingexecution the Business Tr ip in thecollaborations Not- Too- Distant Futur e of business transactions. It is based upon prior UN/ CEFACT the Modeling Pa rt I V - Com pework, ndi umspecifically of Softw a r e Temeta-model chnolog y forbehind S er v i cethe - Or iUN/CEFACT e nte d Ar chit ect ur e s

Methodology (UMM) defined in the N090R9.1 specification. The specification schema supports the specification of business transactions and the Chapt er 14 - Addi tional Specification Details choreography of business transactions into business collaborations. These patterns determine the actual exchange Chapt er 15 - Qui ck Reference Guide of business documents and business signals between the partners to achieve the required electronic commerce I ndex transaction. List of Fi gures

Cache Synchronization Cache synchronization refers to keeping the data values in cache synchronized with the data values in the underlying database. For an example, see page 172.

Caching Caching is the retention of data to minimize network traffic flow and/or disk access. For more discussion, see page 169.

Collaboration Protocol Profile/Agreement (CPP/A) Collaboration Protocol Profile/Agreement (CPP/A) provides interoperability between two parties even though they may use application software and runtime support software from different vendors. The Collaboration Protocol Profile (CPP) defines message-exchange capabilities and the business collaborations that it supports. The Collaboration Protocol Agreement (CPA) defines the way two parties will interact in performing the chosen business collaboration.

Common Warehouse Meta-model (CWM) The Common Warehouse Meta-model (CWM) provides standard interfaces that can be used to enable easy interchange of warehouse and business intelligence metadata between warehouse tools, warehouse platforms, and warehouse metadata repositories in distributed heterogeneous environments.

Composite Application W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

A composite application is created by combining services. Composite applications are built using a service-oriented ISBN:1558609067 by Douglas K. Barr y architecture. Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

CORBA

CORBA is the acronym for Common Object Request Broker Architecture. It was developed under the auspices of Table of Contents Back Cov er(OMG). Com It m is ents the Object Management Group middleware. A CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program Ta ble o f Con t en t s from the same or another vendor, on almost any other operating Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Savcomputer, vy Manager 's Guide system, programming language, and network. For ewor d I ntr oduction

The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specifi- cation. The CORBA specification is responsible for really increasing the Chapt er 1 - ofA service-oriented Business Tr ip in the Not- Too- Distant Futurdiscussion, e awareness architectures. For more see page 45. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Data Cleansing For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Data cleansing are changes made to improve data quality. For existing data being loaded into a data mart or data Chapt er 5 - Growing I mpact of Web Serv ices warehouse, ETL software could be used to improve the quality of the data. For more discussion, see page 52. Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Data Mart - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

A data a database, or collection of databases, often found at the department level of an organization. Chapt er 8mart - is Change Wil l Happen

Sometimes designed for a particular subject or subset Chapt er 9 - they Tips are for Managing Change I ssues dur ing Developm entof data. It is possible for a collection of data marts to form basis of S a er data development Pa r t I I the I - Cr e a ti ng v i cewarehouse. - O r ie nt ed ArThe chi te ctu r es

of data warehouses may involve extract, transform, and load (ETL) software. For more discussion, see pages 50 and 162. Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

Data Warehouse

Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Ar tdata often refersa rto combining many sources across Pa I V - warehouse Com pe ndi um of Softw e Te chnolog ydata for Sfrom er v i ce - Or i edifferent nte d Ar chit ect ur e s

an enterprise. It is also referred to as enterprise data warehouse (EDW). The development of data warehouses usually involves extract, Chapt er 14 - Addi tional Specification Details transform, and load (ETL) software. For more discussion, see pages 50 and 162. Chapt er 15 - Qui ck Reference Guide I ndex

DCOM

List of Fi gures

DCOM is the acronym for the Distributed Component Object Model, an extension of the Component Object Model (COM). DCOM was introduced in 1996 and is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation’s DCE-RPC spec and will work with both Java applets and ActiveX components through its use of the Component Object Model (COM). It works primarily with Microsoft Windows. For more discussion, see page 45.

Directory A directory is a network service that identifies resources on a network and makes them accessible to users and applications. For Web Services, directories could use UDDI or the ebXML directory. For an example, see page 22.

Enterprise JavaBeans (EJB) Enterprise JavaBeans (EJBs) manage and coordinate the allocation of resources to the applications. Enterprise beans typically contain the business logic for a Java application. The EJB server must provide one or more EJB containers. An EJB container manages the enterprise beans contained within it. For each enterprise bean, the container is responsible for registering the object, providing a remote interface for the object, creating and destroying object instances, checking security for the object, managing the active state of the object, and coordinating distributed transactions. Optionally, the container can also manage all persistent data within the object. Also, see Java application servers in this guide.

Electronic Data Interchange (EDI) Electronic Data Interchange (EDI) began as early as the late 1960s. Over the years, there have been significant

efforts on standards for EDI. Two significant standards efforts are in the INCITS (ANSI) ASC X12 committee and UN/ EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport.) These eb Services an dwith Ser viceO rien t and ed Archit ect u re:groups. T h e SaFor vvy more Man ag er 's Gu id esee page 65. standards groupsW are also working the ebXML RosettaNet discussion, by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

eXtensibleProv Access Control Markup Language (XACML) ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

The Extensible Access Control Markup Language (XACML) provides fine grained control of authorized activities, the and t he software engineer ing wor lds. effect of characteristics of the access requestor, the protocol over which the request is made, authorization based onTable classes of activities, andCov content introspection. of Contents Back er Com m ents Ta ble o f Con t en t s

eXtensible rights Markup Language (XrML)

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d

eXtensible rights Markup Language (XrML) is a digital rights language designed for securely specifying and managing rights and conditions associated with various resources including digital content as well as services. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew I ntr oduction Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Extract,- ITransform, andUsed Load nfor m at ion Technology in Thi(ETL) s Tri p

Chapt er 2 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Extract, transform, and load (ETL) products are used to migrate data from one source to some destination. The For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 - is usually a database. The source can be a database or most any other source. The “extract” part is to destination Techniques select the source. reformats and possibly corrects the extracted data. “Load” places the Chapt er data 5 - from Growing I mpact “Transform” of Web Serv ices transformed data intoOrthe destination database. Also, see data warehouse and data mart in this guide. For more Ser viceiented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 - see page 50. discussion, Ar chitect ur es

Failover

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen Failover process of a secondary over forent a primary machine. For database failover, see Chapt er 9 is -the Tips for Managing Change Imachine ssues durtaking ing Developm

replication this guide. Pa r t I I I - Cr eina ti ng S er v i ceFor - O rmore ie nt eddiscussion, Ar chi te ctu rsee es

page 142.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Gadget

Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Gadgets components can be a Web site to provide Chapt er 13are - Rev isi ting the that Business Tr ipadded in thetoNotToo- Distant Futur e dynamic content. For more discussion, see page Pa r t I V 62. - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

HTTP

Chapt er 15 - Qui ck Reference Guide I ndex

HTTP List of Fistands gures for HyperText Transfer Protocol. It is a mechanism for sending requests and responses between computers connected to the Internet or an Intranet. For more discussion on HTTP and SOAP, see page 205.

Internet Inter-ORB Protocol (IIOP) The Internet Inter-ORB Protocol (IIOP) is the protocol used for communication between CORBA object request brokers (ORBs). Also, see CORBA in this guide.

J2EE See Java application servers in this guide.

Java API for XML Parsing (JAXP) The Java API for XML Parsing (JAXP) allows developers to easily use XML Parsers in their applications.

Java Application Servers Java application servers are based on the Java 2 Platform, Enterprise Edition (J2EE). J2EE uses a multi-tier distributed model. The J2EE Platform consists of a Web Server and an EJB Server. (These servers are also called “containers.”) The Web container provides the runtime environment through components that provide naming context and life cycle management. Some Web servers may also provide additional services such as security and concurrency control. A Web server may work with an EJB server to provide some of those services. A Web server, however, does not need to be located on the same machine as an EJB server. The EJB server provides an environment that supports the execution of applications developed using Enterprise JavaBeans (EJB) components.

It manages and coordinates the allocation of resources to the applications. Enterprise beans typically contain the business logic for a J2EE application. Also, see EJB in this guide. More discussion can be found on page 167. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067

by Douglas K. Barr y Load Leveling Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ides both pr actical leader ship and aror chitectur al advmore ice onthan how one t o prmachine. epar e an or ganization to see t ak e Load leveling is aProv design strategy that spreads activity load across For examples, advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic page 140. and t he software engineer ing wor lds. Table of Contents Mapping

Back Cov er

Com m ents

Ta ble o f Con t en t s

Mapping is the toAr make onees—The or moreSav rows database tables appear as programming language Web Ser vices andtechnique Ser vice- Orused iented chit ectur vy in Manager 's Guide objects For ewor d or XML. For more discussion, see www.service-architecture.com. I ntr oduction

Message Router

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e Message direct from a requesting to a responding resource and back. These are also known Chapt er 2 routers - I nfor m at iondata Technology Used in Thi sresource Tri p

as application brokers message brokers. A router “knows” Chapt er 3 - Ser vice- Oror iented Ar chi tectur es and Web Serv ices which of the other internal systems needs to receive a certain type of updates. The individual internal systems can pass updates to a router and would not need to know

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt 4 - such updates. A message router usually needs to transform the data in some way in order to match who er receives Techniques

the format the dataI mpact expected by the receiving system. For more discussion, see page 52. Chapt er 5 -ofGrowing of Web Serv ices Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Message Service Specification (MSS)

Pa r t I I - MaService na gi ng Cha nge N ee de(MSS) d for a is Ser i ce - Or ie nte d Ar chit e ct ur e Message Specification avcommunications-protocol

neutral method for exchanging electronic

business It supports Chapt er 8 messages. - Change Wil l Happen reliable, secure delivery of business information and a flexible enveloping technique, permitting of any format type. Chapt er 9 messages - Tips for Managing Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Meta-Object Facility (MOF)

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

Chapt The er Meta-Object 12 - Mi ddlFacility e- Tier Ar (MOF) chitectur is a e set of standard interfaces that can be used to define and manipulate a set of

interoperable meta-models and theirTrcorresponding models. Chapt er 13 - Rev isi ting the Business ip in the Not- TooDistant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Middleware

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex Middleware hides the complexity of the communication between two or more systems or services. This simplifies the

development List of Fi gures of those systems and services and isolates the complexity of the communication between them. The different systems or services can be on the same hardware or on different hardware. For more discussion, see page 43.

Model Driven Architecture (MDA) The Model Driven Architecture (MDA) is an open, vendor-neutral approach to interoperability using OMG’s modeling specifications: Unified Modeling Language (UML), Meta-Object Facility (MOF), and Common Warehouse Metamodel (CWM).

.NET Microsoft .NET is a set of Microsoft software technologies for Web Services. Microsoft .NET is made up of three core components: 1. NET building block services 2. NET device software for devices such as mobile phones, pagers, and so on 3. NET infrastructure, which includes: NET Framework—the Common Language Runtime (CLR) and .NET Framework class libraries Microsoft Visual Studio.NET: Visual Basic .NET, Visual C# .NET, Visual C++ .NET, Visual FoxPro, and so on Servers called .NET Enterprise Servers

More discussion can be found on page 167. W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Object Request Broker (ORB) by Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

The Object Request Broker (ORB) is middleware that uses the CORBA specification. Also see CORBA in this guide. Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

OMG Interface Definition Language (IDL)

Table of Contents Back CovLanguage er Com m ents permits interfaces to objects to be defined independent of an object’s The OMG Interface Definition (IDL) Taimplementation. ble o f Con t en t sAfter defining an interface in IDL, the interface definition is used as input to an IDL compiler that produces output to be compiled linked an object Web Ser vices and Ser viceOr ientedand Ar chit ecturwith es—The Sav vy implementation Manager 's Guideand its clients. Also see CORBA in this guide. (There are other uses of the IDL initialisms. For example, there is also a Java IDL.) For ewor d I ntr oduction

Partner Interface Process (PIP)

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e A Partner Process (PIP) defines Chapt er 2 Interface - I nfor m at ion Technology Used inbusiness Thi s Tri pprocesses between trading partners. PIPs fit into seven

clusters, ofOrcore business processes, thatServ represent the backbone of the trading network. Each cluster is Chapt er 3 or- groups Ser viceiented Ar chi tectur es and Web ices broken down into segments—cross-enterprise processes involving more than one type of trading partner. Within

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt 4 eacherSegment are individual PIPs. PIPs are specialized system-to-system XML-based dialogs. Each PIP Techniques

specification includes Iampact business document Chapt er 5 - Growing of Web Serv iceswith the vocabulary, and a business process with the choreography of the messageSer dialog. vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise -

Chapt er 6

Ar chitect ur es

Replication

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt Replication er 8 - isChange the process Wil l Happen of making multiple copies of data on separate machines. The replicated data will be

available machine should need take over Chapt er 9 on - the Tipssecondary for Managing Change I ssuesit dur ing to Developm entwhen the primary machine fails. See failover in this guide. page 143. Pa r t I I I For - Cr emore a ti ngdiscussion, S er v i ce - O r see ie nt ed Ar chi te ctu r es Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Resource Description Framework (RDF)

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Resource a way describing a Web Chapt er 13 Description - Rev isi ting Framework the Business(RDF) Tr ip inisthe Not-of TooDistant Futur e site’s metadata, or the data about the data at the Pa r t Isite. V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

RosettaNet Implementation Framework (RNIF)

Chapt er 15 - Qui ck Reference Guide I ndex

TheofRosettaNet Implementation Framework (RNIF) provides the packaging, routing, and transport of RosettaNet List Fi gures PIP messages and business signals.

Security Assertion Markup Language (SAML) The Security Assertion Markup Language (SAML) is an XML framework for exchanging authentication and authorization information.

Service A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. For more discussion, see page 19.

Service Provisioning Markup Language (SPML) Service Provisioning Markup Language (SPML) is an XML-based framework specification for exchanging user, resource, and service provisioning information. The SPML specification is being developed with consideration of the following provisioning-related specifications: Active Digital Profile (ADPr), eXtensible Resource Provisioning Management (XRPM), and Information Technology Markup Language (ITML).

Service-Oriented Architecture A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. For more discussion, see page 18.

Unified Modeling Language (UML) W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

The Unified Modeling Language (UML) is a specification of a graphical language used for visualizing, specifying, ISBN:1558609067 by Douglas K. Barr y constructing, andMor documenting thePubl artifacts distributed object systems. gan Kaufm ann ishersof ?2003 (245 pages) Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Identifier Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Uniform Resource (URI) and t he software engineer ing wor lds.

Uniform Resource Identifiers (URIs, Com alsomknown as URLs) are short strings that identify resources in the Web: Table of Contents Back Cov er ents documents, images, downloadable files, services, electronic mailboxes, and other resources. Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Universal Data Model

For ewor d

I ntr oduction data model is a template or generic data model that can be used as a building block for the development A universal Pa - Se rmodel. vi ce- O r For ie nt ed Ar chi te ctur e Ovsee er v ipage ew ofr taI data more discussion,

120.

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Web Distributed Data Exchange (WDDX) Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption Ser v ices and Other I ntegr ation WeberDistributed Data Exchange (WDDX) of is Web an XML-based technology that enables the exchange of complex data Chapt 4 Techniques

between Web programming languages. WDDX consists of a language-independent representation of data based on - Growing I mpact of Web Serv ices XML, and a set of modules for a wide variety of languages that use WDDX.

Chapt er 5 Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Web Services Language (WSEL) - St ar ti ng t oEndpoint Adopt a Ser vi ceOr iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

The er Web Language (WSEL) is an XML format for the description of non-operational Chapt 8 Services - ChangeEndpoint Wil l Happen characteristics of service endpoints, like quality-of-service, cost, or security properties. - Tips for Managing Change I ssues dur ing Developm ent

Chapt er 9

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Web Services Component Model

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions

The er Web Model Chapt 12 Services - Mi ddl e-Component Tier Ar chitectur e is an XML and Web Services centric component model for interactive Web

applications. The designs must achieve two main goals: enable businesses to distribute Web applications through multiple revenue channels, and enable new services or applications to be created by leveraging existing applications Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s across the Web. Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide

Web Services Conversation Language (WSCL)

I ndex

List of Fi gures

Web Services Conversation Language (WSCL) allows the business level conversations or public processes supported by a Web service to be defined. WSCL specifies the XML documents being exchanged, and the allowed sequencing of these document exchanges. WSCL conversation definitions are themselves XML documents and can therefore be interpreted by Web Services infrastructures and development tools.

Web Services Experience Language (WSXL) Web Services Experience Language (WSXL) enables businesses to distribute Web applications through multiple revenue channels and to enable new services or applications to be created by leveraging existing applications across the Web. WSXL is built on widely accepted established and emerging open standards, and is designed to be independent of execution platform, browser, and presentation markup. Interactive Web applications that are developed using WSXL can be delivered to end users through a diversity of deployment channels: directly to a browser, indirectly through a portal, or by embedding into a third party Web application.

Web Services Flow Language (WSFL) Web Services Flow Language (WSFL) is a language for the description of Web Services compositions. WSFL considers two types of Web Services compositions: 1. The appropriate usage pattern of a collection of Web Services, in such a way that the resulting composition describes how to achieve a particular business goal; typically, the result is a description of a business process 2. The interaction pattern of a collection of Web Services; in this case, the result is a description of the overall partner interactions

Web Services for Interactive Applications (WSIA) eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Web Services forWInteractive Applications (WSIA) is an XML and Web Services centric framework for interactive ISBN:1558609067 by Douglas K. Barr y achieve two main goals: enable businesses to distribute Web applications Web applications. The designs must Mor gan Kaufm ann Publ ishers ?2003 (245 pages) through multiple revenue channels, and enable new services or applications to be created by leveraging existing Provthe idesWeb. both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e applications across advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Web Services for Remote Portals (WSRP) Table of Contents

Back Cov er

Com m ents

TaWeb ble oServices f Con t en tfor s Remote Portals (WSRP) is an XML and Web Services standard that will allow for the plug-n-play

of: portals, intermediary Web that Sav aggregate content, and applications from disparate sources. Web Ser vicesother and Ser vice- Or iented Ar applications chit ectur es—The vy Manager 's Guide

These Web Services for Remote Portals will be designed to enable businesses to provide content or applications in a form that does not require any manual content or application-specific adaptation by consuming applications.

For ewor d

I ntr oduction

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Web Services Interface (WSUI) - A BusinessUser Tr ip in the Not- Too- Distant Futur e

Chapt er 1 Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Web Services User Interface (WSUI) enables Web platforms implemented in entirely different languages (Java, Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices COM/.NET, and Perl) to interoperate and share applications. By using WSUI, an application can be packaged with a For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er descriptor 4 WSUI file and an XSLT stylesheet and be dynamically integrated into another Web site that is running a Techniques WSUI container implementation. Chapt er 5 - Growing I mpact of Web Serv ices

XLANG

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa XLANG r t I I - Ma is na a notation gi ng Chafor ngethe N ee automation de d for a Ser of vbusiness i ce - Or ie nte processes d Ar chit e ct based ur e

on Web Services for the specification of

message among participating Web Services. XLANG is expected to serve as the basis for Chapt er 8 exchange - Change behavior Wil l Happen automated that can track thedur state of processentinstances and help enforce protocol correctness in Chapt er 9 -protocol Tips for engines Managing Change I ssues ing Developm message Pa r t I I I - Crflows. e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

XML Common Biometric Format (XCBF)

Chapt er 11 - Ar chitect ur al Opt ions

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

XMLerCommon Biometric (XCBF) a common of secure Chapt 13 - Rev isi ting theFormat Business Tr ip inisthe Not- Too- set Distant Futur eXML encoding for the formats specified in CBEFF, the pe Common Biometric Pa r t I V - Com ndi um of Softw a r eExchange Te chnologFile y forFormat. S er v i ce - Or i e nte d Ar chit ect ur e s Chapt er 14 - Addi tional Specification Details

XML Encryption

Chapt er 15 - Qui ck Reference Guide I ndex

XML is a process for encrypting/decrypting digital content (including XML documents and portions thereof List of Encryption Fi gures ) and an XML syntax used to represent the encrypted content and information that enables an intended recipient to decrypt it.

XML Key Management Specification (XKMS) The XML Key Management Specification (XKMS) is a specification of XML application/protocol that allows a simple client to obtain key information (values, certificates, and management or trust data) from a Web service.

XML Protocol (XMLP) XML Protocol (XMLP) provides simple protocols that can be ubiquitously deployed and easily programmed through scripting languages, XML tools, interactive Web development tools, etc. The goal is a layered system which will directly meet the needs of applications with simple interfaces (e.g., get- StockQuote, validateCreditCard), and which can be incrementally extended to provide the security, scalability, and robustness required for more complex application interfaces.

XML Signature XML Signature is an XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures provide for data integrity and authentication.

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

A

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic ACORD XML, 215 and t he software engineer ing wor lds.

ad hoc access, 151, 153 Table of Contents

Back Cov er

adapters, 69, 147, 219

Com m ents

Ta ble o f Con t en t s

additional systems, 138

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

agents, 12–13, 164–165 adding to master database/internal systems, 165 I ntr oduction communication, 164 Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew defined, 164, 219 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e forms, 164 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p sophisticated, 164 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices See also architectural options For ewor d

Chapt er 4 15airlines,

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques

Chapt er 5 National - Growing I mpact ofInstitute Web Serv ices 191–192 American Standards (ANSI), Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise analysis 83 Chapt er 6 paralysis, Ar chitect ur es

application message routers Chapt er 7 -routers. St ar ti ngSee t o Adopt a Ser vi ce- Or iented Ar chitectur e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e application servers

Chaptcaching er 8 - in, Change 169, 173 Wil l Happen

in, 169 Change I ssues dur ing Developm ent Chaptcomponents er 9 - Tipsused for Managing Pa r t defined, I I I - Cr e a220 ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

9–10ur es at Each Stage of Adopti on for Web Ser vices Chaptfault-tolerant, er 10 - Ar chitect ChaptJava, er 11 225 - Ar chitect ur al Opt ions

speeding 178 e Chaptprocessing, er 12 - Mi ddl e- Tier Arup, chitectur Chapt architectural er 13 - Rev options, isi ting157–165 the Business Tr ip in the Not- Too- Distant Futur e Pa r t agents, I V - Com164–165 pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

162 Specification Details ChaptBI erpackages, 14 - Addi tional Chaptdata er 15marts, - Qui162–163 ck Reference Guide I ndexdata warehouses, 162

data-centric architecture, 157–158 List of Fi gures

distributed-process architecture,158–162 master databases, 162–163 middle-tier architecture, 167–185 See also service-oriented architectures

Architecture Description Markup Language (ADML), 214 Astronomical Instrument Markup Language (AIML), 213 AV system analogy, 17–19, 77, 87, 90, 97 components, 17–18 connections, 18

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

B

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic basic business elements (BBEs), 37 and t he software engineer ing wor lds.

beliefs Table of Contents Back Cov er Com m ents enterprise architecture, 75–86 Ta blefor o f function Con t en tto s follow form, 79–83 Web Ser vices and Ser vice- Or iented Ar chit(BEEP), ectur es—The Blocks Extensible Exchange Protocol 192 Sav vy Manager 's Guide For ewor defined, d 205

SOAP mapping for, 205 I ntr oduction Pa r t I - Se William, r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew Bridges, 102

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

business intelligence (BI) packages, 11, 162–163 - I nfor m at ion Technology Used in Thi s Tri p adding, to distributed master database, 163 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices with data marts, 162–163 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptdefined, er 4 - 220 Techniques uses, 162 Chapt er 2

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

business objects, 220 Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es Business Process Execution Language for Web Services (BPEL4WS), 220 Business Process Management Initiative (BPMI.org), 192

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Business Modeling Language (BPML), 221 Chapt er 8 Process - Change Wil l Happen

Business Query Language (BPQL), Chapt er 9 Process - Tips for Managing Change I ssues 221 dur ing Developm ent Pa r t I I I - CrProcess e a ti ng S er v i ce - O r ie nt Schema ed Ar chi te ctu r es Business Specification (BPSS),

221

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

business trip example, 5–16 airlines and hotel, 15 Chapt er 12 - Mi ddl e- Tier Ar chitectur e car rental service, 15 Chaptclient er 13updates, - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e 13–14 Pa r t company I V - Com pe ndi um of Softw a r e 11–12 Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s contact information, Chaptcustomer er 14 - Addi tional Specification Details contacts, 9–11 Chaptdefined, er 15 - 5–8 Qui ck Reference Guide I ndexdetails for services and data exchange, 186 List of Fi gures technology use, 9–16 information online calendar services, 12–13 revisiting, 185–188 services and data exchange for, 10 services as commodities, 15 summary, 8 travel agency service, 14–15 Chapt er 11 - Ar chitect ur al Opt ions

business-to-business connections, improving, 65–73

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

C

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic cache synchronization, 172–174 and t he software engineer ing wor lds. defined, 172, 221 issues for mapping, 174Cov er Table of Contents Back Com m ents problem elimination, 174

Ta ble o f Con t en t s

cache Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide contents, 172 For ewor d

location, 169 objects, 172, 173 Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew persistent, 175, 179 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e population methods, 169–170 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p replication, 170 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices tables, 172, 173 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation ChaptXML, er 4 172, - 173 I ntr oduction

Techniques

caching Chapt er 5

- Growing I mpact of Web Serv ices

in application servers, 169,Ar173 Ser viceOr iented chi tectur es and Beliefs about Enter pr ise defined,- 169, 221 ur es Ar chitect Chaptexpanded, er 7 - St175, ar ti ng177 t o Adopt a Ser vi ce- Or iented Ar chitectur e 170–171 Pa r t in-memory, I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e tier, 169–174 Chaptinermiddle 8 - Change Wil l Happen 175, 177–178 Chaptperformance er 9 - Tips gain, for Managing Change I ssues dur ing Developm ent 177 Pa r t protected, I I I - Cr e a ti175, ng S er v i ce - O r ie nt ed Ar chi te ctu r es 173 ur es at Each Stage of Adopti on for Web Ser vices Chapttables, er 10 172, - Ar chitect Chapt er 6

car rental 15 ur al Opt ions Chapt er 11 service, - Ar chitect Chapt er 12 - Mi ddl e- Tier Ar chitectur e change Chaptadvantages, er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e communicating, 104 Pa r t communicating, I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s 102–103

Chaptdealing er 14 -with, Addi96 tional Specification Details Chaptdesign er 15 and, - Qui119–122 ck Reference Guide I ndexissues and responses worksheet, 115, 116

management tips, 119–123 List of Fi gures managing, 93–123 methodologies and, 122 project scope and, 122 resistance to, 100–115 second set of eyes and, 122–123 small teams and, 123 summary, 118 system, force field analysis for, 39 technical issues, 98–102 change issues existing systems adaptation stage, 145 internal service-oriented architecture establishment stage, 152–154 internal service-oriented architecture expansion stage, 154 intersystem dependencies removal stage, 149–150 service-oriented architecture adoption, 101 technical, 98–100 worksheet, 115, 116 Chemistry Industry Data eXchange (CIDX), 213 Collaboration Protocol Profile/Agreement (CPP/A), 221–222 Common Data Format Markup Language (CDFML), 217 Common Object Request Broker Architecture (CORBA), 45 adopting, 45–46 defined, 222 EDI initial use of, 68

EDWs coexisting with, 53 force field analysis for adopting, 45 W eb implementation, 45Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067 by Douglas K. Barr y Internet Inter-ORB Protocol (IIOP), 208 Mor gan Kaufm ann Publ ishers ?2003 (245 pages) restraining forces, 46 VANs and, 66–67 Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e of Web ser vices Web Servicesadvantage interoperation with, 49 and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. XML with, 46 Common Table of Warehouse Contents Back Meta-model Cov er (CWM), Com m ents 222 Tacommunication ble o f Con t en t s Web change, Ser vices 102–103 and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

change advantages, 104 For ewor d in overcoming resistance, 107 I ntr oduction Pa r t I - Se r vi ceO r ie nt ed Ar chi te ctur108–111 e Ov er v i ew complication resistance scenario,

Chaptdefined, er 1 - 108–109 A Business Tr ip in the Not- Too- Distant Futur e

resistance suggestions, Chaptovercoming er 2 - I nfor m at ion Technology Used110–111 in Thi s Tri p issues, Chaptresistance er 3 - Ser vice- Or109–110 iented Ar chi tectur es and Web Serv ices See also For resistance; scenarios ces Affectiresistance ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques components Chaptinerapplication 5 - Growing I mpact servers, 169of Web Serv ices Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chaptdefined, er 6 - 168 Ar chitect ur es programming languages, 168 Chapt er 4

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

composite applications, 5, 222

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

connections, 20–21 Wil l Happen Chapt er 8 - Change improving, Chaptbusiness-to-business, er 9 - Tips for Managing Change65–73 I ssues dur ing Developm ent 88 Pa r t HTTP, I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es Chaptinternal, er 10 - improving, Ar chitect ur63–64 es at Each Stage of Adopti on for Web Ser vices Chaptinternal er 11 -systems, Ar chitect53 ur al Opt ions

in service-oriented architectures, 61 Web Services, 57, 88 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Web site, improving, 62 Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

CORBA, Request Broker Chapt er 14 seeCommon - Addi tional Object Specification Details Chapt costser 15 - Qui ck Reference Guide I ndexdistributed-process architecture, 159

existing List of Fi guressystems adaptation stage, 96 experiment with Web Services stage, 96 internal service-oriented architecture expansion stage, 97 intersystem dependencies removal stage, 97 restraining forces and, 40–41 service-oriented architecture adoption, 96–98 VAN barriers, 66 Customer Relationship Management (CRM), 187 commercial packages, 80 external service, 11–12, 21 on subscription basis, 88 system, 10–11

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

D

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic data cleansing, 222 and t he software engineer ing wor lds.

data conflict resolution, 82–83 Table of Contents

Back Cov er

Com m ents

data interchange standardization, 14, 15 Ta ble o f Con t en t s

data marts, 162–163 BI packages with, 162–163 For ewor d defined, 222–223

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide I ntr oduction

data warehouses, 162 analysis, 50–52 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e defined, 223 Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

databases Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices design, 162 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptdistributed, er 4 141 Techniques ChaptEIS-tier, er 5 - 178 Growing I mpact of Web Serv ices failover options, Ser vice-142 Or iented Ar chi tectur es and Beliefs about Enter pr ise Chaptmaster, er 6 -133–135 Ar chitect ur es 177–180 Chaptmiddle-tier, er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e options, 140–141 Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e options, Chaptreplication er 8 - Change Wil143 l Happen single, 141 Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent data-centric Pa r t I I I - Cr e aarchitecture, ti ng S er v i ce - 157–158 O r ie nt ed Ar chi te ctu r es 157–158 Chaptadvantages, er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices availability, 158 Chaptcomponent er 11 - Ar chitect ur al Opt ions 157 Chaptdata er 12quality, - Mi ddl e- Tier Ar chitectur e combining,162 Chaptdata-centric er 13 - Revarchitecture, isi ting the Business Tr ip in the Not- Too- Distant Futur e

157 Pa r t defined, I V - Com11, pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chaptdelay er 14distribution, - Addi tional158 Specification Details

distributed-process architecture vs.,158–160 effect on operational systems, 157 I ndex illustrated, 159 List of Fi gures See also architectural options Chapt er 15 - Qui ck Reference Guide

day-to-day operational data requirements, 81–82 DCOM,seeDistributed Common Object Model design code writing and, 121–122 database, 162 intersystem dependency considerations, 147–149 as little as possible, 119–121 software packages and, 120 universal data models, 120–121 Distributed Common Object Model (DCOM), 45 adopting, 45–46 defined, 223 EDI initial use of, 68 EDWs coexisting with, 53 force field analysis for adopting, 45 restraining forces, 46 VANs and, 66–67 Web Services interoperation with, 49 XML with, 46 distributed databases, 141 distributed-process architecture, 15, 158–162 cost, 159

data-centric architecture combination, 162 data-centric architecture vs., 158–160 defined, 158 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067 by Douglas high-availability, adding, K. 161Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) illustrated, 160, 161 when to consider, Prov ides 161–162 both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantageoptions of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic See also architectural and t he software engineer ing wor lds.

documentation, 83

Table forces, of Contents Com m ents driving 38, 39 Back Cov er 101 Ta blefor o f change Con t en tissues, s for CORBA/DCOM adoption, Web Ser vices and Ser viceOr iented 45 Ar chit ectur es—The Sav vy Manager 's Guide for EDI adoption, 70 For ewor d for EDW adoption, 51 I ntr oduction and 43, 48 Pa r t mergers I - Se r vi ceO racquisitions, ie nt ed Ar chi te ctur e Ov er v i ew for message router adoption, 56 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e for service-oriented architecture adoption, 117 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p for technical change issues, 99 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices for Web Services adoption, 47 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation ChaptSee er 4also - force field analysis; restraining forces Techniques Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

E

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic ECMA, 193 and t he software engineer ing wor lds. standards, 204 Table Com m ents EIS tierof Contents Back Cov er Ta bledatabases, o f Con t en t178 s defined, Web Ser vices 167 and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide illustrated, 168 For ewor d See also middle tier I ntr oduction

Election (EML), Pa r t I - SeMarkup r vi ce- O r Language ie nt ed Ar chi te ctur e215 Ov er v i ew Chapt er 1 business - A Business ip in the Notelectronic XMLTr(ebXML), 192Too- Distant Futur e Chaptdefined, er 2 - 193 I nfor m at ion Technology Used in Thi s Tri p Chaptinitiative, er 3 - 209 Ser vice- Or iented Ar chi tectur es and Web Serv ices major goal, For209 ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 Techniques messaging specification, 208 ChaptRegistry, er 5 - Growing I mpact of Web Serv ices 24, 208–209 Ser vice- Or iented 198–199, 202 Ar chi tectur es and Beliefs about Enter pr ise Chaptstandards, er 6 Ar chitect ur es using, 193 Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Electronic Data Interchange (EDI), 11, 20, 46, 50, 61 analysis, 70–73 Chapt er 8 - Change Wil l Happen barriers, 65 Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent CORBA/DCOM use, 68 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es data transmission, initial form, 66 Chaptdefined, er 10 - 224 Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chaptdriving er 11 forces, - Ar chitect al Opt ions 70,ur72 Chaptfixed er 12record - Mi ddl e- Tier and, Ar chitectur formats 67 e Chaptforce er 13field - Rev isi ting for theadopting, Business Tr analysis 72ip in the Not- Too- Distant Futur e Pa r t history, I V - Com65–70 pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s Chaptindustry-standard er 14 - Addi tionaldefinitions Specification for, Details 70 Chaptperceived er 15 - Qui complexity ck Reference of, 72 Guide I ndexpotential, 65 product List of Fi guressupport of, 70 proprietary networks for, 72 restraining forces, 72 specification, 65 standards, 65 steps, 65–66 in transition, 69–70, 71 with VANs, 67 Web Services use, 69, 70, 88 XML use, 68, 69 Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

elephant in the room resistance scenario, 114–115 defined, 114–115 overcoming resistance suggestions, 115 resistance issues, 115 See also resistance; resistance scenarios enterprise architectures analysis paralysis, 83 beliefs, 75–86 building architecture analogies, 79–81 common issues, 83–84 data conflict resolution, 82–83 data definition rigidity, 84 day-to-day operations, 81–82 design, 80 flexibility, 79 in “form follows function,” 76

frameworks, 78 goals, 84 W eb methodologies, 78Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067 by Douglas over-standardization, 83 K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages) service-oriented architecture as part of, 76–78 strategic information, Prov ides 81–82 both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic watered down, 84 and t he software engineer ing wor lds.

enterprise data warehouses (EDWs), 50–52, 135 Table Contents Back CovServices, er Com52, m ents with ofCORBA/DCOM/Web 53 data corruption, 52 Ta ble o f Con t en t s data latency, 51 Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide force field analysis for adopting, 51 For ewor d using, 50 I ntr oduction

Enterprise 223e Ov er v i ew Pa r t I - Se r viJavaBeans ce- O r ie nt ed(EJBs), Ar chi te ctur Chapt Enterprise er 1 -Resource A Business Planning Tr ip in the (ERP), Not-19, Too-88 Distant Futur e Chapt er 2 - I nfor m at ion Technology enterprise-wide standards, 40–43 Used in Thi s Tri p Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

event-based replication, 143

Chapt er 4

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation

existing systems adaptation stage Techniques systems,I mpact 138 of Web Serv ices Chaptadditional er 5 - Growing architectures, 133–145 Ser viceOr iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 change issues, 145 Ar chitect ur es Chaptcomponents er 7 - St arconnection, ti ng t o Adopt135 a Ser vi ce- Or iented Ar chitectur e Pa r t costs, I I - Ma96 na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e options,Wil 140–141 Chaptdatabase er 8 - Change l Happen Chaptdefined, er 9 - 90 Tips for Managing Change I ssues dur ing Developm ent Pa r t failover I I I - Cr eoptions, a ti ng S er142 v i ce - O r ie nt ed Ar chi te ctu r es 133–135 Chaptmaster er 10 -database Ar chitectcreation, ur es at Each Stage of Adopti on for Web Ser vices master database update routing, 135–137 Chapt er 11 - Ar chitect ur al Opt ions message router options, 138–140 Chapt er 12 - Mi ddl e- Tier Ar chitectur e replication options, 143 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e staffing, 145 Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s See also Web Services adoption Chapt er 14 - Addi tional Specification Details

expanded 175, 177 Guide Chapt er 15 caching, - Qui ck Reference I ndex experiment with Web Services stage, 89–90, 96, 127–133

change List of Fi guresissues, 132–133 costs, 96 defined, 89 existing systems data exchange, 130 external service use, 127–128 internal service development, 128–129 message router development, 130–132 result of, 89–90 staffing, 132 See also Web Services; Web Services adoption eXtensible Access Control Markup Language (XACML), 32, 224 eXtensible Business Reporting Language (XBRL), 214 eXtensible Data Format (XDF), 217 eXtensible Markup Language. SeeXML eXtensible Name Address Language (xNAL), 214 eXtensible rights Markup Language (XrML), 33, 192, 224 eXtensible Stylesheet Language. SeeXSL external services, 21–22 blurring of, 88, 91 CRM, 11–12 SOAP with, 129 using, 127–128 in Web sites, 63

extract, transform, and load (ETL) defined, 50, 224 software, 52 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds. Table of Contents

Back Cov er

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

F

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic failover and t he software engineer ing wor lds. defined, 142, 224 options, 142 Table of Contents Back Cov er Com m ents types of, 142

Ta ble o f Con t en t s

faultSer tolerance, Web vices and9–10 Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For Financial ewor d Information eXchange (FIX), 214 I ntr oductionproduct Markup Language (FpML), 214 Financial Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

firewalls - A Business Tr ip in the Not- Too- Distant Futur e middle-tier, 180–183 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p XML, 183 Chapt er 1 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

fixed record formats, 26–30 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptcopied er 4 wrong data with, 32 Techniques ChaptEDI, er 5 67- Growing I mpact of Web Serv ices exchanges, Ser57 vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chaptmessage er 6 - brittleness, 31, 57 Ar chitect ur es Chaptrecord er 7 structure - St ar ti ngchanging, t o Adopt a28 Ser vi ce- Or iented Ar chitectur e Pa r t I I - Mapositioning na gi ng Chafor, nge 146–147 N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e flexibility,

Chapt er 8

- Change Wil l Happen Flexible Image Transport System Markup Language (FITSML), 213

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

force field analysis, 38–40 for adopting CORBA or DCOM, 45 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices for adopting EDI, 72 Chapt er 11 - Ar chitect ur al Opt ions for adopting EDWs, 51 Chapt er 12 - Mi ddl e- Tier Ar chitectur e for adopting message routers, 56 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e for adopting service-oriented architecture, 117 Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s for adopting standard, enterprisewide software, 42–43 Chaptfor er adopting 14 - Addistandard tional Specification Details data element definitions, 41 Chaptfor er adopting 15 - Qui Web ck Reference Guide Services, 47 I ndexdefined, 38 List of Fi gures driving forces, 38, 39, 45, 51, 70, 99 illustrated, 38 for making system changes, 39 overview, 38–40 restraining forces, 38, 39, 40, 42–43, 45–46, 99 for technical change issues, 99 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

“form follows function,” 76, 77 frameworks, 78 future, vision of, 90–91

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

G

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic gadgets and t he software engineer ing wor lds. defined, 62, 224 using, Table of 62 Contents Back Cov er Com m ents

Positioning TaGlobal ble o f Con t en t s System (GPS), 187 Web Ser vices andresistance Ser vice- Orscenario, iented Ar chit ectur es—The Sav vy Manager 's Guide guerilla tactics 111–112 For ewor defined, d 111

overcoming resistance suggestions, 112 I ntr oduction 111–112 Pa r t resistance I - Se r vi ce-issues, O r ie nt ed Ar chi te ctur e Ov er v i ew resistance; scenarios ChaptSee er 1also - A Business Trresistance ip in the NotToo- Distant Futur e Chapt er 2tactics - I nfor at ion Technology Used in Thi s Tri p guerilla (2)mresistance scenario, 113–114 Chaptdefined, er 3 - 113 Ser vice- Or iented Ar chi tectur es and Web Serv ices overcoming For resistance ces Affecti ng suggestions, the Adoption114 of Web Ser v ices and Other I ntegr ation Chapt er 4 resistanceTechniques issues, 113–114 ChaptSee er 5also - Growing I mpact of Web scenarios Serv ices resistance; resistance Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

H

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Health Level 7 (HL7) Healthcare XML Format, 215 and t he software engineer ing wor lds.

high-level abstraction, 78 Table of Contents

hotels, 15

Back Cov er

Com m ents

Ta ble o f Con t en t s

HTML, 209

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

HTTP connections, 88 I ntr oduction defined, 225 Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew SOAP use of, 205 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e Web Services use, 47 For ewor d

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Human XML (HR-XML), 215 es and Web Serv ices Chapt er 3Resources - Ser viceOr iented Ar chi tectur For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

I

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic inertia, 104, 132–133, 150 and t he software engineer ing wor lds.

in-memory caching, 170–171 Table of Contents Com m ents highest availability,Back 172 Cov er Ta bleillustrated, o f Con t en170 ts options, Web Ser vices 171 and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide Seed also caches; caching For ewor instant messages, 14 I ntr oduction Pa r t I - Se r viMarkup ce- O r ie nt ed Ar chi te(IML), ctur e Ov er v i ew Instrument Language 215–216

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

integration - I nfor m at ion Technology Used in Thi s Tri p application analysis, 52–57 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices data warehousing analysis, 50–52 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation 43–49 Chaptmiddleware, er 4 Techniques opportunity, 88 Chapt er 5 - Growing I mpact of Web Serv ices technique analysis, 40 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapttechniques, er 6 putting together, 57–60 Chapt er 2

Ar chitect ur es

Interactive 214 Chapt er 7 -Financial St ar ti ng Exchange t o Adopt a (IFX), Ser vi ceOr iented Ar chitectur e Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e interconnections

Chaptfor er internal 8 - Change Wil l 53 Happen systems, Chaptwith er 9message - Tips for router, Managing 54 Change I ssues dur ing Developm ent Pa r t I I I - CrDefinition e a ti ng S er v i ce - O r ie (IDL), nt ed Ar207, chi te227 ctu r es Interface Language

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

internal connections analogous architecture for, 78 Chapt er 12 - Mi ddl e- Tier Ar chitectur e improving, 63–64 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e resilience improvement of, 63 Chapt er 11 - Ar chitect ur al Opt ions

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

internal experts, 104, 121, 145, 149

Chapt er 14 - Addi tional Specification Details

internal service-oriented architecture establishment stage Chapt er 15 - Qui ck Reference Guide I ndexarchitectures, 150–154

change List of Fi guresissues, 152–154

costs, 97 defined, 90 design considerations, 150–151 staffing, 151 stages 1 through 3 before, 150 See also Web Services adoption

internal service-oriented architecture expansion stage architectures, 154 change issues, 154 costs, 97 defined, 90 staffing, 154 See also Web Services adoption internal services, 21–22 blurring of, 88, 91 connection protocols, 88 developing, 128–129 internal systems, 52–54 InterNational Committee for Information Technology Standards (INCITS), 193 standards, 204 Internet resources, access to, 169 Web Services comparison, 89

Internet Engineering Task Force (IETF), 193 standards, 202 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Internet Inter-ORB Protocol (IIOP), 208, 225 by Douglas K. Barr y

ISBN:1558609067

intersystem dependencies removal stage, 90,?2003 97 (245 pages) Mor gan Kaufm ann Publ ishers architectures,Prov 146–150 ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e change issues, 149–150of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic advantage costs, 97 and t he software engineer ing wor lds. defined, 90 Table of Contents Back 147–149 Cov er Com m ents design considerations, Ta blepositioning o f Con t en tfor s flexibility, 146–147 staffing, 149 Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide Seed also Web Services adoption For ewor I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

J

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Java and t he software engineer ing wor lds. API for XML Parsing (JAXP), 225 application servers,Back 225Cov er Table of Contents Com m ents TaJava ble oCommunity f Con t en t s Process (JCP), 193

203–204 Web standards, Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide Message Service (JMS), 208 For ewor d joboduction threat, 104, 152 I ntr Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

L

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

LegalXML, 216 advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

listening, 106–107 Table of Contents

Back Cov er

load leveling, 140, 225

Com m ents

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

M

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Managing Transitions, 102 and t he software engineer ing wor lds.

mapping, 172 Table of Contents Back issues Cov er for,Com cache synchronization 174m ents 172, Ta bledefined, o f Con t en t s 226 SOAP, 192 Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For master ewor ddatabases, 162–163 adding agents to, 165 I ntr oduction 162 Pa r t benefits, I - Se r vi ceO r ie nt ed Ar chi te ctur e Ov er v i ew Chaptcreating, er 1 - 133–135 A Business Tr ip in the Not- Too- Distant Futur e Chaptcreation er 2 - illustration, I nfor m at ion134 Technology Used in Thi s Tri p creation tips, 133–134 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices distributed, software 163 ForBI ces Affecti ngto,the Adoption of Web Ser v ices and Other I ntegr ation Chapthighly er 4 available, 144, 145 Techniques 139 I mpact of Web Serv ices Chaptportals er 5 and, - Growing updates, routing, 135–137 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 See also Ar databases chitect ur es Chapt er 7files, - St ar ti 135 ng t o Adopt a Ser vi ce- Or iented Ar chitectur e master 133, Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

MathML, 216

Chapt er 8

- Change Wil l Happen mergers acquisitions, 42–43 Chapt er 9 and - Tips for Managing Change I ssues dur ing Developm ent

CORBA/DCOM and, 46 driving force, 43, 48 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices restraining force, 42–43 Chapt er 11 - Ar chitect ur al Opt ions Web Services, 48 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

message Chapt er 13 routers - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

quality and, Pa r t data I V - Com pe ndi um56 of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s 54 Chaptdata er 14transformation, - Addi tional Specification Details

defined, 54, 226 developing, 130–132 I ndex EDWs and, 55 List of Fi gures with existing middleware solutions, 57 failover options, 142 force field analysis for adopting, 56 highly available, 140, 144, 145 interconnections with, 54 not highly available, 140 options, 138–140 replication options, 143 transformations in, 55 with Web Services, 58 with Web Services, CORBA, and DCOM, 58 Chapt er 15 - Qui ck Reference Guide

Message Service Specification (MSS), 226 Message-Oriented Middleware (MOM), 44 messages defining with XML, 24 fixed record, 31 high-speed, 151, 152 high-volume, 151, 152 operations, 207 portal, 185 receiving multiple times, 150–151 tagged, 26 Web Services, 25, 186 Meta-Object Facility (MOF), 226

methodologies, 78 second set of eyes, 122–123 using, 122 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y

ISBN:1558609067

middle tier Mor gan Kaufm ann Publ ishers ?2003 (245 pages) caching in, 169–174 both 178–180 pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e consolidated Prov dataides in, 175, advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic defined, 167 and t he software engineer ing wor lds. illustrated, 168 Table persistent of Contents cache in, Back 175,Cov 179 er Com m ents 167–183 Tamiddle-tier ble o f Con architecture, t en t s Web basics, Ser vices167–169 and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

defined, 167–169 For ewor d firewalls, 180–183 I ntr oduction

169O r ie nt ed Ar chi te ctur e Ov er v i ew Pa r t options, I - Se r vi ceChapt middle-tier er 1 -databases, A Business177–180 Tr ip in the Not- Too- Distant Futur e

data, 181 Chaptfor er consolidated 2 - I nfor m at ion Technology Used in Thi s Tri p 178, 180Ar chi tectur es and Web Serv ices Chaptdata er 3 model, - Ser177, vice- Or iented selection For issues, 180 ng the Adoption of Web Ser v ices and Other I ntegr ation ces Affecti temporaryTechniques nature of, 180 178 I mpact of Web Serv ices Chaptupdate er 5 -time, Growing Chapt er 4

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise middle-tier Chapt er 6 -firewalls Ar chitect ur es

adding, 182

Chaptoptions, er 7 - 180–183 St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e Pa r t XML, I I - Ma183 na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

middle-tier persistence, 175–180 - Tips for Managing Change I ssues dur ing Developm ent examples, 180 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es illustrated, 176 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices reasons for consideration, 175 Chapt er 9

Chapt er 11 - Ar chitect ur al Opt ions

Middleware3, 43

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

middleware Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e 43–49 Pa r t architecture, I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s ChaptCORBA, er 14 - 45–46 Addi tional Specification Details ChaptDCOM, er 15 - 45–46 Qui ck Reference Guide I ndexdefined, 226

examples, 44 integration, 43–49 MOM, 44 ORB, 44 RPC, 44 TP monitors, 44 See also Web Services

List of Fi gures

Model Driven Architecture (MDA), 226–227 Mortgage Industry Standards Maintenance Organization (MISMO), 217

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

N

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

.NET, 227

News Industry Text Format (NITF), 217 Table of Contents

Back Cov er

Com m ents

not invented here resistance, 105, 153, 154 Ta ble o f Con t en t s

notification operation, 207

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

O

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Object Management Group (OMG) and t he software engineer ing wor lds. defined, 194 standards, 196 Table of Contents Back Cov er Com m ents

Request TaObject ble o f Con t en t sBroker (ORB), 44, 45, 227 Web Ser vices and Ser 207 vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide one-way operation, For ewor d online calendar services, 12–14 I ntr oduction changing, 13 Pa r t competing, I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew 13

Chaptdata er 1 interchange - A Business Tr ip in the Not-14 Too- Distant Futur e standardization, Chaptrule er 2setup, - I nfor m at ion Technology Used in Thi s Tri p 13–14 Chaptsoftware er 3 - agents Ser vice-and, Or iented Ar chi tectur es and Web Serv ices 12–13 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation online Chapt er repositories 4 Techniques

with BI package, 11 - Growing I mpact of Web Serv ices customer contacts in, 9–11 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise 9–10 Chaptfault er 6 tolerant, Ar chitect ur es Web Services and, 11 Chapt er 5

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

OpenMath, Pa r t I I - Ma na216–217 gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Chapt er 8 - Alliance Change Wil l Happen OpenTravel (OTA), 218 Chapt er 9 - access, Tips for 151, Managing operational 153 Change I ssues dur ing Developm ent Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

organization, this book, 2

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Organization for Standardization Chapt er 11 - Ar chitect ur al Opt ions (ISO), 191 Chapt er 12 - Mi e- Tier Ar chitectur eof Structured Information Standards (OASIS), 32, 68, 192, 196 Organization forddlthe Advancement Chaptstandards, er 13 - Rev isi ting the Business 197, 199–200, 203 Tr ip in the Not- Too- Distant Futur e Pa r t defined, I V - Com194 pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

192 Chaptspecification er 14 - Addiadoption, tional Specification Details 194 Chaptstandards, er 15 - Qui ck Reference Guide I ndex overcoming resistance, 105–108 List of Fi gures communication in, 107

complication scenario, 110–111 elephant in the room scenario, 115 guerilla tactics scenario, 112 guerilla tactics (2) scenario, 114 listening in, 106–107 people involvement in, 107 people selection in, 105–106 resistance in the open and, 107–108 second set of eyes in, 106 See also resistance

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

P

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Partner Interfaceadvantage Processes (PIPs), 227–228 and t he software engineer ing wor lds.

people Table of Contents Back Cov er Com m ents involving, 107 106 Ta blepairing, o f Con ttogether, en t s selecting, 105–106 Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide Seed also resistance For ewor persistence, I ntr oduction middle-tier, 175–180 Pa r t I - Se r vi ce- O r ie43, nt ed85 Ar chi te ctur e Ov er v i ew plug-compatibility,

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

portals, 62 - I nfor m at ion Technology Used in Thi s Tri p expansion, 62 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices master databases and, 139 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptmedical, er 4 - Web Services in, 64 Techniques messages, 185 Chapt er 5 - Growing I mpact of Web Serv ices Web Services in, 129 Chapt er 2

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 are - special resistance, 105, 154 problems Ar chitect ur es Chapt er 7scope, - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e project 122 Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

protected caching, 175, 177

Chapt er 8

- Change Wil l Happen

Publishing -Requirements for Industry Standard Markup (PRISM), 217 Tips for Managing Change I ssues dur ing Developm ent

Chapt er 9

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

R

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Real Estate Transaction Markup Language (RETML), 217 and t he software engineer ing wor lds.

real-time replication, 143 Table of Contents

Back Cov er

Com m ents

REgular LAnguage description for XML (RELAX), 210 Ta ble o f Con t en t s

RELAX NG, 210

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Remote Procedure Calls (RPCs), 44

For ewor d

replication, I ntr oduction 140 Pa r t cache, I - Se r vi170 ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

228 Tr ip in the Not- Too- Distant Futur e Chaptdefined, er 1 - 140, A Business Chaptevent-based, er 2 - I nfor143 m at ion Technology Used in Thi s Tri p

Chaptoptions, er 3 - 143 Ser vice- Or iented Ar chi tectur es and Web Serv ices

real-time, 143

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptstore er 4 and - forward, 143 Techniques

143 I mpact of Web Serv ices Chapttime-based, er 5 - Growing

types of, 143 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise -

Chapt er 6

Ar chitect es repositories.See onlineurrepositories

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

request/response operation, 207

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

resistance, Chapt er 8 - 100–102 Change Wil l Happen

as common human response, 100 - Tips for Managing Change I ssues dur ing Developm ent communication and, 107 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es confusion, 103 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices constant questioning, 103 Chapt er 11 - Ar chitect ur al Opt ions forms of, 102–105 Chapt er 12 - Mi ddl e- Tier Ar chitectur e inertia, 104 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e job threat, 104 Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s lack of training/understanding, 103 Chaptlistening er 14 - and, Addi tional Specification Details 106–107 Chaptlookout er 15 -for, Qui101 ck Reference Guide I ndexin neutral zone, 102 List of Fi gures not invented here, 105 in the open, 107–108 our problems are special, 105 people involvement and, 107 people selection and, 105–106 power of internal “expert,” 104 recognizing, 102 silence, 103 talking about, 107–108 See also change; overcoming resistance Chapt er 9

resistance issues complication scenario, 109–110 elephant in the room scenario, 115 guerilla tactics, 111–112 guerilla tactics (2), 113–114 resistance scenarios, 108–115 complication, 108–111 elephant in the room, 114–115 guerilla tactics, 111–112 guerilla tactics (2), 113–114 Resource Description Framework (RDF), 228 restraining forces, 38, 39, 40–41 for change issues, 101 for CORBA adoption, 45, 46 cost-related, 40–41

for DCOM adoption, 45, 46 for EDI adoption, 72 W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e for EDW adoption, 51 ISBN:1558609067 by Douglas K. Barr y long-term, 42–43 Mor gan Kaufm ann Publ ishers ?2003 (245 pages) mergers and acquisitions, 42–43 for message router adoption, 56 Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic for service-oriented architecture adoption, 117and t he software engineer ing wor lds. for technical change issues, Table of Contents Back Cov er99 Com m ents for Web Services adoption, 47 Ta bleSee o f Con t s field analysis alsot en force Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Return on Investment (ROI), 97

For ewor d

RosettaNet, I ntr oduction 194, 208

194O r ie nt ed Ar chi te ctur e Ov er v i ew Pa r t defined, I - Se r vi ce-

Framework (RNIF), 228Distant Futur e ChaptImplementation er 1 - A Business Tr ip in the Not- Toostandards, 198, 201–202 - I nfor m at ion Technology Used in Thi s Tri p

Chapt er 2 Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

S

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Schematron, 210advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Schools Interoperability Framework (SIF), 214 Table of Contents

Back Cov er

Com m ents

second set of eyes Ta bleino fchange Con t enmanagement, ts 122–123 Web in Ser vices and Ser vice- Or iented overcoming resistance, 106Ar chit ectur es—The Sav vy Manager 's Guide For ewor d Assertion Markup Language (SAML), 33, 228 Security I ntr oduction

service consumers, 34

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

service 34 Tr ip in the Not- Too- Distant Futur e Chapt er 1producers, - A Business Chapt er 2 Provisioning - I nfor m at Markup ion Technology Used(SPML), in Thi s Tri Service Language 33,p 228 Chapt er 3 - Ser viceOr iented adoption Ar chi tectur es and Web Serv ices service-oriented architecture For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptchange er 4 -issues related to, 101 Techniques

consolidated analysis for, 115–118 - Growing I mpact of Web Serv ices costs related to, 96–98 Ser vice- Orfor, iented force field analysis 117Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 Ar chitect ur es stages, 89–90 Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e technical issues related to, 99 Chapt er 5

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

service-oriented architectures, 17–35 Chapt er 8 - Change Wil l Happen

advantages, 85 - Tips for Managing Change I ssues dur ing Developm ent with architectural frameworks/ methodologies, 78 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es basics, 20 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices business trip example, 5–16 Chapt er 11 - Ar chitect ur al Opt ions as collection of services, 19 Chapt er 12 - Mi ddl e- Tier Ar chitectur e compendium of software technology for, 189–232 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e connections emphasis, 61 Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s creating, 125–188 Chaptdefined, er 14 - 18–19, Addi tional 229Specification Details Chaptenterprise er 15 - Qui ck Reference Guideand, 75–86 architecture beliefs I ndexas evolution in process, 73 List of Fi gures goals, 84–85 internal, establishing, 90, 97 internal, expanding, 90, 97 multiple components of, 59 options, 157–165 organization use of, 21 overview, 3–4 as part of enterprise architecture, 76–78, 85–86 plug-compatibility, 85 service management of, 81 starting to adopt, 87–92 Chapt er 9

services, 19 business trip example, 10 car rental, 15 combining, 5 as commodities, 15 defined, 5, 228 external, 11–12, 21–22 internal, 21–22 online calendar, 12–14 responsible for own state, 147–148 taking advantage of, 92 travel agency, 14–15 shared database architecture, 80 cannot be viewed as separate system, 148

as separate systems, 146 Simple Mail Transfer Protocol (SMTP), 205

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

small and medium-sized business (smbXML), 213 by Douglas K. Barr XML y

ISBN:1558609067

Mor gan SOAP, 22, 34, 128, 129 Kaufm ann Publ ishers ?2003 (245 pages) defined, 24 Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e envelope, 205advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic t he software engineer ing wor lds. with external and service, 129 headers, 183 Table of Contents Back Cov er Com m ents HTTP use, 205 Ta blemapping, o f Con t en ts 192 Web structure, Ser vices and Ser vice-view, Or iented high-level 206Ar chit ectur es—The Sav vy Manager 's Guide For ewor d 24 using, I ntr oduction

software agents. Seeagents

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

solicit response operation, 207 - A Business Tr ip in the Not- Too- Distant Futur e specifications Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p organizations working on, 191–195 Chapt er 3 - Ser viceOr iented Ar chi tectur es and Web Serv ices Web Services, 191, 205–209 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 XML, 191,Techniques 209–212 Chapt er 1

Chapt er 5 - Growing mpact of Web Serv ices specifications matrix, I195–204 Ser vice- Or iented servers, 204 Ar chi tectur es and Beliefs about Enter pr ise Chaptapplication er 6 Ar chitect ur es defined, 195 Chaptmessaging, er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e 202 Pa r t models I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e and meta-models, 196

Chaptobject er 8 programming - Change Wil llanguages, Happen 204 Chaptrepository, er 9 - Tips for Managing Change I ssues dur ing Developm ent 199 Pa r t security I I I - Cr e and a ti ngauthorization, S er v i ce - O r ie nt ed Ar chi te ctu r es 200

Chaptservice, er 10 - 201 Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chaptuser er 11interface, - Ar chitect 197ur al Opt ions

198 Chaptworkflow, er 12 - Mi ddl e- Tier Ar chitectur e ChaptXML, er 13203 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s staffing

Chaptexisting er 14 - systems Addi tional Specification Details adaptation stage, 145 Chaptexperiment er 15 - Quiwith ck Reference Guide stage, 132 Web Services I ndexinternal service-oriented architecture

establishment stage, 151 List of Fi gures internal service-oriented architecture expansion stage, 154 intersystem dependencies removal stage, 149 in overcoming resistance, 105–106 store and forward replication, 143 strategic information requirements, 81–82

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

T

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic tagged messages, 26, 29 and t he software engineer ing wor lds.

teams, small, 123 Table of Contents

Back Cov er

Com m ents

technical change issues Ta blediminishing, o f Con t en t s98–100 Web force Ser vices Ser viceOr iented Ar chit ectur es—The Sav vy Manager 's Guide fieldand analysis, 99 For ewor industry-wide, d 100 See also change issues I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te cturMarkup e Ov er v(TIM), i ew Telecommunications Interchange

218

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

time-based replication, 143

training/understanding, lack of, 121,es132, Chapt er 3 - Ser vice- Or iented Ar 103, chi tectur and 145, Web 149 Serv ices transaction processing (TP) 44 of Web Ser v ices and Other I ntegr ation For ces Affecti ng monitors, the Adoption -

Chapt er 4

Techniques

travel agency service, 14–15

Chapt er 5

- Growing I mpact of Web Serv ices

Tree RegularSer Expressions for XML (TREX), 210 vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise -

Chapt er 6 Chapt er 7

Ar chitect ur es

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

U

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic Unified Resourceadvantage Identifier of (URI), 229 and t he software engineer ing wor lds.

United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), 194–195, 209 Table of Contents

Back Cov er

Com m ents

Universal Business Language (UBL), 83, 212 Ta ble o f Con t en t s

universal data model buying, 120–121 For ewor d defined, 120, 229 I ntr oduction issues, 121

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Universal Description, Discovery, and Integration (UDDI), 23–24, 128 - A Business Tr ip in the Not- Too- Distant Futur e Business Registry, 206 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p defined, 205 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices directory, 34 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation 206–207 Chaptgreen er 4 pages, Techniques registry, 23 Chapt er 5 - Growing I mpact of Web Serv ices white pages, 206 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chaptyellow er 6 pages, 206 Chapt er 1

Ar chitect ur es updates, Chapt er 7 routing, - St ar ti135–137 ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t illustrated, I I - Ma na gi137 ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

137 Wil l Happen Chaptrestricting, er 8 - Change Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

V

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic value-added networks (VANs), 66 and t he software engineer ing wor lds. CORBA/DCOM and, 66–67 costofbarrier, 66 Back Cov er Table Contents Com m ents EDI using, 67

Ta ble o f Con t en t s

Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d I ntr oduction Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Chapt er 1

- A Business Tr ip in the Not- Too- Distant Futur e

Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Chapt er 3

- Ser vice- Or iented Ar chi tectur es and Web Serv ices

Chapt er 4

-

Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Techniques Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

W

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e

by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic W3C, seeWorld Wide Web Consortium and t he software engineer ing wor lds.

Web Distributed Data Exchange (WDDX), 229 Table of Contents

Back Cov er

Com m ents

Web Services Ta bleadapters, o f Con t en t s 147, 219 69, Web basics, Ser vices23 and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor bypassing, d 169 connecting components to, 135 I ntr oduction Pa r t connections, I - Se r vi ce- O r57, ie nt88 ed Ar chi te ctur e Ov er v i ew Chaptfor er data 1 - exchange, A Business130 Tr ip in the Not- Too- Distant Futur e 22 m at ion Technology Used in Thi s Tri p Chaptdefined, er 2 - 5, I nfor ChaptEDI er 3use- of, Ser69–70 vice- Or iented Ar chi tectur es and Web Serv ices EDWs coexisting with,ng 53the Adoption of Web Ser v ices and Other I ntegr ation For ces Affecti Chaptevolutionary er 4 use, 73 Techniques 96, 133–145 Chaptexisting er 5 - systems Growingadoption, I mpact of90, Web Serv ices experimentation, 96, 127–133 Ser vice- 89, Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt er 6 external, access 169 Ar chitectto, ur es and,a 77 Chapt“form er 7 follows - St ar function” ti ng t o Adopt Ser vi ce- Or iented Ar chitectur e 47 Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e Pa r t HTTP I I - Mause, na gi ng 61–73,Wil 88–89 Chaptimpact er 8 of, - Change l Happen Chaptinitial er 9 impact - Tipsof, for62–73 Managing Change I ssues dur ing Developm ent 169 Pa r t internal, I I I - Cr e aaccess ti ng S erto, v i ce - O r ie nt ed Ar chi te ctu r es ChaptInternet er 10 - comparison, Ar chitect ur es89 at Each Stage of Adopti on for Web Ser vices interoperation with CORBA/ DCOM, 49 Chapt er 11 - Ar chitect ur al Opt ions intersystem dependencies removal, 90, 97 Chapt er 12 - Mi ddl e- Tier Ar chitectur e in medical portal, 64 Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e message routers with, 58, 131 Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s messages, 25, 186 Chapt er 14 - Addi tional Specification Details online repositories and, 11 Chapt er 15 - Qui ck Reference Guide PC bus analogy, 34 I ndexin portal with mainframe system, 129 List of Fi gures ROI, 97 service-oriented architectures and, 17–35 simplified notation, 34, 35 XML use, 20, 47 Web Services adoption, 47–48 costs, 98 force field analysis for, 47 forces affecting, 37–60 incremental, 64 stages, 89–90 stages, architectures at, 127–155 Web Services Component Model, 229–230 Web Services Conversation Language (WSCL), 230 Web Services Description Language (WSDL), 22–23, 128, 207–208 default transmission, 34 defined, 207 fragment, 25 operation types, 207 parts, 207, 208 service description using, 22 service use of, 23 use illustration, 23 using, 22–23 Web Services Endpoint Language (WSEL), 229

Web Services Experience Language (WSXL), 230 Web Services Flow Language (WSFL), 230

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e

Web Services forbyInteractive (WSIA), 230 Douglas K.Applications Barr y

ISBN:1558609067

gan Kaufm ann (WSRP), Publ ishers231 ?2003 (245 pages) Web Services forMor Remote Portals Prov ides both 205–209 pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e Web Services specifications, advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic BEEP, 205 and t he software engineer ing wor lds. defined, 191 ebXML Registry, 208–209 Table of Contents Back Cov er Com m ents SOAP, 205 Ta ble o f Con t en t s UDDI, 205–207 Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide WSDL, 207–208 For ewor d See also specifications; specifications matrix I ntr oduction

Web Services User Interface (WSUI), 231

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

Webersites Chapt 1 - A Business Tr ip in the Not- Too- Distant Futur e 62 Chaptconnections, er 2 - I nforimproving, m at ion Technology Used in Thi s Tri p Services in, Ar 63chi tectur es and Web Serv ices Chaptexternal er 3 - Web Ser viceOr iented For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation WebSphere Chapt er 4 - MQ, 208 Techniques

World Wide Web Consortium (W3C), 32, 195 - Growing I mpact of Web Serv ices standards, 198, 201–203

Chapt er 5

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

Index X XLANG, 231

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e by Douglas K. Barr y Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

ISBN:1558609067

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

XML, 57, 128, 129 Table of Contents Back Cov er Com m ents ACORD, 215 content, 172, 173 Ta bleas o f cache Con t en ts with CORBA or DCOM, 46 Ar chit ectur es—The Sav vy Manager 's Guide Web Ser vices and Ser vice- Or iented definition expression in, 207 For ewor d documents, 209, 211 I ntr oduction downside, 30 Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew EDI use of, 68, 69 Chapt er 1 - A Business Tr ip in the Not- Too- Distant Futur e electronic business (ebXML), 24, 192–193, 208–209 Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p firewalls, 183 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices Human Resources (HR-XML), 215 For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chaptmessage er 4 - definition with, 24 Techniques namespaces, 211 Chapt er 5 - Growing I mpact of Web Serv ices options, 30–32 Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise ChaptREgular er 6 - LAnguage description for (RELAX), 210 Ar chitect ur es small and medium-sized business (smbXML), 213 Chapt er 7 - St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e standards, 12, 16 Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e syntax, 33 Chapt er 8 - Change Wil l Happen tagged message formats, 22, 26–30 Chapt er 9 - Tips for Managing Change I ssues dur ing Developm ent tagged record structure, 57, 209 Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es tradeoffs, 30 Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Tree Regular Expressions for (TREX), 210 ChaptWeb er 11Services - Ar chitect al 20 Opt ions useurof, ChaptWeb er 12Services - Mi ddl eTier Ar without, chitectur 30–32 e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

XML Common Biometric Format (XCBF), 33

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

XMLerEncryption, 33, 231 Chapt 14 - Addi tional Specification Details Chapt XMLerKey 15 Management - Qui ck Reference Specification Guide (XKMS), 33, 231 I ndex XML Path Language (XPath), 211 List of Fi gures

XML Pointer Language (XPointer), 211 XML Protocol (XMLP), 232 XML Schemas, 210 XML Signature, 33, 212, 232 XML specifications, 209–212 defined, 191 RELAX, 210 RELAX NG, 210 Schematron, 210 TREX, 210 XLink, 211 XML namespaces, 211 XML Schema, 210 XML Signature, 212 XPath, 211 XPointer, 211 XQuery, 212 XSL, 210–211 XSL-FO, 211 XSLT, 212 See also specifications; specifications matrix XML vocabularies, 207, 212–218 accounting, 213 astronomy, 213

chemistry, 213 construction, 214 W eb Services customer information, 214 an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e ISBN:1558609067 by Douglas K. Barr y defined, 191 Mor gan Kaufm ann Publ ishers ?2003 (245 pages) education, 214 finance, 214 Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic government, advantage 215 and t he software engineer ing wor lds. healthcare, 215 human resources, Back 215 Cov er Table of Contents Com m ents instruments, 215–216 Ta bleinsurance, o f Con t en215 ts Web legal, Ser vices 216and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide For ewor d 216–217 math, I ntr oduction news, 217 Pa r t physics, I - Se r vi ceO r ie nt ed Ar chi te ctur e Ov er v i ew 217 Chaptreal er 1estate, - A Business Tr ip in the Not- Too- Distant Futur e 217 Chapttelecommunications, er 2 - I nfor m at ion 218 Technology Used in Thi s Tri p travel, 218 Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices UniversalFor Business Language (UBL), 212, 213 ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation Chapt er 4 XML/EDI,Techniques 214 Chapt er 5 212 - Growing I mpact of Web Serv ices XQuery, Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Chapt 6 XSL,er210–222 Ar chitect ur es Chaptdefined, er 7 - 210 St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Objects (XSLFO), Pa r t Formatting I I - Ma na gi ng Cha nge N ee de d 211 for a Ser v i ce - Or ie nte d Ar chit e ct ur e parts, 210–211 - Change Wil l Happen Transformations (XSLT), 210–211, 212

Chapt er 8 Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices Chapt er 11 - Ar chitect ur al Opt ions Chapt er 12 - Mi ddl e- Tier Ar chitectur e Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex List of Fi gures

W eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e List of Figures by Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Chapter 2: Prov Information Technology inadvThis ides both pr actical leader ship and arUsed chitectur al ice on Trip how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software ing wor Figure 2.1: Services and dataengineer interchange forlds. C. R.'s business trip. Table of Contents

Back Cov er

Com m ents

Chapter 3: Service-Oriented Architectures and Web Services Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Figure 3.1: Audio-visual components.

For ewor d

I ntr oduction Figure 3.2: Service-oriented architecture basics. Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

ChaptFigure er 1 -3.3: A Business Tr ip in basics. the Not- Too- Distant Futur e Web Services Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

Figure 3.4: Web Services messages. Chapt er 3 - Ser vice- Or iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation ChaptFigure er 4 -3.5: Tagged messages. Techniques ChaptFigure er 5 -3.6: Growing I mpact Web Serv ices Adding a newofelement. Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise

Chapt er 6

-

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapt er 8

- Change Wil l Happen

Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Ar chitect ur esof the resilience provided by tagged messages. Figure 3.7: Example

3.8: Record content without length oferecord. Pa r t I Figure I - Ma na gi ng Cha nge N ee de changes d for a Ser v i ce - Orchanging ie nte d Ar chit e ct ur Figure 3.9: Example of the brittleness of fixed record messages.

Pa r t I Figure I I - Cr e3.10: a ti ng How S er v ithe ce - wrong O r ie nt ed Ar chi ctucopied r es data cantebe

using fixed records.

Chapt er 10 - Ar chitect ur es at Each Stage of Adopti on for Web Ser vices

Simplified Web ChaptFigure er 11 -3.11: Ar chitect ur al Opt ionsServices notation. Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapter 4: Forces Affecting the Adoption of Web Services and Other Integration Techniques

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

Chapt er 14 - Addi tional Specification Details Chapt er 15 - Qui ck Reference Guide I ndex

Figure 4.1: Force field analysis.

List ofFigure Fi gures 4.2: Force field analysis for making a system change.

Figure 4.3: Force field analysis for adopting standard data element definitions. Figure 4.4: Force field analysis for adopting standard, enterprise-wide software. Figure 4.5: Basic middleware architecture. Figure 4.6: Force field analysis for adopting CORBA or DCOM. Figure 4.7: Force field analysis for adopting Web Services. Figure 4.8: Web Services interoperating with CORBA and DCOM. Figure 4.9: Force field analysis for adopting an enterprise data warehouse. Figure 4.10: Enterprise data warehouse co-existing with Web Services, CORBA, and DCOM. Figure 4.11: Some possible interconnections for internal systems. Figure 4.12: Interconnections when using a message router. Figure 4.13: Transformations in a message router. Figure 4.14: Force field analysis for adopting a message router. Figure 4.15: A message router using Web Services. Figure 4.16: Message router used with Web Services, CORBA, and DCOM.

Figure 4.17: Multiple components of s service-oriented architecture eb Services an d Ser vice- O rien t ed Archit ect u re: T h e Sa vvy Man ag er 's Gu id e Chapter 5: W Growing Impact of Web Services by Douglas K. Barr y

ISBN:1558609067

Mor gan Kaufm ann Publ ishers ?2003 (245 pages)

Figure 5.1: Using external Web Services in a Website.

Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic

Figure 5.2: Using Web Services in medical portal. and t he software engineer ing wor lds. Figure 5.3: Initial form EDI transmission. Table of Contents Back of Cov er data Com m ents

Ta ble Figure o f Con t5.4: en t sEDI using Value-Added Networks (VANs). Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Figure 5.5: EDI initial use of CORBA or DCOM. For ewor d I ntr oduction

Figure 5.6: EDI use of XML with CORBA or DCOM.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

ChaptFigure er 1 -5.7: A Business in the Not- Too- Distant Futur e EDI useTrofipWeb Services. Chapt er 2

- I nfor m at ion Technology Used in Thi s Tri p

ChaptFigure er 3 -5.8: SerEDI vice-in Ortransition. iented Ar chi tectur es and Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation ChaptFigure er 4 -5.9: Force field analysis for adopting Electronic Data Interchange(EDI). Techniques Chapt er 5

- Growing I mpact of Web Serv ices

Chapt er 7

- St ar ti ng t o Adopt a Ser vi ce- Or iented Ar chitectur e

Chapter Ser 6:viceService-Oriented Architectures Beliefs about Enterprise Or iented Ar chi tectur es and Beliefs about Enter prand ise Chapt er 6 Ar chitect ur es Architectures Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Figure 6.1: Audio-visual components with a personal computer.

Chapt er 8

- Change Wil l Happen

ChaptFigure er 9 -6.2: TipsShared for Managing Change I ssues dur ing Developm ent database architecture. Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

Each ur service manages data in aWeb service-oriented architecture. ChaptFigure er 10 -6.3: Ar chitect es at Each Stage its of own Adopti on for Ser vices Chapt er 11 - Ar chitect ur al Opt ions

Chapter 8: Change Will Happen

Chapt er 12 - Mi ddl e- Tier Ar chitectur e

Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e Pa r t I Figure V - Com8.1: pe ndi um of Softw a r erelated Te chnolog y for S erWeb v i ce - Services Or i e nte d Ar chit ur e s Costs over time to adopting and a ect service-oriented

architecture.

Chapt er 14 - Addi tional Specification Details

field analysis ChaptFigure er 15 -8.2: QuiForce ck Reference Guide of technical issues related to adopting a service-oriented architecture. I ndex

Figure 8.3: Force field analysis of change issues related to adopting a service-oriented architecture.

List of Fi gures

Figure 8.4: Change issues and responses worksheet. Figure 8.5: Force field analysis of adopting a service-oriented architecture.

Chapter 10: Architectures at Each Stage of Adoption for Web Services Figure 10.1: Using an external service. Figure 10.2: Using Web Services in a portal with a mainframe system. Figure 10.3: Using Web Services to exchange data between internal systems. Figure 10.4: Using a simple message router with Web Services. Figure 10.5: Creating a customer master database. Figure 10.6: Connect components to Web Services. Figure 10.7: Routing master database updates. Figure 10.8: Using a portal and master database. Figure 10.9: Message router options. Figure 10.10: Database options. Figure 10.11: Types of failover for both highly available message routers and databases.

Figure 10.12: Types of database replication for both message routers that store messages and databases. WAdding eb Services an d Ser vicerien t ed Archit ect u re: e Sa vvy router. Man ag er 's Gu id e Figure 10.13: high-availability for O the customer master andT hmessage ISBN:1558609067

by Douglas K. Barr y

Figure 10.14: Shared database architecture that be viewed as separate systems. Mor gan Kaufm ann Publ ishers ?2003 (245can pages) Prov ides both pr actical leader ship and ar chitectur al adv ice on how t o pr epar e an or ganization to t ak e Figure 10.15: Shared database architecture that cannot be viewed as separate systems.

advantage of Web ser vices and ser vice- or iented ar chitectur es, bri dging t he gap bet ween the data- centr ic and t he software engineer ing wor lds.

Figure 10.16: Keeping high-volume, high-speed messages within a service. Table of Contents

Back Cov er

Com m ents

Figure 10.17: Conflict between ad hoc Internet/Intranet processing and internal processing.

Ta ble o f Con t en t s Web Ser vices and Ser vice- Or iented Ar chit ectur es—The Sav vy Manager 's Guide

Chapter 11: Architectural Options

For ewor d

I ntr oduction

Figure 11.1: A response to a request for all customer data comes from one highly available source.

Pa r t I - Se r vi ce- O r ie nt ed Ar chi te ctur e Ov er v i ew

ChaptFigure er 1 -11.2: A Business Tr ip intothe Not- Too-for Distant Futur e data must come from multiple sources. A response a request all customer Chapt er 2 - I nfor m at ion Technology Used in Thi s Tri p

Adding high-availability to and a distributed-process-architecture. ChaptFigure er 3 -11.3: Ser viceOr iented Ar chi tectur es Web Serv ices For ces Affecti ng the Adoption of Web Ser v ices and Other I ntegr ation ChaptFigure er 4 -11.4: Adding business intelligence software to distributed master databases. Techniques Chapt er 5

Growing I mpact of Web Serv ices Figure -11.5: Adding agents to a master database and internal systems.

Chapt er 6

-

Ser vice- Or iented Ar chi tectur es and Beliefs about Enter pr ise Ar chitect ur es

Chapter- St12: Middle-Tier Architecture ar ti ng t o Adopt a Ser vi ceOr iented Ar chitectur e

Chapt er 7

Pa r t I I - Ma na gi ng Cha nge N ee de d for a Ser v i ce - Or ie nte d Ar chit e ct ur e

Middle-tier architecture. ChaptFigure er 8 -12.1: Change Wil l Happen Chapt er 9

- Tips for Managing Change I ssues dur ing Developm ent

Figure 12.2: Middle-tier in-memory data caching.

Pa r t I I I - Cr e a ti ng S er v i ce - O r ie nt ed Ar chi te ctu r es

ChaptFigure er 10 -12.3: Ar chitect ur es at caching. Each Stage of Adopti on for Web Ser vices In-memory Chapt er 11 - Ar chitect ur al Opt ions

caching in ane application server. ChaptFigure er 12 -12.4: Mi ddlData e- Tier Ar chitectur Chapt er 13 - Rev isi ting the Business Tr ip in the Not- Too- Distant Futur e

Figure 12.5: Cache synchronization issues for mapping.

Pa r t I V - Com pe ndi um of Softw a r e Te chnolog y for S er v i ce - Or i e nte d Ar chit ect ur e s

ChaptFigure er 14 -12.6: Addi Middle-tier tional Specification Details persistence. Chapt er 15 - Qui ck Reference Guide I ndex Figure 12.7: Using a persistent cache in the middle tier. List of Fi gures

Figure 12.8: Using the middle-tier database for consolidated data. Figure 12.9: Adding firewalls to a middle-tier-architecture.

Chapter 13: Revisiting the Business Trip in the Not-Too-Distant Future Figure 13.1: Detail for services and data interchange for C. R.’s business trip.

Chapter 14: Additional Specification Details Figure 14.1: High-level view of the SOAP structure. Figure 14.2: Parts of WSDL.