!standard E.05 (01) 02-02-08 AI95-00273/01 !class amendment 01-09-05 !status work item 02-02-08 !status received 01-08-23 !qualifier Error !priority Low !difficulty Hard !subject Use of PCS should not be normative !summary Implementations are not required to support the interface of the language-defined package System.RPC. Implementations are permitted to support alternative versions of the package System.RPC for implementing remote subprogram calls. !question System.RPC is designed to allow users to change from one vendor PCS to another. System.RPC is well suited for the possible implementation mentioned in E.4(20). But this specification makes strong assumptions on the implementation and other implementations become almost impossible. For instance, AARM E.4(20d) suggests that partition ids are statically defined. Therefore, System.RPC.Partition_Id has no specific primitives. A more dynamic implementation of DSA would probably provide an additional library unit as part of the PCS in order to deal with partition ids. But the user is no longer able to change of PCS. By removing this rule, compiler vendors would be allowed to delegate the implementation of DSA (or at least the PCS implementation) to other vendors like CORBA vendors. This would also allow DSA to interoperate with other distribution models like CORBA (no longer Ada talking to Ada). !recommendation Implementations are not required to support the predefined interface of System.RPC if another interface is more appropriate for the communication subsystem. Implementations are allowed to provide an alternative version of package System.RPC, however they should be encouraged to support a substantially equivalent set of capabilities to that defined in the predefined specification of the package. !wording Delete the normative sentence at the end of E.5(1) that requires using the language-defined System.RPC interface. Under implementation advice, add: An alternative declaration is allowed for package System.RPC as long as it provides a set of operations that is substantially equivalent to the specfication defined in this clause. !discussion The current language requires implementors of Annex E to support the interface to the PCS defined in E.5 (package System.RPC). The original concept of requiring this standardization was to allow for a well-defined interface separating the compiler support for marshalling and unmarshalling from the implementation of the underlying communication subsystem, which might well be provided by another vendor. The idea was that such a separation would enhance portability of PCS implementations by providing a "plug and play" capability. As it has turned out in practice, Annex E has not been widely implemented by vendors. In fact, at the time of this writing, only one vendor has chosen to provide full support for the Annex. This vendor has discovered that the existing definition of System.RPC is overly constrained for supporting distributed environments such as CORBA, which provide a richer set of capabilities than that afforded by the predefined RPC interface. Although the language allows extending the set of operations of System.RPC and the definition of child units, it still imposes a model based on a particular notion of Partition_Ids and send-receive operations that may limit its applicability. It's unreasonable to constrain implementations to support an interface that is deemed unsuitable or overly inflexible for their target distribution environments. In particular, it doesn't make sense to require vendors to support the predefined interface along with other interfaces only for the purpose of satisfying a reference manual requirement if their target users do not benefit from its support. An analogy can be made with the run-time support for tasking implementations, where it would be unreasonable for the language to attempt to define a particular interface to tasking primitives, since this would be unlikely to provide a suitable and efficient mapping to a wide variety of underlying tasking executives. Consequently this AI removes the normative rule requiring support for the language-defined interface for System.RPC and changes this to Implementation Advice. Note that the flexibility provided by relaxing this requirement is similar to what is allowed for package Ada.Command_Line, where implementations are permitted to change the interface to suit the particulars of argument passing on a given operating system. Given that System.RPC is not a user-level interface it seems even more appropriate to permit vendors to have this kind of flexibility in changing the interface of System.RPC and not to be burdened with supporting an interface that may be inappropriate or inadequate for the distributed communication protocols available on their chosen environments. !corrigendum xx.xx(xx) @drepl The @i (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS. An implementation conforming to this Annex shall use the RPC interface to implement remote subprogram calls. @dby The @i (PCS) provides facilities for supporting communication between the active partitions of a distributed program. The package System.RPC is a language-defined interface to the PCS. @dinsa The Write operation on a stream of type Params_Stream_Type should raise Storage_Error if it runs out of space trying to write the Item into the stream. @dinst An alternative declaration is allowed for package System.RPC as long as it provides a set of operations that is substantially equivalent to the specfication defined in this clause. !ACATS test Several existing ACATS tests will have to be deleted if this AI is approved. !appendix !topic use of PCS should not be normative !reference RM95-E.5(1) !from Laurent Pautet 01-08-23 !keywords Annex-E, PCS, System.RPC !discussion 1/ System.RPC is designed to allow users to change from one vendor PCS to another. System.RPC is well suited for the possible implementation mentioned in AARM E.4(20). But this specification makes strong assumptions on the implementation and other implementations become almost impossible. For instance, E.4(20d) suggests that partition ids are statically defined. Therefore, System.RPC.Partition_Id has no specific primitives. A more dynamic implementation of DSA would probably provide an additional library unit as part of the PCS in order to deal with partition ids. But the user is no longer able to change of PCS. 2/ There is no such rule in the rest of the language. For instance, it would probably be dramatic to force a tasking implementation to use a given API. A direct consequence of this rule is that it is very difficult (and almost impossible) to port DSA on the top of a CORBA ORB without violating E.5(1). As suggested in the possible implementation E.4(20), a distributed entity is described by a partition id and a RPC-receiver defined in System.RPC. Therefore, it is very difficult to represent a distributed entity as an IOR. Note also that CORBA does not normalize things at the level of ORB interface but at the level of stub and skeleton interface and at the protocol level. 3/ By removing this rule, the revision team would allow compiler vendors to delegate the implementation of DSA (or at least the PCS implementation) to other vendors like CORBA vendors. Using System.RPC has too much impact of the communication system architecture. This would also allow DSA to interoperate with other distribution models like CORBA (no longer Ada talking to Ada). More generally, this would encourage DSA implementations (rather than constraining it), open this annex to other technologies like CORBA and increase its use and interest. **************************************************************** From: Robert Duff Sent: Sunday, August 26, 2001 4:03 PM !topic use of PCS should not be normative !reference RM95-E.5(1) !reference Laurent Pautet 01-08-23 !from Bob Duff !keywords Annex-E, PCS, System.RPC !discussion > 2/ There is no such rule in the rest of the language. For instance, it > would probably be dramatic to force a tasking implementation to use a > given API. I won't comment (yet?) on the rest, but I'll just point out that there *is* precedent for this sort of rule: the stuff about user-defined storage pools in chap 13 is like that. The compiler has to be prepared to redirect "new" and Unchecked_Deallocation to the user-defined operations. Likewise, in Annex E, the compiler has to be prepared to redirect networking operations to user-defined code. **************************************************************** From: Laurent Pautet Sent: Monday, August 27, 2001 9:02 AM Right. Another example would be stream attributes. But you should compare features of same magnitude. You cannot compare malloc/free with all the socket primitives. The job to get a working network programming interface is more difficult than to get a memory allocation interface. To be fair, compare with tasking. And it is still not really fair because I guess that in the Ada community, people are more familiar with real-time systems than with non-realtime distributed systems. The intention for storage pools and stream attributes is to make user code portable between compilers. For DSA, it is to make code generated by compilers portable between PCS implementations. The first intention was to allow compiler vendors to delegate the PCS implementation to some other vendors and not to the user ! Let's assume that the second intention was to allow user to provide a PCS implementation. It can explain why System.RPC is so simple. But to get back to the tasking example, how many users develop their own run-time compared to those that develop their own storage pools ? And if they develop their own run-time, do you agree that they have better to work very tighly with the compiler vendor ? For the same reason, very few users will develop their PCS. For the same reason, if they do, they will interact with their compiler vendor very tighly. System.RPC was defined 8 years ago without any implementation available to validate this interface. If you look at other distribution model, it is clear that for instance, DSA is missing a naming service like COSNaming in CORBA. System.RPC was specified with the static design described in the AARM in mind. Is it reasonable to keep working with such an API for Ada0X ? Distributed systems is a domain in which Ada should expand and not be constrained. **************************************************************** From: Pascal Leroy Sent: Monday, August 27, 2001 2:55 AM > 3/ By removing this rule, the revision team would allow compiler > vendors to delegate the implementation of DSA (or at least the PCS > implementation) to other vendors like CORBA vendors. An implementation may provide a (configuration?) pragma Do_Not_Use_PCS in order to short-circuit the PCS and use whatever communication subsystem it likes. This is perfectly legal, and much easier/faster than changing the language. Moreover, considering the number of implementations which support annex E, I don't think the portability problems would be too bad... **************************************************************** From: Robert Dewar Sent: Monday, August 27, 2001 4:48 AM <> Obviously this response is more than adequate for current Ada 95 compilers. I think the comment was more about the future revision of Ada. The question is whether the current view of plug-and-play PCS makes sense to continue in the new version, given its total lack of success for Ada 95. Yes, at least we have one complete implementation of Annex E, and it is being used successfully, but the notion of a standard interface for the PCS turns out to be completely irrelevant, and, as pointed out by this comment, actively unhelpful. **************************************************************** From: Robert Duff Sent: Monday, August 27, 2001 3:24 PM Does this mean that the plug-and-play PCS idea is hopeless? Or does it merely mean that this particular interface is the wrong interface? **************************************************************** From: Randy Brukardt Sent: Tuesday, August 28, 2001 7:09 PM > System.RPC was defined 8 years ago without any implementation > available to validate this interface. If you look at other > distribution model, it is clear that for instance, DSA is missing a > naming service like COSNaming in CORBA. System.RPC was specified with > the static design described in the AARM in mind. Is it reasonable to > keep working with such an API for Ada0X ? Distributed systems is a > domain in which Ada should expand and not be constrained. The problem here is that Annex E was designed for a homogeneous distributed system written completely in Ada, while the sort of systems that you are envisioning are hetrogeneous distributed systems written in a variety of languages. I would expect that Annex E would need a lot more changes than to just the PCS to work in such an environment. I don't think a piecemeal approach to revising the annex will buy much, and any revision to the annex will eat up a lot of valuable time. (I'd rather spend the time on a standard Sockets library - a lot more users would benefit.) The big question is whether enough users are interested in a revision of Annex E to justify the work. If we base that on the existing users and implementations, the answer would appear to be no. So I think anyone wanting to revise Annex E would need to show an constituency and probably some volunteers to work on the proposals. **************************************************************** From: Robert Dewar Sent: Tuesday, August 28, 2001 9:09 PM <> The answer is that a major effort has been put into studying this issue, and the answer is well understood to be that Annex E can most certainly be implemented in such environments without any language changes, except that the PCS interface is not relevant or implementable. Note that the fact that Annex E was designed for homogenous distributed systems, but the GNAT implementation has always fully supported heterogenous distribution using XDR, and several of our GLADE customers are using Annex E in a heterogenous environment. <> Nobody is asking for such a revision. The only people who are interested in implementing this are telling you that the only thing that is needed to make the implementation practical is to relax the PCS interface requirement. It is not practical for GNAT to implement two quite separate PCS interfaces, so this becomes a crucial issue. So please do not waste any of your (or anyone else's) time "revising" Annex E, such work is of no interest to those who have actually invested (and are interested in continuing to invest) major effort in Annex E implementation. The one and only issue here is that it would be helpful to revise the language at this stage to make the use of the PCS interface described in the RM to be implementation advice rather than a requirement. That seems to me a very small step, and one that will enable continued valuable work to be done in this area. **************************************************************** From: Tucker Taft Sent: Tuesday, August 28, 2001 8:39 PM Laurent Pautet wrote: > ... > > The intention for storage pools and stream attributes is to make user > code portable between compilers. For DSA, it is to make code generated > by compilers portable between PCS implementations. The first intention > was to allow compiler vendors to delegate the PCS implementation to > some other vendors and not to the user ! The original intent was to delegate the PCS implementation to the (sophisticated) user. This was based on the presumption that the average compiler writer knows less about networking than the average builder of a distributed system. I still believe that is true. It can be argued that one of the initial problems with Ada 83 was that compiler vendors were expected to build real-time executives, when many of them had no clue how to do so. Now we see a large percentage of Ada systems being built on top of commercial RT executives, but that wasn't true in Ada 83. Every vendor felt it necessary to build a RT executive from scratch. To be fair, in 1983, there weren't many commerical RT execs around. In any case, we wanted to avoid creating the same situation, where compiler vendors would produce lousy implementations of the PCS and thereby interfere with high-performance distributed Ada applications. Clearly the compiler had to do marshalling and unmarshalling, but there seemed no reason why the compiler vendor had to be involved directly with the actual partition-to-partition communication process, especially given the number of bizarre buses that are used for interconnecting CPUs. It may be that sockets have become so ubiquitous that effectively the same thing is accomplished by allowing a user to supply their own TCP/IP stack, but I have to believe that plenty of distributed systems don't want the full overhead of TCP/IP. So that was our intent. I can believe we screwed up the PCS interface in various ways, but I still think the idea is reasonable, and perhaps a better PCS could be defined. Whether it is worth it at this point I don't know. Certainly we should allow vendors to bypass the PCS (we do), and since there is only one compiler vendor that supports annex E (as far as I know), there seems little burden in requiring them to continue to support the PCS interface. **************************************************************** From: Robert Dewar Sent: Wednesday, August 29, 2001 4:57 PM <> Well the consequence of "requiring them to continue to support the PCS interface" is that we will likely abandon Annex E as the basis for distribution over e.g. CORBA, since it is impractical for us to maintain two separate PCS interfaces in the compiler. That's too bad, but we tried :-) We don't really allow vendors to bypass the PCS if the validation tests (three rather miserable tests) require the PCS to be implemented as described in the RM. **************************************************************** From: Pascal Leroy Sent: Thursday, August 30, 2001 3:58 AM Robert proposed: > The one and only issue here is that it would be helpful to revise the > language at this stage to make the use of the PCS interface described > in the RM to be implementation advice rather than a requirement. That > seems to me a very small step, and one that will enable continued valuable > work to be done in this area. That seems like a reasonable idea to me, as it doesn't have any negative impact, and it enables implementations to support more sophisticated distribution models. Moreover, if some customers really want the original PCS, well, they'll tell Robert. Tuck replied: > I can believe we screwed up the PCS > interface in various ways, but I still think the idea is reasonable, > and perhaps a better PCS could be defined. Whether it is worth > it at this point I don't know. I'd say that it's a good thing to look into once Tuck has completed all of his other outstanding action items (hint). I'm unwilling to spend any ARG time on this, if only because we have very little expertise in this area. Of course we can invite the GNAT implementers, but since they are the only ones who understand the issues, we might as well give them carte blanche by making the PCS an implementation advice. > ... since there is only one compiler vendor > that supports annex E (as far as I know), there seems little burden > in requiring them to continue to support the PCS interface. I think I heard Robert say the opposite. I can imagine that having to support two interfaces can be a significant maintenance burden, and if one of them is unused, why bother? **************************************************************** From: Nick Roberts Date: Tuesday, October 30, 2001 4:55 PM (Forwarded by Tucker Taft) If not fresh in your mind, this AI is about the fact that the PCS defined in the RM95 is really only suitable for a distributed system composed of a static set of Ada 95 partitions, and is (almost) unusable for more dynamic or interoperative types of distributed system. The suggestion is to make the whole PCS mechanism optional in the next revision, largely on the grounds that the reviewers do not have time to develop the PCS idea to the extent it would have to be to fulfil the wider, more flexible, requirements. I believe that there would be great value in a new and (significantly) improved PCS (standard, language-defined) definition, and that it could and should be developed. I would be willing to devote the time necessary to develop my own detailed suggestion for this, if it would be of any interest to you. The next revision could specify both the current PCS solution (System.RPC) and the new one (perhaps System.Advanced_RPC), and permit an implementation (conforming to the annex) to use either one, or to provide a choice of either (or neither), via a configuration pragma: pragma Partition_Communication_Subsystem(Normal|Advanced|Native); The 'Native' option would provide for an implementation that bypasses either of the standard PCSs. I also feel that the standard should define a naming service (like CORBA's COSNaming). I have already worked to some extent on a naming service for AdaOS; this could be readily adapted. Needless to say, this is an issue that could have great significance for AdaOS. I don't (readily) have the e-mail addresses of the other reviewers of this AI (Laurent Pautet, Bob Duff, Pascal Leroy, Robert Dewar, and Randy Brukardt), and I'm not too sure of the correct protocol or procedure in this situation, so I hope you don't mind me e-mailing you this way. I'd be grateful if you could steer me onto the right path (if there is one). **************************************************************** From: Robert Dewar Date: Thursday, November 8, 2001 9:42 PM I think it is pointless to do this work on a PCS at the ARG level. There is no point in mandating things at this stage, when only one vendor has shown any interest in doing Annex E at all. I think it would make more sense for Nick to do an experimental implementation with GNAT. ****************************************************************