Connection Patterns
Connection PatternsToday, it is increasingly likely that you are working with a multi-tiered application that contains distributed components that need to communicate with each other. It's very likely that you establish a connection to a database to access and update data. Recurring themes have emerged and are being harvested from popular practical use of connections.
In the ComponentDesignPatterns project, a mini-pattern language has emerged that contains related ConnectionPatterns.
How about ConnectionFacade?, ConnectionAdapter?, ConnectionPool, ConnectionMultiplexor? and ConnectionProxy??
Why? Can you provide some examples or how these would be used by components? --PhilipEskelin
I mean, aren't they commonly used already in lots of systems using components? Aren't there already existing systems that use a facade to abstract and represent a connection but hide the internal classes and their collaborations? Aren't there already components that use adapters to plug from one kind of connection to another, or decorators to add abilities or behavior to an existing connection? Aren't there systems employing resource managers that need to manage a pool of connections (or of things that can be connected to/from a given machine)? Aren't there already systems that need components to multiplex to/from a connection (a la reactor)? Aren't there already systems that need to know some info about a connection residing on some other network or address space for collaborations between other objects, but for which an object or component on this machine and address space uses a proxy object of some sort to monitor or advise?
Don't all these things already exist and already have needs and uses in existing systems today? Why don't they deserve to be written up like ConnectionSingleton and ConnectionObserver? and ConnectionFlyweight do? Aren't they just examples of the GoF patterns in the subconnect of components and distribution and don't such examples exist for almost all the GOF patterns in this subcontext? What is the important variation or added commonality that lends additional insight to discussing their applications in the component subcontext?
Perhaps there are other patterns on the subject of connections between components. For some reason I still don't understand how your proposed patterns are applicable -- I think I need some concrete examples.
When writing up the ConnectionPatterns, I asked myself -- when thinking of component-based systems I've helped build -- what was present in these systems that seemed to operate well, meet requirements, code looks geometrically aesthetic, etc. I answered to the best of my ability, "What's present is _____."
In the case of many components in a process communicating with distributed server components, where connections were managed efficiently and resources weren't wasted, I saw a ConnectionSingleton present that allowed each component to share a single connection.
When I ripped the network cable out of the wall, observed the resulting behavior of each component, plugged it back in, observed again, killed the server, observed again, etc. I saw a ConnectionObserver? present helping each component receive notification of events such as connection termination, etc. and allowed them to respond appropriately.
On the server side, when I saw thousands of requests coming in from remote components, and as I observed efficient resource management by the application infrastructure, I saw a ConnectionFlyweight (or connection cache if you will) present that was being shared amongst them.
These were the three that I saw in about three different component-based projects. I think KyleBrown created the initial ConnectionFlyweight pattern based on one of his own sightings. So as I said above, perhaps there are others in different contexts that help make a component-based system operate efficiently in terms of connection management which lead to additional patterns.
After hibernating on this, I do see the viability of adding some of the additional patterns proposed above. For example, ConnectionFacade? is an interesting one in the EAI space given the need to manage connections with multiple possibly heterogeneous systems while keeping them transparent to the client. --PhilipEskelin
I think the point that is being made is that the ConnectionPool or ConnectionPooling? idea is fundamental to just about all J2EE app servers. Given that one of the aims of DesignPatterns is to catalogue existing solutions to common problems it would seem odd to omit it. Having said that I think we can plausibly argue that the ConnectionFlyweight pattern describes the same idea as connection pools but is mis-named. -- AdewaleOshineye
EditText of this page
(last edited April 17, 2002)
or FindPage with title or text search