Definition of type of transformation service

[marklittle]

We seem to have agreed here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81237 on an interface for the transformation service. However, when I first started that discussion I mentioned two interfaces: the actual service one (which we've discussed) and the one users see. This second interface is more of a wrapper for looking up the service and doing the work.

Ignoring that interface for now (it's just a helper class after all), the question becomes: how do we identify the type of transformation(s) that a particular service offers?

[tfennelly]

So, this is about how the "Transformation Dispatcher" makes its decision on which TransformationService implementation it should route a Message to for transformation?

Question:
1. Does this need to be done dynamically based on the message content?
2. Could it be part of the contract definition from the registry?

[marklittle]

I think it can be best summarised as: how can something determine which transformation service to use. We don't need to worry about what the "something" is at this stage, or how the information is conveyed (yes, I think it will be obtained from the registry).

[tfennelly]

This is the sort of image I have in my head (some semi-random thoughts) ...

1. Client queries reg for the ServiceX contract def...
2. ServiceX dispatcher config is constructed appropriately as outlined in contract...
3. Stub constructs dispatch Message and it's sent down the dispatcher chain...
4. Message reaches TransformationDispatcher...
5. TransformationDispatcher queries the service contract def (from 1 above) to find out the name (URN?) of the TransformationService impl it needs to use + perhaps the address of the reg from which it's contract def should be loaded...
6. TransformationDispatcher initiates (somehow) the construction of the TransformationService dispatcher config and pushes the message down this dispacther chain...
7. It reaches the TransformationService impl...
8. The TransformationService impl decides which transformation needs to be performed on the message based on the message content (EPR, whatever).

[tfennelly]

Obviously there's a step between 5 and 6 there - TransformationDispatcher queries reg for TransformationService contract def

Also, I didn't bother to go to 9+ but I think these are obvious enough... service transforms message, transformed message comes back up the stack and is routed on to ServiceX etc

[marklittle]

Sure, but as the deployer of the service in your example, how did I know which transformation service to put in my contract for the client?

[daniel.brum]

Mark, are you thinking that the transformation service could be used as an independent service, but somehow a client would have access to it through the ESB?

Why would a client not be able to directly converse with the transformation service, without any interaction with an ESB?

When we designed ours, our standalone XLST service could be called, and in fact was called in exactly the same way weather it was through the ESB or standalone outside of the context of an ESB event.

Are you thinking of listing the transformation service in a registry of sorts inside the ESB to let clients know "what" transformation services are available? Would this registry lookup not best be available in such a way that it could also be used without any ESB interaction whatssoever? I.E: A client of some sort, needs some transformation, but is not interested in publishing anything through the ESB. Is this scenario supported in your design?

[marklittle]

Mark, are you thinking that the transformation service could be used as an independent service, but somehow a client would have access to it through the ESB?

Why would a client not be able to directly converse with the transformation service, without any interaction with an ESB?

When we designed ours, our standalone XLST service could be called, and in fact was called in exactly the same way weather it was through the ESB or standalone outside of the context of an ESB event.

Are you thinking of listing the transformation service in a registry of sorts inside the ESB to let clients know "what" transformation services are available? Would this registry lookup not best be available in such a way that it could also be used without any ESB interaction whatssoever? I.E: A client of some sort, needs some transformation, but is not interested in publishing anything through the ESB. Is this scenario supported in your design?

Daniel, if you check out http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81237 it may help. Everything in the architecture is a service: no exceptions. So the short answer to your question is: yes. The longer answer is: yes, but loop-back/local/colocation optimisations are always possible. However, initially we should be considering this as a separate service (or services). Even with colocation optimisations enabled, the transformation service will still look like a service as far as client/service(!) are concerned.

[marklittle]

I should have said: the answer to your first question is ...

Obviously you asked a few other questions, but hopefully they got covered too. ;-)

[daniel.brum]

Ok thanks.

For some reason when I click on that link it doesn't work, it takes me to a Server Not Responding. I am on a flaky link at the hotel in Barcelona and a lot of pages that normally work will not work, even within the same server.

[marklittle]

The link definitely works: I just tried it again. Probably your flaky network ;-)

