For example, suppose we have a component named DataServices. The DataServices component communicates directly with the database and performs all of the Create, Read, Update, and Delete (CRUD) services with the database. The DataServices component will have the following methods: Create, Read, Update, and Delete. Another component, called the UserServices component, will interact with the user. The UserServices component will allow the user to review, update, add, and delete records from the database through the DataServices component.
Tightly bound systems
Currently, the usual way to create a system of interdependent components is to design all of the components together and have one component call the methods and properties of another component directly. In our example, the user would request a service from the UserServices component and the UserServices component would make a direct request to the DataServices component to actually perform this service. Figure 1-2 illustrates this process for a request to update a record.
Figure 1-2. Request to update a record in a tightly bound system.
As you can see, the UserServices component will be coded such that it will call the Update method in the DataServices component. If you change the Update method, you will also have to change the code within the UserServices component. This is called a tightly bound system, meaning that components in the system are directly dependent on other components in the system.
This type of system requires you to design all of its components at the same time. You can build the UserServices component first, but you'll need to know what methods the DataServices component will have-in other words, you will need to design the DataServices component at the same time as the UserServices component. When you are creating a Windows DNA system, which spans an entire enterprise that consists of hundreds of components, the task of designing all of the components at the same time can become nearly impossible. Add to this the capability of communicating with components outside the system through extranets, and you may now have a system that cannot be built using tightly bound components.
Corporations usually have many existing tightly bound systems. These systems do not always need to be replaced, but might need to be upgraded with newer components that can communicate with the older components. Tightly bound components can be appropriate in systems that have few components. XML can be used to build or augment tightly bound systems by using SOAP. Using SOAP, one component can call the methods or set the properties of another component using XML and HTTP.
Loosely bound systems
To solve the problems of the tightly bound system, we must do some rethinking. We need to allow components to request services without knowing in advance which component will actually perform that service-in other words, we need to create a loosely bound system.
A request for a service can be considered as a message. When a component requests a service, it sends a message to another component specifying what it wants the other component to do. A request for a service can also contain additional information that is required to perform the service (such as the ID of the record that is about to be updated and the updated values for the record).
To request a service in a loosely bound system, a component packages the request in a message that is passed to a messaging component. The messaging component will then be responsible for determining the message type and identifying which component will provide the services associated with the message. Our update request will now look like the one shown in Figure 1-3.
Figure 1-3. Request to update a record in a loosely bound system.
In the loosely bound system, the UserServices component does not need any information about the DataServices component; it needs to know only the format of the update message. The DataServices component, including its interface, can be completely and repeatedly rewritten, and nothing will have to change in the UserServices component as long as the DataServices component still works with the same message format.
Building on this example, suppose we have two corporations: Corporation A and its partner, Corporation B. As you can see in Figure 1-3, it's quite possible that the UserServices component is running in Corporation A and the DataServices component is running in Corporation B. Neither corporation has to be concerned about using the same platforms or the same types of components or about any of the details of the components running in the other corporation. As long as both corporations can agree on a standard format for messages, they will be able to request services on each other's systems. BizTalk is all about creating these standard formats for messages used in business-to-business (B2B) communications. Thus, BizTalk will allow the creation of large Windows DNA systems that support both the internal DNS for the corporation's knowledge workers and the extranet for the corporate partners.