SOA and Web Services Interface Design: Principles, Techniques, and Standards

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $8.95
Usually ships in 1-2 business days
(Save 87%)
Other sellers (Paperback)
  • All (9) from $8.95   
  • New (6) from $11.62   
  • Used (3) from $8.95   

Overview

Today’s enterprise is experiencing tremendous economic and market pressures. Growth and more importantly survival require broad-scale interoperability, rapid delivery and agility. SOA can help to enable transformation of today’s enterprise from responsive to anticipatory, where new capabilities are assembled from reusable services. Yet a lack of SOA and servicing formalism impedes this business transformation. A well-defined service interface design process and combined with effective techniques and patterns are critical to SOA success.

In his new book, data architecture guru James Bean teaches you exactly how to design service interfaces and emphasizing the interoperability afforded by Web services. These services are capable of being extended to accommodate changing business needs and promote integration simplicity.

The book first provides an overview of critical SOA and service design principles of loose coupling, interoperability, extensibility, reuse, and discoverability. Each successive chapter then offers explicit, real-world techniques for ensuring compliance with these principles. Using a focused, tutorial-based approach, the book provides working syntactical examples developed using the Altova XML Spy™ tooling and described by Web services standards such as XML, XML Schemas, WSDL and SOAP. Moreover, these examples and techniques can be used to directly implement interface design procedures, allowing you to immediately generate value from your efforts. There is simply no other volume that provides as deep, concise, and practical sets of design techniques and patterns.

  • Provides chapters on topics of introductory WSDL syntax and XML Schema syntax, taking you through fundamental concepts and into deeper techniques, thus allowing you 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 your efforts.
  • A companion website with all artwork and code examples accompanies the book.
Read More Show Less

Product Details

  • ISBN-13: 9780123748911
  • Publisher: Elsevier Science
  • Publication date: 11/4/2009
  • Series: MK/OMG Press Series
  • Edition description: New Edition
  • Pages: 384
  • Product dimensions: 7.40 (w) x 9.10 (h) x 1.00 (d)

Meet 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 More Show Less

Read an Excerpt

SOA and Web Services Interface Design

Principles, Techniques, and Standards
By James Bean

Morgan Kaufmann Publishers

Copyright © 2010 Elsevier Inc.
All right reserved.

ISBN: 978-0-08-095383-0


Chapter One

SOA—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.

(Continues...)



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.

Read More Show Less

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

A. Appendix

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)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

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