Issue 4025: New component issue: connection failure recovery (components-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them? The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario. Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.) The following questions arise: When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.) What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference? What happens during run-time when Y invokes an operation on A and: The application server process containing X has terminated (COMM_FAILURE returned)? Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)? The underlying object supporting A in X has been deleted (INV_OBJREF returned)? An unexpected application error occurs (UNKNOWN returned)? With respect to error detection and recovery: How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party. How does one indicate the set of objects that can recover the error? How does one indicate whether the error should be detected? How does one indicate whether recovery should be attempted? How does one indicate the recovery strategy, especially if there are several objects that can recover the error? If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list? Where should this information be specified: IDL, CIDL, or XML? What are the implications when the components have different type and container semantics? Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y? Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible? Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X? In these questions, what happens if X is an entity and Y is transient? In these questions, what happens if Y aborts rather than X? Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics. Resolution: rejected Revised Text: Actions taken: November 7, 2000: received issue May 13, 2002: closed issue Discussion: The CORBA Component Model Specification does not address fault tolerance problems in general. However, a CCM implementation is free to use for instance the OMG Object Transaction Service (OTS) and the OMG Fault Tolerance Service defined in CORBA 2.5 in order to address any failure and recovery problems during the deployment and execution of CCM applications. If a standard for a Fault Tolerant CORBA Component Model is strongly required by the industry, then this would be addressed by a future RFP. End of Annotations:===== ate: Tue, 07 Nov 2000 15:04:04 -0600 From: Tom Hawker X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: New component issue: connection failure recovery Content-Type: multipart/alternative; boundary="------------E131D997F5A1EE1A7D2E2480" X-UIDL: \>-e9dlQ!!**0!!2YG!! See the CORBA Components Model specification, orbos/99-07-01. The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them? The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questionWhat happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference? What happens during run-time when Y invokes an operation on A and: The application server process containing X has terminated (COMM_FAILURE returned)? Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)? The underlying object supporting A in X haAssume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X? In these questions, what happens if X is an entity and Y is transient? In these questions, what happens if Y aborts rather than X? Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics. s been deleted (INV_OBJREF returned)? An unexpected application error occurs (UNKNOWN returned)? With respect to error detection and recovery: How does one indicate the set of objects that can detect the error? Possible objectHow does one indicate the set of objects that can recover the error? How does one indicate whether the error should be detected? How does one indicate whether recovery should be attempted? How does one indicate the recovery strategy, especially if there are several objects that can recover the error? If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list? Where should this information be specified: IDL, CIDL, or XML? What are the implications when the components have different type and container semantics? Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y? Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the Xs are Y, Ys related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario. Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element define The following questions arise: When does the connection take place, during assembly construction or on reference to the ports the association. Said element From: "Jean-Christophe Dubois" To: Cc: References: <4.2.0.58.20001108113540.050d9a00@emerald.omg.org> Subject: Re: issue 4025 -- Components FTF issue Date: Thu, 9 Nov 2000 11:01:18 -0500 Organization: Open Network Engineering MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: (Y%e9@Cmd9#0D!!R(He9 Hello Tom, Well, these are some very interesting questions. Part of them can be covered by the OMG fault tolecance spec or the OMG transcaction service spec. However I have to admit if the OTS is integrated in CCM, it seems the CCM spec doesn't give a lot of clues on how the CCM spec integrates into a fault tolerant environment (or vice-sersa). You have to come up with your own solution at this point. It certainly mean extending a little bit the CCM capabilities for the container and also possibly some of the DTDs used for deployment. Now, I don't think the CCM spec should try to redefine what is already available in the Fault Tolerance spec, however it could certainly give some hints and hooks to (optionaly) integrate the fault tolerance service. Too bad this doesn't seem to be the case for now. For your specific questions, I am trying to give my view of them below. CCM team members may have different opinion on this and I would be interested to know what they think. Regards JC ----- Original Message ----- From: "Juergen Boldt" To: ; Sent: Wednesday, November 08, 2000 11:36 AM Subject: issue 4025 -- Components FTF issue This is issue # 4025 Tom Hawker New component issue: connection failure recovery The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them? The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario. Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element's providesport acquires X's facet A and assigns that through the usesport to Y's interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.) The following questions arise: When does the connection take place, during assembly construction or on reference to the port's receptacle inside Y? JCD: I believe it is the assembly job to get the A facet reference on component X (provide_facet("facetName")) and provide it to the component Y (connect("receptacleName", facetRef)). Obviously it can only be done after the 2 component are instanciated. That is, is this immediate or lazy initialization? JCD: The generated code of the connect() operation will certainly try to narrow() the received reference before calling the connect_receptacleName() generated method. The narrow() most of the time end up as an _is_a() operation that will actually activate and ping the X facet. It doesn't mean there is a "connection" as such put the path will be tested. When are event channels created or attached? JCD: a publish port creates its private channel (create_channel()) and and emits port lookup an already existing channel (obtain_channel()). It is up to the generated code or user code to determine when it needs to be called. Can the producer delay creation or attachment until a push() operation? JCD: Delaying creation of a channel (for "publish" port) may not be a good idea because consumers will want to register to it (before events are sent to it). Now the attachement to an "emits" channel could certainly be delayed until the first push() operation as the channel is supposed to exist anyway (but do you want to do it? I imagine you want to check that ressources are availble [including even channels] before doing real operations). Can the consumer accomplish the creation? JCD: For the "publish" port it is not possible as it is created by the component that "publish" events. For a port were supliers will "emits" it seems to be possible Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.) JCD: A "publish" port is a 1:n relationship (where you are supposed to be able to control n at the publisher level.). An emits port is a m:n relationship per definition. What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference? JCD: If this is during the deployment phase (assembly.build()) it is up to the assembly object to stop there and return FALSE on the build() call. It is not clear how cleanup could/should occur. Wat happens during run-time when Y invokes an operation on A and: The application server process containing X has terminated (COMM_FAILURE returned)? Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)? The underlying object supporting A in X has been deleted (INV_OBJREF returned)? An unexpected application error occurs (UNKNOWN returned)? JCD: I believe that it is up to your code to determine what it want to do in any of these cases. Most likely, it should report the problem to a monitoring system and wait for somebody to take action and reconfigure/fix things. Unless you can come up with intelligent strategy to fix the problem. But some of the above exception might not be transient and reconfiguring (redeploying) the assembly might not fix it. The point is that only your component knows how important this "missing" connection is and if it can work in degraded mode without it. In the scenario you have described until now this is the assembly that has created the Component instances and connected them together. It is doubtfull that the component can do anything by itself to recover from that. Sending an SOS and waiting for help seems like a reasonable decision in this scenario. With respect to error detection and recovery: How does one indicate the set of objects that can detect the error? Possible objects are Y, Y's home, Y's container, X's container, X's home, the assembly, an independent third party. How does one indicate the set of objects that can recover the error? How does one indicate whether the error should be detected? How does one indicate whether recovery should be attempted? How does one indicate the recovery strategy, especially if there are several objects that can recover the error? If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list? Where should this information be specified: IDL, CIDL, or XML? What are the implications when the components have different type and container semantics? Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y? JCD: Here the scenario change litle bit. Component X is now transient with means more likely that it is a service or session component. It should also imply that the component is created by Y when it need it and not by the assembly (component X is instantaited for the duration of the service [1 method call ] or the duration of the session [ open, use, close ] ). It is then destroyed (implicitely or explicitely) when Y doesn't need it anymore. - A service Component is stateless so it should be safe to recreate a new one and use it. - A seesion component might not be able to take over where the previous component left (as they are not supposed to have persistence). Therefore you may have to back up (abort) and restart the all session. Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X's be deleted [dismissed] after the old X is again accessible? JCD: the garbage collection is not a strong point of CORBA. However it is up to you to implement your own "policies" in your component if the reference to a session or service component was to be lost (let's say that Y crashes after creating X). It can be implemented either in the component, the container, or maybe the home interface. May be something could be added to the spec in the various XML files about this if it was to be handled by the (session) container. Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X? In these questions, what happens if X is an entity and Y is transient? In these questions, what happens if Y aborts rather than X? JCD: it depend on your operation and it depends if you are using the transaction service. You should be able to achieve this using the transaction service. If you don't want to use it you have to be a lot more carefull. Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics. ================================================================ Juergen Boldt Senior Member of Technical Staff Object Management Group Tel. +1-781 444 0404 ext. 132 250 First Avenue, Suite 201 Fax: +1-781 444 0320 Needham, MA 02494, USA Email: juergen@omg.org URL: www.omg.org ================================================================ From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Thu, 9 Nov 2000 14:36:40 -0600 Message-Id: Subject: RE: issue 4025 -- Components FTF issue MIME-Version: 1.0 TO: jcd@one.com, thawker@atdsprint.com CC: components-ftf@emerald.omg.org Content-Type: multipart/mixed; boundary="openmail-part-34a7460d-00000001" X-UIDL: HX+e9i~\d9f0X!!_-1!! I've included some clarifications and additional thoughts. Let me reiterate that this is dealing with recovery of connections that an assembly establishes automatically. In other words, the connections are accomplished transparently to component operation -- there is no "application" behind things to help here. > -----Original Message----- > From: Jean-Christophe Dubois [mailto:jcd@one.com] > Sent: Thursday, November 9, 2000 10:01 AM > To: thawker@atdsprint.com > Cc: components-ftf@emerald.omg.org > Subject: Re: issue 4025 -- Components FTF issue > > > Hello Tom, > > Well, these are some very interesting questions. > > Part of them can be covered by the OMG fault tolecance spec or the OMG > transcaction service spec. However I have to admit if the OTS is > integrated in CCM, it seems the CCM spec doesn't give a lot of clues on > how the CCM spec integrates into a fault tolerant environment (or > vice-sersa). You have to come up with your own solution at this point. > It certainly mean extending a little bit the CCM capabilities for the > container and also possibly some of the DTDs used for deployment. Actually, I don't think any of these questions are handled by the FT spec at all! Here at Sprint we've spoken with Louise Mosier and her group at Eternal Systems a few times. Looking over the spec, what it gives you is object replication and automatic message redirection. It does this by "cheating", using portable interceptors (pretty cool). If I construct my event channels or [facet] interface objects using the FT service, perhaps transparently, then I wouldn't see any errors unless my entire platform could no longer access remote platforms, where this does not necessarily lose client accessibility (the user that started the request). Then, I would still be faced with how to handle the failures. Eventually, the FT service would need to notify me that NO object replica was available. Having the assembly logic build any connection automatically for me is of only minimal use unless it also handles or otherwise provides some error recovery on failure. (I really don't care if that "recovery" were to tear everything down and return an error.) I'm willing to let all of this be "advanced" capabilities specified solely in the XML, but I think we'll find that some or all of this can benefit from code generation, and therefore we want to put it in the IDL/CIDL. There seems to be an inherent assumption here that most user's would not be worried about such failures. But the trend in the industry is toward more highly distributed and interconnected software systems, where these systems must be highly available and highly reliable. If the user can perceive the system as 100% 24x7, it does not matter how that is finally accomplished. Yet most of the "smarts" will be in software, which will become more componentized over time. The more assistance we give to the problem now, the less reinventing we will be doing later. Of course, I have some problems with the formal model of components and homes (and assemblies). Just as soon as I finish writing my complaints up, I'll post these as another issue. > Now, I don't think the CCM spec should try to redefine what is already > available in the Fault Tolerance spec, however it could certainly give > some hints and hooks to (optionaly) integrate the fault tolerance > service. Too bad this doesn't seem to be the case for now. I agree there should be no redefinition. Hints and hooks would be nice, and they should probably be defined as extensions to the FT spec. In some of my recent correspondence with Eternal Systems, Louise has said that they have a prototype model that can run transparently beneath the CCM. That would certainly provide help for failures other than those directly related to logic defects. And there is no reason why a vendor could not implement an FT-compliant (or capable) set of containers, POA, ORB, or whatever. > For your specific questions, I am trying to give my view of them below. > CCM team members may have different opinion on this and I would be > interested to know what they think. I appreciate your efforts. I will add clarifications to your comments. > Regards > > JC > > ----- Original Message ----- > From: "Juergen Boldt" > To: ; > Sent: Wednesday, November 08, 2000 11:36 AM > Subject: issue 4025 -- Components FTF issue > > > This is issue # 4025 Tom Hawker > > New component issue: connection failure recovery > > The CCM does not describe the behavior of the system in case of various > fault situations. In particular, this issue only concerns itself > with the > recovery mechanisms of event subscriptions or facet receptacles that were > automatically established through an assembly. While it is outside > the > scope of the CCM to describe general fault behavior, it is felt that > recovery mechanisms (or their absence) should be explicitly > identified for > connections automatically built between ports. Otherwise, why go to the > trouble of building them, since error detection and recovery > wrappers would > be needed around any use of them? > > The following scenario highlights the various situations. It assumes that > the components are deployed in separate processes on different platforms so > that one of the two components remains operational despite failure > or > inaccessibility of the other. The scenario primarily deals with the > recovery of an interface provided by Component X and used by > Component Y. > Appropriate questions related to event channels are also given where > applicable. Event channels are themselves more difficult because the > notification services adds yet another object to the set that may > fail > during the scenario. > > Scenario: Component X declares that it provides an interface A. Likewise, > Component Y declares that it uses interface A. (Or, X emits or publishes > event A to which Y subscribes.) Instances of the components are combined > through an assembly. Now, the assembly description indicates that a > connection is to be built between X and Y. That is, the descriptor defines > connections in which a connection element defines the association. Said > element's providesport acquires X's facet A and assigns that through the > usesport to Y's interface receptacle. (For events, read these as emitsport > or publishesport and subscribesport.) > > The following questions arise: > > When does the connection take place, during assembly construction or on > reference to the port's receptacle inside Y? > > JCD: I believe it is the assembly job to get the A facet reference > on > component X (provide_facet("facetName")) and provide it to the component Y > (connect("receptacleName", facetRef)). Obviously it can only be done after > the 2 component are instanciated. TSH: I disagree. All I really have to bind together is the way for the referring component to create or otherwise acquire the referent. I can use connect() for static components or when the reference I use is to a "proxy" [my preference]. Run-time cost is minimum; the logic can be automatically generated from suitable implementation stubs. In fact, you can create a tree of classes to provide what you want: class -- primary abstract class defining interface class _stub :: -- implements marshalling, etc. class _impl :: -- provides basic implementation (skeleton) class _proxy :: -- acts as a proxy to defer to objref The user can then write a subclass of the proxy, or override the default implementation generated automatically, to provide fault recovery. > That is, is this immediate or lazy initialization? > > JCD: The generated code of the connect() operation will certainly > try to > narrow() the received reference before calling the connect_receptacleName() > generated method. The narrow() most of the time end up as an _is_a() > operation that will actually activate and ping the X facet. It > doesn't mean > there is a "connection" as such put the path will be tested. TSH: I'm not sure what your answer means. I personally am more in favor of dynamic connection, even dynamic instantiation of the target component [here, "X"]. In several systems I have built where there are intercomponent dependencies, the client's request actually determines whether the service uses a dependency. In such cases I might not want to even start an X until I need it, but I would want to keep it around after I had. This would tend to minimize resource utilization, I would think. I guess I think of assemblies in a very different way than the proposal. To me, an assemly is merely a deployment convenience that describes how multiple pieces of interacting software relate. It doesn't mean that I force on the user a particular set of semantics with respect to when the different pieces get brought up. I would treat an assembly exactly like I would treat an individual component (which includes using them as part of other assemblies, which is another issue). The only piece that is "visible" is the interface part that I contacted, however the home got involved to create it. The other pieces can be created at the same time or delayed until referenced; this should be a deployment specification property so that suitable code can be generated to create as needed. > When are event channels created or attached? > > JCD: a publish port creates its private channel (create_channel()) > and and > emits port lookup an already existing channel (obtain_channel()). It is up > to the generated code or user code to determine when it needs to be called. TSH: OK, how, when, and where is the emits channel created? I find it crass in the extreme to require me to configure the environment externally to the component structure in order to prebuild channels. If anything, the channel should be created on first reference by any component, emitter or subscriber. Make this another XML attribute? > Can the producer delay creation or attachment until a push() operation? > > JCD: Delaying creation of a channel (for "publish" port) may not be a good > idea because consumers will want to register to it (before events are sent > to it). ... TSH: Since a subscriber must contact the publisher in order to establish the event subscription, delayed creation would be possible. > ... Now the attachement to an "emits" channel could certainly be delayed > until the first push() operation as the channel is supposed to exist anyway > (but do you want to do it? I imagine you want to check that ressources are > availble [including even channels] before doing real operations). TSH: Not necessarily; it depends on the purposes behind the channel. It is certainly possible - and desirable - to have "low-grade" events that may or may not be published or propagated through the system. An example would be debugging notifications, such as that supported by the Unix logging daemon syslogd. You can have them or not... Perhaps we should be able to declare events as "optional"? > Can the consumer accomplish the creation? > > JCD: For the "publish" port it is not possible as it is created by > the > component that "publish" events. For a port were supliers will > "emits" it > seems to be possible TSH: I fail to see why the subscriber cannot create the channel, where the publisher attaches to it if present. All you need is a mechanism that guarantees uniqueness to the individual component instance. Since this is all being done as part of an assembly, we should be able to get some concept of naming by "ownership"... > Can an m:n emitter to consumer notification matrix be built? (The > specification is unclear on this.) > > JCD: A "publish" port is a 1:n relationship (where you are supposed > to > be able to control n at the publisher level.). An emits port is a > m:n > relationship per definition. TSH: If this is the case, then the documentation for emits ports is highly misleading. I distinctly remember reading this and noticing that one either had 1:n channels or n:1 channels. While n:1 may be indicative that the "1" corresponds to an NS proxy, thereby permitting the n:m construction, it certainly is not obvious. Perhaps this part of the document needs to be edited somewhat. > What happens if the interface reference to A cannot be acquired because (1) > X has failed or is inaccessible, (2) X fails during the get operation, or > (3) X returns a nil reference? > > JCD: If this is during the deployment phase (assembly.build()) it is up to > the assembly object to stop there and return FALSE on the build() call. It > is not clear how cleanup could/should occur. TSH: The problem with this approach shows up in your comments to the next question. You indicate that "only your component knows", etc. How can we say that an assembly must stop when, in fact, the overall system and application design indicate whether the inaccessible item can [temporarily] be ignored safely during build? Again, there is an inherent assumption that behavior should be "all or nothing" when, in reality, it will always be "what can hobble along". It's not that I do not want robust systems, but that I must live with imperfection. I should therefore avoid an incomplete, vague, or [worse] inconsistent treatment in the spec. Of course, the subsequent objection that I can always instantiate the reference by hand removes the need for assembly automation in the first place. > What happens during run-time when Y invokes an operation on A and: > * The application server process containing X has terminated (COMM_FAILURE returned)? > * Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)? > * The underlying object supporting A in X has been deleted (INV_OBJREF returned)? > * An unexpected application error occurs (UNKNOWN returned)? > > JCD: I believe that it is up to your code to determine what it want to do in > any of these cases. Most likely, it should report the problem to a > monitoring system and wait for somebody to take action and reconfigure/fix > things. Unless you can come up with intelligent strategy to fix the problem. > But some of the above exception might not be transient and reconfiguring > (redeploying) the assembly might not fix it. The point is that only your > component knows how important this "missing" connection is and if it can > work in degraded mode without it. In the scenario you have described until > now this is the assembly that has created the Component instances and > connected them together. It is doubtfull that the component can do anything > by itself to recover from that. Sending an SOS and waiting for help seems > like a reasonable decision in this scenario. TSH: See the above response. I dislike the idea that i need to wait around for someone to "fix things". Sending up a flare seems to me about as distasteful. Now that I look at these, only COMM_FAILURE and INV_OBJREF are recoverable in any automated way. The others are not likely to be transient and show some form of incompatibility or logic defect. (UNKNOWNs, I've found, are a good indication that exceptions are not being propagated correctly.) > With respect to error detection and recovery: > * How does one indicate the set of objects that can detect the error? > Possible objects are Y, Y's home, Y's container, X's container, X's home, > the assembly, an independent third party. > * How does one indicate the set of objects that can recover the error? > * How does one indicate whether the error should be detected? > * How does one indicate whether recovery should be attempted? > * How does one indicate the recovery strategy, especially if there are > several objects that can recover the error? > * If the strategy has multiple fallback conditions, should this logic be > placed into a single object or should it be given as a precedence list? > > Where should this information be specified: IDL, CIDL, or XML? > What are the implications when the components have different type and > container semantics? TSH: You commented above about intelligent strategies. This is one type of configurable strategy. The Scripting language might be a useful tool. The key to this problem is automation - why bother building something for me if you can't help me pick up the pieces later? > Let component X be transient and component Y be an entity. If component X > fails, can a new X be safely created for its corresponding Y? > > JCD: Here the scenario change litle bit. Component X is now transient with > means more likely that it is a service or session component. It should also > imply that the component is created by Y when it need it and not by the > assembly (component X is instantaited for the duration of the service [1 > method call ] or the duration of the session [ open, use, close ] ). It is > then destroyed (implicitely or explicitely) when Y doesn't need it anymore. > > - A service Component is stateless so it should be safe to recreate a new > one and use it. > - A seesion component might not be able to take over where the previous > component left (as they are not supposed to have persistence). Therefore you > may have to back up (abort) and restart the all session. TSH: I do not agree with the implication that Y creates X. In fact, we have a number of conditions where X would create one or more Y's, [session creates or manipulates one or more entities, but the entities require access to a facet of X for context and control], especially if X is a session component. I might possibly agree that this is no longer likely to be built by an assembly. Unfortunately, the model behind this is a little too limited. > Assume a new X was created and the old X still exists but became > inaccessible. Can the old X be detected and one of the X's be > deleted > [dismissed] after the old X is again accessible? > > JCD: the garbage collection is not a strong point of CORBA. However > it is up > to you to implement your own "policies" in your component if the reference > to a session or service component was to be lost (let's say that Y crashes > after creating X). It can be implemented either in the component, > the > container, or maybe the home interface. May be something could be added to > the spec in the various XML files about this if it was to be handled by the > (session) container. TSH: In fact, you have just identified one of our principle objections to homes, in that homes combine factory/finder behavior and management behavior. While these two may be combined, you don't necessarily want to do so, especially for robust environments. This is too vague; the spec should at least state that this amounts to a vendor implementation decision and define the minimum set of policies. > Assume a request to X completes successfully in X but fails during the > reply to Y. Can the operation be retried or the previous results > retransmitted, either on the old X after recovery or on a new X? > In these questions, what happens if X is an entity and Y is transient? > In these questions, what happens if Y aborts rather than X? > > JCD: it depend on your operation and it depends if you are using the > transaction service. You should be able to achieve this using the > transaction service. If you don't want to use it you have to > be a lot more carefull. TSH: OK, I'll leave this one for the OTS. > Ideally, it would be nice if either the IDL extensions or the CIDL > constructions permitted specification of an error recovery wrapper around > access to a receptacle (or event channel). This could actually work > as a > general mechanism for any component and not just components grouped > in an > assembly. The wrapper would be a specialized object implemented > specifically in the context of the component or assembly that > provided the > desired error detection and recovery behavior. It would be a proxy similar > to a stub: it would have the same interface as the target object to which > it delegates. Errors would be caught (as described) and recovered > automatically, if possible. This includes the initial reference to > an > object, which would now be built or acquired dynamically at run-time rather > than semi-statically at assembly instantiation. Multiple > inheritance, in > languages that support it, would be very useful in standardizing > proxy > behavior. The component DTD could be used to specify desirable run-time > operation and associated characteristics. > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > ================================================================