You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Frederik Juchart <ju...@swt.uni-stuttgart.de> on 2006/06/29 18:24:34 UTC
question regarding sequence of header processing in synapse
Hi,
I'm currently working on my diploma thesis "developing a routing mechanism for
soap messages". In addition to "simply" routing the message from one node to
another I have to dynamically (depending on the routing) define the sequence in
which soap headers are processed.
Example: someone sends a soap message and wants that message to be routed to a
logging service, a signature service and an encryption service in exactly that
order. These services are addressed via distinct soap headers. There wouldn't
be a problem if each soap node could only understand one of those headers... but...
If one soap node was able to process all of those headers I would have to make
sure that the headers are executed in the correct order.
I know that the soap standard does not define a sequence on headers, but it
says "The processing of one or more SOAP header blocks MAY control or determine
the order of processing for other SOAP header blocks and/or the SOAP body. For
example, one could create a SOAP header block to force processing of other SOAP
header blocks in lexical order." - which is what I want to do, though I wont
use lexical order, of course ;)
I am currently trying to implement a mechanism to define the processing
sequence of soap headers.
As I want the routing/sequence of headers to be defined within the message (as
a soap header) I would have to be able to change the sequence of header
processing in synapse while processing the "routing" header _at runtime_ ...
Is it possible to change the sequence of header processing ONLY for the current
message? If so... could you give me a hint on where to look?
Or do I have to do it differently?
Or is this impossible with synapse? *yikes*
Sorry for bothering you with my question but I did not know where else to look...
Thank you very much in advance,
Frederik Juchart
Re: question regarding sequence of header processing in synapse
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Frederik
I think your question should be posted to the Axis2 Java developer
mailing list. Synapse uses Apache Axis2 underneath
asankha
Frederik Juchart wrote:
> Hi,
>
> I'm currently working on my diploma thesis "developing a routing mechanism for
> soap messages". In addition to "simply" routing the message from one node to
> another I have to dynamically (depending on the routing) define the sequence in
> which soap headers are processed.
>
> Example: someone sends a soap message and wants that message to be routed to a
> logging service, a signature service and an encryption service in exactly that
> order. These services are addressed via distinct soap headers. There wouldn't
> be a problem if each soap node could only understand one of those headers... but...
> If one soap node was able to process all of those headers I would have to make
> sure that the headers are executed in the correct order.
>
> I know that the soap standard does not define a sequence on headers, but it
> says "The processing of one or more SOAP header blocks MAY control or determine
> the order of processing for other SOAP header blocks and/or the SOAP body. For
> example, one could create a SOAP header block to force processing of other SOAP
> header blocks in lexical order." - which is what I want to do, though I wont
> use lexical order, of course ;)
>
> I am currently trying to implement a mechanism to define the processing
> sequence of soap headers.
> As I want the routing/sequence of headers to be defined within the message (as
> a soap header) I would have to be able to change the sequence of header
> processing in synapse while processing the "routing" header _at runtime_ ...
>
> Is it possible to change the sequence of header processing ONLY for the current
> message? If so... could you give me a hint on where to look?
> Or do I have to do it differently?
> Or is this impossible with synapse? *yikes*
>
> Sorry for bothering you with my question but I did not know where else to look...
>
>
> Thank you very much in advance,
>
>
> Frederik Juchart
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Paul Fremantle <pz...@gmail.com>.
Frederik
You don't have to route on the destination service. You can route on
ANY part of the message.
So in your case we can do:
<switch source="soap:Envelope/soap:Header/my:head[0]">
<case regex="...">
<sequence>...</sequence>
</case>
...
</switch>
So in this case, Synapse will match the regular expression against the
specific header that you point to in the source attribute. I think
this does exactly what you need.
We have thought about using BPEL as a language inside Synapse, and
because Synapse is extensible we may add it later.
Paul
On 7/4/06, Frederik Juchart <ju...@swt.uni-stuttgart.de> wrote:
> Hi,
>
> unfortunately it won't be possible for me to make the routing decision
> with filters as you described. I do not want to use the destination
> service as the decision key - what I would like to do is introduce a new
> soap header containing a link to an external process describing the
> routing. Each intermediary then takes this information and asks the
> process (BPEL) what to do next. So it is kind of like an orchestration
> service for additional services like logging etc... I described this in
> a little more detail in my answer to Thomas Kelly`s mail in this thread.
>
> Paul Fremantle wrote:
> > You can actually do something like this with Axis2, but the Axis2
> > design is actually there to figure out the order of handlers
> > based on the "standard" pattern, so you would have to bypass that and
> > use the services.xml to completely specify the handler order.
>
> Could you describe that in a little more detail? I do not have a clue as
> to where I can change the handler sequence at runtime from within a
> handler. I don't even know if doing so would also affect other messages'
> processing - which of course wouldn't be wanted at all.
>
>
> Fred.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Frederik Juchart <ju...@swt.uni-stuttgart.de>.
Hi,
unfortunately it won't be possible for me to make the routing decision
with filters as you described. I do not want to use the destination
service as the decision key - what I would like to do is introduce a new
soap header containing a link to an external process describing the
routing. Each intermediary then takes this information and asks the
process (BPEL) what to do next. So it is kind of like an orchestration
service for additional services like logging etc... I described this in
a little more detail in my answer to Thomas Kelly`s mail in this thread.
Paul Fremantle wrote:
> You can actually do something like this with Axis2, but the Axis2
> design is actually there to figure out the order of handlers
> based on the "standard" pattern, so you would have to bypass that and
> use the services.xml to completely specify the handler order.
Could you describe that in a little more detail? I do not have a clue as
to where I can change the handler sequence at runtime from within a
handler. I don't even know if doing so would also affect other messages'
processing - which of course wouldn't be wanted at all.
Fred.
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Paul Fremantle <pz...@gmail.com>.
Hi
Interesting question.
How about:
<filter source="get-property('to')" regex="http://my_specific_url">
<sequence>
... specific order of mediators here...
</sequence>
</filter>
This checks if the incoming target (the TO address) matches
http://my_specific_url.
If it does then it will execute the sequence of mediators in the order
you specify.
So as long as you have mediators to log, sign and encrypt, you can
specify that order there.
The filter is efficient but not for large numbers of filters, because
it will test each one,
so to do this efficiently for a bunch of different URIs/URLs you can
use the switch, which only matches one
URI out of a bunch:
<switch source="get-property('to')" >
<case regex="http://my_specific_url1">
<sequence>
... specific order of mediators here...
</sequence>
</case>
<case regex="http://anotherURI">
<sequence>
...
</sequence>
</case>
</switch>
I think that does *exactly* what you want today.
You can actually do something like this with Axis2, but the Axis2
design is actually there to figure out the order of handlers
based on the "standard" pattern, so you would have to bypass that and
use the services.xml to completely specify the handler order.
Paul
On 6/29/06, Frederik Juchart <ju...@swt.uni-stuttgart.de> wrote:
> Hi,
>
> I'm currently working on my diploma thesis "developing a routing mechanism for
> soap messages". In addition to "simply" routing the message from one node to
> another I have to dynamically (depending on the routing) define the sequence in
> which soap headers are processed.
>
> Example: someone sends a soap message and wants that message to be routed to a
> logging service, a signature service and an encryption service in exactly that
> order. These services are addressed via distinct soap headers. There wouldn't
> be a problem if each soap node could only understand one of those headers... but...
> If one soap node was able to process all of those headers I would have to make
> sure that the headers are executed in the correct order.
>
> I know that the soap standard does not define a sequence on headers, but it
> says "The processing of one or more SOAP header blocks MAY control or determine
> the order of processing for other SOAP header blocks and/or the SOAP body. For
> example, one could create a SOAP header block to force processing of other SOAP
> header blocks in lexical order." - which is what I want to do, though I wont
> use lexical order, of course ;)
>
> I am currently trying to implement a mechanism to define the processing
> sequence of soap headers.
> As I want the routing/sequence of headers to be defined within the message (as
> a soap header) I would have to be able to change the sequence of header
> processing in synapse while processing the "routing" header _at runtime_ ...
>
> Is it possible to change the sequence of header processing ONLY for the current
> message? If so... could you give me a hint on where to look?
> Or do I have to do it differently?
> Or is this impossible with synapse? *yikes*
>
> Sorry for bothering you with my question but I did not know where else to look...
>
>
> Thank you very much in advance,
>
>
> Frederik Juchart
>
>
>
>
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Frederik Juchart <ju...@swt.uni-stuttgart.de>.
Hi,
this sounds very interesting. Though I won't be able to supply a
mediator configuration in my soap header. Is it possible to "ask"
installed mediators which header they process? Because I think then I
would be able to build the mediator sequence manually based on e.g.
header namespaces...
Fred.
Hadrian Zbarcea wrote:
> Hi,
>
> I am not sure I understand your question correctly, but I would try to
> respond. I am by no means a Synapse expert, but afaik Synapse does
> not allow you to do this out of the box today, but imho it is
> possible. You would have to write your own custom mediator though.
>
> You need to pass some information such as a <sequence> mediator
> configuration in your soap header. The SynapseMediator would be
> instantiated with your custom mediator which needs to do the following
> _runtime_ (during mediate()):
> 1. Read the soap envelope and extract the relevant routing information
> from the header.
> 2. Call on the appropriate MediatorFactory to build a mediator as
> specified in the header (you can pool such mediators of course if the
> rules are not too dynamic to save resources).
> 3. Invoke down on the dynamically created mediator.
>
> The information in the header doesn't necessarily need to be synapse
> configuration, but then you'd have to build your mediators
> programatically.
>
> Is this what you want to do or just my misunderstanding?
>
> Regards
> Hadrian
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi,
I am not sure I understand your question correctly, but I would try to
respond. I am by no means a Synapse expert, but afaik Synapse does not
allow you to do this out of the box today, but imho it is possible. You
would have to write your own custom mediator though.
You need to pass some information such as a <sequence> mediator
configuration in your soap header. The SynapseMediator would be
instantiated with your custom mediator which needs to do the following
_runtime_ (during mediate()):
1. Read the soap envelope and extract the relevant routing information from
the header.
2. Call on the appropriate MediatorFactory to build a mediator as specified
in the header (you can pool such mediators of course if the rules are not
too dynamic to save resources).
3. Invoke down on the dynamically created mediator.
The information in the header doesn't necessarily need to be synapse
configuration, but then you'd have to build your mediators programatically.
Is this what you want to do or just my misunderstanding?
Regards
Hadrian
On 6/29/06, Frederik Juchart <ju...@swt.uni-stuttgart.de> wrote:
>
> Hi,
>
> I'm currently working on my diploma thesis "developing a routing mechanism
> for
> soap messages". In addition to "simply" routing the message from one node
> to
> another I have to dynamically (depending on the routing) define the
> sequence in
> which soap headers are processed.
>
> Example: someone sends a soap message and wants that message to be routed
> to a
> logging service, a signature service and an encryption service in exactly
> that
> order. These services are addressed via distinct soap headers. There
> wouldn't
> be a problem if each soap node could only understand one of those
> headers... but...
> If one soap node was able to process all of those headers I would have to
> make
> sure that the headers are executed in the correct order.
>
> I know that the soap standard does not define a sequence on headers, but
> it
> says "The processing of one or more SOAP header blocks MAY control or
> determine
> the order of processing for other SOAP header blocks and/or the SOAP body.
> For
> example, one could create a SOAP header block to force processing of other
> SOAP
> header blocks in lexical order." - which is what I want to do, though I
> wont
> use lexical order, of course ;)
>
> I am currently trying to implement a mechanism to define the processing
> sequence of soap headers.
> As I want the routing/sequence of headers to be defined within the message
> (as
> a soap header) I would have to be able to change the sequence of header
> processing in synapse while processing the "routing" header _at runtime_
> ...
>
> Is it possible to change the sequence of header processing ONLY for the
> current
> message? If so... could you give me a hint on where to look?
> Or do I have to do it differently?
> Or is this impossible with synapse? *yikes*
>
> Sorry for bothering you with my question but I did not know where else to
> look...
>
>
> Thank you very much in advance,
>
>
> Frederik Juchart
>
>
>
>
Re: question regarding sequence of header processing in synapse
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Frederik Juchart wrote:
> Hi Thomas,
>
> Thank you very much for your answer and detailed feedback.
> I agree that it is a very bad idea to have the client dictate the
> routing (as in now obsolete WS-Routing standard) as this introduces
> all of the problems and scalability issues described in your submission.
> That is why I plan to introduce a new routing header which is inserted
> by the client and only says something like "i want this message to be
> treated according to routing process A" (actually it only contains the
> URI of the process).
> Process A must already have been defined in an external BPEL-process -
> yes I would like to define routing information as bpel processes. So
> each intermediary may inspect the client inserted header which
> contains the URI and correlation id of a specific bpel process. That
> way each intermediary can query the bpel process on what is next to be
> done with the message. The process answers to these questions with the
> URI of an intermediary and the namespace of the header to be processed
> next. That makes it possible to route a message in a well defined way
> without the client knowing the details of the routing.
>
> As I am complete new to synapse: Is something like that possible?
> Could you give me some hints as to where to look further? That is if
> you don't think that I am absolutely crazy if I use BPEL as a simple
> routing table... ;)
hi Fred,
the only problem with it that i can see is that if the mechanism is
generic it would be possible to hijack clients and make them into zombie
that are controlled by BPEL overlord to direct WS-* (DeathStar?) based
DOS attacks ... which would be interesting ;-)
>
> Of course I am aware that introducing a central bpel process for
> routing purposes is critical in itself as there is no guarantee on
> this service being reachable from anywhere on the network.
it does not have to be central: if client uses WS-Addressing (or just
playing with DNS) the actual address of a BPEL router can be determined
by an intermediary (for looking on WS-Addressing headers for lower level
routing and/or resolving DNS address to multiple IP addresses and trying
them in round robin fashion etc ...)
> This would be something an administrator would have to assure prior to
> installing the extension ;) And that might be a security issue on its
> own *sigh*
it could be bad especially if the logic for routing is capable of
expressing enough for generating more than one message to send (your
aggregation service below?) without need to send a message to BPEL
controller (one message could trigger an avalanche of messages ...)
> It might very well be that defining routing as bpel process is like
> using a sledge-hammer to crack a nut - but it makes routing very
> flexible and might some day even make simultaneous processing of a
> message at multiple intermediaries possible (that is if one can come
> up with some sort of aggregation service). But that is still far far
> away...
>
> As to "who controls the decision process":
> I agree that these policies should not be controlled by the client but
> the service layer.
> Yet I think that even if you move the decision making away from the
> client it would still be necessary to have the client insert the
> required headers. So you can decide within the service layer when to
> invoke a specific service but not the parameters of that service. Or
> am I completely wrong here?
you could also create clients that have "cookies" that capture in an
opaque way bpel state (just a long number maybe with crypto and
timestamped to make sure client can not manipulate it) and it is passed
to routing controller for routing the message in a bigger conversation.
still i wonder what is exactly the use case for it? is it compelling
enough? how does it compare to other ways of doing the same?
best,
alek
>
> homas.Kelly@perficient.com wrote:
>>
>> Frederick,
>> It seems that it is not a matter of whether it can be done, but
>> whether it should be done. As far as I can tell from what you have
>> submitted, the intermediaries must be able to a) process the headers
>> at all, ie we must have some kind of paradigm implemented where the
>> headers are recognizable, and b) The intermediaries must contain
>> logic necessary to be able to process the multiple headers, in
>> varying order, according to a changing set of criteria. This we have
>> established. My problem is that you are saying that the criteria is
>> being established by a client application who is detailing to the
>> service provider how a message is to be processed. This should not
>> happen for many reasons. 1) It is a major security breach because you
>> expose the entirety of you intermediary services to the outside world
>> which is offering a buffet of information to potential intruders. 2)
>> The client application thickens considerably in that now dynamic
>> changes over time must be accounted for at this remote layer. 3) If
>> it comes to pass that we must implement a custom processing scheme at
>> the intermediary layer, it is best to isolate this programming and
>> make it applicable to other clients, many of which may not yet exist.
>> When you couple this client and this intermediary, you essentially
>> bar expansion on both sides of the river.
>> It comes down to who commands the processing sequence.
>> Service providers and supporting intermediaries dictate the
>> sequence in which processing should occur and the current aim is to
>> move away from any dependence on the client in this decision-making
>> process because it defeats the concept of the Enterprise Service Bus
>> altogether to house this understanding outside the service provider
>> layer and its immediate supporting applications. This actually is a
>> throwback to the whole interface concept in C++, CORBA, and later
>> java, I want to expose an interface but telling the client the
>> details regarding my application causes problems. If I begin telling
>> clients how to route mesages, where does it end? How do I add useful
>> capabilities to my service provider layer without breaking the
>> coupling between client and server. In my humble opinion, I think
>> that what you should be focusing on here is declarative coupling
>> between service providers and dynamic routing of messages after they
>> enter some type of intermediary gateway which is charged with the
>> responsibility of message routing based on a policy. So we A) isolate
>> the clients according to whatever WSDL has been published, but the
>> client is blind to everything but the essential requirements. b) We
>> implement a gateway intermediary that accepts the client invocation
>> and applies a policy. even if this triggers a header rewrite, which
>> is fine as long as it is stripped when going outside of a secure
>> paradigm, C) implement supporting intermediaries that route according
>> to the policy established.
>> Thus, the intermediaries route based on the invocation, and the
>> policy applies to the invocation alone. Consider, you said you may
>> want to log, verify, and de-encrypt, or perform some other useful
>> action, do we do this on the client, or on the invocation itself? If
>> a client says do this, how do I implement the policy and be secure,
>> and if I implement the policy to ensure verification or de-encryption
>> for example, then I don't need the client to specify anything for me.
>> All in all, it seems the same steps must be applied in either case so
>> eliminating the client dependency is the correct move in terms of
>> design.
>> The usual response here is what about differentiation of clients, ie-
>> one client requires said security while another does not. In this
>> case, it makes no sense to deal with the header issue either because
>> the coming standards for WSI interoperability and highly detailed
>> WSDLs will eventually mandate seperate operation signatures and port
>> urls, which will then use URL rewriting to realign on the back end
>> when invoking the same service. So, we seem to be agreed here that
>> you have to develop custom intermediaries. However, in this revised
>> case, you move the responsibility from the client to the first
>> intermediary and end up with a much more scaleable application. I
>> think if you look at some of the more mainstream ESB based products
>> you will see this multi-step protocols trying to establish this
>> paradigm. Particular examples are SOA appiances such as datapower and
>> reactivity, and the more scaleable ESB products such as BEA and
>> websphere. If I am completely wrong here, please forgive me, everyone
>> misfires. I just spend some time trying to get a grip on the client
>> layer design issues and the scaleability problems of your description
>> and have to wonder if perhaps there was a more eloquent way to solve
>> this very important issue.
>> -Thomas
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-dev-help@ws.apache.org
>
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Frederik Juchart <fr...@juchart.de>.
Hi Thomas,
Thank you very much for your answer and detailed feedback.
I agree that it is a very bad idea to have the client dictate the
routing (as in now obsolete WS-Routing standard) as this introduces all
of the problems and scalability issues described in your submission.
That is why I plan to introduce a new routing header which is inserted
by the client and only says something like "i want this message to be
treated according to routing process A" (actually it only contains the
URI of the process).
Process A must already have been defined in an external BPEL-process -
yes I would like to define routing information as bpel processes. So
each intermediary may inspect the client inserted header which contains
the URI and correlation id of a specific bpel process. That way each
intermediary can query the bpel process on what is next to be done with
the message. The process answers to these questions with the URI of an
intermediary and the namespace of the header to be processed next. That
makes it possible to route a message in a well defined way without the
client knowing the details of the routing.
As I am complete new to synapse: Is something like that possible? Could
you give me some hints as to where to look further? That is if you don't
think that I am absolutely crazy if I use BPEL as a simple routing
table... ;)
Of course I am aware that introducing a central bpel process for routing
purposes is critical in itself as there is no guarantee on this service
being reachable from anywhere on the network. This would be something an
administrator would have to assure prior to installing the extension ;)
And that might be a security issue on its own *sigh*
It might very well be that defining routing as bpel process is like
using a sledge-hammer to crack a nut - but it makes routing very
flexible and might some day even make simultaneous processing of a
message at multiple intermediaries possible (that is if one can come up
with some sort of aggregation service). But that is still far far away...
As to "who controls the decision process":
I agree that these policies should not be controlled by the client but
the service layer.
Yet I think that even if you move the decision making away from the
client it would still be necessary to have the client insert the
required headers. So you can decide within the service layer when to
invoke a specific service but not the parameters of that service. Or am
I completely wrong here?
-Fred
Thomas.Kelly@perficient.com wrote:
>
> Frederick,
> It seems that it is not a matter of whether it can be done, but
> whether it should be done. As far as I can tell from what you have
> submitted, the intermediaries must be able to a) process the headers
> at all, ie we must have some kind of paradigm implemented where the
> headers are recognizable, and b) The intermediaries must contain logic
> necessary to be able to process the multiple headers, in varying
> order, according to a changing set of criteria. This we have
> established. My problem is that you are saying that the criteria is
> being established by a client application who is detailing to the
> service provider how a message is to be processed. This should not
> happen for many reasons. 1) It is a major security breach because you
> expose the entirety of you intermediary services to the outside world
> which is offering a buffet of information to potential intruders. 2)
> The client application thickens considerably in that now dynamic
> changes over time must be accounted for at this remote layer. 3) If it
> comes to pass that we must implement a custom processing scheme at the
> intermediary layer, it is best to isolate this programming and make it
> applicable to other clients, many of which may not yet exist. When you
> couple this client and this intermediary, you essentially bar
> expansion on both sides of the river.
> It comes down to who commands the processing sequence.
> Service providers and supporting intermediaries dictate the sequence
> in which processing should occur and the current aim is to move away
> from any dependence on the client in this decision-making process
> because it defeats the concept of the Enterprise Service Bus
> altogether to house this understanding outside the service provider
> layer and its immediate supporting applications. This actually is a
> throwback to the whole interface concept in C++, CORBA, and later
> java, I want to expose an interface but telling the client the details
> regarding my application causes problems. If I begin telling clients
> how to route mesages, where does it end? How do I add useful
> capabilities to my service provider layer without breaking the
> coupling between client and server. In my humble opinion, I think that
> what you should be focusing on here is declarative coupling between
> service providers and dynamic routing of messages after they enter
> some type of intermediary gateway which is charged with the
> responsibility of message routing based on a policy. So we A) isolate
> the clients according to whatever WSDL has been published, but the
> client is blind to everything but the essential requirements. b) We
> implement a gateway intermediary that accepts the client invocation
> and applies a policy. even if this triggers a header rewrite, which is
> fine as long as it is stripped when going outside of a secure
> paradigm, C) implement supporting intermediaries that route according
> to the policy established.
> Thus, the intermediaries route based on the invocation, and the policy
> applies to the invocation alone. Consider, you said you may want to
> log, verify, and de-encrypt, or perform some other useful action, do
> we do this on the client, or on the invocation itself? If a client
> says do this, how do I implement the policy and be secure, and if I
> implement the policy to ensure verification or de-encryption for
> example, then I don't need the client to specify anything for me. All
> in all, it seems the same steps must be applied in either case so
> eliminating the client dependency is the correct move in terms of design.
> The usual response here is what about differentiation of clients, ie-
> one client requires said security while another does not. In this
> case, it makes no sense to deal with the header issue either because
> the coming standards for WSI interoperability and highly detailed
> WSDLs will eventually mandate seperate operation signatures and port
> urls, which will then use URL rewriting to realign on the back end
> when invoking the same service. So, we seem to be agreed here that you
> have to develop custom intermediaries. However, in this revised case,
> you move the responsibility from the client to the first intermediary
> and end up with a much more scaleable application. I think if you look
> at some of the more mainstream ESB based products you will see this
> multi-step protocols trying to establish this paradigm. Particular
> examples are SOA appiances such as datapower and reactivity, and the
> more scaleable ESB products such as BEA and websphere. If I am
> completely wrong here, please forgive me, everyone misfires. I just
> spend some time trying to get a grip on the client layer design issues
> and the scaleability problems of your description and have to wonder
> if perhaps there was a more eloquent way to solve this very important
> issue.
> -Thomas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
Re: question regarding sequence of header processing in synapse
Posted by Th...@perficient.com.
Frederick,
It seems that it is not a matter of whether it can be done, but whether
it should be done. As far as I can tell from what you have submitted, the
intermediaries must be able to a) process the headers at all, ie we must
have some kind of paradigm implemented where the headers are recognizable,
and b) The intermediaries must contain logic necessary to be able to
process the multiple headers, in varying order, according to a changing
set of criteria. This we have established. My problem is that you are
saying that the criteria is being established by a client application who
is detailing to the service provider how a message is to be processed.
This should not happen for many reasons. 1) It is a major security breach
because you expose the entirety of you intermediary services to the
outside world which is offering a buffet of information to potential
intruders. 2) The client application thickens considerably in that now
dynamic changes over time must be accounted for at this remote layer. 3)
If it comes to pass that we must implement a custom processing scheme at
the intermediary layer, it is best to isolate this programming and make it
applicable to other clients, many of which may not yet exist. When you
couple this client and this intermediary, you essentially bar expansion on
both sides of the river.
It comes down to who commands the processing sequence.
Service providers and supporting intermediaries dictate the sequence in
which processing should occur and the current aim is to move away from any
dependence on the client in this decision-making process because it
defeats the concept of the Enterprise Service Bus altogether to house this
understanding outside the service provider layer and its immediate
supporting applications. This actually is a throwback to the whole
interface concept in C++, CORBA, and later java, I want to expose an
interface but telling the client the details regarding my application
causes problems. If I begin telling clients how to route mesages, where
does it end? How do I add useful capabilities to my service provider layer
without breaking the coupling between client and server. In my humble
opinion, I think that what you should be focusing on here is declarative
coupling between service providers and dynamic routing of messages after
they enter some type of intermediary gateway which is charged with the
responsibility of message routing based on a policy. So we A) isolate the
clients according to whatever WSDL has been published, but the client is
blind to everything but the essential requirements. b) We implement a
gateway intermediary that accepts the client invocation and applies a
policy. even if this triggers a header rewrite, which is fine as long as
it is stripped when going outside of a secure paradigm, C) implement
supporting intermediaries that route according to the policy established.
Thus, the intermediaries route based on the invocation, and the policy
applies to the invocation alone. Consider, you said you may want to log,
verify, and de-encrypt, or perform some other useful action, do we do this
on the client, or on the invocation itself? If a client says do this, how
do I implement the policy and be secure, and if I implement the policy to
ensure verification or de-encryption for example, then I don't need the
client to specify anything for me. All in all, it seems the same steps
must be applied in either case so eliminating the client dependency is the
correct move in terms of design.
The usual response here is what about differentiation of clients, ie- one
client requires said security while another does not. In this case, it
makes no sense to deal with the header issue either because the coming
standards for WSI interoperability and highly detailed WSDLs will
eventually mandate seperate operation signatures and port urls, which will
then use URL rewriting to realign on the back end when invoking the same
service. So, we seem to be agreed here that you have to develop custom
intermediaries. However, in this revised case, you move the responsibility
from the client to the first intermediary and end up with a much more
scaleable application. I think if you look at some of the more mainstream
ESB based products you will see this multi-step protocols trying to
establish this paradigm. Particular examples are SOA appiances such as
datapower and reactivity, and the more scaleable ESB products such as BEA
and websphere. If I am completely wrong here, please forgive me, everyone
misfires. I just spend some time trying to get a grip on the client layer
design issues and the scaleability problems of your description and have
to wonder if perhaps there was a more eloquent way to solve this very
important issue.
-Thomas