[daniel.brum]

Mark, what WS-* standards exactly did you have in mind for initial support? What are required, and what are the use-cases for them? I am not knowledgeable enough in WS-* and how they should be used, so your input would go a long way towards clearing up some ideas I have right now. I know you're involved and have done a lot of work with WS-* support.

thanks!

[marklittle]

There are two levels of dependency as far as I can see: (i) what we need to run, independetly of the user/services, and (ii) what users/services require.

Number (ii) really depends upon deployment requirements. For example, if a user or service needs transactions or security and they go for a pure Web Services deployment, then we'd need to provide WS-TX or WS-SX support. Hopefully by the time we come to need that stuff we'll have JBossWS integration out-of-the-box. If someone wants to use something other than JBossWS then that'll be possible too, but then they'd need to make sure it has the requisite support.

Number (i) is easier. All we need to run at the moment is something *based on* WS-Addressing, which we use for endpoint reference identification and something *based on* WS-Context, which we'll use for context association and manipulation. However, our use of either of these doesn't mandate Web Services: we'll use them in isolation.

Hope this helps.

[tfennelly]

Sure, but as the deployer of the service in your example, how did I know which transformation service to put in my contract for the client?

Hmmm... tricky alright. Will the contracts be statically defined?

Would it be possible to dynamically insert contract details re transformation at the time the contract is being requested i.e. based on the dialects the client and services use - if different, look in the reg for a transformation service that can do the translation.

So, if something like this was possible it would mean service definitions would need to be decorated with capability type info. In the case of the clients target service, that might be the dialect it *speaks*. In the case of transformation services, they might be decorated with details re the translations they can perform.

So, the deployer of the service wouldn't specify anything about transformations that need to be performed. She/he would just decorate the service definition dialect details and leave the reg to insert the transformation details when the contract is being requested by the client. Of course this all means the clients dialect needs to be identified somehow.

Mark, I'm sorry I didn't get a chance to read the WS standards yet. I'm sure they are crucial to this topic - especially the addressing and context ones.

[marklittle]

"tfennelly" wrote:

Sure, but as the deployer of the service in your example, how did I know which transformation service to put in my contract for the client?

Hmmm... tricky alright. Will the contracts be statically defined?

Would it be possible to dynamically insert contract details re transformation at the time the contract is being requested i.e. based on the dialects the client and services use - if different, look in the reg for a transformation service that can do the translation.

So I wasn't expecting that all services would have to define a way to do transformation in their contract definitions. If no such information exists, then the user (or something in the service invocation path) is going to have to figure out how to transform from type A to type B. In order to do this it'll need to know that messages are in different types (should be fairly straightforward with suitable message schemas) and then be able to locate a suitable transformation service.

I thought that lookup could occur in a number of ways. For a start, each transformation service could publish itself in the registry under some Transformation Service heading allowing users to scan the list (like yellow pages entries). Another heading could be on the specific transformation service type, e.g., Type A-to-B, which would list all of the services that can transform from A to B.

So, if something like this was possible it would mean service definitions would need to be decorated with capability type info. In the case of the clients target service, that might be the dialect it *speaks*. In the case of transformation services, they might be decorated with details re the translations they can perform.

Yes, that's pretty much what I was after: how do we define the types of transformation that a service can perform?

So, the deployer of the service wouldn't specify anything about transformations that need to be performed.

Kind of. As I said, the service deployer doesn't have to augment the service contract with a reference to the transformation service. But he/she could and there may be good reasons to do so (e.g., optimised lookup, trusted party status, etc.)

However, I think that's a topic for a separate discussion item. What we need (and what this started out as) is a way of defining the types of transformations that are possible. It's a secondary issue as to how the information is obtained IMO.

She/he would just decorate the service definition dialect details and leave the reg to insert the transformation details when the contract is being requested by the client. Of course this all means the clients dialect needs to be identified somehow.

Mark, I'm sorry I didn't get a chance to read the WS standards yet. I'm sure they are crucial to this topic - especially the addressing and context ones.

No problem. None of them touch this stuff anyway :-)