A company has a number of integration solutions that reference a single library that contains resources that are used by the integration solutions.
The initial configuration for this scenario has two applications (App1 and App2) and two Message Broker projects (Proj1 and Proj2). Each of the applications and Message Broker projects has a message flow that references a library (MessageMappingLib).
The following screen capture shows the development resources for the library, and the applications and Message Broker projects that reference the library. At this stage, the library references are references to a single copy of the library. Any changes that are made to the library are immediately available in the development resources for the application.
The following screen capture shows the resources after the Message Broker projects and applications are deployed to the execution group. After deployment, there are three copies of the MessageMappingLib library in the execution group.
Because of the runtime isolation that is provided by applications, the resources that are associated with the App1 application, including a copy of the MessageMappingLib library, are grouped under the application name and are only visible and available to the App1 application. Similarly, the resources that are associated with the App2 application are only visible and available to the App2 application. However, the resources for both of the Message Broker projects (the Proj1Flow1 message flow from the Proj1 Message Broker project, the Proj2Flow1 message flow from the Proj2 Message Broker project, and another copy of the MessageMappingLib library) are stored directly in the execution group. These resources are available and visible to each other and to all other resources that are deployed directly in the execution group, but not available or visible to the applications.