Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: 2.0.1
-
Fix Version/s: Product Backlog
-
Component/s: Core: Configuration, Core: Routing / Filters
-
Labels:None
-
User impact:High
-
Similar Issues:None
Description
After reading Jackie's introduction document, it finally dawned on me that we could make it a lot easier for developers to configure message styles. When talking about styles I mean, Synchronous, Asynchronous, Request/Respsonse, Remote synchronous and Async Request/Response.
Right now we control this behaviour with a mix of:
- Properties on the Endpoint i.e. synchronous and remoteSync
- The omission of properties i.e. Async is default
- The presence of other configuration elements such as outbound endpoints (i.e. if a service has a synchronous inbound endpoint and no outbound endpoint, then we use Request/Response style messaing) or async-reply endpoints.
Doing it this way can be very confusing even for seasoned Muleys (sounds like a british pub chain)
I think we could clarify a lot of this by replacing sync properties on the endpoint with a new property 'messagingStyle'. This would be a select list of the styles above. The list would be different for inbound and outbound endpoints. Plus we can apply validation to configurations with good error messages to say when there is a miss-match between messagingStyle on the endpoint and how the service is configured. Behind the scenes we can just set the sync/remote sync properties correctly.
This would require a schema change that would have a big impact on users, but ultimately would make it much easier to understand how to configure Mule messaging styles.
From Dan F.
[Dan F]
We need to think it through in detail though to work out what we do with:
[Ross M]
Agreed.
To enforce the message style rules it would really need to be done at the code level. I guess this could happen as part of Service initialisation, where we can do a series of checks for each messaging style. From the IDE's perspective, it would be pretty hard to validate unless we use something like schematron.
There definitely will be mutex config, and should be able to list a well defined set of rules for each messaging style and how they can be combined.
We may also want to restrict certain messaging styles for some endpoints.
[Dan F]
Things like only allowing certain messaging styles for some transports we can do with the schema, you have to almost redefine the endpoint type in the transport schema but that is very easy with our use of groups. I agree the mutex issues will just have to be resolved in code.
I assume we would want to do this at the message level so a service can have multiple inbound endpoints using different patterns?
Maybe we can throw up a list of the combinations somewhere up on the wiki. There's what you listed + combinations to think about e.g. sync request/response + async outbound.
[Ross M]
This is what I would describe a Async Request/Response
[Dan F]
That term's confusing for me because the request/response piece is sync. The different is that there is an additional async out channel. Anyway we can define terms better from diagrams I think...
I actually put together some diagrams precisely to explain these patterns for the presentation I have the other week, so uploading those will give us a good start.
Cool, put them up on the wiki as a start.
http://mule.mulesource.org/display/MULECDEV/Messaging+Styles
- mutual exclusiveness of things, if there is any
- what happens if messaging style on inbound endpoint and presence/lack-of outbound endpoints and what configured on them somehow conflict.
- what to do with implicit messaging styles imposed by some routers or endpoints e.g. chaining-router and ws-endpoints.
[Ross M] Agreed. To enforce the message style rules it would really need to be done at the code level. I guess this could happen as part of Service initialisation, where we can do a series of checks for each messaging style. From the IDE's perspective, it would be pretty hard to validate unless we use something like schematron. There definitely will be mutex config, and should be able to list a well defined set of rules for each messaging style and how they can be combined. We may also want to restrict certain messaging styles for some endpoints. [Dan F] Things like only allowing certain messaging styles for some transports we can do with the schema, you have to almost redefine the endpoint type in the transport schema but that is very easy with our use of groups. I agree the mutex issues will just have to be resolved in code. I assume we would want to do this at the message level so a service can have multiple inbound endpoints using different patterns? Maybe we can throw up a list of the combinations somewhere up on the wiki. There's what you listed + combinations to think about e.g. sync request/response + async outbound. [Ross M] This is what I would describe a Async Request/Response [Dan F] That term's confusing for me because the request/response piece is sync. The different is that there is an additional async out channel. Anyway we can define terms better from diagrams I think... I actually put together some diagrams precisely to explain these patterns for the presentation I have the other week, so uploading those will give us a good start. Cool, put them up on the wiki as a start. http://mule.mulesource.org/display/MULECDEV/Messaging+Styles