Hi Eric
Ah, I was close to remove them. I'm not familiar with those
builder/formatter pairs. When (und which condition and in which order)
are they executed?
As this is a very central place this is a general behaviour for all
service, right?
Yeah.
I should have a more detailed look at this and get back to you...
Cool.
Thanks, I will take care. :-)
Will do so! Thanks for the explanation - now the behaviour is clear.
OK, fine.
Yeah, I think this should solve the problem. But this implies running
this filter on every request, also on SOAP requests were this would make
no sense at all. Maybe this check is not very expensive, but I'm
doubtful whether this would be a good approach or not.
I know there is always a trade-off between generic, very flexible and
more static solutions.
Well, I must say that this check is going to be there anyway, even if we
have enabled the protocol specific sequences. Because in order to pick
the right sequence we will need to do a check :-), but I agree this
filter is going to be a very very little more expensive than that check.
I also thought of storing a kind of "service or protocol type"
information in the registry for other reasons - namely testing.
One other feature I'm missing is a way to check whether my current esb
configuration is valid. I mean not valid in terms of syntactical checks
but valid from a functional view. E.g. did the administrator specify the
right service endpoints? Are hostnames and ports correct? It would be
cool, if one could easily test this on different levels (single
endpoint, all endpoints, single proxy service, all proxy services). In
order to do meaningful testing one would have to generate a proper
request, send it, and present the result. Maybe one could specify the
name of an existing test method of the service. How to incorporate this,
if the esb (registry) does not know, which protocol to use?
Well, to do this do we need to keep the information on protocols in a
central place. If you have a look at WSO2 WSAS, there is a feature
called try it, which gives you a simple UI for any endpoint to test that
(it can be an endpoint external to ESB or an proxy service endpoint
within ESB). But I don't understand why you need to keep the protocol
information in a central place to do this??? Am I missing something or
totally lost? :-(
This is only one example where I think having this information centrally
available would help. Protocol-specific sequences are another example.
This (protocol specific sequences) is a trivial fix, but adds more
complexity to the configuration language, IMHO
Thanks,
Ruwan
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
