[tfennelly]

"tfennelly" wrote:
So if the message was (for example) delivered via the file router, can this be used to validate the message?

In the sense that any router forwards to a subsequent service and that service would then be responsible for validation, yes.

That's what I meant... cool :)

"tfennelly" wrote:
Support for multiple schemas?

It only allows you to specify a single request schema, if that is what you are asking The schema is supposed to represent the contract of the service so the service is free to define alternatives within that schema if necessary.

If, however, you are asking whether a single service can support multiple, distinct, contracts then this is not possible with the current code. You would need to have the distinct contracts handled by distinct services.

I was thinking of a single message that could contained data from multiple namespaces.

[kconner]

"tfennelly" wrote:
I was thinking of a single message that could contained data from multiple namespaces.

That is a good question. I suspect that the schema import capability, especially with respect to the validation and WSDL generation, may not be supported in the current codebase.

We should be able to handle this though, should we include it for 4.5?

[kconner]

I have created https://jira.jboss.org/jira/browse/JBESB-2217 so that we can investigate the support of schema imports.

[tfennelly]

Yeah I doubt that an would do the trick, but it's worth a try. Someone will need this sooner or later and even if did work, it's not very user friendly... I think it would be nice to be able to define multiple schemas on the service config.

[tfennelly]

Opps... it didn't escape angle brackets... should have been...

Yeah I doubt that an [import] would do the trick, but it's worth a try. Someone will need this sooner or later and even if [import] did work, it's not very user friendly... I think it would be nice to be able to define multiple schemas on the service config.

[kconner]

Defining multiple schemas for the service will have a knock on for the WSDL/WS endpoint generation (as well as validation) as the service is expected to have a single contract.

Multiple contracts (schemas) are really distinct services, and can certainly be implemented in that fashion as things currently stand.

What benefit do you see in supporting multiple contracts for a single service, rather than using multiple services? Perhaps I am missing something here.

[tfennelly]

Well one use case might be... where the ESB is being used to proxy a message to an external endpoint (perhaps do some content based routing etc), and as part of this the ESB provides validation services for the messages before routing to the target endpoint. If these messages can potentially contain data from multiple namespaces (for whatever reason - it can happen), then you'd need to be able to specify the schemas for these namespaces, right?

[r1c]

So schema validation is available in trunk and will be available in the 4.5 release - is this still scheduled for February?

Is it possible to specify only the schema for the request to only validate the request?

"tfennelly" wrote:
If these messages can potentially contain data from multiple namespaces ... then you'd need to be able to specify the schemas for these namespaces

Or create a new schema importing the existing schema documents would allow you to enter a single schema to validate against. Am I right in believing that this currently is not supported?

[kconner]

"tfennelly" wrote:
Well one use case might be... where the ESB is being used to proxy a message to an external endpoint (perhaps do some content based routing etc), and as part of this the ESB provides validation services for the messages before routing to the target endpoint.

So these are schemas that you know in advance? That are therefore distinct services that you are wishing, for whatever reason, to coalesce into a single service?

Or are these schemas something that are determined by the dynamic nature of the proxy you are configuring?

"tfennelly" wrote:
If these messages can potentially contain data from multiple namespaces (for whatever reason - it can happen), then you'd need to be able to specify the schemas for these namespaces, right?

I don't think the misunderstanding is arising due to the namespaces, but rather whether these should be a single service or distinct ones. Would this be a fair comment?

I am not being deliberately stupid, I promise, I am just trying to understand where you are coming from :)

[kconner]

"r1c" wrote:
So schema validation is available in trunk and will be available in the 4.5 release - is this still scheduled for February?

It is, yes.

"r1c" wrote:
Is it possible to specify only the schema for the request to only validate the request?

yes

"r1c" wrote:
Or create a new schema importing the existing schema documents would allow you to enter a single schema to validate against. Am I right in believing that this currently is not supported?

This is certainly the approach we have taken so far, a single schema defining a single contract, but I do not believe the ability to import schemas exists in the current codebase.

[tfennelly]

"tfennelly" wrote:
Well one use case might be... where the ESB is being used to proxy a message to an external endpoint (perhaps do some content based routing etc), and as part of this the ESB provides validation services for the messages before routing to the target endpoint.

So these are schemas that you know in advance? That are therefore distinct services that you are wishing, for whatever reason, to coalesce into a single service?

Or are these schemas something that are determined by the dynamic nature of the proxy you are configuring?

"tfennelly" wrote:
If these messages can potentially contain data from multiple namespaces (for whatever reason - it can happen), then you'd need to be able to specify the schemas for these namespaces, right?

I don't think the misunderstanding is arising due to the namespaces, but rather whether these should be a single service or distinct ones. Would this be a fair comment?

I am not being deliberately stupid, I promise, I am just trying to understand where you are coming from :)

I'm sure there are loads of examples, but in this case I was thinking that the "Service" (consumer of the message) is not on the ESB at all... the ESB is just being used as plumbing between 2 endpoints, providing CBR, transformation etc etc and potentially validation. So you have no control over the endpoint that actually consumes this message (i.e. the "service" in my mind) and it's not running on the ESB. The message this non-ESB service consumes can potentially contain data from multiple namespaces (not defined in a single top level schema), so if the ESB is going to be able to provide the validation services for this use case, in my mind it would need to be able to somehow support specification of multiple namespaces. I don't think the import would work, but even if it did, it's a bit ugly IMO.

[kconner]

"tfennelly" wrote:
I'm sure there are loads of examples, but in this case I was thinking that the "Service" (consumer of the message) is not on the ESB at all... the ESB is just being used as plumbing between 2 endpoints, providing CBR, transformation etc etc and potentially validation.

It doesn't really make any difference whether the end service is on the ESB or not as it can still be exposed through an ESB service with an appropriate contract. So the validation can still take place but perhaps not where you are currently expecting it to. If there is a known schema then there is a defined contract.

If, on the other hand, the ESB is just being used as plumbing and is unaware of the correct format of the message then it should be up to the end service to perform any necessary validation. In fact the end service should be doing this regardless.

"tfennelly" wrote:
So you have no control over the endpoint that actually consumes this message (i.e. the "service" in my mind) and it's not running on the ESB. The message this non-ESB service consumes can potentially contain data from multiple namespaces (not defined in a single top level schema), so if the ESB is going to be able to provide the validation services for this use case, in my mind it would need to be able to somehow support specification of multiple namespaces. I don't think the import would work, but even if it did, it's a bit ugly IMO.

Control over the endpoint would not be necessary as it is the schema being enforced that would dictates the contract.

I guess I am still missing your point, sorry about this.

Perhaps we should discuss it further over a few pints during the f2f :)

[tfennelly]

Well one of is definitely not getting something lol... Let's do it at the f2f

[r1c]

Well I've got everything I need from this thread.

Thank you both.

[tfennelly]

"r1c" wrote:
Well I've got everything I need from this thread.

Thank you both.

Translates to... "Would you two gimps shut the ***k up..." lol

Ah come one.... lets flog this one a bit more ;)