Flylib.com

Books Software

 
 
 

Open Standards


Open Standards

In many industries, companies adhere to standards that allow for greater prosperity than would be possible if each company followed its own proprietary rules. Standards in housing construction, for example, ensure that manufacturers of pipes can benefit from economies of scale in pursuit of a larger market than would be available in the absence of industry-wide standards.

The primary benefit of SOA standards is that they make services interoperable , which means that services can communicate with one another, even if each implementation is written in a different computer language or is accessed by way of a different transport protocol (software that oversees the runtime transmission of data).

Standards also ensure that an SOA runtime product can support Quality of Service features, as described in Chapter 2.

SOA standards are open in the sense that any software manufacturer has the right to use those standards when developing an SOA- related product. In addition, the process of creating and revising the standards is based on a political process that is more or less democratic . Any interested party has the right to participate in all meetings that lead to decisions about a standard.

Each company that works on an open standard seeks a text that matches the company's marketplace strengths. The competition among those companies is one reason for the long delay in making a standard final.

Several major organizations oversee development of open standards for SOA:

  • Open Grid Forum ( http://www.ogf.org )

  • Organization for the Advancement of Structured Information Standards (OASIS; http://www.oasis-open.org )

  • Web Services Interoperability Organization (WS-I; http://www.ws-i.org )

  • World Wide Web Consortium (W3C; http://www.w3.org )

Later chapters give you practical insight into standards that are in effect or under consideration, and Appendix A describes several others.

Open standards are distinct from open source , which is source code that you can learn from and use in your own projects, with certain legal restrictions. Open-source implementations of Service Component Architecture (SCA) and Service Data Objects (SDO), for example, are being developed in the Tuscany incubator project of the Apache Software Foundation. For details and code, see the following Web sites: http://incubator.apache.org/tuscany and http://www.apache.org .



Structure of a Service-Oriented Application

A service-oriented application is an application composed largely of services. Often, the invoked services are in a hierarchy, as Figure 1.1 illustrates.

image from book
Figure 1.1: Service-oriented application

The topmost level contains one or more integration services , each of which controls a flow of activities such as processing an applicant 's request for insurance coverage. Each integration service invokes one or more business services.

The second level is composed of services that each fulfill a relatively low-level business task. For example, an integration service might invoke such business services to verify the details provided by an insurance-policy applicant. If the business services return values that are judged to mean "issue a policy," the integration service invokes yet another business service, which calculates a quote and returns the quote to the software (for example, a Web application) that invoked the service-oriented application.

The third level consists of data-access services , each of which handles the relatively technical task of reading from and writing to data-storage areas such as databases and message queues. A data-access service is most often invoked from the business layer.

Great complexity is possible. Some integration services, for example, provide different operations to different requesters, and some invoke other integration services and are said to be composed of those services. Many applications, however, fulfill the three-level model described here.