Hi all, I think the last comment touches on a key point: ".... keep attempting to innovate new infrastructures that provide the PROPER interactions for a distributed business system while shielding the end developers from _WHY_ the design decisions were made." This comes from the long sought vision to have plug and play software components. It is difficult to have plug and play software if the industry cannot agree on how the software is connected. Not only is software tied to a particular transport layer, it often has lots of information embedded in it about the environment it was initially deployed in. This prevents software from being able to be used in different environment using different protocols. We are working on an Open API for a transport independent framework that will allow any underlying middleware to be used. It is based on service oriented architectues such as Jini. Everything is a component and publishes services as interfaces. The interfaces are designed in terms of business logic, not transport layers. There are three major categories of transport connectors: 1. Asynchronous Messaging (JMS, CMS, etc.) 2. Synchronous Method Invocation (DCOM, CORBA, RMI, DCE RPC, EJB over RMI, etc) 3. Streams (audio, video, etc.) Much like the collections framework, application programmers should only write interfaces based on their business logic and the core nature of the interaction (synchronous, asynchronous, or streams). In fact a grouping of interfaces can make a more complex connector (using multiple protocols or bidirectional). Using an interface should be as simple as getting an object from a factory that implements the interface. Publishing an interface should be as simple as providing a object that implements an interface. All of the underlying details of finding listing services, looking up objects, finding connectors, and connecting with a particular transport should be hidden from the application programmer. These things should be handled with properties or deployment descriptors. Thats my two cents ... Guy Bieber Lead Architect C4I Architectures Section Integrated Systems Division (ISD) Motorola Systems Solution Group (SSG) [EMAIL PROTECTED] 1-480-441-7692 "Nothing is ever simple, unless we make it so." -----Original Message----- From: Stuart Charlton [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 06, 1999 4:08 PM To: [EMAIL PROTECTED] Subject: Re: Seduction by perceived ease of use, was RE: Granularity of EJBObj ects > At the risk of pi??ing off Sun, the network ain't the > computer yet. When > bandwidth is virtually unlimited, and server resources > approach infinity, > the game will change. On the contrary, I believe. There never will be enough bandwidth, nor will there be enough resources, as we always find bigger and better needs for them. I believe the only weapon we have to combat poor enterprise systems architecture is to keep attempting to innovate new infrastructures that provide the PROPER interactions for a distributed business system while shielding the end developers from _WHY_ the design decisions were made. I suppose it's also rather utopian of me to think that we can develop a beautiful infrastructure of this sort, but I view it as more realistic primarily because the requirements on how to build a robust, high performance distributed system HAVE NOT CHANGED a lot over the last 20 years. [We just never totally understood those requirements. For instance, RPC's seemed to be a good idea t the time - today that's not quite the case, explaining the love/hate relationship many have with CORBA or RMI. :) ] There are a lot of examples of notable steps forward with regards to encapsulating "expert knowledge" of how to properly design enterprise systems. From a theoretical perspective, Oliver Sims did just that in his Business Objects book in 1994. From a product perspective, NeXTStep did it in the late 80's by literally _inventing_ distributed objects, object/relational mapping and serialization. Persistence did it in the early 90's by providing the first real C++ object cache on top of an RDBMS. Gemstone/Servio did it in the late 80's by providing one of the most elegant persistence/transactional frameworks ever [and the first ODBMS]. (All three of these products are still going strong too, through PowerTier, GS/S and GS/J, and WebObjects, respectively.) We still have a way to go, but let's not forget how far we've come, and that the major thing (as always) that is holding things back is politics. EJB isn't an innovative spec for this reason. EJB fulfills about 2/5 of what Sims' wanted in his infrastructure, but had more important goals of pleasing the OMG, business developers, vendors and the press all in one sweep. That's a tall order. So far, it's done a fair job at that. Of course, I'm a little disappointed at the adoption rate - people still seem to be convinced that a highly scalable, fault tolerant e-business solution can be made with IIS, ASP and some SQL statements. That being said, EJB is the first real stab at a standard runtime architecture in several years, so I think the onus is on the industry to MAKE it work. [otherwise, once again, Microsoft will probably wipe the floor.... ] Just my two cents Stu Charlton Distributed Systems Developer, Nuvation Labs =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
