External Applications in Application Systems
In Distributed System Designers, applications such as external Web services describe applications that are not included in your solution but that are referenced by other applications in the solution. In Application Designer, you can add these applications to the application diagram as a way to visualize, reference, and connect these applications. For more information, see Defining Applications on Application Diagrams.
In System Designer, when you design an application system containing applications that reference other applications not implemented in your solution, you can choose to include and connect the referenced applications in the system, or you can create proxy endpoints on the system for each consumer endpoint that connects to the referenced applications. For more information, see Defining Communication Pathways on System Diagrams and Exposing Behavior of Members in Application Systems.
Note
Though this topic focuses on external Web services as the example, the same concepts apply to BizTalk Web services, databases, generic applications, and custom application types created using the System Definition Model (SDM) Software Development Kit (SDK). For more information, see Application Types and Prototypes for Defining Applications.
The following sections discuss these approaches and guidelines for using them:
Including External Web Services in Systems
Excluding External Web Services from Systems
Choosing the Right Approach
Including External Web Services in Systems
If an application connects to an external Web service on the application diagram, you can choose to include the external Web service in a system. Including an external Web service in a system does not indicate that the Web service will deploy with the system. However, including an external Web service in a system makes it possible for you to accomplish the following:
Visualize a reference to the external Web service on the system diagram.
Connect multiple applications to the referenced external Web service to indicate that those applications must connect to the same Web service URL. For more information, see Communication within Application Systems.
When defining deployment for the system, specify the logical server to which the referenced external Web service must deploy. You can also validate that communication paths exist in the logical datacenter to support connections between the external Web service and applications that reference it. For more information, see Evaluating System Deployment with Deployment Designer.
With this approach, be aware of the following considerations:
A consumer endpoint can be connected to a single provider endpoint or to a proxy endpoint but not both.
If you connect a consumer endpoint to an external Web service within the system, you will not be able to create a proxy endpoint for that consumer endpoint on that system. If there is no proxy endpoint, you cannot expose the behavior of that consumer endpoint outside the system, so you cannot connect that proxy endpoint to a Web service in another system in order to resolve the URL.
When the system is deployed, the URL of the external Web service provider endpoint must be provided. This URL will be used to configure the connected consumer endpoints.
Representing ASP.NET Web Applications with External Web Services
When you have an application connected to an implemented ASP.NET Web application (with a Web provider service endpoint) on the application diagram, you can replace that ASP.NET Web application with an external Web service if you want to design a system that excludes that ASP.NET Web application. However, to use this strategy, you must either remove the ASP.NET Web application from the solution or create another solution without the ASP.NET Web application and define the system in that solution, prior to creating the external Web service.
Note
Do not replace the ASP.NET Web application on the application diagram by creating an external Web service from that application. The location of a Web service provider endpoint can be referenced only once on the application diagram. For more information, see How to: Locate WSDL Files for Web Services.
Excluding External Web Services from Systems
If an application connects to a Web service that you do not want to include in a system, you must create proxy endpoints for that application's consumer endpoints. Adding proxy endpoints makes it possible for you to expose those consumer endpoints and connect them outside the system if you plan to reuse the system in other systems. For more information, see Exposing Behavior of Members in Application Systems.
Note
The Web service could be an external Web service or an ASP.NET Web application with a Web service provider endpoint.
With this approach, be aware of the following considerations:
When defining a deployment for the system, you cannot specify the logical server to which the referenced external Web service must deploy. You also cannot validate that communication paths exist in the logical datacenter to support connections between the external Web services and applications that reference it.
Tip
You can work around this scenario by including the system and/or the external Web service within another system.
You cannot indicate on the system diagram that applications in the system must connect to the same Web service URL.
Tip
If you use this approach, tt is recommended that you separately document scenarios in which proxy endpoints on the system must connect to the same Web service URL. For example, you can add comments to the system diagram. This information will be important to anyone that reuses the system in another system. For more information, see How to: Add Comments to Distributed System Diagrams.
If a system with proxy (consumer) endpoints is deployed as a standalone system, that is, not within the context of another system, the Web service URL of each proxy endpoint must be provided as part of the deployment process. These URLs will be used to configure the consumer endpoints that the proxy endpoints expose. If the system is deployed within the context of another system, the provider endpoints in the containing system that are connected to the consumer proxy endpoints will provide the source for the URLs.
Choosing the Right Approach
When the system is self-contained and will be deployed as a standalone system (not included in another system), you can choose to include external applications, generic applications, or custom application types along with the applications that reference them in the system. If you plan to include the system in other systems, the consumer endpoints on the referencing applications require proxy endpoints to expose their behavior and connect outside the system.
However, a combination of these approaches is also possible. If you want to deploy the system as a standalone system but also be able to include it in other systems, you can create two related systems with one included inside the other. You can define one system that contains the referencing applications and exposes proxy endpoints. You can define another "wrapper" system, which includes the system with proxy endpoints as well as the referenced external applications, which are then connected to those proxy endpoints. If the underlying applications are needed within the context of another system, the inner system with the proxy endpoints can be used. If the functionality is to deployed independently, the wrapper system can be used. However, this approach requires you to maintain two systems at the same time. For more information, see How to: Combine External Applications with Referencing Applications in Application Systems.