Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [alf-dev] ALF Source Code Mangement VocabularyMeeting+1-303-928-3232 id 6053141# Wednesday 10:00AM PDT

Richard,

You may have the right approach, I'd have to think about it though. But at the end of the day, when we provide an example integration for an open source tool like CVS, we will need to write that command wrapper for CVS. Unless someone is particularly bored and needs something to do, this will in all likelyhood be a tomcat instance wrapping the cvs command line.

It could very well be that from an ALF perspective, we are making the request to web services on the server which in turn look up the appropriate agent and hit web services there. The web services on the agent are a practical solution to the real problems we are facing. They may not be formally accepted as a best practice though.

The model I would expect to see in many tools at the end of the day is something like:

  +------------+ +-----------+ +-----------+ +-----------+
  | T1 client  | | T1 client | | T2 client | | T2 client | ...
  +------------+ +-----------+ +-----------+ +-----------+
  |   Tomcat   | |   Tomcat  | |   Tomcat  | |   Tomcat  |
  +------------+ +-----------+ +-----------+ +-----------+
        |              |            |             |
  ===================ALF bus/internet===========================
                |                           |
          +------------+              +------------+
          |  Tomcat    |              |  Tomcat    |
          +------------+              +------------+
          | T1 server  |              | T2 server  |
          +------------+              +------------+


But from an ALF perspective, it seems like making requests to the servers is quite attractive. However the communication to the clients is done is only our business insofar as someone involved with ALF will need to write the integrations for some common open source tools to gain adoption.

-- Eric


Richard Title wrote:

On the so-called "workspace" discussion: I view this as more of an
architecture question than anything else, though it does have a bearing on
the vocabulary as I will show below. Let me try to characterize the two
points of view architecturally.

Let's first of all note that most of the tools that are plugged into the ALF
"bus" have both a client portion and a server portion. Of course monolithic
(single-process) tools are also possible, but for generality we should
assume most tools are client/server. For purposes of this discussion,
"client" means "interacts with the end user of the tool", while "server" is
the portion of the tool housing the persistent storage. Generally for a
given tool instance there are many clients and one server.

So let's suppose you have tools T1, T2, T3, etc, all connected to a common
ALF bus. (By "ALF bus" I just mean they are all talking through a web
services API to a common ALF broker. I saw a book which referred to this
sort of architecture as a "enterprise service bus", and I liked the term
"bus", so I adopted it. No pun intended on Tim "Buss" :-) ).

For example, T1 might be an SCM tool, T2 might be an issue-tracking tool,
etc. Thus we would have:


  +------------+ +-----------+ +-----------+ +-----------+
  | T1 client  | | T1 client | | T2 client | | T2 client | ...
  +------------+ +-----------+ +-----------+ +-----------+
        |              |            |             |
  ===============ALF bus/internet===========================
                |                           |
          +------------+              +------------+
          | T1 server  |              | T2 server  |
          +------------+              +------------+


