Defining and Deploying Systems

We have demonstrated the key principles for binding applications onto servers, using the default deployment as our vehicle. That resulted in an automatically generated system—named Default—which collected all applications together.

Now you'll see how to define your own systems from groups of applications.

System definition for the full application design

You can define a new system combining all of the applications shown on an Application Diagram by right-clicking the diagram surface (with nothing selected) and choosing the Design Application System option.

In the Design Application System dialog that appears, you can enter a name for the system; for example, for a system based on the StockBroker application design, you could enter FullStockBrokerSystem. A new diagram will appear in the Solution Items folder with the extension.sd—in this case, FullStockBrokerSystem.sd.

The resulting system will contain the same set of applications as the default deployment, except that in this case when you subsequently use Deployment Designer, the System View would list the applications under the more meaningful FullStockBrokerSystem heading, rather than the Default heading.

On the face of it, this technique achieves little more than what was achieved using the Define Deployment function, but this approach need not be limited to defining a system for the whole application design. You can define a system for a subset of the application design.

System definition for a subset of the application design

We'll follow the same procedure just described, but this time we'll select two specific applications to be combined as a system. On the StockBrokerApplicationDesign diagram, click the StockBroker application, and then hold down the Ctrl key and click the StockQuoteApp application. With those two applications selected, right-click and choose Design Application System. When the Design Application System dialog appears, you can enter StockBrokerWebApplications as the name of the system.

The result will be the new system diagram named StockBrokerWebApplications.sd, which is shown in Figure 4-5. Initially, you won't see the connections between the StockBroker endpoints and the system boundary, so you must add these by right-clicking the endpoints on the StockBroker and selecting Add Proxy Endpoint.

Figure 4-5

Important

Alternatively, you can simply click an application endpoint, hold down the Alt key, and drag to the system boundary.

To connect to a system, that system must expose a proxy endpoint, through which communication can occur into the system. When you read the "Nested Systems" section later, you will understand why we needed to create the proxies here.

It makes sense to combine the two applications—StockQuoteApp and StockBroker—into a single system because we intend to supply them together as our software release, whereas the MarketMaker and StockMarket applications are design representations of external, or third-party, applications. On that basis, we could consider also including the DealingApp within the same system, but we have chosen not to in this example because, besides forming part of our core product, we also intend StockBroker and StockQuoteApp to be deployed to the same server type (i.e., an IISWebServer) and possibly on the very same server instance. Therefore, in this case we have defined the scope of our system based on deployment constraints, rather than commercial product groupings.

Important

Note that there is no requirement to define in a system applications that must be deployed to a single server. You can potentially reuse the subsystem on other systems or in isolation.

Having defined a new system using System Designer, we can now define a deployment of that system using Deployment Designer.

Defining deployment

Start by right-clicking the StockBrokerWebApplications system shown in Figure 4-5, and choose Define Deployment. When the Define Deployment dialog appears, browse to the StockBrokerDatacenter.ldd diagram to deploy against.

A new deployment diagram (e.g., StockBrokerWebApplications1.dd) will be created; and when displayed, this diagram will be the same as the one shown in Figure 4-3. This time, the System View window will provide the two applications—StockBroker and StockQuoteApp—that comprise the StockBrokerWebApplications system (see Figure 4-6).

Figure 4-6

Important

If you chose Define Deployment for the FullStockBrokerSystem mentioned earlier, the System View would list all applications, as with the default deployment. The applications would be grouped under the heading FullStockBrokerSystem, rather than the heading Default.

To bind the StockBrokerWebApplications onto servers, you can simply drag the applications onto the server representations of the deployment diagram, just as before.

Nested systems

When defining the StockBrokerWebApplications system, we defined the scope of our system based on deployment constraints, rather than commercial product groupings. In doing so, however, we acknowledged the case for combining the DealingApp into a system along with the StockBroker and StockQuoteApp applications—perhaps as a "release" of our software.

One way to achieve that, while preserving the integrity of the original StockBrokerWebApplications system, is to include a system within a system, as shown in Figure 4-7. You can see there that we have created a new system—named StockBrokerRelease1 and containing the DealingApp—to which we have added the StockBrokerWebApplications system itself.

Figure 4-7

As a starting point for that diagram, we selected DealingApp in Application Designer, right-clicked and chose Design Application System, and named the new system StockBrokerRelease1. We then dragged the StockBrokerWebApplications system straight from the System View onto the StockBrokerRelease1 system.

At that point, the diagram would not show connections between the DealingApp consumer endpoints and the StockBrokerWebApplications provider endpoints (which we delegated earlier), so we added those connections in the usual way.

When attempting this yourself, you might wonder how we knew which of the provider endpoints to connect to which of the consumer endpoints. One way would be to reveal the provider endpoint labels—right-click and choose Show Label. Another way would be to simply let the designer warn you of an incorrect connection, which it will with the following message:

      Warning: The Binding Name and Namespace of the endpoints do not match 

There is no practical limit to the number of systems that can be nested within one another or the depth of nesting, but a system cannot directly or indirectly contain a use of itself, which would result in a circular reference. Please note that this is just a warning; you can ignore it if you are not using binding names and namespace to identify the type of a Web service endpoint.