PETALS CDK evolutions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PETALS CDK evolutions

cdeneux-4
Here is the PEtALS CDK evolutions topic

1. Create a NormalizedMessage wrapper
In the CDK API, like the wrapped message exchange, the normalized message will be wrapped to provide utilities such as properties settings :
- message.setSecuritySubject(Subject s) will set the
javax.jbi.security.subject
property
- message.setProtocolType(String s) will set the protocol type property
- message.setHeaders(Map m) will set the headers properties.
- message.xxx()

2. Provide WSA support

3. Refactor the JBIListener part
The JBIListener are no more listener but workers, the classes must be refactored according to this new architecture.




-------------------- m2f --------------------

Read this forum topic online here:
http://petals.ebmwebsourcing.com/forum/viewtopic.php?p=239#239

-------------------- m2f --------------------

_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: PETALS CDK evolutions

cdeneux-4
WSA support comments :
Taking the of the SOAP BC, Let say that the WSA information is taken from the input SOAP message and put as JBI message property.
I think that we must divide the WSA information for JBI consumers and JBI providers because imagine that we are in the SOAP proxy case :
1. On the JBI consumer side, take the WSA information from the incoming SOAP message and put it in the JBI message properties
2. On the JBI provider side, take the WSA-to information from the message property as reference to the external web service to call instead of the JBI SU address field => Loop !!!

So we really need to be able to differentiate the in and out WSA information or add options to CDK.

Comments?




-------------------- m2f --------------------

Read this forum topic online here:
http://petals.ebmwebsourcing.com/forum/viewtopic.php?p=244#244

-------------------- m2f --------------------

_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general
Reply | Threaded
Open this post in threaded view
|

Re: PETALS CDK evolutions

cdeneux-4
In reply to this post by cdeneux-4
I think that setting a wsa:To calling the BC SOAP from outside is to call a specific JBI provider endpoint. If wsa:To is set with the SOAP endpoint corresponding to the JBI consumer, I think that the BC SOAP should remove it before to forward the request. With this process, I think that the loop won't occur.

chamerling wrote:
WSA support comments :
Taking the of the SOAP BC, Let say that the WSA information is taken from the input SOAP message and put as JBI message property.
I think that we must divide the WSA information for JBI consumers and JBI providers because imagine that we are in the SOAP proxy case :
1. On the JBI consumer side, take the WSA information from the incoming SOAP message and put it in the JBI message properties
2. On the JBI provider side, take the WSA-to information from the message property as reference to the external web service to call instead of the JBI SU address field => Loop !!!

So we really need to be able to differentiate the in and out WSA information or add options to CDK.

Comments?




-------------------- m2f --------------------

Read this forum topic online here:
http://petals.ebmwebsourcing.com/forum/viewtopic.php?p=245#245

-------------------- m2f --------------------

_______________________________________________
General mailing list
[hidden email]
http://forum-list.petalslink.org/cgi-bin/mailman/listinfo/general