8 Replies Latest reply on Jul 5, 2010 1:30 PM by Thomas Smith

    How to define remote services that are ESB aware?

    Thomas Smith Newbie

      Ok, perhaps I'm missing something fundamental in the ESB architecture after reading all of the documentation, but I'm trying to do something that should be straightforward.  I (well, my company) control the business logic being configured as services that will be registered with the ESB, as well as the clients that call them.  All business logic servers are deployed in JBoss 5 instances, but not the same instance or machine as the ESB.  They will only get called by our own clients, ever, and we can even coordinate releases.

       

      That should make some of the architecture and configuration questions easy.  But I'm stuck on the basic registration of the services.  How do they get registered with the central ESB registry when they start up or are deployed?  What is the best way to develop them so that it is not necessary to configure the server locations in the ESB service deployment?  I can make the services as "ESB aware" as necessary or desirable.

       

      Thanks,

        Tom

        • 1. Re: How to define remote services that are ESB aware?
          Hans Wolffenbuttel Expert

          Hi Thomas,

           

          Can you give an example of what you might want to do with JBossESB? The services inside JBossESB are registered by catagory and service name. If you look at the quickstarts you will see how to call a service you have defined in jboss-esb.xml by those two parameters. Furthermore you can call the service just as you would call a normal service, that is, if you have exposed them through EBWS or a http-gateway for communication over the HTTP-protocol.

           

          Regards,

           

          Hans

          • 2. Re: How to define remote services that are ESB aware?
            Thomas Smith Newbie

            Certainly.  We are developing application functions as services, which will be consumed by clients that are the applications themselves.  The service endpoints will be distributed across multiple systems, the clients will be distributed across multiple (different) systems, and they can all be made aware of a central ESB location for finding each other.  This seems like precisely what this architecture should facilitate.

             

            Furthermore, since this is all new technology developed on a consistent stack (Java 6, JBoss 5, etc.) that should also open up some implementation options since there are no legacy systems to account for.  Simply passing the ESB-aware messages from the client to the endpoint (and the response message back) is all we need to do.

             

            However, after doing some experiments it seems we have to implement the entire registration mechanism ourselves.  Could this possibly be true?  I cannot find how to deploy a service configuration on the ESB and register an endpoint for that service when the endpoint implementation comes online.  I keep suspecting I'm looking for the wrong vocabulary in the documentation, but here's what I think I know so far:

            • Many of the "out of the box" routers are translators from ESB-aware to unaware technologies, such as webservices.  They require that the service configuration on the ESB know the location of the endpoint and how to translate the message to it.  This tightly couples the ESB service configuration to the endpoint implementation, and is only useful for legacy systems.
            • The EJBProcessor is superficially close, but it expects the service on the ESB to unpack the message, not the service endpoint itself.  It too requires the JNDI location where the EJB is registered.  And astoundingly, the EJB endpoint must be deployed and started before the service configuration is deployed on the ESB, so I can't imagine how this could be used in real life.
            • All of the quickstarts that I have read either illustrate communication with legacy systems or implement the service endpoint in code that is deployed within the service on the ESB itself.

             

            All of which makes me believe that my "routing" problem isn't actually to be solved by a router within an ESB service, but something so simple that it doesn't require a sample quickstart.  Can you straighten me out here?  Thanks.

            • 3. Re: How to define remote services that are ESB aware?
              Mike Finn Newbie

              At the risk of oversimplifying here - it sounds like you are just looking to do request/response within services within the ESB? Have you looked at something like SyncServiceInvoker?

               

              Services register themselves into the registry when they start up, and are available to be looked up by the category and name that you define in the jboss-esb.xml. You get back an EPR to the service, to which the message is sent. You can look them up and invoke them programmatically as well. Also, every service has one or more listeners, and required to have at least non-gateway (ESB aware) listener - so every service is resolvable and invokable within the ESB.

               

              Mike

              • 4. Re: How to define remote services that are ESB aware?
                Thomas Smith Newbie

                Actually, that's exactly the opposite - I'm trying to do a request-response where neither the client and endpoint are within the ESB.  In the real world, wouldn't all clients and service endpoints be implemented someplace other than within the ESB?   If all services were implemented within the ESB itself the whole notion of a "bus" would be unnecessary.

                 

                Regarding SyncServiceInvoker, the way I read the documentation it looked like it was a way to invoke service X from the action chain of service Y.  Curious that there isn't a quickstart sample for it...  But that still leaves the problem of how to register an EPR for a service whose ESB-aware endpoint is deployed someplace outside the ESB.

                • 5. Re: How to define remote services that are ESB aware?
                  Mike Finn Newbie

                  >>

                  Actually, that's exactly the opposite - I'm trying to do a request-response where neither the client and endpoint are within the ESB.  In the real world, wouldn't all clients and service endpoints be implemented someplace other than within the ESB?

                  <<

                   

                  Apologies - I went back and read your initial post again. It sounds like you are building logic that happens to reside in JBoss, but not in the ESB? And, you want that logic to communicate in *ESB* messages? That is not a typical ESB approach. ESB messages are typically for within the ESB, not outside it.

                   

                  >>

                  But that still leaves the problem of how to register an EPR for a service whose ESB-aware endpoint is deployed someplace outside the ESB

                  <<

                   

                  ESB-aware endpoint describes something that resides ON the ESB. I believe the Prog Guide has some clear definition around this. ESB message is a wrapper around your payload, that carries metadata for use by the ESB.

                   

                  This is not to say you *can't* do it, but it won't be something that adds much value. Normally, you would remote those business services over something like SOAP. ESB would then consume them using their "native" message, and expose a single logical service that is served by one or more business services and relevant rules and other logic.

                   

                  HTH,

                  Mike

                  • 6. Re: How to define remote services that are ESB aware?
                    Thomas Smith Newbie

                    Ok, I appreciate the help with the vocabulary.  The criteria of loose data binding between the client and the server applies all the way through to the endpoint.  It wasn't clear if this was done by having the endpoint know about ESB messages, or by simply passing the message body through to the endpoint.  However, I wasn't sure I was on the right track because again all of the illustrations of this flow appear to be geared to exposing existing service endpoints to ESB clients, not creating new ones.

                     

                    I did suspect I was using the term "ESB aware" in the incorrect way.  However, if that's not the term then what would I use for a service endpoint that knows it will only ever be called through the ESB, because it being written right now?  Or is this something that nobody actually does?

                    • 7. Re: How to define remote services that are ESB aware?
                      Hans Wolffenbuttel Expert

                      Hi Thomas,

                       

                      The fact that a service is only called from the ESB is just an architectical issue, not a technical one. If you want to ensure that calls are only availible through ESB you might want to implement SSL or some other validation of your sender application. Again ESB aware means your message is send from within the ESB and is wrapped in the JBossMessage format.  The wrapping of your message is done by gateways which can handle various types of input.

                       

                      Keep in mind that a bus always needs to know the service it has to send its messages to.So you need to register your endpoints outside the ESB within the ESB. This can be done by defining a proxy or a direct routing.

                       

                      Regards,

                       

                      Hans

                      • 8. Re: How to define remote services that are ESB aware?
                        Thomas Smith Newbie

                        I understand the registration need - What surprised me was that this simple registration mechanism wasn't part of the provided package.  I thought I might just simply be looking in the wrong place or for the wrong words.  It is now clear from the helpful replies that the JBoss ESB implementation is designed to tie legacy service endpoints into a common framework, rather than to facilitate new client/service development in a coherent distrbuted architecture.

                         

                        Therefore we will define a simple internal registry convention for our endpoints to register themselves as service providers with the bus, which they can do because they know there is a bus.  Then we will write an ESB action that looks in the registry for endpoints that have registered themselves with the bus, and route to them.  Oh well.