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
[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
