Nice argument!
Unfortunately I don't agree with [1]. "Dynamic" flexible invocation is a part of most Web Services stacks - both Axis1 and even JAX-RPC. The fact that Axis2 doesn't have a single client class that can call a service whatever MEP seems rather limiting. You state [1] as if it were an obvious conclusion. But it doesn't strike me as axiomatic.
Paul
On 11/30/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi Paul,
Paul Fremantle wrote:I think you have misunderstood my statement.On 11/29/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
I think the preferred way is to write a Client extending from MEPClient.
But I don't think it should come in to Axis2.
-- EC
<Axis2 Hat on>
[1]When we write Clients extending from MEPClient, at least for the time being, we limit to support for basic MEPs.
what we have always been telling to the users was that, if you want to have some custom MEPs or if you want to have a combination, you can easily write your own one. One has "enough" support and flexibility within Axis2 to do that.
Let me take your question again. You wanted to write a client, which doesn't know it is invoking an INonly service or a IN-OUT service. So this statement contradicts with my statement [1]. There are lot of combinations you can get wiring some IN pipes and OUT pipes. And at the same time if the client tries to support different combinations of MEPs at the same time, the situation becomes more complicated.
No I don't think this is a valid argument. When you write your own MEPClient extension, this does not anyway breaks the statement "If Synapse sticks to APIs only and not internals, then this won't be a problem."Why don't you think it should come from Axis2? From Synapse POV, I would
like the only APIs I use from Axis2 to be the published APIs of Axis2. At
the moment I am using all sorts of cool stuff from inside Axis2. Which means
when you change it, Synapse will complain. If Synapse sticks to APIs only
and not internals, then this won't be a problem.
You are not going in to internals by writing a custom client.
FYI, I wanted to extend the functionality of IN-OUT mep once, for a test, and I didn't introduce a new MEPClient for that for Axis2. I wrote my custom MEPClient within the test package and used that :-) .
</Axis2 Hat on>
<Synapse Hat on>
I don't see any problem why we can not write our own extension from MEPClient within Synapse. And I don't think that will anyway harm our rules or concepts. Rather that will make the job easier.
</Synapse Hat on>
Paul, may be I'm missing something, or I have got this unneccessarily complicated (if yes, 1000 appologies :-) ). I think its better to only support basic MEPs within Axis2, and not customs MEPs, nor combinations of basic MEPs.
-- Chinthaka
Another way of looking at this - Synapse is a user of Axis2. If a user
really needs this (and in this case is willing to help write it) why
wouldn't you want to support that user?
I don't think this is such an unusual use case that it wouldn't be useful
for other users.
Paul
