On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
> So if i understand you correctly, you are mostly concerned of enhancing
> the JMS flow in the following areas:
> * avoid ping/pong and lower bandwidth requirement
> (avoid sending the whole exchange and only send the actual data)
> * enhance security (authentication, encryption ?)
> * enhance the endoint registry wrt to services or instances going
> up and down
>
>
> Did I catch you correcty ?
>
> For the bandwidh requirement, I'm sure we can do that and reconstruct
> a fake
> exchange on the other side. We would loose informations wrt to the
> input message
> but I don't think this would be too much a problem. For the ping/
> pong stuff, I'm sure
> we can find a way to optimize it somehow. We may have troubles
> handling the
> InOptionalOut pattern though, as you don't really know if you will
> receive an Out
> message or nothing, but for the other simple patterns (InOnly and
> InOut) it should
> be quite easy to send back the exchange with a DONE status just after
> having send
> the jms message containing the In or Out.
>
> On the security subject, I know there is lots to do, but this is an
> area i'm not so familiar
> with. My biggest concern is that we security can be applied at the
> connection level
> or at the message level. NMR-NMR security for the JMS flow could be
> delegated
> to ActiveMQ i guess (using AMQ security features).
An interceptor framework might help this situation where the necessary
authentication and authorization interceptors could be added to handle
the situation. Then it's just up to the implementation of each.
> On the registry side, I think one of the main problem is that there
> is no way to tell the
> difference between an endpoint that goes down because the server is
> no more
> accessibe (it will be up again at a later time) or because the
> endpoint has been
> undeployed. Imho, this is a key requirement to be able to make
> routing decisions.
> I don't know yet how to handle this problem: if a server has been
> shutdown, it may
> never go up again... So i'm still not sure how to handle the problem :-(
This is one place where a proper registry might be useful. If the
registry handles metadata for a given component, it can provide this
type of finer grained information to anyone that is interested. E.g.,
if a component is undeployed, the deployer tells the registry that
componentX is being undeployed and the registry would store that
information. When componentX comes back online it tells the registry
and the registry updates the metadata.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
