[Architecture] FE / BE - the next steps

[Paul Fremantle]

I've just been viewing Danushka's excellent demo of the WSF/C Carbon admin.

It made me realize we can do even better.

1) We can use our new WS-Discovery capability to publish and find BEs

This means we can find a list box of servers to manage. Even better in the
future we can have a list of available servers grouped by topology. But a
simple list would be great. We need to have some name for each server as
well instead of just the URL.

2) Once we have a list of servers it starts to become necessary to have
single sign on for FE/BE. I think we are doing this already: right?

3) We need the BE to be able to let the FE know which features it supports.
So when I connect to a WSF/C BE, the FE should:
a) Offer just the right interface based on the capabilities of the BE
b) Offer to go to the p2 repo and download any missing features it needs to
manage that BE.

I don't think we have this right now? So in order to do this we need a
service on the BE that provides the right information to the FE to figure
the rest out.

So here is my scenario: I have a set of servers around, some WSF/C++, some
WSAS, ESB, some p2 enhanced random collections. I download the Carbon Admin
Console (e.g. empty Carbon). I point it at my Registry (or it finds it via
UDP Discovery). Then it lists me available servers. I choose the WSF/C++
server and it automatically builds the right OSGi feature set to manage
that.

Paul

-- 
Paul Fremantle
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, VP, Apache Synapse

Office: +44 844 484 8143
Cell: +44 798 447 4618

blog: http://pzf.fremantle.org
twitter.com/pzfreo
paul at wso2.com

wso2.com Lean Enterprise Middleware
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.wso2.org/pipermail/architecture/attachments/20100219/ebd940be/attachment.html>