Doug: I'll pipe in here to make just a few points. One, in the MV world you can't do much better than use off-the-shelf components for U2 (i.e. UniObjects). If you need more then use mv.NET, or mess around with IBM's version of mv.NET. mv.NET is a great product! Secondly, it is often difficult to make your application agnostic to any communications, database, and/or other infrastructure. Applications like PeopleSoft, Oracle Financials, SAP, etc are somewhat agnostic, but they too have serious business or technological structural requirements! There is no getting away from this reality. There's an old saying in the Army that describes a personnel specialist vs a personnel generalist; specialist - they learn more and more about less and less until they know everything about nothing, generalist - they learn less and less about more and more until they know nothing about everything. In technology, going too far in either direction gets us back to the same place - nowhere. A good CPA will tell you they don't have time to do it right but they do have time to do it twice. :-) Preparing your application for tomorrow brings mostly high costs and little benefit. There are far too many good applications resting on the trash-heap of history to be encouraging. An example of this theme, in the MV world, was FlashConnect. What a great product, built on top of sockets! We developed several modules using its underlying connectivity and it was easy and very stable. In the end though, because D3 components are a dead-end, we migrated these little modules to .NET and this is far more difficult and costly to maintain and enhance. Now, we spend ten times (at least) in dollars and time what we used to spend to maintain and enhance this modules. So much for simple sockets. :-( IMHO, of course, today's IT is a disaster. It is overly convoluted, over-complicated, over-engineered, has too many standards, has ever-changing frameworks, incomplete implementations, and requires a never-ending amount of time to accomplish and re-learn the same simple tasks. I'm tired of relearning my cell phone interface just to make calls every two years. I'm tired of spending money for a new technology that gives our application fad-appeal, and nothing more. I'm tired of putting new clothes on all of our technology, for no other reason than "image is everything". :-) Anything we do to exacerbate this ongoing technology issue costs more then it benefits. As more technology is introduced into a solution, the more unstable and difficult to maintain the solution becomes. This should probably be the first law of application development. It's often hard to justify the cost of this ongoing technological development effort. My point is, keep it simple. This is often the best strategy. Bill ______________________________________________________________________
From: Glen Batchelor <[email protected]> Sent: 4/13/2009 8:56 AM To: [email protected] Subject: Re: [U2] universe sockets -----Original Message----- From: [email protected] [mailto:owner-u2- [email protected]] On Behalf Of doug chanco Sent: Friday, April 10, 2009 6:14 PM To: [email protected] Subject: Re: [U2] universe sockets Wow great points ..... see below for my answers dougc >A full response to your inquiry really depends on the answer to >another question, which is "why are you doing this?" We want to explore other connection options that are not tied to uniobjects so that if we decide to switch from universe to say database "x" we can do so easier. Keep in mind that any protocol you develop would need to be deployed on the migration platform, which means additional development later. If you're OK with that, then consider the differences in the way that sockets are implemented on various flavors. Before you go about making a custom communications module with the intent of portability, consider making the interface non-sockets oriented. Use O/S files, directories, and file locking to control I/O. You can easily tag sockets to the front of the file I/O handler, outside of the MV comm module. If you're on Linux consider using pipes to do IPC, for example, and tie that in with inetd or xinetd. [snipped] ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
