-
15. Re: Transformation service interface
marklittle Apr 28, 2006 6:57 AM (in response to marklittle)
I think messageSource == wsa:From, but I don't think the message necessarily
needs to know where it is going, the esb routes it based on the header informstion
and the esb configuration.
In order to ensure JBossESB is a SOA infrastructure at heart, we need to guarantee that there are no hard-dependencies between clients and services (or services and services). The WS-A approach (combined with something like WS-Context) is good for that. This means that if there is a wsa:ReplyTo on the incoming message, this will be used for routing any replies (faults can be routed separately via wsa:FaultTo). Any intermediate node as a message flows may write/rewrite parts of the header (e.g., based on application information that may be known only within a specific service), but all of the necessary routing information for one hop to another is encoded (explicitly or implicitly) within the message header. -
16. Re: Transformation service interface
marklittle Apr 28, 2006 7:01 AM (in response to marklittle)Hit submit too early!
So if there's a wsa:ReplyTo present on the message, that should be used to route the transformed message: which could be to another transformation service if we need a pipeline. If there's no wsa:ReplyTo then we either a) use the default rules within WS-A (depends on other aspects of WS-A elements) or the transformation service may use some application intelligence (e.g., based on what's in the message or, I suppose, the input parameters) to route the transformed message. -
17. Re: Transformation service interface
arvinder Apr 28, 2006 9:08 AM (in response to marklittle)Ok, maybe a small prototype will make things clearer w.r.t. the message flow/routing and its interaction with services.
-
18. Re: Transformation service interface
marklittle Apr 28, 2006 9:14 AM (in response to marklittle)Once the WS-A implementation is in place, we'll be able to illustrate. But I'd definitely recommend checking out the WS-A specification and something that uses it (e.g., WS-TX): take a look at the on-the-wire message, because that's what I'm discussing. How that message is formed (as it flows from the client code, down through the dispatchers to the various plugins) is obviously important too, and I wonder if that's where some of the confusion is arising.
-
19. Re: Transformation service interface
arvinder Apr 28, 2006 9:58 AM (in response to marklittle)I still need to read up on the WS-* references you posted earlier. Time time where is the time!
-
20. Re: Transformation service interface
marklittle Apr 28, 2006 10:14 AM (in response to marklittle)Yeah, tell me about it! I could use a 10 day week at the moment!!
-
21. Re: Transformation service interface
tfennelly May 2, 2006 6:46 AM (in response to marklittle)Sorry about the delay in contributing to this. I was offline for a few days.
OK, I'm a bit confused as to where exactly we're trying to get to on this. So, I drew up a simple interaction diagram in an attempt to illustrate my current understanding. I read the requirements doc but it's clear to me that I need to find time to read the WS Addressing, Catalog etc specs.
[img]http://milyn.org/images/jbossesb-transsd.jpg[/img]
From what I can see after reading your posts, the requirements doc and SVN code, the transformation services/processors could simply receive the esb Message and get whatever it needs from that (from the EPR etc). Does this help any?[/img] -
22. Re: Transformation service interface
tfennelly May 2, 2006 6:53 AM (in response to marklittle)Sorry about the image :-(
-
23. Re: Transformation service interface
arvinder May 2, 2006 7:01 AM (in response to marklittle)Hi, is the TransformationDispatcher just a service facade for the actual service impl no matter where it is located? Or maybe should this come from the service registry? I am not sure whether the service would come into play before a dispatch or after it, perhaps mark can comment ?
-
24. Re: Transformation service interface
tfennelly May 2, 2006 7:42 AM (in response to marklittle)is the TransformationDispatcher just a service facade for the actual service impl no matter where it is located?
To be honest, I haven't really been thinking about the routing aspects at all. Was thinking of that as a separate issue which will take care of itself. I've been thinking primarily about the interfaces.I am not sure whether the service would come into play before a dispatch or after it
Me too! For me, the line between Dispatcher and Service is fairly blurred at the moment. Is a Service a Dispatcher implementation too - just the last one? -
25. Re: Transformation service interface
arvinder May 2, 2006 7:57 AM (in response to marklittle)Me too! For me, the line between Dispatcher and Service is fairly blurred at the moment. Is a Service a Dispatcher implementation too - just the last one?
IMHO, I think we can consider the Dispatcher to be a service aswell, (mark?), this stems from an earlier discussion where mark abstracted this in part see
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81502
You could say a dispatcher simply gets a message from A to B, so a further abstraction is that the dispatcher could be classed as p2p or pub/sub dispatcher, but this may be getting offtopic here, better to let mark comment on whether the Dispatcher can be considered as a Service. -
26. Re: Transformation service interface
arvinder May 2, 2006 8:00 AM (in response to marklittle)I forgot to add, if you want, why not add your thoughts on the wiki starting from here http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossESB
That way, we can build upon some initial design and define te interface etc, together with the forums? -
27. Re: Transformation service interface
marklittle May 3, 2006 3:27 AM (in response to marklittle)Was offline yesterday presenting a talk at Manchester University. Anyway, in the architecture document, the dispatchers aren't the service: they're (typically) the things that augment the message as it flows from the client to the network/messaging infrastructure (e.g., add the transaction or security context), and strip off information from the message as it flows from the messaging infrastructure up to the service.
Now of course en-route to the messaging infrastructure, a message may undergo a transformation, but I see that as a service invocation too. Here's an example (in text): if I get a chance I'll produce a diagram later. Note, this is not the only way in which transformations would work in the ESB, but it is simple enough to illustrate the difference between services and dispatchers in this example.
Suppose a client C wants to talk to a service S and the client doesn't natively support the message format that S does (C supports formatA and S supports formatS). When S was looked up (via the registry), information about the message format would have been included in the contract definition. Also included in this definition (or via a separate lookup to the registry) would be an EPR for a transformation service (T) that can take message vocabulary formatA and transform it to formatB.
Now one way the client could then talk to S would be for it to explicitly call T, giving it the message in formatA and getting back a message in formatB, which is then sends to S.
The other way would be for C to make its call directly on S, but the dispatcher hierarchy that has been set up for C for this to happen now includes a transformation dispatcher (maybe as the very last thing that gets called prior to the messaging infrastructure, if we want to transform the context information, such as transactions or security, as well as the payload) which knows about T. This dispatcher makes an invocation on T (acting as a client, so it will have an T-specific dispatcher hierarchy and potentially use a completely different messaging infrastructure to make the call - colocation optimisations come much later) and when it gets back the transformed message, it then completes the client's invocation on S by calling down to the messaging infrastructure. -
28. Re: Transformation service interface
tfennelly May 3, 2006 6:47 AM (in response to marklittle)OK, I think the flow is starting to become a bit clearer to me now (I hope) :-) I updated the http://milyn.org/images/jbossesb-transsd.jpg with my current understanding. Is this any more accurate Mark?
Questions from the sequence diagram:
1. Is the MOMDispatcher sequence between the transformation dispatcher and service required??
2. Can the contract definition cope with this or will it require some form of contract definition hierarchy, one for the contract between the transformation dispacther and transformation service nested inside a second contract defintion for the higher level contract between client c and service s? This would seem nuts!
So, from this, do we still need a "special interface" for transfomation services? I still can't see why we would!! -
29. Re: Transformation service interface
tfennelly May 3, 2006 6:56 AM (in response to marklittle)OK, I'm slowly learning that all the BB features are turned off here!! Grrrr!!