Some Architecture Thoughts
Based on todays meeting, I have been thinking about some of these architecture
issues on the flight home. There was one fundamental new idea we kicked
around. I want to see if we are all in sync with this.
We now have a model with a special user-owned "server" that provides the
following functions.
-
The user server, call it "MyServer", runs on the users "home" workstation
where he or she keeps things like private keys.
-
MyServer can be accessed by any number of web clients such as browsers,
hand-helds, etc. as long as they can do an encripted password authentication
with the server.
-
MyServer runs a set of Portal Services. These Portal Services include:
Event Service, Security Service, Information Service, Remote Execution
Service, Collaboration Services. Each of these services should be
a plug-in-component of MyServer.
-
MyServer probably takes the form of an HTTP server with Java2 and JPython.
It may also take the form of a Zope Server. It propbably also has
a CORBA ORB embedded in it. (this requires one of our technical evaluation.)
More About the Services
It would seem that the cleanest architecture we can envision would be one
where the core services are components that can be installed in MyServer
easily (perhaps even dynamically loaded.) In fact there should probably
be no difference between the core services running locally and other "service
objects" running on our behalf remotely. It should also be possible
for a user to write a new service and easily install it.
How does the server SEE services?
A service is just a component that provides an interface of standard methods.
For example, the Event Service provides an interface that allows a MyServer
"program" to subscribe to an event stream by type or source, or register
itself as a publisher of events. The Information Service should look
like the interface for JNDI. The Remote Execution Service should
have a COGKit style API that allows the service user to specify a resource
and a task to run. We need to sit down hash through each
of these APIs.
How does the server PROGRAM and USE the services?
BetterPortalML generates scripts which run in the server. Each script
represents a different functionality of some portal application.
these server scripts can be java objects that directly access the services
or they may be python scripts or whatever needs access to the service component
APIs.
How are the server services to interact with the rest of the world?
Each of our services should represent a "gateway" to external resources.
For example,
the local Event Services objects from different MyServers are connected
together into a global event network or to standard event channels such
as CORBA Notification or Jini Event systems. The Information system
should be directly connected to the grid GIS/LDAP network, the Jini look-up
service and other distributed information systems.
In some cases the services communcate with the outside world by SOAP
calls and in other cases through other mechanisms. But these "hook-ups"
should hidden behind the standard service API that the service presents
to the MyServer and BetterPortalML derived scripts.
What this means is that much of the portal can be uploaded from the
remote "chem portal central site" as an xml document and MyServer scripts
and run in the local protected environment where MyServer lives.
The stuff that runs remotely are the applications that are controled by
proxy and instantiated with the users authorization from the myServer proxy
creation service. Alternatively, MyServer can also connect to the
central server and allow it to run there. This allows the protection
level to range from totally secure local execution of the workbench to
trusting remote execution.
What do you think?
Dennis