In SOA and Web Services Interface Design, data architecture guru James Bean teaches you how to design web service interfaces that are capable of being extended to accommodate ever changing business needs and promote incorporation simplicity. The book first provides an overview of critical SOA principles, thereby offering a basic conceptual summary.It then provides explicit, tactical, and real-world techniques for ensuring compliance with these principles. Using a focused, tutorial-based approach the book provides working syntactical examples - described by Web services standards such as XML, XML Schemas, WSDL and SOAP - that can be used to directly implement interface design procedures, thus allowing you immediately generate value from your efforts. In summary, SOA and Web Services Interface Design provides the basic theory, but also design techniques and very specific implementable encoded interface examples that can be immediately employed in your work, making it an invaluable practical guide to any practitioner in today's exploding Web-based service market.
- Provides chapters on topics of introductory WSDL syntax and XML Schema syntax, taking take the reader through fundamental concepts and into deeper techniques and allowing them to quickly climb the learning curve.
- Provides working syntactical examples - described by Web services standards such as XML, XML Schemas, WSDL and SOAP - that can be used to directly implement interface design procedures.
- Real-world examples generated using the Altova XML Spy tooling reinforce applicability, allowing you to immediately generate value from their efforts.
About the Author
James Bean is the President and CEO of the Relational Logistics Group. He is the author of the books: the "Sybase Client/Server EXplorer" © 1996 Coriolis Group Books and "XML Globalization and Best Practices" © 2001, and has written numerous magazine articles for technology journals. He is also the Chairman of the Global Web Architecture Group.
Read an Excerpt
SOA and Web Services Interface DesignPrinciples, Techniques, and Standards
By James Bean
Morgan Kaufmann PublishersCopyright © 2010 Elsevier Inc.
All right reserved.
Chapter OneSOA—A Common Sense Definition
To fully understand and implement a service-oriented architecture (SOA), it is critical to have a solid grounding in business and technology evolution. From this, we can describe a set of common sense analogies and then drive into practical examples. First and foremost is realizing that SOA is not exclusively a technology solution. Rather, SOA is an example of business and computing evolution. It is an architectural approach for business that includes and requires supporting technology capabilities. SOA enables business enterprises to become more dynamic, agile, and responsive to change.
1.1 ORIGINS OF SOA
Unfortunately, it is unclear exactly where the term "service-oriented architecture" originated. Rather than try to identify a specific individual or organization that coined the term, it is probably more important to describe what SOA is and how it has evolved to become a recommended approach to solving business challenges. IBM infers that SOA originated from several technologies and practices:
The origin of SOA can be traced back to Remote Procedure Calls (RPCs), distributed object protocols such as CORBA and Java RMI, and component-based architecture such as J2EE/EJBs (Sun) and (D)COM/COM /.Net (Microsoft).
While this is a reasonable definition, it also implies a strong technical origin for SOA. While it is clear that SOA did evolve from technology origins, the reality is that SOA is also a business enabler. SOA begins to provide the long-awaited promises of rapid development, business agility, and reuse. To achieve these goals, SOA combines technology capabilities with the evolution and needs of the business enterprise.
To help explain the evolution of SOA, let's visualize a timeline of significant and related technology shifts (see Figure 1.1). Our starting point of interest is somewhere in the mid to late 1990s. This is the era where distributed computing, the Internet, e-commerce, and the Web started to become mainstream technologies for business. To keep a real-world focus, we'll extend our timeline to just beyond the present.
Along this timeline, we can see that there are three major shifts where technology takes on different roles in support of the business enterprise. These shifts in the role that technology plays are not limited to specific boundaries or time periods. We can visualize these shifts as "planes" that lie along a timeline and overlap to some degree. As we can see, the three shifts become progressively impactful to the business enterprise:
1. Technology becomes a commodity.
2. Technology becomes an enabler.
3. Technology becomes a transformer.
1.1.1 Technology becomes a commodity
Initially and with the advent of the Internet, Web, and e-commerce, technology began to emerge as a commodity. That is, the technologies in this era began to take on less of a large scale and monolithic investment and began moving into lower cost and smaller scale, distributed platforms and shared infrastructures solutions. Processor performance and storage continued to scale upward, while costs stabilized, and, in many cases, costs even reduced.
What became obvious is that with distributed and Web computing, it became easier to develop and implement point solutions. The business enterprise was able to quickly onboard into the e-commerce space and to extend its Web presence. Along with this ability to rapidly implement lower cost commodity technology solutions, a number of challenges also resulted.
A proliferation of point applications and redundancy emerged as less desired outcomes. The business enterprise also realized that there were a number of other competitive, market, and economic pressures. With the low cost commoditization of technology, businesses of every type were able to enter into the fray. The business landscape was becoming one where competitive products and services were being rapidly offered to the market. Surprisingly, many of these competitive threats included small-scale startups and innovators that did not have the large organizations and processes to contend with. They could very quickly and easily penetrate the market at a modest cost. If your enterprise wanted to retain or improve its market position, it also needed to become more dynamic and responsive. This is often referred to as "business agility." To respond to these challenges and pressures, technology organizations became recognized as an equal partner at the business table.
1.1.2 Technology becomes an enabler
Addressing increased competitive threats required a new focus. The business looked to technologies for opportunities to optimize their delivery of solutions. This included a renewed emphasis on managing development, infrastructure, and operational cost, as well as a much-needed escalation in rapid delivery. The technology response to these business needs included a shift in focus to one of technical excellence, rapid development for solution delivery and including consolidation and virtualization for cost management, and integration to resolve the many disconnected point solutions. This is the plane along the timeline where technology became a business enabler. It is also when technology direction began to exhibit many of the basic characteristics of SOA.
Interestingly, the siloed and point solutions that resulted from rapid technology delivery during the Commodity phase also started to become painful to the enterprise. While a requirement of that period was to retain market share and to stay competitive, the overarching emphasis was on rapid delivery of commodity solutions, and this contributed to a proliferation of stand-alone technology applications. Operational and maintenance costs began to rise, and even more obvious was the degree of difficulty in connecting the various point systems and sharing of information.
The notion of a 360-degree view of a customer is perhaps the most common and obvious example of needed integration (e.g., a "360-degree view" that encompasses all customer data for a complete picture of the customer and customer relationships, across the enterprise). The value of a customer became more than the size of an order, and began to focus on the total relationship (both current and potential). However, having many different customer applications and methods of communicating and interacting with the business, the resulting customer information became disconnected and disparate. The ability to up-sell or cross-sell to a customer was difficult if not impossible. To resolve this new problem of disparate systems and data, "integration" in all of its various forms became another critical component of business enablement. We began to see Enterprise Application Integration (EAI) and Enterprise Information Integration (EII) gain momentum.
SOA emerged as a combination of an architectural approach and technology enabler for the enterprise. SOA introduced several new technologies with an emphasis on technical excellence, and including a number of new development practices. These new technologies became the technical capabilities that enable an SOA, and the development practices evolved to become a set of principles and governance. This is also the current state perspective of SOA for many business enterprises today. For those that have successfully led the SOA curve, it is almost a historical view.
1.1.3 Technology becomes a transformer
As the technology evolution continued, additional emphasis was placed on "transforming the enterprise." That is, transforming a business enterprise from reactive to proactive. The business enterprise is less focused on responding to the market (in this context, "responding is—after the fact"). Rather than being a follower of the market and competitive landscape, the enterprise begins to anticipate those demands. This is also where SOA becomes a transformational solution.
To some degree, this third plane in the technology evolution is unfinished. There continue to be new capabilities and enhancements to the SOA paradigm. One of which is a "closed loop SOA," where the technology orchestration of business processes not only enables the enterprise to offer new products and services, but with a feedback loop and simulation capabilities, the business can begin to reconfigure how it will do business. You'll learn more about this in Section 1.5, "Business Activity Monitoring."
As an enterprise transformer, there is also an emphasis on federated SOAs and extending into a service-oriented community. The most common service interaction is Application-to-Application (A2A), which is the foundation for all consumer-to-service interactions. While SOA-enabled federated servicing communities are still in their infancy, the expectation is that we will begin to see broader SOA-enabled collaboration that extends beyond A2A and into service collaborations between different enterprises (E2E). This model of collaboration includes enterprise relationships where business partners and competitors can play a role. Web 2.0 is another emerging area. There are some examples of currently available technology solutions classified as Web 2.0 today (such as mashups, wikis, and semantic tagging frameworks). However, there is some controversy as to an accurate definition of Web 2.0. Interestingly, while the definitions of SOA and of Web 2.0 vary, most industry perspectives are such that SOA and Web 2.0 exhibit a strong synergy and dependence. If you accept this perspective, SOA plays a fundamental role to underlay and support Web 2.0 technologies by delivering information with services.
No doubt, some industry practitioners would dispute this brief history of SOA. Others might argue that the technologies and pressures from which SOA originated, extend well beyond those described. Yet there are many definitions for SOA. Several are similar, while others are quite different. Some definitions emphasize SOA technology and others accentuate the business aspects of SOA. All of these views of SOA are to some degree accurate but lacking a concise definition that everyone has agreed or will agree to.
1.2 A DEFINITION FOR SOA
All of the various industry definitions for SOA are worthy of consideration. However, without a standard that everyone can agree upon, understanding the operational context becomes more important. Fundamentally, service-oriented architecture (SOA) is an evolution in technology that becomes a business enabler and eventually a business transformer. So how do we drive this statement into something that is more discrete and real world, and which can be easily understood without prescribing specific technology products?
Let's start with another, more explicit definition of SOA. The following definition is one that I have developed and refined while working on different SOA initiatives over of the past several years.
A service-oriented architecture (SOA) is a combination of consumers and services that collaborate, is supported by a managed set of capabilities, is guided by principles, and is governed by supporting standards.
Excerpted from SOA and Web Services Interface Design by James Bean Copyright © 2010 by Elsevier Inc. . Excerpted by permission of Morgan Kaufmann Publishers. 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.
Table of Contents
1. SOA – A Common Sense Definition
2. Core SOA Principles
3. Web Services vs. other Types and Styles of Services
4. Data – the Missing Link
5. Data Services
6. Transformation to Resolve Data Impedance
7. The Service Interface - the “Contract”
8. Canonical Message Design
9. The Enterprise Taxonomy
10. XML Schema Basics
11. XML Schema Design Patterns
12. Schema Assembly and Reuse
13. The Interface and Change
14. Service Operations and Overloading
15. Selective Data Fragmentation
16. Update Transactions
17. Fixed Length Transactions and Nulls
18. Document Literal Interfaces
19. Performance Analysis and Optimization Techniques
20. Error Definition and Handling