I have a Three-Tier architecture. Wouldn't it be simpler to just use point connections from my app server to all my other applications/legacy servers on the back end?

Not Really. If you simply connect from an application server using client connections (such as JDBC, SOAP or HTTP etc.) to back end systems you are probably ignoring the following issues:

• What kind of fail-over strategy will the client connections use if they fail to connect to their primary target system on the back end? Have you made redundant network paths that the client can use to reach its target service? If so, how will the client route its messages intelligently through the redundant paths?
• If the target system is moved, can you guarantee that all the clients will detect the change without interruption or reconfiguration?
• If the target system is replaced with a different one will you have to break open the code in all the clients and modify them so that they can talk to the new system? How will you implement seamless fail-back to the old system if it becomes necessary?
• If a requirement arises in the future that means you need to send a given message exchange to an additional system (perhaps with a new protocol or data format), can the client code incorporate the new requirement with the minimum impact? What if ten or more new systems are added? Is the impact on a given client linear? What if in the future one system is required to be notified of a hundred different client exchanges? An ESB handles multiple subscribers (fan-out), single subscribers to multiple producers (fan in), or duplication of subscribers as a built-in part of the architecture.
• What impact will changes to the interface on the target system have on the clients? If they are close-coupled interfaces (as most client connections are) will you be overwhelmed by the ripple effects of changes in one part of the system that propagate out and impact the rest of the system?
• Will your client/server interactions be visible, reportable, and auditable? Can you guarantee that problems will be easy to diagnose when development tools that created them are not available, for instance in a Production environment? How will you monitor the client interactions? How will you implement automated failure operations? Are there adequate systems monitoring tools in the market place for your chosen method of client/server exchange?
• How will you secure the client connections? How will you distribute and manage certificates and keys amongst clients and servers?
• If you hit a performance bottleneck on the back-end server, do you have a strategy for scaling the client workload? Can you easily replicate the back-end server instances to handle an increasing load? If you can't scale vertically, do you have a strategy to scale out horizontally? How will you achieve workload balancing with point-to-point client connections?

In addressing these issues you will almost certainly find that you are re-inventing an ESB. You should seriously consider re-architecting your solution so that the clients are clients of the ESB rather than clients of a specific server instance.

If I implement my system with SolutionsWorks' ESB, how can I avoid becoming a victim of vendor "lock-in"?

SolutionsWorks' solution is designed to be as open as possible at every step of the way. By adhering to Java open standards and the JMS you can interact seamlessly with other vendor's adapters and services as long as they communicate using the JMS. Beneath the JMS layer the SolutionsWorks ESB can interact with most popular JMS providers, and by using a JNDI service you can make use of any provider that adheres to the JMS specification.

Past experience has shown us that the most timely and cost effective solution is achieved by making sure in advance that you, the customer, and SolutionsWorks, the provider, will both profit financially from the relationship. Our greatest success stories have been achieved by not trying to generate quick product revenue from "pumping and dumping" software products or by bleeding a client's budget dry with little or no software and extensive "body-shopping" and over-staffing. We take pride in a more old-fashioned long-term approach that relies on exceeding customer expectations today and by maximizing our revenue by generating repeat business tomorrow.

What differentiates SolutionsWorks' ESB from other ESB implementations?

SolutionsWorks has implemented its ESB with a rich set of coarse-grained adapters and full-featured services. You can quickly create services that perform functions such as broadcasting updates on tables within databases, sending e-mails, performing file-transfer with point-in-time recovery, taking HTTP post requests, SOAP requests etc. using stock services provided with the base product. Other vendors have oriented their ESBs towards workflow scenarios that are more analogous to workflow scripting. In our experience, highly granular logic specification (often implemented as a graphical flowchart) in an integration tool suffers all of the pitfalls of the now defunct "Fourth Generation" languages of decades past and virtually no advantage over procedural languages. We encourage the use of industry standard Java code to implement customizable extensions to our product, rather than what are often thinly disguised proprietary scripting languages.

The SolutionsWorks solution is designed to be complete workhorse for integration, with clearly designed strategies for extending and customizing the product without boxing the customer in to a vendor-proprietary solution. For example, automated error handling and reporting are built into the product, along with sophisticated monitoring tools and functions like heartbeats for passive monitoring and situational alerts for system generated exceptions.

We allow you to interact with a messaging provider of your choice and even to swap or bridge messaging systems with ease.

The SolutionsWorks ESB is uniquely flexible, with sophisticate operations, such as completely transferring application containers or services from different environments or between different machines, generally being as simple as a drag-and-drop operation in a centralized graphical console.

Our solution is designed to be usable in all the stages of your project life-cycle - from integrating well into Java program IDEs during Development, to providing test harnesses and performance measurement facilities during Test, and providing robust security and high availability features in Production along with extensive monitoring possibilities and ease of deployment.

If I adopt an ESB approach, am I committing myself to Java?

Yes, you are committing yourself to Java, XML and the JMS. You are also positioning yourself to take advantage of mainstream industry initiatives and open standards.

I have a short deadline, a huge deliverable and a tight budget, can I afford to adopt an ESB for this stage of my project?

You probably can't afford not to. Don't make the mistake of confusing what may be a new way of thinking with additional overhead for your project. BeePlex may turn out to be quite a culture shock for you - and a pleasant one, too. Tasks that you might estimate from experience to be weeks of work may be performed in minutes with BeePlex. With an ESB you have a solid foundation-architecture on which to build. We often say that the litmus test for a good fundamental architecture is that over time tasks become easier, deliverables quicker, and you find that you can leverage your investment to deliver extraordinary results with relative ease.

If you are a veteran in IT, but new to BeePlex, we trust you will find our solution to be a breath of fresh air compared to what you are accustomed to.