Preparing to Implement the Connector Pattern

This section contains some useful pointers for the Connector pattern. Many of these pointers depend on how much freedom you have with your own application implementation. In the end, how you build your physical tier separation and communication to applications depends heavily on the computing ecosystem you choose to promote.

For example, an EJB environment often proves difficult and heavy for small applications and small businesses. A pure J2SE implementation is lighter but misses substantial opportunities to allow infrastructure other than your own to handle enterprise-scale issues. Many application servers that support EJBs take care of database connection pooling, thread pooling, and load balancing. You should offload this type of infrastructure to experts, such as those who focus on application server implementations , whenever possible. This code has no added value to the functionality provided by your business and only appears if there are failures in the code. The following are some useful pointers for implementing physical tiers with the Connector pattern:

Use native support in your Web Service environment whenever possible: Different levels of native support are inherent in most Web Service implementations. Apache Axis includes providers that allow interprocess communication from Apache to EJBs and to JMS. You can also write your own providers that Apache can use. Integration at this level will most often be quicker than writing your own service implementation, but it will also tie you to a particular Web Service implementation.

There is an "up front" performance penalty for using separated processes: The performance penalty embodies itself in the remote communication between the Web tier and the logic tier. Marshaling and unmarshaling parameters and communicating outside of your own process is always an order of magnitude slower than a local method call. Fortunately, because you are already in a Web environment, the slowdown is not sufficient to cause panic. Further, the ability to build an optimized, isolated, and reusable logic tier that communicates directly between components and reuses existing instances in a single process often outweighs the slight performance loss. Remember that in the case of a technology such as JDO, the separate threads, class loaders, and processes that a Web Service implementation may use can lead to duplicate instantiations and ineffective use of the underlying database. By isolating the use of JDO and JDBC, and technologies like them, to a single deployment process and class loader, you may be able to get far superior performance than if you allow the Web Service environment to control instantiation.

There are broader options for deployment depending on the remote mechanism you use to implement the Connector pattern: Once you insert remote mechanisms between theWeb tier and the logic tier, you open the ability to place the tiers on separate processors and separate networks, as long as there is still a communication path between the servers.

You lose any benefits of residing within the Web Service container that aWeb Service implementation offers: There are two primary benefits to residing within the Web Tier container: the ability to manage a single environment containing the entire application and the performance inherent in having everything reside in a single container. The first problem, consolidated application management, is the most difficult. There may be ways to plug all of the server and application management into a single management framework; however, the reality of such a scenario is more than likely many years off. The second problem, performance, also takes work to handle. You could allow some service implementations to reside entirely in the Web tier while others communicate outwardly with their logic tier counterparts. Stateless Web Services that have little interaction with other application components are good candidates for leaving out of the new tier design.