13 Replies Latest reply on Feb 17, 2006 5:17 AM by marklittle

    SOA internally as well as externally

    marklittle

      From 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.

        • 1. Re: SOA internally as well as externally
          tom.baeyens

          afaik, the microcontainer should give us the pluggability of services. that would imply that the microcontainer itself is not pluggable. do you see a reason to make the microcontainer itself as pluggable ?

          indeed services should be pluggable. but the main question will be what services are used by the esb implementation and what swappable plugins do we forsee. that can only come from making the requirements explicit.

          regards, tom.

          • 2. Re: SOA internally as well as externally
            marklittle

            Tom, even the microcontainer should be replaceable. There are vendors and users who may well have their own containers, so we need to be able to support those. Of course that could be done by embedding our microcontainer in theirs, but ultimately we may have to allow for the whole thing to be replaced.

            However, at this point (and specifically concerned with this item), we're talking architecturally: the container is an implementation detail.

            Also, I haven't finished adding issues, so hopefully more of your questions will be answered soon.

            Cheers,

            Mark.

            • 3. Re: SOA internally as well as externally

               

              "mark.little@jboss.com" wrote:
              Tom, even the microcontainer should be replaceable.


              Absolutely. The microcontainer is about configuring, managing and enhancing POJOs
              without writing anything into the POJOs that knows about this.
              (Except maybe some annotations for ease of development - which will be ignored
              in other containers.)

              So we compete with those other vendors on what we are able to add to people's beans!

              This is the fundamental rule. Stick to your core competency and let the "container"
              handle the middleware, config, management, etc.

              • 4. Re: SOA internally as well as externally
                marklittle

                Agreed. Out-of-the-box, the idea is to have 100% pure JBoss in the ESB (as much as possible, because some things, like UDDI support, we just don't have native). Then let users, vendors etc. customise it to their heart's content if they think they have a better service implementation. Gives us a great best-of-breed story, plus it should help to energize the community: don't see us as a competitor, but as the glue. SOA is all about leveraging existing infrastructural investments, and if the ESB practices that internally as well as externally, then we don't become part of the legacy problem that other ESBs already are.

                Mark.

                • 5. Re: SOA internally as well as externally
                  marklittle

                  This may help some of the discussion.

                  • 6. Re: SOA internally as well as externally
                    starksm64

                    So what is the bootstrap of the esb kernel API? There seems to be a circular situation here with respect to the kernel of the esb. I don't see using the jboss microcontainer as the base implementation as limiting anything. If I want to use an alternate services model (spring, osgi, jbi) I just provide a pojo deployment that supports that model.

                    • 7. Re: SOA internally as well as externally
                      marklittle

                      I did say that the JBoss Microcontainer could be embedded in other containers if vendors/users want to manage services in their own container technologies. However, I certainly can't project that this will satisfy everyone at this stage, either technically or politically. I can't see a good reason to not support this at this stage within the architecture: fairly obviously as we progress things it may become apparent that this much flexibility is too much and causes complications elsewhere, but I'd rather cross that bridge when/if we come to it.

                      • 8. Re: SOA internally as well as externally
                        starksm64

                        What I'm looking for is the defining core API/bootstrap process for the JBossESB vs JBossAS where the microcontainer certainly is the core.

                        • 9. Re: SOA internally as well as externally
                          marklittle

                          So maybe this hasn't come across explicitly in all of the stuff I've posted so far, but the default out-of-the-box JBossESB will be 100% pure JBoss (with the caveat that some of the things we'll need, such as transformations and registry, aren't available in-house at the moment). That's obviously the implementation part of the equation, which is as important as the architectural part of the equation - the result obviously being the end product! But since the intention has to be that JBoss-through-and-through is what you get by downloading JBossESB from us, then how we map the architecture and its requirements into concrete implementation should be tailored to closely fit with our requirements.

                          Don't get me wrong: I'm not saying the architecture needs to be tied to JBoss components, but it doesn't make sense for us to make it more difficult for our stuff to fit into our own product! It does make sense to allow components to be replaced by others (best-of-breed, community involvement etc.) and we should encourage that and ensure we don't put up any roadblocks to prevent it. However, that's the domain of others to work on (and hopefully submit back to the community).

                          So back to this case in point: if the API/bootstrap process of MC is suitably powerful enough, then we've always thought that would be the route to take in the ESB too. I think we're all agreed that every service, whether it's a real service (e.g., registry) or a conceptual service (e.g., the container) should be abstracted through *appropriate* interfaces. The definition of *appropriate* in this context isn't to start from scratch; if there's already something there that is suitable, let's use that. We're doing the same with the addressing by leveraging WS-Addressing, for example.

                          Mark.

                          • 10. Re: SOA internally as well as externally
                            starksm64

                            Ok, I'm following now and agree. In terms of the bootstrap/API in the esb, I was not sure if there were additional specs down to this level that would say define how to instantiate an esb instance using a web service management request from an admin console that required a non-jboss or at least pluggable bootstrap process. I'm just trying to draw a box around the abstractness of the esb to something less abstract than "a diffeomorphic Hilbert space" Adrian might propose.

                            • 11. Re: SOA internally as well as externally
                              marklittle

                              If you ever see a Hilbert class in the code, kick me or Kevin! ;-)

                              Mark.

                              • 12. Re: SOA internally as well as externally
                                gavin.king

                                100% agree with Scott.

                                I don't see why mc would not be the kernel. Why reinvent?

                                mc itself is the thing that "containers" can plug into (eg. the EJB container).

                                • 13. Re: SOA internally as well as externally
                                  marklittle

                                  I don't think we're in disagreement. Take a look at the whole discussion first.

                                  Mark.