Anonymous
Posted March 15, 2008
This book is valuable resource for understanding and realizing the benefits of SOA and provides pragmatic recomendations for building and integrating XML and Web services effectively.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.Anonymous
Posted May 7, 2005
It's interesting how this book simplifies the complex topics and issues surrounding the incorporation of XML data and Web Service Endpoints into the common enterprise. It breaks down the topics into different levels of integration so you can find advice for approaching a task not based on what it is you're integrating but based on the scope of your integration. Of most value to us were the unique tips and recommendations that I have not yet seen anywhere else. I think this type of information is not yours tandard textbook-level how to content. It is knowledge passed along from experience.
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.Anonymous
Posted May 12, 2004
There has been a tremendous buildout in Web Services standards over the last two years. Its description forms the bulk of this book. The book factors neatly into two parts, which are interspersed as different chapters. One part is the above. The other deals with XML. Consider the XML part first, because that is simpler, and Web Services build upon it. Even if you have no intention of using Web Services, this book has excellent advice on XML development. It assumes that you know about the syntax and parsing. So it doesn't waste any time going over that. Rather, it focuses on suggesting how to best implement/deploy it. Chapter 5 includes a nice analysis of the limitations of XML Schema and DTDs. Plus, there is something which lower level XML books often don't discuss. In those, XML examples are given using lengthy labels in tags, that have human-readable utility. Which is a strength of XML. But this comes at a cost of greater storage and processing time and bandwidth (when you transmit the XML). Given that XML is meant to be processed by software, and that humans should often only view it directly as a manual exception handling process, then having shorter tags might sometimes be acceptable, if you want to improve performance. This is something I've encountered in my own coding, when I write/read 100Mb XML files. The sheer size of these leads me to define tags with labels of just one or two characters. Which does make them harder to manually read. But my reading routines run faster. Erl also suggests that if you have personnel who want to learn XML, books may be far cheaper than training courses offered by third parties. Granted, this is a little self-serving, because he is saying this in his book. But no more so than asking some consulting company if you should hire them to teach XML. Now consider the Web Services part of the book. There has been a veritable laundry list of second generation technologies developed. Like Transaction, Coordination, Security, Policy, BPEL4WS, Attachment and Addressing. Erl tries to pull these together into a coherent usage framework. The book does not go into the details to each technology. That is the purview of other books. Rather, Erl discusses integrating these into your development. Helpfully, he points out that any specific application usually only needs a subset of the above. Which is vital in learning and using them in a modular fashion. Analogous to how in java, you don't have to know all the class libraries that come with the latest java, in order to usefully program. He offers another tip which alone may justify the entire book to you. If you asking a vendor for a full enterprise WS conversion of your legacy applications, she often gives a hub and spoke model. In this, the spokes are modifications of your applications, and the hub is written by the vendor. Typically, this gives a vendor lockin. So beware!
Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
More About This Textbook
Overview
—Tom Glover, Senior Program Manager, Web Services Standards, IBM Software Group, and Chairman of the Web Services Interoperability Organization (WS-I).
—David Keogh, Program Manager, Visual Studio Enterprise Tools, Microsoft.
—Kevin P. Davis, Ph. D., Software Architect.
Service-oriented integration with less cost and less risk
The emergence of key second-generation Web services standards has positioned service-oriented architecture (SOA) as the foremost platform for contemporary business automation solutions. The integration of SOA principles and technology is empowering organizations to build applications with unprecedented levels of flexibility, agility, and sophistication (while also allowing them to leverage existing legacy environments).
This guide will help you dramatically reduce the risk, complexity, and cost of integrating the many new concepts and technologies introduced by the SOA platform. It brings together the first comprehensive collection of field-proven strategies, guidelines, and best practices for making the transition toward the service-oriented enterprise.
Writing for architects, analysts, managers, and developers, Thomas Erl offers expert advice for making strategic decisions about both immediate and long-term integration issues. Erl addresses a broad spectrum of integration challenges, covering technical and design issues, as well as strategic planning.
Service-oriented architecture is no longer an exclusive discipline practiced only by expensive consultants. With this book's help, you can plan, architect, and implement your own service-oriented environments-efficiently and cost-effectively.
About the Web Sites
Erl's Service-Oriented Architecture books are supported by two Web sites. http:// www.soabooks.com provides a variety of content resources and http:// www.soaspecs.com supplies a descriptive portal to referenced specifications.
Product Details
Related Subjects
Meet the Author
Thomas Erl is the world's top-selling SOA author and the Series Editor of the Prentice Hall Service-Oriented Computing Series from Thomas Erl http://www.soabooks.com/
His first two books, Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services and Service-Oriented Architecture: Concepts, Technology, and Design have become international bestsellers and have been formally endorsed by senior members of major software organizations, such as IBM, Sun, and Microsoft. Thomas is also the founder of SOA Systems Inc. http://www.soasystems.com, a company specializing in SOA training and strategic consulting services with a vendor-agnostic focus. Through his work with standards organizations and independent research efforts, Thomas has made significant contributions to the SOA industry, most notably in the areas of service-orientation and SOA methodology. Thomas has had numerous articles and papers published on Web sites and in industry trade magazines, and is a speaker and instructor for private and public events. To learn more, visit http://www.thomaserl.com.
Table of Contents
Preface.
1. Introduction.
Why this guide is important. The XML & Web Services Integration Framework (XWIF). How this guide is organized. www.serviceoriented.ws. Contact the author.
I. THE TECHNICAL LANDSCAPE.
2. Introduction to XML technologies.
Extensible Markup Language (XML). Document Type Definitions (DTD). XML Schema Definition Language (XSD). Extensible Stylesheet Language Transformations (XSLT). XML Query Language (XQuery). XML Path Language (XPath).
3. Introduction to Web services technologies.
Web services and the service-oriented architecture (SOA). Web Services Description Language (WSDL). Simple Object Access Protocol (SOAP). Universal Description, Discovery, and Integration (UDDI).
4. Introduction to second-generation (WS-*) Web services technologies.
Second-generation Web services and the service-oriented enterprise (SOE). WS-Coordination and WS-Transaction. Business Process Execution Language for Web Services (BPEL4WS). WS-Security and the Web services security specifications. WS-ReliableMessaging. WS-Policy. WS-Attachments.
II. INTEGRATING TECHNOLOGY.
5. Integrating XML into applications.
Strategies for integrating XML data representation. Strategies for integrating XML data validation. Strategies for integrating XML schema administration. Strategies for integrating XML transformation. Strategies for integrating XML data querying.
6. Integrating Web services into applications.
Service models. Modeling service-oriented component classes and Web service interfaces. Strategies for integrating service-oriented encapsulation. Strategies for integrating service assemblies. Strategies for enhancing service functionality. Strategies for integrating SOAP messaging.
7. Integrating XML and databases.
Comparing XML and relational databases. Integration architectures for XML and relational databases. Strategies for integrating XML with relational databases. Techniques for mapping XML to relational data. Database extensions. Native XML databases.
III. INTEGRATING APPLICATIONS.
8. The mechanics of application integration.
Understanding application integration. Integration levels. A guide to middleware. Choosing an integration path.
9. Service-oriented architectures for legacy integration.
Service models for application integration. Fundamental integration components. Web services and one-way integration architectures. Web services and point-to-point architectures. Web services and centralized database architectures. Service-oriented analysis for legacy architectures.
10. Service-oriented architectures for enterprise integration.
Service models for enterprise integration architectures. Fundamental enterprise integration architecture components. Web services and enterprise integration architectures. Hub and spoke. Messaging bus. Enterprise Service Bus (ESB).
11. Service-oriented integration strategies.
Strategies for streamlining integration endpoint interfaces. Strategies for optimizing integration endpoint services. Strategies for integrating legacy architectures. Strategies for enterprise solution integration. Strategies for integrating Web services security.
IV. INTEGRATING THE ENTERPRISE.
12. Thirty best practices for integrating XML.
Best practices for planning XML migration projects. Best practices for knowledge management within XML projects. Best practices for standardizing XML applications. Best practices for designing XML applications.
13. Thirty best practices for integrating Web services.
Best practices for planning service-oriented projects. Best practices for standardizing Web services. Best practices for designing service-oriented environments. Best practices for managing service-oriented development projects. Best practices for implementing Web services.
14. Building the service-oriented enterprise (SOE).
SOA modeling basics. SOE building blocks. SOE migration strategy.
About the Author.
About the Photographs.
Index.
Preface
Preface
My father runs a placer mine, far North in a remote part of the Yukon wilderness. For almost half a century, he's made his living plowing through mountains with his bulldozers, looking for gold. Due to the climate, he gets only a limited amount of time during which he can actually mine. His priority, therefore, is to keep his business fully operational throughout this period. Any disruption results in lost revenue. Despite his best efforts, though, he is constantly faced with obstacles.
He's had to contend with volatile, sometimes even violent environmental conditions. He's had to confront bears that roamed into his camp, looking for food. He's even chased thieves off his land in the middle of the night. Once, the hydraulic pump on his front-end loader collapsed, crushing his hand. Instead of "wasting" two days to get to the nearest hospital, he simply wrapped a diesel soaked rag around his broken fingers and kept on going.
The worst kind of problem he's ever had to face, though, is mechanical failure. If a key piece of equipment breaks, if an engine slows or stops, or if any other part of his infrastructure seizes, his business comes to a (literally) grinding halt. It can take weeks to get new equipment or spare parts — a delay that can be devastating to his bottom line.
When faced with these challenges in the past, he's had only himself to rely on. I asked him once how he deals with these situations. He told me that there are very few problems in life that can't be solved with a blowtorch and a welding rod.
I think about that "life philosophy" sometimes, when staring at thecursor, blinking hypnotically amidst some problem displayed on my computer screen. I've always been involved with new technology. It has the mystery of the unknown and the attraction of potential. It's also put me in more "impossible" situations than I care to remember. Although I have respect for the expertise required to produce product documentation and tutorials, I generally classify this information as "option A." It is surprising how often option A does not work in integrated environments. But, that's what option B is for. Option B is when I roll up my sleeves and light my own blowtorch.
This attitude is important when working on integration projects. Some integration tasks are easy. Making two compatible pieces of software talk to each other can be straightforward, involving a predictable development and deployment effort. Others, though, can be a nightmare. Sometimes two pieces of software aren't just "not compatible," they seem violently opposed to each other's very existence.
The goal of this guide is to help you define your own options for whatever integration challenges you might be facing. I am fortunate to be writing a book about integration strategy at a time when the IT community has at its disposal a platform that fosters integration and interoperability like never before.
I hope that you will find this guide not only useful, but that it will lead you to view XML, Web services, and service-oriented principles as problem-solving tools. So that no matter what obstacles cross your path, you will be able to use your own blowtorch to carve out that perfect solution.
© Copyright Pearson Education. All rights reserved.
Introduction
Preface
My father runs a placer mine, far North in a remote part of the Yukon wilderness. Foralmost half a century, he's made his living plowing through mountains with his bulldozers,looking for gold. Due to the climate, he gets only a limited amount of time duringwhich he can actually mine. His priority, therefore, is to keep his business fullyoperational throughout this period. Any disruption results in lost revenue. Despite hisbest efforts, though, he is constantly faced with obstacles.He's had to contend with volatile, sometimes even violent environmental conditions.He's had to confront bears that roamed into his camp, looking for food. He's evenchased thieves off his land in the middle of the night. Once, the hydraulic pump on hisfront-end loader collapsed, crushing his hand. Instead of "wasting" two days to get tothe nearest hospital, he simply wrapped a diesel soaked rag around his broken fingersand kept on going.
The worst kind of problem he's ever had to face, though, is mechanical failure. If a keypiece of equipment breaks, if an engine slows or stops, or if any other part of his infrastructureseizes, his business comes to a (literally) grinding halt. It can take weeks to getnew equipment or spare parts -- a delay that can be devastating to his bottom line.When faced with these challenges in the past, he's had only himself to rely on. I askedhim once how he deals with these situations. He told me that there are very few problemsin life that can't be solved with a blowtorch and a welding rod.
I think about that "life philosophy" sometimes, when staring at the cursor, blinkinghypnotically amidst some problem displayed on my computer screen. I've alwaysbeeninvolved with new technology. It has the mystery of the unknown and the attraction ofpotential. It's also put me in more "impossible" situations than I care to remember.Although I have respect for the expertise required to produce product documentationand tutorials, I generally classify this information as "option A." It is surprising howoften option A does not work in integrated environments. But, that's what option B isfor. Option B is when I roll up my sleeves and light my own blowtorch.
This attitude is important when working on integration projects. Some integrationtasks are easy. Making two compatible pieces of software talk to each other can bestraightforward, involving a predictable development and deployment effort. Others,though, can be a nightmare. Sometimes two pieces of software aren't just "not compatible,"they seem violently opposed to each other's very existence.
The goal of this guide is to help you define your own options for whatever integrationchallenges you might be facing. I am fortunate to be writing a book about integrationstrategy at a time when the IT community has at its disposal a platform that fostersintegration and interoperability like never before.
I hope that you will find this guide not only useful, but that it will lead you to viewXML, Web services, and service-oriented principles as problem-solving tools. So that nomatter what obstacles cross your path, you will be able to use your own blowtorch tocarve out that perfect solution.