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.
Despite the weaknesses of business objects combined with Web Services, they will always have a place in an application. In many cases, the Business Object and Business Object Collection patterns remain pure-Java implementations , and you will use either an adapter or a business process that hides the use of the Business Object and Business Object Collection patterns.
Businesses gamble on Web Services because of the evolving and growing use of business processes as formal building blocks for applications. The EbXML glossary (available at http://www.ebxml.org/), defines a business process as the following:
The means by which one or more activities are accomplished in operating business practices.
Essentially, business processes address how to model business, whereas business objects address how to model the physical representation of entities within a business. Using business processes as a model for one or more activities in a business does not preclude the use of business objects, and it does not imply the use of business objects. Instead, you look at a business purely from the aspect of the activities that business conducts. These business activities compose into larger business processes defined by common process interfaces. A business process in Web Services is a composition of business activities that may or may not be other Web Services. A business activity may or may not be a first-class business process.
It is important to realize that there are two facets to discussing business processes; one facet addresses the structure of a business process, and the other facet addresses how to standardize interfaces to business processes. This pattern describes a general pattern for the structure of a business process implementation, not the deeper discussion of the standardization of business process interfaces. For more information on the standardization of business process interfaces, you should refer to the e-business Extensible Markup Language (XML) effort and the specifications produced by the ebXML standards body or the Organization for the Advancement of Structured Information Standards (OASIS) group (http://www.oasis- open .org/). Each of these groups has processes for standardizing business processes and committees that you can join to develop the standards. Beyond the formal standards bodies, you will likely find contacts in your industry trying to make de facto standards for Web Service interfaces or larger groups focused just on your own industry. Perhaps the most interesting part of viewing the work of the larger bodies, such as ebXML and OASIS, is the document templates and standards they have produced. These documents can serve as a starting point for designing your own business processes.