Thanks Hinde, I think I'm starting to get it;-) Another question in line. I might find the answer in the paper you reference so I'll go off and read that but I'll ask here anyhow just in case there is an easy answer.
Simon On Fri, Jun 20, 2008 at 4:27 PM, Hinde Bouziane <[EMAIL PROTECTED]> wrote: > Simon Laws wrote: > >> On Fri, Jun 20, 2008 at 1:30 PM, Hinde Bouziane <[EMAIL PROTECTED]> >> wrote: >> >> >> >>> Simon Laws wrote: >>> >>> >>> >>>> On Fri, Jun 20, 2008 at 8:33 AM, Hinde Bouziane <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Hi >>> >>> >>>> This is an interesting thread. Can you give me an idea of : >>>> >>>> >>>> 1 - how frequently the logical components (as opposed to the instances >>>> of >>>> those logical components) change. >>>> >>>> >>>> >>>> >>> Do you mean logical composition? >>> >>> For me the "logical" composition is the application description that >>> represents the designer point of view, before execution. It kept the >>> same. >>> An instance of the composition will be the architecture of the >>> application >>> at execution. It can be different from the logical. In the example (A;B), >>> I >>> added the Proxy which is not in the logical composition. The result is an >>> instance of the original composition that have an architecture changing >>> at >>> execution. The frequency of changes depends on the both the execution >>> time >>> of tasks in components and the policy adopted to manage the evolution of >>> the >>> workflow. >>> >>> For example: >>> - A policy can be the one that I cited in the (A;B) example, where a >>> component is created once the flow reaches it. The frequency of changes >>> depends on the flow and time execution of tasks. If the task of A takes >>> one >>> day, the manager of the application architecture creates B once this task >>> is >>> finished. >>> >>> - A policy can be based on prediction mechanisms to create in advance >>> components that may be used in a near future in the flow. Before the >>> completion of the task of A, B can be created. >>> >>> I hope that help understanding, Do not hesitate to tell me if something >>> is >>> still ambiguous. >>> >>> Regards, >>> Hinde >>> >>> >>> 2 - how frequently the workflow that directs the order of execution of >>> >>> >>>> these >>>> components changes >>>> For example, Is it every request, every minute, every six months, etc. >>>> Regards >>>> >>>> Simon >>>> >>>> >>>> >>>> >>>> >>> >>> >> Thanks Hinde >> >> I don't know it this helps but let's talk about the distinction between >> how >> an application is assembled and the way that work flows through it at >> runtime. From an SCA point of view each time work flows through an >> assembled >> application it may take a different route. This depends on the business >> logic in each component in the application. This is true even though we >> may >> only change the description of the composite application every 6 months. >> >> > Yes, that is usual in assembly models of existing components models. The > assembly model like in SCA does not capture the flow of an application > execution. This flow is hidden in both components implementation and > (usually) a main code that direct the flow of execution/component usage. In > our case, we built an assembly model that appears as a combination of a > classical assembly model (to express references-services dependencies) and a > workflow language (to express data flow and control flow dependencies > between components). A component in our model is a classical component, > like an SCA component, extended with the concepts of tasks and > input/output data ports. These concepts are projected to a set of > predefined/automatic generated services/references (at the end we obtain an > SCA component). > > So to build an application, we define/develop SCA components but we don't > use purely the SCA assembly model but another one. A built assembly > expresses the flow of execution of tasks and references-services > dependencies. From this assembly we can extract the sequence of actions to > create/destroy components and move data from components to others during the > execution; this mainly according to the expressed flow. > > > An example, a digital film rendering application which, on a frame by >> frame >> basis does the following (I'm just making this up b.t.w). >> >> 1. Apply wire frame >> 2. Render background >> 3. If there are characters in the frame render characters. >> >> In the SCA composite for such and application I could imagine 4 components >> >> A. FrameRenderingCoordinator >> B. WireFrameProcessor >> C. BackgroundRenderer >> D. CharacterRenderer >> >> Where the FrameRenderingCoordinator contains a piece of workflow that is >> wired to components B, C & D and always calls components B & C and then >> makes a decision whether to call D or not depending on if there are >> characters in the scene. >> >> To spread load across machines we could deploy these components into a >> clustered environment that supports SCA (see demos/load-balancing-webapp). >> Alternatively we could write some new binding infrastructure that is able >> to >> spray work out based on some set of policy(we can't do this today). >> >> In both of these cases the application developer just assembles the >> business >> application and pays no attention to how the work is distributed. >> >> I suppose I'm trying to demonstrate here how I think about SCA >> applications. >> In your case you have some interesting infrastructure ideas, e.g. >> predictively creating component instances if it is anticipated that flow >> will reach them in the future. It's unclear to me how you want to >> represent >> these kinds of rules. >> >> >> > The flow is anticipated thanks to the assembly model that propose. Because, > it is difficult to make figures by email, you can take a look in > > https://www.irisa.fr/paris/bibadmin/uploads/pdf/0.21342000%201213723399_paper.pdf > > > Are you suggesting changes to the details of the Tuscany runtime >> infrastructure to accommodate these improvements without the application >> developer being aware? >> >> > Not exactly. We aim to use SCA Tuscany runtime to realize our proposal. > The problem that I'm facing is to use it for dynamic creation/removal of > components, nodes, and components within nodes, that without having to > preliminary describe all nodes, their placement and their content (like I > explained in previous message). That should be decided during the execution > (decide for example the placement of a component, then its node) once the > flow reach it). Are you treating components like a Job such as you might encounter in Grid schedulers or, for example, in Globus or OMII. I'm asking as I'd like to understand the scenario in which a component is placed on a new node. Is this just in the case where new physical computers are added to the network or is this a general purpose idea where components are applied to available resources. If the latter do you think there is a difference between assigning a component to all nodes where they might be used and then later choosing which one you are going to use (remember assigning a component to a node doesn't actually mean an instance will be created there) versus only assigning components to nodes when the time comes to use the component. > > Are you suggesting that the application itself should be making these >> decisions, for example we could rearrange our example flow to read >> >> 1. If there are characters in the frame ask character renderer to get >> ready >> while I do steps 2 & 3 >> 2. Apply wire frame >> 3. Render background >> 4. If there are characters in the frame render characters. >> >> > It is not the application itself that make decisions but a manager that we > have to develop able to extract the actions to do from the assembly > description of the application to be executed. This manager is expected to > use the Tuscany runtime to create/destroy/connect components/nodes. The > manager also decides about the placement of components and the content of > nodes which can evolve during the execution. So it sounds to me like the manager is a new piece of infrastructure that decides where and when components are deployed and used. Can policies attached to the assembly model affect the behaviour of this manager? > > Regards, > Hinde > > Regards >> >> Simon >> >> >> > >
