"Modern" Software Framework?
in [OOP]
|
Prev: Design by Contract vs Law of Demeter : Preconditions
Next: New England Patriot jerseys for men,worldwide express, paypal payment
From: philip_b_taylor on 17 Aug 2007 18:30 On 17 Aug, 16:33, "xpyttl" <xpyttl_NOS...(a)earthling.net> wrote: > <philip_b_tay...(a)yahoo.co.uk> wrote in message > > news:1187343263.648716.93040(a)22g2000hsm.googlegroups.com... > > > 2. Multi-platform (Linux, Windows, + Real-time platforms TBD) > > 3. Multi-language (probably Java, C++, Python) > > These two requirements seem to be mutually exclusive. As Dmitry implied, > Python certainly has nothing to do with real time, but you coud make the > same argument for Java, and maybe even C++. > > You might consider having some engineers review the marketing hype before > you get too far down the road. > > .. Sorry perhaps I was not clear enough. There is, of course, no intention of using Python on the real-time platforms - the requirement is that Python be inter-operable within the framework used, not that it will be used on every host in the system. Python (and to some extent Java) will be mainly used in the supervisory and scripting tiers of the system. Some (soft) real- time hosts will use C++, perhaps Java. There will be specialist hard real-time processors which may have to be excluded from the framework. As regards size, I don't know, except 'large'. There should be no size limitations imposed by the framework. My guess is ~100 hosts and 100K+ I/O points? There's a couple of years detailed design yet to go. The reason I mention CORBA is that (like many large organisations) we are not free to start from a clean sheet and design a system from scratch. An existing CORBA-based solution is being proposed for sensible financial and political reasons. I was asking about new technology options that may be being ignored because of these constraints. There has certainly been no marketing hype anywhere (so far), as the proposed solution is not sold commercially, Philip
From: Phlip on 17 Aug 2007 22:37 philip_b_taylor wrote: > The CORBA solution currently proposed is being criticized (amongst > other reasons) as > being "old technology". CORBA's main problem is it grew under a broken "request for proposals" model. The stakeholding committees chartered their proposal system to discourage and inhibit reference implementations for new feature requests. This simple but horrific mistake allowed client companies to compete with each other by submitting elaborate requests, allowing the CORBA specification to clutter up with endless cruft. It would be hard to think of a system worse than MS's ActiveX, but CORBA did it. I predict that CORBA as we know it will not last another few years, and that something else will take its spot. Maybe a simplified version of the ACE-TAO-CIAO framework(s). > Any suggestions as to what the "new technology" solution might be? Let's try Ruby on Rails... > 1. Distributed, networked control/data handling/analysis system You distribute Ruby with dRB. A Ruby object can operate over a wire just as easily as locally. To synchronizing objects from other languages, you use SWIG or something to bond them to Ruby objects. End to end, this system is very light, flexible, and feature-per-feature competitive with DCOM or CORBA. > 2. Multi-platform (Linux, Windows, + Real-time platforms TBD) Uh, check, including self-hosting systems that put a lite server inside its own web browser. That is the GUI of the future, folks. > 3. Multi-language (probably Java, C++, Python) For the love of the diety of your chosing... why? So that each programmer on a project can write in their own language? Modern applications are multi-lingual in their layers. Rails, for example, goes from SQL in your database (any database) thru Ruby in your middleware to HTML and JS in your browser. What other languages are there?? > 4. Widely distributed development (worldwide), including academic as > well > as industrial participants. Check. > 5. Development time 5-10 years, operational lifetime 20-30 years (yes > really). You mean uptime of 20 to 30 years? I don't know. But open source projects, with wide community support, tend to only get better over time... You forgot item 0. - wall-to-wall support for unit tests. You weren't going to start this heroic 30 year project without unit tests, were you?? -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax
From: Phlip on 17 Aug 2007 22:39 philip_b_taylor wrote: > There's a couple of years detailed design yet to go. Please google for "waterfall". Such a long _detailed_ design phase is setting you up for _assured_ disaster. > The reason I mention CORBA Quite like CORBA's request for proposal system... -- Phlip http://www.oreilly.com/catalog/9780596510657/ "Test Driven Ajax (on Rails)" assert_xpath, assert_javascript, & assert_ajax
From: kjin101 on 18 Aug 2007 00:28 On Aug 17, 9:04 am, spenc...(a)ociweb.com wrote: > > TAO also has a component model called CIAO which is leading edge. > CORBA component model (CCM) was largely influenced by the techniques developed during later 90's in the Apache Avalon project and early EJB 1.0 work. These tehcniques have been abandoned in the mainstream industry for years and the EJB 1.x has became a classic negative example of architect design. If CCM is still hyped as a "leading edge" technique, it is most likely out of an ostrich attitude or an "if you can't convince them (users), confuse them!" tactic. > > Only open source can gve you the long term use you need. Most of the > installations we support are 10 year minimum systems. > CCM introduced a compliance barrier that not only tightly locks in compliant component implementations, but also locks out almost all existing CORBA business logic implementations (servants) and even certain client applications and important common services (such as Event/Notification). To be reusable in CCM (regardless whether the given CCM container is in open source), these CORBA application implementations and common services have to be refactored or even completely redefined and reimplemented. All of these additional engineering cost largely defeat the very purpose of having this component framework even if it was in open source. Regards, Ke
From: kjin101 on 18 Aug 2007 00:55
On Aug 17, 2:34 am, philip_b_tay...(a)yahoo.co.uk wrote: > I am looking at the architecture and possible framework solutions for > a system which has the following requirements: > 1. Distributed, networked control/data handling/analysis system > 2. Multi-platform (Linux, Windows, + Real-time platforms TBD) > 3. Multi-language (probably Java, C++, Python) > 4. Widely distributed development (worldwide), including academic as > well > as industrial participants. > 5. Development time 5-10 years, operational lifetime 20-30 years (yes > really). > > The CORBA solution currently proposed is being criticized (amongst > other reasons) as > being "old technology". > As a matter of fact, Linux, C/C++, Python are all older than CORBA. Regards, Ke > Any suggestions as to what the "new technology" solution might be? > > Philip Taylor |