On Aug 24, 2007, at 7:28 PM, Kit Plummer wrote:
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 ?
Yes. The registry piece is a little interesting for us to.
Because we
are integrating "hardware" via service components we've had to
abstract the
notion of capabilities. It would be nice if the registry were
extensible.
If we leverage the OSGi registry, you can associate a bunch of metadata
to each service registered in the registry (in our cases, endpoints).
Cheers,
Guillaume Nodet
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.
I think as long as everything is optional wrt to optimizations the
fact that
it may exclude various patterns is acceptable. We've done
everything in an
InOnly world.
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).
Agreed. It is now...the Network of Brokers feature. But, there is
not
really any concept of policy.
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...
Yeh, like if it has been blown up by an IED...
So i'm still not sure how to handle the problem :-(
Yep, you are right. Right now if we undeploy a service assembly, its
endpoint still exists, and messages are still routed to it. Could
just be a
bug. ; }
I'm sure more discussion on this will follow.
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 3:35 PM, Kit Plummer wrote:
Sure Guillaume.
Maybe the best thing to do is explain the concept...and what we've
done to
meet our requirements.
It is actually quite simple. We needed to be able to connect two
computers
together via TCP/IP, and have a publisher on one system, the
consumer on the
other. Granted we've got lot's of both on each - but, the premise
is that
link between is transparent.
Currently, we are using a feature of ActiveMQ called "Network of
Brokers"
(NoB) to create a mapping of destinations/endpoints.
Where it gets really complicated is when we only want to allow a
specific
MEPs to cross the NoB connection. In this example, bandwidth is
not a
commodity and must be tightly constrained. We were tolerant of all
the SEDA
flow handshaking, but I believe it would be nice if InOnly MEPS
really were
just a single transmission (turning off levels of reliability/
durability).
Also, in our environment multicast isn't possible, and the networks
are
fairly ad-hoc...meaning not stable. Plus, we need to know about
the state
of the link.
Service registration happens also in different configurations. For
example,
one topology we support is a hierarchical flow (master-slaves).
Imagine a
simple sensor net. There would be a single point at the top, where
are data
were to be aggregated. So, in this example the NoBs need to support
"followers" only communicating with their "leader"...and the
"leader" only
communicating with its "leader". But, there might also be a need
to have
"shared" data that is available on all platforms in network
(health, state,
etc.). Ding lifecycle.
I could keep going...but, am curious if anyone else looks at it
this way.
Obviously, the notion of simple performance scalability is one way
to look
at. There is a lot of capability in the NoB, but I think it falls
a bit
short. There are a few features that we'd like to see, that would
help us
federate better. BC/SE/SA-level authentication to the bus, as
well as
platform-to-platform, or NMR-to-NMR authentication would be very
helpful.
We've been looking at grid/cluster-like capabilities too - for
example, if
one platform is maxed out from a processing perspective, sending
the SA and
the message/task to another platform in network automatically.
Thanks for taking the time to do this.
On 8/23/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
Hi Kit,
I'm quite sure you would have a very valuable input there, given
your
experience
on ServiceMix. So I'm starting this new thread. Would you mind
throwing a few
ideas there ?
Cheers,
Guillaume Nodet
On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote:
On 8/22/07, Terry Cox <[EMAIL PROTECTED]> wrote:
Interesting.
We need to have a very serious chat about application lifecycles
and
governance...
Terry
And Federating...distribution of the NMR across n-platforms!
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
