Hi All,
Another advantage I see in the new endpoint model is that we can nest load
balance and failover groups inside each other. One good use case for this is
that we can load balance over set of failover groups to acheive scalability
as well as high availability.
So I propose following changes to endpoints and to the send mediator to
support this model.
We can have a Endpoint interface which is implemented by all the endpoints.
public interface Endpoint {
public void send(MessageContext synapseMessageContext);
}
send method sends the message according to the given endpoint object.
For example a basic endpoint would send the message to the actual
endpoint address and a load balance endpoint would select another
endpoint according to a load balance policy and call its send method.
So we can achieve the nested structure.
Send mediator has a single endpoint object in which there can be a
hierarchy of endpoints. When mediating, the send mediator just calls
the send method of its endpoint object.
Each endpoint has its own endpoint factory which implements the
EndpointFactory interface.
public interface EndpointFactory {
public Endpoint createEndpoint(OMElement endpointConfig);
}
SendMediatorFactory will call above factory method for its immediate
child endpoint. And each EndpointFactory will call factory methods for
their child endpoints except for leaf level endpoints (address and
WSDL endpoints). This is similar to the AbstractListMediatorFactory.
I think we can achieve the nested endpoint model cleanly using this
design. If this endpoint model and the desing is ok, I will start
working on it.
Comments...
Chathura
On 2/22/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Chathura has written some load-balancing code for Synapse, but it
seems like the current model for endpoints needs a little refactoring
to sit well with it.
Currently an endpoint is "just" one endpoint. In the config language
(http://ws.apache.org/synapse/Synapse_Configuration_Language.html) it
says you can have several endpoints in a <send>..</send> but we've
never implemented that.
If we did it that way, then you couldn't use the load-balancing with a
proxy without defining a sequence, because the proxy just takes a
single endpoint reference.
So it seems it makes more sense to have the <endpoint> tag refer to a
"logical" endpoint. A logical endpoint could be defined in lots of
ways. For example, it could actually be a load-balancing group, or a
failover pair.
So here is a potential syntax:
<endpoint name="string">
(
<address uri="http://"; [format="soap|soap11|soap12|pox"]>
<enableRM policy=" "/>?
<enableSec [policy="key"]/>?
<enableAddressing/>?
.. extensibility ..
</address> |
<wsdl [uri="http://..";] [service="qname"] [port/endpoint="qname"]>
<wsdl:definition>...</wsdl:definition>?
<wsdl20:description>...</wsdl20:description>?
<enableRM policy=" "/>?
<enableSec [policy="key"]/>?
<enableAddressing/>?
.. extensibility ..
</wsdl> |
<loadbalance policy="round-robin">
<endpoint ../>+
</loadbalance> |
<failover policy="exponential-retry">
<endpoint ../>+
</failover> |
.. extensibility .. )
</endpoint>
So in this model, we can define an endpoint as either an address, or
using a WSDL, or as a load-balance group, or failover group. There
could be other types (maybe using MEX?).
Chathura has some cool implementation thoughts to go with this, which
I hope he will send as well (hint, hint).
Paul
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
