1 Reply Latest reply on Nov 7, 2012 12:28 PM by tcunning

    Best practice for service chaining and message structure

    dee0ne

      Dear JBossESB community,

       

      I'm a bit lost with the offered flexibility that JBossESB (especially the message) provides me. I need some best practice from more experienced users of JBossESB.

      There are several areas around service-chaining that I'm interested in.

       

      Let's imagine that I have 3 different ESB services (with different services inside the esb), called A, B and C.

      Service A and B are exposing a webservice similar to the native_client quickstart, service C is a common service used by A and B.

      All the services are using the InVM transport without explicit providers/listeners.

       

      I have 2 different choices to chain service A->C and B->C:

      1) using routers to forward the message to service C

      2) use the serviceInvoker inside an action of service A and B

       

      I prefer option 1 as it feels more natural to forward the message and it's not hiding this service call inside the action class.

       

      Now the first question arised on how service C does find it's relevant data inside the message.

      As the primary target of service A and B is to apply policies and enrich the original message from SOAP, it feels natural to have the incoming SOAP/XML message inside the DEFAULT_LOCATION and put other information inside named objects.

      Inside the Programmers Guide I've found that it is possible to store the service contract inside the UDDI, but I have no clue how to make use of it and how it should look like.

      When I studied the "Flight Reservation Service" I've seen that all the relevant data was put inside the message as simple key/value pairs, this is sufficient for simple data, but what if the data is more complex?

      I could make use of a "shared" object holding a complex structure that service C is returning (or forwarding), but I feel like this will be not so loose coupled (as I'm exposing implementation details of service C to service A|B). But for now it makes it much easier to hold the data inside objects.

      This brings me to the next question about "shared objects", where do I keep them if both service A|B and service C need to know it?

      a) Making service A depending on service C (using deployment.xml) and keep it inside the lib folder of service C?

      b) Put it inside a jar and put it into the server lib folder?

      c) Assemble another .esb archive containing only shared objects and make the other services dependent on it (similar a)?

       

      The same question is also arising when it comes to utility classes/services that more or less all services make use of. Where to put them?

       

      If I would have many service chained together and every service is adding some objects to the message, I will end up in a huge message containing information that was only relevant in-between. Shall I remove some objects from the message (housekeeping) at a certain point in the chain?

       

      In order to make the long story short, here are all the relevant questions from the text:

      * service chaining (inter-service contracts?)

      * inter-service routing vs. implicit serviceInvoker inside action?

      * service dependency (deployment.xml)

      * shared objects != loose coupled (where to keep them?)

      * message "pollution" from action chain "message enrichment"

      * utility services (where to put them? .esb archive and make other esb services archives dependent on this?)

       

      I'm very sorry that I have to ask all of this questions, but I tried hard to read all documentation, the user and developer forum, but I still have no simple answers to those questions.

      Any help is really appreciated.

       

      Best regards,

      D

        • 1. Re: Best practice for service chaining and message structure
          tcunning

          Hi Dee,

           

          Is there a reason that you don't have all three services within the same ESB archive?    Are they functionally different?    From what you are describing with the chaining it sounds like maybe they shoulde be in the same archive, and you'd avoid a ton of issues with dependency and shared objects, and possibly with utility service dependency as well.

           

          --Tom