Skip to content

[3.5 M1][CORE] Mule Container Resources

pablolagreca edited this page Aug 28, 2013 · 27 revisions

Jira:

Forum discussion:

Motivation / Context

Several mule users have requested the capability to share resources between applications that are deployed within the same container. The main reason for the request is that they want to create an application that is a composition of mule applications. This allow them to have different teams working independently.

Another request is the capability of consuming services between mule applications deployed in the same container using VM. This allow mule applications to make use of services deployed in other mule applications in a really easy and performant way.

We are going to provide such capabilities through the definition of resources at the container level and exposing them to all the applications deployed in the container.

Uses cases

As an architect I have different teams working on different parts of an applications. I want them to work as independent units but they must:

  • share the same security mechanism
  • all the services must be provided through the same port
  • share the connection to the persistent storage
  • share services between each other through a well defined interface

Design

Provide an xml configuration file at the domain level in which users can define the mule components that they want to share between mule applications. Components defined in this file can be referenced from a mule application that belongs to that domain and make use of it.

shared resources deployment diagram

Configuration

Configuration file for the container

<mule-domain-config>
   <http:connector name="ApiConnector"/>
</mule-domain-config>

A file located named mule-domain-config.xml located in a jar file in the domain will contain the configuration for shared resources

<mule>
   <flow name="httpService">
      <http:inbound-endpoint host="localhost" port="8080" connector-ref="ApiConnector"/>
      <set-payload value="#['success']" />
   </flow>
</mule>

Any mule application within that domain can make use of the shared connector by just reference it from the configuration

What resources we will be able to configure as shared

  • HTTP connectors
  • VM connectors
  • Security Managers
  • TBD ???

Acceptance criteria

Mule domain configuration

  • If there's a jar containing a mule-domain-config.xml file it must created shared resources ONLY for the applications within that domain
  • If there's more than one mule-domain-config.xml file in the jars of a domain then that domain deployment and all the applications related to that domain must fail.

Http connector sharing

  • Different applications must be able to share the same port
  • Different applications can't be configured to use the same host port path combination. When they do the last one to be deployed must fail

VM connector sharing

  • When using a shared connector it must be possible to send message between mule applications
  • There can't be two applications using the same vm queue path

Security Manager sharing

  • It must be possible to define a security manager at the container level and reference it from the mule applications
  • ???? We may need to add the possibility of having more than one security manager per application

Risks

We need to take into consideration that with the current threading implementation we are going to start reusing thread across different applications.

Mule Studio Impact

We need to find a way to, for every applications, allow the definition of the container shared resources file so Studio can load it when it deploys the application.

We can also think of creating a new project structure that represents the set of applications that belongs to the same container and the file with the shared resources.

MMC Impact

We must add support for the shared resources and show it status as we currently do for connectors.

CH Impact

Initially there's no impact since CH only uses one application for AMI and by default there will be no shared resources.

Service Registry Impact

No impact.

Migration Impact

No impact yet.

Documentation Impact

Requires a new documentation section for this functionality.