Paul
I am going to start commiting changes on these proposals and endpoints
etc, and so will a few others. I thought that it would be good to keep
the current code in a branch until we get to a stable point back again
while making these changes on the trunk. Do you think we should do a
0.92 with what we have today - NIO SSL and bug fixes being the changes?
thanks
asankha
Paul Fremantle wrote:
Apologies for the long post.
Sanjiva, Asankha and I have been reviewing some items, and one of the
things we came up with was this scenario:
I start out with a proxy, targeted to an endpoint. Then I want to add
some mediators to the flow. At the moment, I have to change the proxy
to target an insequence/outsequence, which now uses <send><endpoint
ref=""></send>.
It seems more logical that targeting the
endpoint/insequence/outsequence should be additive. In other words I
should be able to leave the proxy targeted to the endpoint, and then
specify an insequence. In this case the insequence should run, AND
then the target should be used.
So what happens if I have a <send> in my insequence? Hold on, I'll get
to that in a minute.
I also would like to make it optional to specify an outsequence. I
can't remember if we need both at the moment, but I don't think we
should require both.
It would also be really nice to be able to inline the
insequence/outsequence definitions rather than just refer to them.
Same goes for the endpoint.
Here is a pseudo definition of the proxy, with those improvements.
<proxy name="string" [transports="(http |https |jms )+|all"]>
<description>..</description>
<target [inSequence="name"] [outSequence="name"]
[faultSequence="name"] [endpoint="name"]/>?
<endpoint>...</endpoint>
<in-sequence>...</inSequence>
<out-sequence>...</outSequence>
<fault-sequence>...</faultSequence>
</target>
<publish-wsdl uri=".." key="string">
<wsdl:definition>...</wsdl:definition>?
<wsdl20:description>...</wsdl20:description>?
</publish-wsdl>?
<policy key="string">
// optional service parameters
<parameter name="string">
text | xml
</parameter>
</proxy>
In this you can either use references to endpoints/sequences, or
inline them inside the <proxy>. I also added faultSequence to be
complete.
We discussed changing the WSDL tagname to publish-wsdl just to be a
big clearer about what this is (its not the endpoint wsdl). We also
discussed doing the same for this tag - letting you inline the wsdl if
you want to. I know it will create an enormous synapse.xml but that's
the user's choice!
So now back to send. We had a lot of discussion ages ago about
changing send and making it more logical, but I don't think we
implemented it.
Based on this idea, it seems like <send/> shouldn't end the sequence.
If the user has a sequence with <send/> and a target endpoint, then we
should send out two messages. After all, this may be a one-way
scenario. What if there are two replies. My preference would just be
to send back the first reply, and log the fact that we dropped the
second reply. If the user wants to do something more clever, they can
figure out a sequence to handle the responses and drop the right one.
Thoughts?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
