+1 we simply 'mark' a mustunderstand header as already 'processed' to
Axis2, so that our MessageReceiver gets hold of the actual message.
Saminda Abeyruwan wrote:
Hi Devs,
Axis2 folks have proposed the following solution.
Synapse ships as a .MAR. So it has the control of the first Axis2
chain. So having a Handler in the last phase of this chain to get
mustunderstand header and set it as processed, would make all messages
to pass to SynapseMessageReceiver. This would be hold for the Gateway
model as well.
Your consensus on this would greatly appreciated.
Thank you
Saminda
On 7/13/06, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:
I Agreed with you.
As Paul proposed while back, QOS like RM/Sec handles in a mediator.
An AxisEngine is newed in this mediator and pass all messages to
it.
Synapse execution happens in a MessageReceiver, which is the end of
Axis2 execution chain. In order to get messages to this MR, according
to the current AxisEngine#receive(), this message should pass the must
understand check of the first chain. In this context, if a message
comes with must understand would not reach SynapseMessageReceiver at
the first place, because we are not applying any qos at this chain. So
the problem lies with the first Axis2 chain until
SynapseMessageReceiver.
IMHO, if a Synapse has to have a role or next to it, it should be
checked in the SynapseEnvironment before that message injected in to
the system to be mediated. In either case, first of all IMO the
message should come into SynapseEnvironment.
Thank you
Saminda
On 7/13/06, Deepal jayasinghe <
[EMAIL PROTECTED]> wrote:
I
totally agree with Paul , in this case Synapse is acting as SOAP node
(intermediate SOAP node)
Paul Fremantle wrote:
> I don't know enough about the mustUnderstand handling in Axis2,
but it
> seems to me that we might also want to identify a Synapse instance
as
> a given role.
>
> In other words, if we are acting as an intermediary, we may be
> implementing a specific role, and not the "ultimate receiver". So
we
> only need to understand the headers that are targeted at our role
or
> the "next" role.
>
> Paul
>
> On 7/12/06, Asankha C. Perera <
[EMAIL PROTECTED]> wrote:
>
>> Saminda
>>
>> Yes.. you are right, we need to be able to ask Axis2 to not
validate
>> mustunderstand headers.. we should get them to introduce a
property for
>> this and use it..
>>
>> asankha
>>
>> Saminda Abeyruwan wrote:
>> > Hi Devs,
>> >
>> > AxisEngine#receiver() always check for must understand
header before
>> > invoking the relevant message receiver. This would really
give a hard
>> > time in Synapse when we tried to implement qos support
such as RM ect.
>> >
>> > Synapse has its own SynapseMessageReceiver(SMR) and
SynapseDispatcher
>> > and all the messages will be passed to this message
receiver via
>> > SynapseDispatcher. During this first phase we are not
apply any QOS.
>> > All QOS handles through mediators. Ex: RM will handles
through
>> > RMMediator(RMM). RMMediator is a part of Synapse. We use
these
>> > mediators to engage Axis2 modules hence supporting QOS.
>> >
>> > So in the case of RM all control messages and application
messages
>> > will be passed to RMM. Now if a messages comes with must
understand
>> > true, it will not pass to SMR at the first phase, because
Axis2 engine
>> > check for must understand and it will throw an exception.
>> >
>> > Intermediaries like Synapse would not need to understand
must
>> > understand headers and it should be upto the Service
endpoint to
>> > understand it.
>> >
>> > So IMHO, in order to user AxisEngine in
SynapseEnvironment, we need a
>> > switch to configure must understanding.
>> >
>> >
>> > Thank you
>> >
>> > Saminda
>> >
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
