[
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
|
One terminology point. ALF does not specify a Service Bus (currently)
although it may leverage one it the future. The reason for this is that
there is no standard for the concept "service bus" and we would have to
pick an implementation. This may be detrimental to the adoption of ALF.
For now I would prefer we didn't use the term since it will be
confusing. ALF uses BPEL to orchestrate services into a logical flow
and defines an event manager (really a dispatcher) to provide a common
entry point for tools and to link service flows.
Some other points
1. I don't see Richards' architectures 1 and 2 as mutually exclusive.
Any combination of any of the diagrams I have seen may occur in a
particular ALF installation. Generally, if a tool is server based, we
might expoect it to provide services directly from its server but there
will be cases when this is not practical and the only way to achieve the
function is to wrap the tool's client with a service. ALF dictates
neither. ALF says only that the services should be provided as SOAP
based web services that are useable from BPEL.
2. While it might seem burdensome to wrap the SCM client with "tomcat"
since the client is running in the locality of the tool it is quite
likely that tomcat is already there since the tool will require it
(assuming java or C++ of course).
3. While it might seem burdensome to install the client for every tool
that needs SCM to materialize files, this is typical for any other SCM
user so I'm not clear why it should be strange.
4. There is no assumption (currently) that routing in ALF is dynamic.
Initially it will be a static configuration. Thus it is necessary to
know where all the tools are at the time you deploy an ALF integration.
It is assumed that you will know that your design requires there to be
an SCM service associated with the tool service and you will configure
your installation accordingly. If you change you installation you must
adjust your deployment but vocabularies can't address that issue.
5. On multiple endpoints, while there are some ALF service flow design
choices concerning a shared "get" vs a number of independent "gets" it
is it chiefly a matter of server/tool deployment configuration and not
relavent to ALF vocabularies. Basically do you call the get service
once for a number of tools or once per tool. It seems likely that a
typical installation would use a common SCM client and a network file
share allowing the tools to share a file space and possibly a workspace.
It is also quite likely that a number of different tools will be
installed on the same physical server. Obviously this has limitations
but they are probably not relevent in most cases. For cases where the
network file share is not practical it may be necessary to set up some
other infrastructure (eg. file system replication) independent from the
ALF integration.
Tim
-----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.
