Skip to main content

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

I'd like to suggest an alternative way of viewing the ALF bus:

Because of the "heavyweight" nature of web services and XML (requiring
object-to-XML serialization, wrapping with SOAP for transport,
unwrapping on the receiving end, parsing, and mapping to an object model
in the receiver), web services lend themselves best to large grained
interactions.  For the Client and Server models, I view the server as
having knowledge of the more significant events - perhaps the "commit
points" that would be an appropriate place to raise an ALF event.  So I
view the ALF bus as connecting the servers, rather than the clients in
most situation.

I would have drawn the conceptual figure as:

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

In this figure, the normal client-to-server interactions do not flow
over the ALF bus, instead, only large-grained significant events flow
over the ALF bus.  (Now clearly, if we run ALF over HTTP web services,
we would need Tomcat (or similar) to attach the T1 and T2 servers to the
ALF bus (whether it be SOAP/HTTP/IP or SOAP over an ESB).

So (in general) we envisioned the ALF vocabulary interfaces implemented
as Richard's "wrap-the-server".

For the SCM workspace, I view the "server" as a thin wrapper around a
file system, where the wrapper serves as an agent for retrieving and
storing files. For existing SCM tool clients, they would access the
workspace as they do now - as a file system.  ALF-borne operations would
access the workspace through the ALF vocabulary interface (that thin
wrapper).  That SCM workspace wrapper would normally be located on the
box where the file system resides - which could be the same user machine
as the user runs and SCM client on, or it could be on a shared "build
server".

Regards,
Brian

Brian Carroll
Architect, Eclipse ALF project
www.eclipse.org/alf
Serena Fellow
Serena Software
(ofc)  (503) 617-2436
(cell)  (503) 318-2017
bcarroll@xxxxxxxxxx 


-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eric Minick
Sent: Wednesday, June 07, 2006 8:48 AM
To: ALF Developer Mailing List
Subject: Re: [alf-dev] ALF Source CodeMangement
VocabularyMeeting+1-303-928-3232id 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
>  
>

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

**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.



Back to the top