Fast SOA: The way to use native XML technology to achieve Service Oriented Architecture governance, scalability, and performance

Be the first to write a review

Overview

FastSOA is a great book with lots of meat on the bones and practical real-world XML and SOA knowledge. Much of what passes for SOA right now is simply block diagrams and vague exhortations to get the architecture right. Frank Cohen gives a practical guide to what software developers, architects, and CIOs have to do to deliver highly scalable, well performing, and easy to maintain services. —Jeff Barr, Amazon.com, Web Services Evangelist

Without the right controls to govern SOA ...

See more details below
Paperback
$48.85
BN.com price
(Save 17%)$58.95 List Price
Other sellers (Paperback)
  • All (7) from $1.99   
  • New (3) from $31.58   
  • Used (4) from $1.99   
Fast SOA: The way to use native XML technology to achieve Service Oriented Architecture governance, scalability, and performance

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$55.95
BN.com price

More About This Book

Overview

FastSOA is a great book with lots of meat on the bones and practical real-world XML and SOA knowledge. Much of what passes for SOA right now is simply block diagrams and vague exhortations to get the architecture right. Frank Cohen gives a practical guide to what software developers, architects, and CIOs have to do to deliver highly scalable, well performing, and easy to maintain services. —Jeff Barr, Amazon.com, Web Services Evangelist

Without the right controls to govern SOA development, the right set of tools to build SOA, and the right support of exciting new protocols and patterns, your SOA efforts can result in software that delivers only 1.5 transactions per second (TPS) on expensive modern servers. This is a disaster enterprises, organizations, or institutions avoid by using Frank Cohen's FastSOA patterns, test methodology, and architecture.

In FastSOA you will learn how to apply native XML technology to SOA for:

• Data mediation using mid-tier data and service caching to handle the explosion of new schemas and new devices in an ever changing environment
• Data aggregation in the SOA middle-tier for off-line browsing, service acceleration through mid-tier caching and transformation, and bandwidth-needs reduction
• Increased service and application scalability and performance
• Successful evaluations of application server, XML parser, relational and native XML database, Enterprise Service Bus, Business Integration server, workflow server, and Web Service tools for performance, scalability, and developer productivity
• Improved service governance through XML persistence in SOA registries and repositories
• Composite data services (CDS) to provide maximum reuse of software components and data, accelerate performance, and reduce development time and maintenance in your SOA

About the author
Frank Cohen is the "go to" guy when enterprises need to build, test, and solve performance and scalability problems in complex interoperating information systems. Frank's articles appear on IBM developerWorks, and he is author of Java Testing and Design: From Unit Tests to Automated Web Tests. He is the principal maintainer of the popular TestMaker open-source test utility and framework, and Director of Solutions Engineering at Raining Data, publisher of the TigerLogic XQuery engine and native XML database.

Read More Show Less

Editorial Reviews

From the Publisher
"Frank Cohen is both a keen observer and a key participant as the software industry struggles to understand what the words 'Enterprise SOA' really mean. FastSOA is an excellent guide to the current technologies (and how to route around their pitfalls and shortcomings)."

—William Grosso, Software Development Forum, Board Member; Author of Java Enterprise Best Practices and Java RMI

"If it is possible for a technical book to present an intimate side to one engineer's experiences getting SOA applications to deliver good performance, then this book is it."

—Ilya Sterin, Software Engineer at Nextrials, Author of XML and Perl

“FastSOA is a great book with lots of meat on the bones and practical real-world XML and SOA knowledge. Much of what passes for SOA right now is simply block diagrams and vague exhortations to get the architecture right. Frank Cohen gives a practical guide to what software developers, architects, and CIOs have to do to deliver highly scalable, well performing, and easy to maintain services.”

—Jeff Barr, Amazon.com, Web Services Evangelist

"Anyone considering an SOA should definitely study Chapter 5. It not only shows how to construct the middle-tier FastSOA, it also backs up the impressive performance-improvement claims with data based on real- world tests."

—Douglas K. Barry, Barry & Associates, Inc., Author of Web Services and Service-Oriented Architectures: The Savvy Manager's Guide

"In FastSOA Frank Cohen puts attention to actual performance and scalability issues caused by the unsuitable tools traditionally used to build SOA. He proposes using the right tools that are specifically designed for XML messaging - a core concept of SOA. FastSOA is an elegant architecture aimed to improve scalability, governance and performance of SOA by using native XML technologies like XQuery instead of objects and other common but unnatural data representations. FastSOA goes beyond architecture by answering common SOA performance issues and proposing tools to test and evaluate SOA system scalability and performance. That is, Frank Cohen offers a complete solution that makes sense."

—William Martinez Pomares, Software Architect, Group Avantica

"When it comes to XML performance and scalability, Frank Cohen is the Go To Guy."

—Simon Tuffs, Software Architect of OneJar and SOAPStone

Read More Show Less

Product Details

Read an Excerpt

FastSOA

By Frank Cohen

