In article <2ikmgj$8jq@sugar.NeoSoft.COM>, I solicited testimonials about the EZ-RPC product. This is a summary of what I've learned since. The first stop for those whom this tool interests is to read the re- view Smith, Ben [ben@bytep.byte.com] 1994 "Client/Server Made Easy", Byte, volume 19, number 3, pages 143-144 (March 1994) The highlights there are EZ-RPC's most significant feature is that, with few exceptions, it lets you use all standard C argument constructs, variable dereferencing (i.e., use of addresses and pointers), and data structures. Other toolkits limit you to a single argument and to simple data types ... With EZ-RPC, you don't need to rewrite existing functions ... Smith worked through a real development, and observed that ... EZ-RPC easily built the communications stubs ... It would have been a nightmare to try to build the data communications with sockets, or, for that mat- ter, with shared memory, semaphores, and named pipes. He concludes ... EZ-RPC is a valuable tool for creating robust, well-behaved communications links ...that run on almost all Unix platforms, and, with NetWare and Windows, all from source code with no built-in communications. These distributed applications tools are far more economical and expedient than hiring or training communications experts to build distributed applications. I'll comment on this review, and EZ-RPC, through three themes: A. contexts in which EZ-RPC is of interest; B. differences I have with Smith's review; and C. other gossip I've accreted about EZ-RPC. How to communicate? =================== I assert without proof that these are the software technologies that are practical for distributing processing: 1. fourth-generation application builders (Sybase, Uniface, Forte Software, Powerbuilder, System Architect, ...); 2. rolling one's own--programming at the level of sockets 'n DDE 'n ONC RPC 'n distributed SQL and such; and 3. use of a communications-savvy toolkit (EZ-RPC, DCE RPC, Linda, InterViews, ...). The first can be overblown--it typically involves large per-user-seat royalties, performance penalties, and an inflexible business model, from the perspective of a systems implementor. These tools can be marvelously powerful, *if* one understands their use and shares their view of the architecture of an application. That's reasonable to ex- pect for most IS sorts of applications, but not for engineering and systems work. The second just isn't practical to manage; the care and feeding of implementors who are efficient at low-level communications, *and* knowledgeable about an application domain, are too expensive. That's my judgment, at least. Why EZ-RPC? What doesn't the article say? ========================================== Mr. Smith argues for EZ-RPC primarily in terms of the ease of parameter passing. That's a reasonable stance; at a managerial level, though, I warm to EZ-RPC because it gives the correct answers for: 1. platform dependence, 2. level of abstraction, and 3. such advanced topics as performance and specialized communications models, including client broadcasting, multiple servers, UDP, ... Along with all the Unixes Smith lists, and Windows and Novell, NobleNet now has a VMS version, with NT on the way. I'm not sure I can justify the $5000 entry price to begin using EZ-RPC when I compare it to hand- coding one client-server application on one fixed configuration of platforms, but it means a LOT to me to be able to tell my team members, "It's ready for {VMS,NT,HPUX,...}, without more development time". *That*'s where I see the pay-off; reliance on EZ-RPC or a comparable tool- set is a strategic decision that gives an organization the opportunity to implement on a level that makes business sense. That's what a lot of ap- proaches advertise, but NobleNet has hit a level of abstraction (not too high, not too low) that works well for the projects in my experience. Incidentally, I'm ready to create an acronym for "This-[$4995]-may-seem- steep-to-a-PC-developer,-but ..."-we-in-the-UNIX-world-can-pay-that,- 'cause-it's-a-lot-less-espensive-than-the-alternatives; I describe something that way at least once weekly, and I've been doing so for at least nine years. Why not DCE? EZ-RPC is ready *now* on the environments that matter to my organization. EZ-RPC is perhaps easier to use. Its good documentation contributes much to this. There are rumors that Really Big Hardware companies will adopt EZ-RPC as some sort of standard, but I haven't any confirmation of the rumors. Why not Linda or class libraries? Those are interesting approaches, with plenty to recommend them. I still haven't decided against a good C++ library for some of our work; I'm sure it'll demand more experience and wisdom, though, than programming at the EZ-RPC level. Incidentally, does anyone know why Linda has fared so invisibly in the commercial world? I think it's a neat technology, but it never has caught on the way it might. Mr. Smith might have had an earlier release of EZ-RPC than the one I've seen; his article mentions the "rpcgen" command, where my distribution offers "ezrpc". One possibility Mr. Smith's brief article doesn't mention has to do with reverse engineering EZ-RPC. Think of it this way: the value EZ-RPC con- tributes comes in two lumps, the documentation and the implementation. The former is worth a lot; much of what NobleNet has done is to demonstrate the utility of a particular interface definition. They've done this, and documented it well, to the point that I expect copies of their manual will begin to circulate just for the other-than-product-specific background they give on client-server and communications topics. Next, if you accept their interface, is that they've implemented that interface well. EZ-RPC is easy to use (in the Unix-world sense of "easy to use"), and it has good smarts. NobleNet makes lofty claims about its efficiency, flexibility, and so on; I've been able so far to test only a small fraction of these, but EZ-RPC has passed my tests. The question that arises is, what if I'm a contented EZ-RPCer, but now I want to move my work to an AS/400, or Macintosh, or a kind of Unix for which I'm just too cheap to pay the $1500 license for an incremental platform? EZ-RPC makes so much sense that I can conceive of doing this (good: a product with a clear definition is likely to be a product with fewer troubles), but NobleNet implements its definition so well that I doubt that it's worth my trouble to try to com- pete with them (also good). Other ===== While researching this, I bumped into more than one person who favored DCE RPC as "cleaner", more consistent, and with better commercial acceptance than ONC RPC and implicitly EZ-RPC, which largely is a descendant of ONC. The question of commercial status is a big one for me. Microsoft has chosen, if I understand correctly, to rely on DCE RPC as a layer in the system administration utilities for NT; that suggests that DCE will be with us for a long time to come. NobleNet, on the other hand, argues that EZ- RPC works now, and, though nominally proprietary, is available on a variety of platforms *now*. NobleNet is a small company, and their workers are hungry enough to go to the effort of answering questions intelligently. I'm still not sure I'll recommend EZ-RPC for my current employer, but, if I do, I have confidence it will perform acceptably once we start.