(No significance should be attached to the fact that I put clients on the
top and servers on the bottom - it's just for convenience)

(The "ALF bus/internet" is meant to portray the network connection between
the various components, which might be ALF broker or it might just be their
own proprietary protocols going over the internet... which one is to be
determined by the discussion below)
So, the architectural question is whether you implement ALF by wrapping the
client portion of the tools with an application server (Tomcat), or by
wrapping the server portion of the tools with Tomcat. The 2 possibilities
are shown below:

[1]

  +------------+ +-----------+ +-----------+ +-----------+
  | T1 client  | | T1 client | | T2 client | | T2 client | ...
  +------------+ +-----------+ +-----------+ +-----------+
  | Tomcat     | | Tomcat    | | Tomcat    | |  Tomcat   |
  +------------+ +-----------+ +-----------+ +-----------+
        |              |            |             |
  ===================ALF bus/internet ===========================
                |                           |
          +------------+              +------------+
          | T1 server  |              | T2 server  |
          +------------+              +------------+

Or:


[2]


  +------------+ +-----------+ +-----------+ +-----------+
  | T1 client  | | T1 client | | T2 client | | T2 client | ...
  +------------+ +-----------+ +-----------+ +-----------+
        |              |            |             |
  ===================ALF bus/internet===========================
                |                           |
          +------------+              +------------+
          |  Tomcat    |              |  Tomcat    |
          +------------+              +------------+
          | T1 server  |              | T2 server  |
          +------------+              +------------+


In picture [1], the tool *clients* talk to each other through ALF, while
still talking to their respective servers through their own private
interface. In picture [2], the tool *servers* talk to each other through
ALF, while still talking to their respective clients through their own
private interface.

Now let's talk a bit about SCM workspaces, since this seems to be the issue
that is causing people to advocate for architecture [1]. An SCM "workspace"
is a file area on a client machine where the files under SCM control are
materialized and worked with. An SCM operation has a "workspace context" if
it requires a workspace. Examples of SCM operations that have workspace
context: "Update workspace", "Add files (from a workspace) to source
control", "Check in new versions of files (from a workspace)", etc. Examples
of SCM commands not requiring a workspace context: "Produce a difference
report between stream A and stream B", "List the history of all changes to
file F".

In architecture [1] (wrap-the-client), you deal with workspace context by
determining the right client to send the request to (i.e. the client owning
the workspace). Note in this architecture the burden is placed on the *ALF
broker* to route the command to the correct client. For instance, in picture
[1], if T1 is an SCM tool, the ALF broker would have to decide whether to
route a given request to the first "T1 client" or the second "T1 client".
Presumably this would be done by picking apart the request to determine its
workspace context, and presumably the "workspace" description in our
vocabulary would have enough information in it so the ALF broker can
determine the correct URL to route the request to. For SCM requests not
requiring a workspace context, an arbitrary choice of SCM client could be
made.

Thus a complete flow, assuming architecture [1], would be something like:

1. Some tool (say T2) makes an SCM request
2. ALF analyzes the request to determine what SCM client to send it to, and
based on the request's workspace context, decides to send it to SCM client 1
3. SCM client 1 performs the action by executing the command


In architecture [2] (wrap-the-server), the ALF broker would have a single
point of contact for a given instance of an SCM tool: The SCM server. If the
command has a workspace context, then it is up to the *SCM server* to route
the request to the appropriate SCM client. This assumes a mechanism by which
the SCM server could remote-execute commands on its clients. The SCM tool
would have to create that mechanism, perhaps at install time. What we've
talked about here at AccuRev is installing a simple "command server" when we
install our client, which could be a very stripped down web server that we
could send SCM commands to. Thus a complete picture would look like this:

  +-------------+ +-------------+ +-----------+ +-----------+
  | SCM client 1| | SCM client 2| | T2 client | | T2 client | ...
  +-------------+ +-------------+ +-----------+ +-----------+
  | cmd server  | | cmd server  |
  +-------------+ +-------------+
        |              |                |             |
  ===================ALF bus/internet===========================
                |                           |
          +------------+              +------------+
          |  Tomcat    |              |  Tomcat    |
          +------------+              +------------+
          | SCM server  |             | T2 server  |
          +------------+              +------------+

(Note the "cmd server" in this picture is just a private portion of the SCM
tool, not supplied by ALF)

Thus a complete flow, assuming architecture [2], would be something like:

1. Some tool (say T2) makes an SCM request
2. ALF routes the request to the SCM server
3. The SCM tool analyzes the request, determines it has a workspace context,
determines SCM client 1 owns it, and routes it SCM client 1's cmd server.
4. SCM client 1 performs the action by executing the command

ALF's SCM vocabulary could support either architecture, leaving it up to the
SCM tool to decide which approach it wants to take. However I am still of
the opinion that [2] is architecturally the better approach. It places less
burden on ALF (less complexity in routing SCM requests if you have a single
point of contact per SCM tool), and it leaves SCM decisions in the hands of
the SCM tool (the SCM server decides how to route requests to its clients),
and it is more lightweight (running a full Tomcat/J2EE stack at each client
seems a heavy-handed approach if all you want to do is execute commands).

I hope this clarifies what I am arguing for and why.

Richard Title
AccuRev


_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev



Back to the top