MORGAN KAUFMANN

Copyright © 2007 Elsevier Inc.
All right reserved.
ISBN: 978-0-08-052294-4

Chapter One

The Problem with Service-Oriented Architecture

Enterprises, organizations, and institutions want their existing data-centers, their existing software developers, and their existing information systems operations managers to work cooperatively on composite applications. A composite application is stitched together by using many small and very well focused services to solve a business problem. Imagine the efficiency, low costs, and fast time-to-market speed if composite applications were a reality?

Business managers love the idea of Service-Oriented Architecture (SOA). They widely believe SOA will get them to composite applications immediately. By 2006, many businesses quickly and widely adopted SOA as their strategy for building new information systems.

Enterprises, organizations, and institutions adopted SOA even though there is no standards body, such as the World Wide Web Consortium (W3C), OASIS, or others, to formalize SOA into a recommended specification. SOA has no core group of thought-leaders to tell software architects, developers, and operations managers the best practices to build functional, scalable, and maintainable SOA.

Instead, in the world of SOA, you find people like me. I am a practitioner. Businesses and institutions hire me to apply my deep technical knowledge and software testing experience to learn the scalability and performance profile of their information systems. In 2001, I began to look deeply into the impact Extensible Markup Language (XML) was having on scalability and performance. At first I looked at distributed systems that used XML to make remote procedure calls. Then I looked at SOAP-based Web Services. These experiences led me to look at SOA scalability and performance built using application server, enterprise service bus (ESB), and business integration (BI) tools. Across all of these technologies I found a consistent theme:

At the intersection of XML and SOA are significant scalability and performance problems that are found using my test methodology and solved by using native XML technology, including XQuery and native XML databases.

The scalability and performance problems in XML-based SOA designs are significant enough that I've seen entire projects canceled because of them. For instance, when General Motors asked me to write their Web Services Performance Benchmark, I found that a modern and expensive multiprocessor server that could easily serve 80 Web pages per second could only serve 1.5 to 2 XML transactions per second. Scalability and performance indexes like that shown in Figure 1-1 can kill a project.

I followed a path most Java developers will take. I fell in love with XML. I investigated the impact on performance and scalability that my choice of XML parsers, SOAP binding proxy generators, XML encoding styles, object-relational XML mapping techniques, databases, and architectures had on the resulting services. I found a solution to the SOA problem through the use of native XML technology.

I coined the name FastSOA for an architectural design pattern created to achieve the following goals:

1. Good scalability and performance in SOA and XML environments

2. Rapid development of software code

3. Flexible and easy maintenance of software code as the environments and needs change

The FastSOA architecture and software development patterns I present in this book are a way to mitigate and solve XML scalability and performance problems in your environment.

To understand FastSOA, I begin by explaining my view of the driving forces behind the rapid adoption of SOA in the business, software development, and software tools communities. I demonstrate the benefits of adopting SOA. I show the building blocks of SOA and the pitfalls of using existing tools and technology to implement SOA applications. I end this chapter with an introduction to the FastSOA architecture and patterns you may use in your own environment.

1.1 What Drives a Business to SOA?

In the late 1990s, Sun Microsystems was well along the way to adopting Web-based e-commerce technology for Sun's internal and customer-facing information systems. Sun wanted to get new distributions of Java, Solaris, and other software titles to customers quickly. Slow Internet connections were still prevalent and 100-megabyte downloads were not practical to customers. Compact disc (CD) distribution through the mail cost Sun a fortune in fulfillment costs. Sun's financial managers asked customers to pay $10 to $20 to receive a CD in the mail. This required Sun to take orders through an on-line store, process credit card payments, and integrate with manufacturing systems to fulfill the CD orders.

One of the Information Technology (IT) engineers at Sun wrote a credit card processing service for the CD fulfillment on-line store. The service uses HTTP transport protocols and an XML encoded form to process a credit card charge. The engineer later changed jobs and began working in the Java group. He wrote an application that let users order a subscription to a service to receive quarterly update CDs in the mail. The subscription service took a credit card as payment. The engineer coded the new application to use the on-line store credit card processing service from his old group.

A few years went by. The engineer moved on to another job with another company. Internet connection speeds improved and Sun decided to stop offering the CD fulfillment service. Sun took down the fulfillment service and the credit card processing service. Consequently, the Java subscription service stopped taking orders. From this experience it was apparent to many people that Sun had problems:

• No manager could tell you which services depended on other services. There was no map to show the choreography and interdependencies of services.

• No manager, software developer, or operations executive could forecast his or her computer hardware and network bandwidth needs to serve a given population of users at a defined quality of service.

• No software division could answer the question, "Who will answer the phone when the service stops working?" There was no governance plan for the services.

• No division's financial manager could tell Sun's executive management how to forecast the costs of engineering a new service.

• No engineering manager could determine the skills needed by a software developer to maintain an existing service. Each change to the system—no matter how minute—required a developer to go back into the code.

• Sun could not determine if a newly planned service already existed.

