SOA internally as well as externally
marklittle Feb 13, 2006 10:13 AMFrom the outset, one of the things I think we need to have in the architecture is the principle of "SOA within the bus as well as outside the bus". So this is the principle of SOA internally to the implementation as well as externally. Some ESBs are fine at allowing you to leverage SOA principles "above" the bus: yes, you can plug in services to the ESB and develop applications based on SOA, but if you want to replace services/capabilities within the ESB implementation itself, then that's a different matter. Often it's either very difficult, or impossible to achive, leading to many companies already having to work with "legacy ESBs"!
Enterprises will always be heterogeneous; legacy systems are here to stay and will continue to grow. The ESB is the best solution to bridge these technologies by leveraging SOA. The best way in which is can accomplish this is to abstract all of the components ? JBossESB will not mandate any implementations because it then becomes part of the legacy problem. Therefore, SOA principles will be used internally to JBossESB as well as externally: everything will be a logical service and at the architectural level interacted with via messages. Everything is a service, including the bus, and all services are interacted with via messages. As such, even though at an implementation level services may reside within containers responsible for lifecycle management (e.g., init/destroy, start/stop, suspend/resume), it will be considered architecturally as though those services were plugged directly into a lifecycle bus and receiving appropriate messages.
JBossESB will be architected so that it should be possible to switch in different core services, such as micro-containers to provide the various capabilities. From an architectural perspective, it shouldn't really matter what implementations comprise the runtime framework. The default, out-of-the-box configuration will be pure JBoss, but this can be customizable. Furthermore, heterogeneity of ESB implementations will be the normal situation. Therefore, the "bus" has got to be able to interoperate with other "buses": think of what we want to achieve as a global, virtual ESB.
JBossESB will provide a basic core ESB framework that allows everything else to be configurable. Plug-in modules/components provide the real meat of the product, but all of them will be swappable by end users. Interdependencies will not be allowed in a hard-coded manner, but should be taken care of within the framework in an abstract (and configurable) manner. At the limit, it should be possible for someone to replace every single component of the ESB.