You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Nandana Mihindukulasooriya <na...@gmail.com> on 2008/09/22 07:52:50 UTC
Re: MTOM, WS-MTOMPolicy and MTOM configuration extension
Hi Dobri,
It seems that this WS-MTOMPolicy implementation is very basic. Currently
> there is only one possible assertion that can be used and it just specifies
> if MTOM should be used:
>
> <wsoma:OptimizedMimeSerialization xmlns:wsoma="
> http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization"/>
>
> This is obvious looking at the
> org.apache.axis2.policy.builders.MTOMAssertionBuilder and
> org.apache.axis2.policy.model.MTOMAssertion implementations. The only
> possible way to specify that MTOM is optional is programmatically, but not
> using a policy.
>
It seems WS-MTOMAssertion spec only defines OptimizedMimeSerialization
assertion. So Axis2 mtom-policy module seems to cover the WS-MTOMPolicy
spec. But this policy is not considered in Axis2 and only enableMTOM
parameter is considered.
What about covering the whole WS-MTOMPolicy specification and creating a
> separate module that can be engaged/disengaged when a MTOM policy is find
> into the WSDL. Doing so a client can make use of MTOM throughout reading the
> policy assertion and engaging the module.
>
We can have a module which can check whether the
"wsoma:OptimizedMimeSerialization" assertion is present in the effective
policy of the service and set the parameters accordingly. We can even have
a private assertion through which we can provide configuration parameters
[1] related to MTOM and the module can set the parameters on Axis2
accordingly. This way we can allow MTOM configuration to be done through
policy without effecting the backward compatibility. But I am not sure
introducing a module for this would be a overkill.
thanks,
nandana
[1] - http://wso2.org/library/264
> On Thu, Jul 17, 2008 at 8:31 PM, Thilina Gunarathne <cs...@gmail.com>
> wrote:
>
>> Axis2 has a mtom-policy implementation and I hope it works, but I have not
>> tested it personally...
>>
>> We went a little bit further with enableMTOM...
>> http://thilinag.blogspot.com/2007/07/improved-apache-axis2-attachment.html
>>
>> thanks,
>> Thilina
>>
>>
>> On Thu, Jul 17, 2008 at 6:00 AM, Dobri Kitipov <
>> kdobrik.axis2@googlemail.com> wrote:
>>
>>> Hi all,
>>> currently I am researching the possibilities to make MTOM configuration
>>> more advanced, than just saying that enableMTOM=true. For example it will be
>>> nice to specify a threshold that defines the size of the binary when MTOM to
>>> be activated etc.
>>> I want to ask and if there are any plans to support the WS-MTOMPolicy. Is
>>> there any willing/steps into the community to support this in the near
>>> future.
>>>
>>>
>>> Regards, Dobri
>>>
>>
>>
>>
>> --
>> Thilina Gunarathne - http://thilinag.blogspot.com
>
>
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
Re: MTOM, WS-MTOMPolicy and MTOM configuration extension
Posted by Dobri Kitipov <kd...@googlemail.com>.
Hi Nandana,
I have looked at the axis2-mtompolicy-mar and the fixed axis2-mtompolicy.
Now we are much more closer to the MTOM-Policy specification. Anyway there
are some things that we need to be fixed (e.g. MTOMPolicy class engageNotify
method is not correct at the moment, but this is easy to be fixed), but this
is not the most importatnt thing.
Just to comment, I agree with the prepositions you have made. Now it seems
we can do the following:
1) As we have discussed we can make parameter and policy assertion
configuration backward compatible. Doing so the user will have the freedom
to choose the both ways to configure MTOM and stay backward compatible. This
means that the parameter should reflect the policy (i.e. have it serialized
into the WSDL as policy) and vice versa (i.e. if policy is available then a
parameter is added to the service).
2) make full implementation of the MTOM Policy specification and provide the
proper error handling for all use cases that we could come across (e.g.Here
we can make use of a handler. )
3) Think if we really need any custom policy assertions for MTOM? Anyway I
think wih the current concept it is possible to document how it is possible
to extend and make use of custom assertions (e.g. if you read the spec - 3.2
Assertion Syntax - you can have /wsoma:OptimizedMimeSerialization/@any -
This is an extensibility mechanism to allow additional attributes to be
added to the element. then a custom handler can take place). We need to
discuss this.
4) As you have mentioned, we need to figure out how to deal with dynamically
changing policies / parameters.
WDYT?
Regards, Dobri
On Thu, Sep 25, 2008 at 2:24 PM, Nandana Mihindukulasooriya <
nandana.cse@gmail.com> wrote:
> Hi Dobri,
>
> I mean that the "optional" MTOM configuration is not implemented (i.e.
>> /wsoma: OptimizedMimeSerialization/@wsp:Optional="true").
>>
>
> Yep. Created a JIRA for that [1] and fixed it.
>
>
>> You are right. I can agree this may cause an overkill, but can you be
>> more concrete? Anyway I think that the natural way to configure a QoS is
>> making use of policies and modules? All these give us lots of benefits (e.g.
>> interoperability, modularity etc.). Please, can you give the cons of doing
>> that. IMHO I can agree this will consume lots of efforts for creating a
>> module that give a little functionality at the end and module that we do not
>> expect to develop too much in the future (compared to Rampart for example).
>> Anyway we should decide if this is ok for the long term. Isn't that
>> inevitable to move MTOM in a module at some point of time?
>>
>
> My concern was that whether people will like to add a new module just to do
> MTOM configuration. But when we think it though it seems it is reasonable
> to have a module for this. So what I thought was a module that sets the the
> MTOM parameters according to the policy. We can also do the other way around
> too by setting the policy when MTOM is enabled using the parameters. So
> when MTOM is configured either way, the policy will appear in the WSDL. I
> have created a prototype for the module [2]. People will still be able to
> set MTOM parameters without engaging this module if there don't care about
> policy and everything will be backward compatible.
>
> We can create a private custom assertion too which will contain
> configuration options described here [2]. This will be something similar to
> RampartConfig assertion in Rampart module.
>
> WDYT ?
>
> thanks,
> nandana
>
> [1] - http://issues.apache.org/jira/browse/AXIS2-4046
> [2] - https://wso2.org/repos/wso2/people/nandana/mtompolicy/
> [3] - http://wso2.org/library/264
>
>
>
>
>
>
>> [1] - http://wso2.org/library/264
>>>
>>>
>>>> On Thu, Jul 17, 2008 at 8:31 PM, Thilina Gunarathne <cs...@gmail.com>
>>>> wrote:
>>>>
>>>>> Axis2 has a mtom-policy implementation and I hope it works, but I have
>>>>> not tested it personally...
>>>>>
>>>>> We went a little bit further with enableMTOM...
>>>>>
>>>>> http://thilinag.blogspot.com/2007/07/improved-apache-axis2-attachment.html
>>>>>
>>>>> thanks,
>>>>> Thilina
>>>>>
>>>>>
>>>>> On Thu, Jul 17, 2008 at 6:00 AM, Dobri Kitipov <
>>>>> kdobrik.axis2@googlemail.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>> currently I am researching the possibilities to make MTOM
>>>>>> configuration more advanced, than just saying that enableMTOM=true. For
>>>>>> example it will be nice to specify a threshold that defines the size of the
>>>>>> binary when MTOM to be activated etc.
>>>>>> I want to ask and if there are any plans to support the WS-MTOMPolicy.
>>>>>> Is there any willing/steps into the community to support this in the near
>>>>>> future.
>>>>>>
>>>>>>
>>>>>> Regards, Dobri
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thilina Gunarathne - http://thilinag.blogspot.com
>>>>
>>>> <http://www.wso2.org>
>>>
>>
>>
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>
Re: MTOM, WS-MTOMPolicy and MTOM configuration extension
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Dobri,
I mean that the "optional" MTOM configuration is not implemented (i.e.
> /wsoma: OptimizedMimeSerialization/@wsp:Optional="true").
>
Yep. Created a JIRA for that [1] and fixed it.
> You are right. I can agree this may cause an overkill, but can you be more
> concrete? Anyway I think that the natural way to configure a QoS is making
> use of policies and modules? All these give us lots of benefits (e.g.
> interoperability, modularity etc.). Please, can you give the cons of doing
> that. IMHO I can agree this will consume lots of efforts for creating a
> module that give a little functionality at the end and module that we do not
> expect to develop too much in the future (compared to Rampart for example).
> Anyway we should decide if this is ok for the long term. Isn't that
> inevitable to move MTOM in a module at some point of time?
>
My concern was that whether people will like to add a new module just to do
MTOM configuration. But when we think it though it seems it is reasonable
to have a module for this. So what I thought was a module that sets the the
MTOM parameters according to the policy. We can also do the other way around
too by setting the policy when MTOM is enabled using the parameters. So
when MTOM is configured either way, the policy will appear in the WSDL. I
have created a prototype for the module [2]. People will still be able to
set MTOM parameters without engaging this module if there don't care about
policy and everything will be backward compatible.
We can create a private custom assertion too which will contain
configuration options described here [2]. This will be something similar to
RampartConfig assertion in Rampart module.
WDYT ?
thanks,
nandana
[1] - http://issues.apache.org/jira/browse/AXIS2-4046
[2] - https://wso2.org/repos/wso2/people/nandana/mtompolicy/
[3] - http://wso2.org/library/264
> [1] - http://wso2.org/library/264
>>
>>
>>> On Thu, Jul 17, 2008 at 8:31 PM, Thilina Gunarathne <cs...@gmail.com>
>>> wrote:
>>>
>>>> Axis2 has a mtom-policy implementation and I hope it works, but I have
>>>> not tested it personally...
>>>>
>>>> We went a little bit further with enableMTOM...
>>>>
>>>> http://thilinag.blogspot.com/2007/07/improved-apache-axis2-attachment.html
>>>>
>>>> thanks,
>>>> Thilina
>>>>
>>>>
>>>> On Thu, Jul 17, 2008 at 6:00 AM, Dobri Kitipov <
>>>> kdobrik.axis2@googlemail.com> wrote:
>>>>
>>>>> Hi all,
>>>>> currently I am researching the possibilities to make MTOM configuration
>>>>> more advanced, than just saying that enableMTOM=true. For example it will be
>>>>> nice to specify a threshold that defines the size of the binary when MTOM to
>>>>> be activated etc.
>>>>> I want to ask and if there are any plans to support the WS-MTOMPolicy.
>>>>> Is there any willing/steps into the community to support this in the near
>>>>> future.
>>>>>
>>>>>
>>>>> Regards, Dobri
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thilina Gunarathne - http://thilinag.blogspot.com
>>>
>>> <http://www.wso2.org>
>>
>
>
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
Re: MTOM, WS-MTOMPolicy and MTOM configuration extension
Posted by Dobri Kitipov <kd...@googlemail.com>.
Hi Nandana,
> It seems that this WS-MTOMPolicy implementation is very basic. Currently
>> there is only one possible assertion that can be used and it just specifies
>> if MTOM should be used:
>>
>> <wsoma:OptimizedMimeSerialization xmlns:wsoma="
>> http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization
>> "/>
>>
>> This is obvious looking at the
>> org.apache.axis2.policy.builders.MTOMAssertionBuilder and
>> org.apache.axis2.policy.model.MTOMAssertion implementations. The only
>> possible way to specify that MTOM is optional is programmatically, but not
>> using a policy.
>>
> It seems WS-MTOMAssertion spec only defines OptimizedMimeSerialization
> assertion. So Axis2 mtom-policy module seems to cover the WS-MTOMPolicy
> spec. But this policy is not considered in Axis2 and only enableMTOM
> parameter is considered.
>
I mean that the "optional" MTOM configuration is not implemented (i.e.
/wsoma: OptimizedMimeSerialization/@wsp:Optional="true"). If we read the
point 2.3 from the specification:
3.2 Assertion Syntax
The normative outline for the Optimized Mime Serialization policy assertion
is:
* <wsoma:OptimizedMimeSerialization ... /> The following describes
additional constraints on the outline listed above:
/wsoma:OptimizedMimeSerialization
A policy assertion that specifies that MTOM [MTOM] MUST be used in messages
sent to the Web service. It also specifies that responses from the Web
service MUST be optimized using MTOM [MTOM], i.e. that the messages must be
sent using the application/xop+xml mime type.
* /wsoma:OptimizedMimeSerialization/@wsp:Optional="true"
Per WS-Policy [WS-Policy], this is compact notation for two policy
alternatives, one with and one without the assertion. This indicates that
the behavior indicated by the assertion is optional, specifically that
non-MTOM-encoded exchanges are also supported by the endpoint.
* /wsoma:OptimizedMimeSerialization/@any
This is an extensibility mechanism to allow additional attributes to be
added to the element.
>
> What about covering the whole WS-MTOMPolicy specification and creating a
>> separate module that can be engaged/disengaged when a MTOM policy is find
>> into the WSDL. Doing so a client can make use of MTOM throughout reading the
>> policy assertion and engaging the module.
>>
>
> We can have a module which can check whether the
> "wsoma:OptimizedMimeSerialization" assertion is present in the effective
> policy of the service and set the parameters accordingly. We can even have
> a private assertion through which we can provide configuration parameters
> [1] related to MTOM and the module can set the parameters on Axis2
> accordingly. This way we can allow MTOM configuration to be done through
> policy without effecting the backward compatibility. But I am not sure
> introducing a module for this would be a overkill.
>
You are right. I can agree this may cause an overkill, but can you be more
concrete? Anyway I think that the natural way to configure a QoS is making
use of policies and modules? All these give us lots of benefits (e.g.
interoperability, modularity etc.). Please, can you give the cons of doing
that. IMHO I can agree this will consume lots of efforts for creating a
module that give a little functionality at the end and module that we do not
expect to develop too much in the future (compared to Rampart for example).
Anyway we should decide if this is ok for the long term. Isn't that
inevitable to move MTOM in a module at some point of time?
>
> thanks,
> nandana
>
> Thanks,
Dobri
>
> [1] - http://wso2.org/library/264
>
>
>> On Thu, Jul 17, 2008 at 8:31 PM, Thilina Gunarathne <cs...@gmail.com>
>> wrote:
>>
>>> Axis2 has a mtom-policy implementation and I hope it works, but I have
>>> not tested it personally...
>>>
>>> We went a little bit further with enableMTOM...
>>>
>>> http://thilinag.blogspot.com/2007/07/improved-apache-axis2-attachment.html
>>>
>>> thanks,
>>> Thilina
>>>
>>>
>>> On Thu, Jul 17, 2008 at 6:00 AM, Dobri Kitipov <
>>> kdobrik.axis2@googlemail.com> wrote:
>>>
>>>> Hi all,
>>>> currently I am researching the possibilities to make MTOM configuration
>>>> more advanced, than just saying that enableMTOM=true. For example it will be
>>>> nice to specify a threshold that defines the size of the binary when MTOM to
>>>> be activated etc.
>>>> I want to ask and if there are any plans to support the WS-MTOMPolicy.
>>>> Is there any willing/steps into the community to support this in the near
>>>> future.
>>>>
>>>>
>>>> Regards, Dobri
>>>>
>>>
>>>
>>>
>>> --
>>> Thilina Gunarathne - http://thilinag.blogspot.com
>>
>>
>>
>
>
> --
> Nandana Mihindukulasooriya
> WSO2 inc.
>
> http://nandana83.blogspot.com/
> http://www.wso2.org
>