| RE: [alf-dev] SCM Workspace discussion |
|
[in response to Mark’s email] I respectfully disagree, I think (A) is
the wrong architecture, and I’ll explain why below. The issue is what software do you expect
to be installed and running on each SCM *client*,
in a web-services world. Let’s drop back for a moment and
talk about real-world examples outside of the software-tools world. For
example, say I order a book from amazon.com, or a request my bank balance from
bankofamerica.com. In those examples, I (the client) sends a request to a
centralized server. I do *not*
send the request to an Apache server running on my home PC which invokes a
client-executable that I previously installed, that contacts the server through
some private socket interface… I mean, in principle it could be
implemented that way, but that is not normally what one thinks of as a web (or
service-oriented) architecture. That would just be old-fashioned client/server architecture
with some browser window-dressing. One of the expectations of web-interfaces (and
web-services-interfaces, I think) is that you can access the service with zero
(or at least minimal) install on the client side. “But SCM is different from those
examples… the SCM tool needs to update local files on the client side”
I hear you saying. Well yes, and that adds some challenge. But it does not make
it impossible. Let me tell you how we solved the web-interface problem
back when I worked on ClearCase Web (in a previous job). The architecture
looked like this: Server-side -----------
+--------------------+
| ClearCase server(s)|
+--------------------+
+----------------------------+
| CCWeb server (Apache-based)|
+----------------------------+
|
| Client-side
| HTTP-based interface -----------
|
| +-----------+
+-----------+ | Client
| | Client |
. . . | (Browser)
| | (browser) | +-----------+
+-----------+ In the
above picture, you have the (one) CCWeb server running on the server-side and
presenting a single URL (for instance http://myserver.mycompany.com/ccweb) to
all the clients. The clients, which are browser-based, go to that URL and
login. Once logged in, they can do any ClearCase operations they want,
including creating (local) workspaces, updating them, etc. In this
picture, workspace management (e.g. writing files on the client machine) is
accomplished by a signed Java applet that is downloaded from the server as part
of the HTTP-based interface, and launched from the browser. The key
point is that no ClearCase software needs be installed in advance on the client
machines for this to work. Nor do they have to share a filesystem with the
server. It just works. That’s what’s expected in a web world. (By
the way, having client A “push” files to client B was not a
requirement, and was not supported. That would have security and implementation
problems.) Getting
back to ALF and web services, I just don’t think running a web server on
every SCM client machine, and having that server turn the requests into SCM commands,
is the right architecture for the web. After all, what’s the
fundamental difference between that and simply running the commands on the
client machine? Why not just standardize on an SCM command language, and have
the requester do a Java Runtime.exec() to invoke standardized SCM commands, if
that’s all we’re doing? My goal
here is to come up with the *right*
implementation architecture for SCM in ALF, not just what’s most
expedient. Wrapping existing SCM CLI’s with a Tomcat server on each
client seems to me expedient but architecturally wrong. As to
what I think *is* the right SCM architecture
for web services… Well, I agree with Mark that Tim’s B1/B2 (us
implementing a common Storage Service) would be biting off too much. I think
the right answer is for us to provide the *mechanism*
by which SCM systems could download and run a workspace manager, but not
actually supply the workspace manager itself. Go back to the CCWeb architecture
for a moment – the reason it was implementable at all is that HTTP/browsers
provide a mechanism for downloading and running trusted code on the client
(e.g. signed Java applets). Can ALF provide something like that? I think this
is something like Tim’s B3, but with us providing a mechanism for the SCM
system to run its workspace manager on the client. Does
this make sense? Richard
Title AccuRev |