[alf-dev] Workspace discussion

[Mark Phippard <markp@xxxxxxxxxxxxxxx>]

I view the relationships as being more like this:



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


Tool client talks to Tool server using capabilities already existing in 
tool.  Servers raise ALF events.  Servers will typically provide web 
services interface that expose actions that the customer can use to build 
service flows.  It is possible that some types of tools would only raise 
events, and others would only provide services.  Whether the web service 
is physically part of the "main server" or resides on another system is 
purely an issue for the tool/customer to decide.  As an example, the 
server for our product resides on OS/400.  Some customers will run the web 
application server on the same physical server, others will run it on a 
Linux/Windows server.  Some run one copy on an internal server and one on 
an external server.  In any of the cases, the application server layer 
just talks to the backend physical server using the internal product API.

In the case of SCM, where and how many services are running would 
ultimately be based on the capability of the SCM tool.  If the tool 
requires physical access to the disk to manage a workspace, you would need 
to run the service on whatever physical systems you wanted to touch with 
an ALF service flow.  If the tool has its own "agents" already in place 
that allow it to update systems "indirectly" then you would likely only 
need one service.

>From the point of view of an ALF vocabulary, I think we should keep this 
as simple as possible and let the tools and customers handle the 
deployment and implementation.  If we try to solve these other issues, we 
will never "get out of committee".

Mark



_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________