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
