Using a Singleton Mediator to provide loose coupling

Question

I need to discuss the pros and cons of using a singleton mediator to provide loose coupling between component implementation classes.
Suppose you are building a SE or a BC where an endpoint is defined upon a SU deployment. In this scenario, you will end up finding out that the Component, ComponentLifeCycle and ServiceUnitManager implementations should know each others instances. I can figure out these solutions:
-     Use tight coupling
-     The component implements the three interfaces (or two of them and associates the third)
-     Use a singleton mediator to hold the instances
-     Use a third party solution, like Spring's ApplicationContext and ApplicationContextAware contracts
-     Some other solution I didn't think of (the scenario has to be more specific)
Assuming the scenario as described above, I prefer the third solution.
I appreciate your opinions.
Hossam Karim

Answer 1

When you evaluate the JBI implementations available, you will notice that each one has built a less abstraction layer over the JBI component contracts in order to simplify its subsequent tasks. As a component builder, you would either reuse one of these layers and get tight with a specific implementation, or start writing your own.
I recently proposed a simple framework to my team; you can find a class diagram here (http://www.gaiati.com/products/emee/framework.png), it has the following elements:
�     AbstractBootstrapAdapter: Simple adapter for the Bootstrap interface
�     ComponentApplicationContext: Provides a Spring based Application context for this component, the context beans should be loaded upon component initialization. An instance of this class will be available to all classes or interfaces that extend the ApplicationContextAware Spring interface. All classes and interfaces on the previous diagram that associate a ComponentApplicationContext instance (applicationContext) implement the ApplicationContextAware interface. One exception is the AbstractComponentAdapter class, because it actually creates the instance.
�     AbstractComponentAdapter: Adapter for the component and lifecycle contracts. Upon initialization, this class creates a ComponentApplicationContext instance, and uses the beans to configure itself, the class recognizes other framework contracts and able to communicate with them.
�     AbstractMessageListener: Consumes this component's DeliveryChannel message exchanges, and fires a handling trigger.
�     DeployedEndpoint: Represents an endpoint that was deployed using a SU
�     DeployedEndpointConfiguration: Holds the configuration needed by a DeployedEndpoint instance
�     DeployedEndpointTarget: Represents the target JBI specific address that a DeployedEndpoint instance should route the messages to.
�     GenericMessageListener: Handles the trigger fired by the AbstractMessageListener, delegating the work to an instance of the DeployedEndpoint interface
�     GenericServiceUnitManager: Handles GenericServiceUnit instances
�     GenericServiceUnit: Acts as a proxy and encapsulates a DeployedEndpoint instance
�     AbstractDeployedEndpointFactory: An abstract factory for creating DeployedEndpoint instances using DeployedEndpointConfiguration instances
Yes, I ended up using Spring, and you are right, it might not be appropriate to attempt to separate the interfaces, may be I misunderstood or was mislead by Open-ESB implementation of the SOAP and file binding components.
It is true sometimes you can have "personal taste", but most important is to achieve best practice.
Finally, I hope the specification in its next versions, would provide us with a best practice framework or proposal, instead of so much choices.
Hossam Karim