Re: Queries on certain M2 concepts
On Jul 19, 2006, at 10:48 PM, rakesh dash wrote: Jim, Thanks a lot for your response. 1. In the slide 4, it states to reduce the number of concepts of SCA. How does composite attains it? For example- services are equivalent to entry point, references are similar to external service. The added thing is properties. It keeps similar concepts of modules and adds properties also. How do we think that it redu ces SCA concept when it is adding more functionality to it? Here I would recommend to use the existing module/M1 concept and add things to it instead of doing things from scratch. Let us reuse the functionality which is already in M1. Please clarify. The *specification* has changed and we (Tuscany) are following the specification. I think if you compare UML representations of the .9 spec and recursive model it is dramatically simpler, two of the most apparent examples being: - Components have services and references; there is no need for additional concepts of entry points or external services - We removed the concept of module component. Since module components could also be configured, the notion of composite properties is not really new, although with the addition of XPath and includes, it is significantly more powerful. Also, I'm not sure I follow you but I think having fewer concepts can result in something that is much more powerful. For example, recursion reduces the number of specialized concepts yet is offers many more possibilities than the 2-level model we had before. 2. In slide 11 there is a list of reasons provided which tries giving us explanation of why the current M1 architecture requires refactoring? I would request to provide a one to one mapping of this list to the new concepts of M2 which resolves the issues of M1 architecture. I'm sure this would be helpful and if someone is brave enough to attempt this, I am willing to answer questions. However, since that is a very wide open request (and difficult to tackle in its entirety), my suggestion would instead be to proceed by asking specific questions. Apart from this, I do agree with you that the wiring concept in M2 may be simplified with all the present functionalities. We should certainly make it more simplified keeping the existing functionality. It would be great if you could give me a clear picture on how targetInvoker works. I understand that the targetInvoker resolves the target instance by resolving scopeContainer. It actually invokes on Component, which uses a scope container to resolve an implementation instance. I think the whole process should have the address of target instance using which the target invoker may locate the target instance. Outside of a callback and reference that invokes over a binding, why does a target invoker need the address of the component? In SCA, components cannot be directly exposed or directly invoke outside the boundaries of their parent composite; all cross-composite invocations must flow across services and references. This means we can statically analyze and wire all component-to-component invocations, alleviating the need to use addresses for intra-composite invocations. I am not sure where this address is provided to the targetInvoker? Do the ScopeContainer provides the target address/reference to the targetInvoker? The scope container is responsible for tracking implementation instances using whatever mechanisms are appropriate (e.g. session/ conversation id, etc.). That should be opaque to clients of the scope container, such as Components. Can you please clarify? Can you please let me know the packages/ classes which I can go through to get a good idea about it. In core there is an implementation package. There are also samples. My recommendation would be to start perhaps with the eager init or calculator samples and then work your way into running the test cases. If you have any questions, I'll try to help as best I can. Jim cheers, Rakesh. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Queries on certain M2 concepts
Jim, Thanks a lot for your response. 1. In the slide 4, it states to reduce the number of concepts of SCA. How does composite attains it? For example- services are equivalent to entry point, references are similar to external service. The added thing is properties. It keeps similar concepts of modules and adds properties also. How do we think that it redu ces SCA concept when it is adding more functionality to it? Here I would recommend to use the existing module/M1 concept and add things to it instead of doing things from scratch. Let us reuse the functionality which is already in M1. Please clarify. 2. In slide 11 there is a list of reasons provided which tries giving us explanation of why the current M1 architecture requires refactoring? I would request to provide a one to one mapping of this list to the new concepts of M2 which resolves the issues of M1 architecture. Apart from this, I do agree with you that the wiring concept in M2 may be simplified with all the present functionalities. We should certainly make it more simplified keeping the existing functionality. It would be great if you could give me a clear picture on how targetInvoker works. I understand that the targetInvoker resolves the target instance by resolving scopeContainer. I think the whole process should have the address of target instance using which the target invoker may locate the target instance. I am not sure where this address is provided to the targetInvoker? Do the ScopeContainer provides the target address/reference to the targetInvoker? Can you please clarify? Can you please let me know the packages/classes which I can go through to get a good idea about it. cheers, Rakesh.
Re: Queries on certain M2 concepts
Hi comments inline On Jul 16, 2006, at 10:17 PM, rakesh dash wrote: Hello, I am starting to understand the basics of certain M2 related concepts and am trying to navigate the src tree of the run time. It would be great if someone may clarify few of my basic queries on it. My apologies in advance, if I have misinterpreted any concept wrongly. Please rectify it and clarify. Thanks in advance. 1. Due to various reasons the existing core architecture was considered to have substantial refactoring.It would be great if an one to one mapping could be established between these reasons and how the new update in the core/runime may solve it.This may help us to get a good understanding. We did a long presentation on this a while back. Unfortunately, it was not recorded (a good reason why mailing list discussion is better than presentations). There are slides from this under sandbox/chianti/ doc that lay out the reasoning behind the refactors and basic chianti architecture. I would have a look there and post questions to the list as they arise. 2. How the new model reduces the number of SCA concepts? For example-composite seems to be more bulkier than the previous 'module' in M1. In the 'composite' model most of the concepts are similar to the module. An added properties field is present. While composite adds more functionality, it seems to be making the simplest SCA component more complicated. I think it actually reduces the number of concepts since we no longer have the module component specialization. The design is also more symmetrical. Just a side note, a module and a composite are different concepts, the former being more about a unit of deployment, which is something we haven't addressed very well in the spec as of yet. As a different instance, the wiring concept has inbound and outbound concepts which has interceptors and other features. Again making things complicated.Please clarify. We have these two concepts for several reasons: - In SCA, policies can be applied to the source (outbound) or target (inbound) side of a wire - We need to have the ability to re-wire at runtime, e.g. change a target and reconstitute the wire. IMO having two sides like this actually reduces the complexity in performing this operation That said, I do agree the runtime invocation model is complex. The important question is whether it is more complex than it needs to be. That said, we always need to look at simplifying the design without loosing capabilities. I do think, however, there is always going to be a base level of complexity to meet the use cases we have in mind (see below). It would be good to have more eyes on simplifying the design so any help would be greatly appreciated. 3. While I am not sure of how the target Invoker dispatches a request to the target implementation, I think the TargetInvoker will have address or reference for the Target instance using which it may locate the target implementation. In the slides mentioned above, there is a section which explains this. One of the key things about the runtime (and SCA in general) is that it attempts to perform static analysis on wires since it most often knows the source and target, optimizing where appropriate. This is one of the key differences with other approaches such as JBI. Hence, most of the time a TargetInvoker (which is per operation, not per service) is set to the target *component* and no dynamic routing is necessary. The one detail here is that it is not necessarily set to the target component *instance*; during an invocation it is the job of the component to delegate to its scope container to return the correct instance. There are two caveats to the above. First, one optimization is that certain target invokers may cache the target instance (e.g. when invoking from a lesser scope to a larger scope, session--- module). The other caveat is that for callbacks we will need a way to dereference the correct callback instance. I'm not sure this is the job of the target invoker, though. Now is it possible to represent this address or reference in such a format which can be stored and saved in file? I would say it has to be serializable in some form supported by the transport binding (in the case of in-VM, Java serializable, other protocol bindings may have different requirements). This may give another option using which the wire invocation handler(at the source)may locate the target address. This may avoid storing always storing the TargetInvoker to the source wire invocation handler everytime before an invocation is initiated. Again, I think the important thing here is static optimization. For *all* component-to-component invocations in SCA, the source and targets are known since all remote wiring must be done through composite references and services. Hence, there is no reason to perform an address lookup at this level.
Queries on certain M2 concepts
Hello, I am starting to understand the basics of certain M2 related concepts and am trying to navigate the src tree of the run time. It would be great if someone may clarify few of my basic queries on it. My apologies in advance, if I have misinterpreted any concept wrongly. Please rectify it and clarify. Thanks in advance. 1. Due to various reasons the existing core architecture was considered to have substantial refactoring.It would be great if an one to one mapping could be established between these reasons and how the new update in the core/runime may solve it.This may help us to get a good understanding. 2. How the new model reduces the number of SCA concepts? For example-composite seems to be more bulkier than the previous 'module' in M1. In the 'composite' model most of the concepts are similar to the module. An added properties field is present. While composite adds more functionality, it seems to be making the simplest SCA component more complicated. As a different instance, the wiring concept has inbound and outbound concepts which has interceptors and other features. Again making things complicated.Please clarify. 3. While I am not sure of how the target Invoker dispatches a request to the target implementation, I think the TargetInvoker will have address or reference for the Target instance using which it may locate the target implementation. Now is it possible to represent this address or reference in such a format which can be stored and saved in file? This may give another option using which the wire invocation handler(at the source)may locate the target address. This may avoid storing always storing the TargetInvoker to the source wire invocation handler everytime before an invocation is initiated. It might add to the interoperability. Please let me know your opinion.
