Exploring the Business Process (Composition) Pattern

Abstract

Through the Business Object and Business Object Collection patterns, you enable capabilities that are already available in today’s programming languages. Specifically you have a type of proxy model to connect data representations across a network. To access the data, the client of the Web Service must re-create the object model on the server in its own language. There are many limitations to the Web Service model when you attempt to use them to fulfill an object-oriented architectural style (Chapter 6, “Exploring the Business Object Pattern,” and Chapter 7, “Exploring the Business Object Collection Pattern,” document these points more fully):

There is a mismatch in the component-style model of Web Services with the capabilities of object-based languages: For example, Web Services (which are a variation on a component-style architecture) do not have a rich inheritance model or use polymorphism. You are also missing the concept of object references vs. object copies in Web Services. The data you retrieve from a collection are always copies of data.

The unpredictable nature of the architecture of a client program that accesses your Web Service limits the richness of the object structure that you can usably expose to the client: Beyond Java, languages such as Perl, Python, C, and even a language such as COBOL could access Web Services. The more complex your structure, the more difficult it will be for users of these languages to access your Web Service.