Sound familiar? IT managers contend with these problems every day. In my experience helping software architects, developers, and IT managers, I found that these issues are universally suffered at General Motors, the U.S. Navy, Lockheed Martin, BEA Systems, the European Union, and others. These are the issues that SOA is meant to solve.

Sun experienced these issues while deploying a customer-facing e-commerce system. Indeed, most businesses, institution, and organizations face the same issues when delivering supply-side vendor integration, customer service and support systems, financial analysis services for management, manufacturing and operations controls, market and customer trend analysis functions, and communication (email newsletter, phone, email, and Web) services. Take your pick. The issues are the same. The developers and architects who build these systems, the operations managers who run them, and the CIOs who manage their maintenance over time of these systems are looking for something in common. They all need methodology, procedures, and software to accomplish enterprise system integration projects.

By the early 2000s, IT groups tried to use Enterprise Application Integration (EAI) and Extract, Transform, and Load (ETL) tools and techniques to reduce integration and development costs and shorten the time it takes to build applications. These tools provide data synchronization between a system of record and a system to which you are copying the data. Applications communicate through the system of record whenever they need data.

EAI works well for very large enterprises, where economies of scale come into play for thousands of applications. Many enterprises, institutions, and organizations, however, find that EAI requires cooperation among the departments and organizations within the enterprise and that this cooperation is usually not present unless a strong central leader emerges to mandate EAI use. The tightly controlled, top-down approach works well in only a few organizations in the world.

While many consider the EAI approach to be dead, it is still useful in many environments. Managers propose systems integration projects today instead of EAI projects, even though they may use EAI tools in the project. With an open mind to EAI alternatives, many managers began to consider SOA to be a good choice for system integration efforts.

SOA emerged as a popular architectural choice with CIOs, software developers, and software architects because SOA works well in environments lacking centralized control and planning. The general feedback I get from the software development community is that SOA is reminiscent of the early days of the Web. Enthusiasm abounds and experimentation is frequent. Many developers are learning what works in an SOA environment as they share their knowledge in on-line communities, sharing example code, and participating in open-source projects. Figure 1-2 shows the convergence of excitement, experiments, and protocols around SOA.

CIOs, software architects, and developers have individual needs and goals for building the next generation of software applications. They also have a lot of excitement. Consider the following.

1.1.1 Software Developers Like Mashups

Mashups are integrations of data available on the Web. For instance, I wrote an application that integrates a map-generating service with a donut shop locator service. Never again will I be far from a donut as I travel on business.

Mashups are possible because many services on the Web support important connectivity and data encoding techniques. For instance, the Representational State Transfer (REST) lets me use HTTP protocols with XML data to make complex requests to Web services and receive the response in XML format that is easily parsed by my application. Additionally, a body of emerging standards known as Microformats embed XML data tags into Web page content, making the Web even more of a data source for my mashups. For instance, a calendar microformat enables Web page authors to embed special tags around dates that appear on a Web page for a conference schedule that I may easily use from within an application. While my mashup application delivers dubious business value, it taught me the skills needed to build composite applications.

Composite applications are the end-products of SOA. They deliver the business value a company derives from its SOA. Whether the composite application is designed for internal teams, customers, partners, or vendors, a composite application represents how organizations map business needs and processes to underlying information assets using SOA. Figure 1-3 illustrates a business that uses composite applications in an SOA environment to deliver business process automation.

Composite applications create value by delivering new views, transformations, and persistent queriable stores of data connected through a business process workflow to a presentation interface such as a Web browser or service interface. For instance, in Figure 13, a business operates a customer service desk to implement a set of business processes. When a customer calls the help desk, a representative manages the customer issues and updates the customer status. If the customer issue requires a technician to visit the customer's premises, the representative schedules a service call. Finally, the representative offers new products and services based on the customer's current subscriptions. The application to implement this business process must interoperate with several independent systems and develop a common view of the customer's data for the representative. Composite application techniques are well suited for this scenario for three reasons.

First, a composite application does not require any of the enterprise data tier providers to make changes to their databases. In an EAI or ETL approach, the applications would copy and synchronize data with the system of record. Composite applications get only the data they need at the time the user operates the composite application. The composite application uses the transaction capabilities of the databases to commit or rollback changes.

(Continues...)


Excerpted from FastSOA by Frank Cohen Copyright © 2007 by Elsevier Inc.. Excerpted by permission of MORGAN KAUFMANN. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Read More Show Less

Table of Contents

Chapter 1: A Love Affair with XML
Chapter 2: XQuery Primer
Chapter 3: Solving The SOA Scalability Problem
Chapter 4: The RSS Data Aggregator: SOA Federation and Acceleration
Chapter 5: SOAR: SOA Repository
Chapter 6: The Enterprise Data Bus: Extending XQuery and SOA
Chapter 7: EDB in Action: Supply Chain (RFID,) Insurance (HL7,) US Department of Defense (NCES,) Manufacturing (UBL)

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)
    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)