An Aussie mate of mine, Ethann Castell, has recently published a very nice article that everyone who's involved with Lotus Notes/Domino applications for the Internet should read and heed. You'll find his article here:
Top 10 issues when developing Lotus Notes Domino Internet applications
Ethann's article for some reason triggered a bout of recalling memories about computing hardware and software that I've been involved with.
This is my 39th year in the IT industry (I've been programming for over forty years though). I started with IBM Australia in January 1970, and took an early -- very early -- retirement package offer at the end of February 1992. However, under that early retirement plan it transpired that I didn't need to formally retire from IBM until I reached the 25-year mark in mid 1995, so I managed to qualify as a member of the IBM Quarter Century Club, which is a nice thing (although, along with some other such vintage things at IBM, the QC Club is now a "pale image of its former self").
During my 22+ years active career at IBM, I worked on three or four generations of IBM systems and software platforms. This included the IBM mainframes (System/360, System/370, and later), System/7 (sensor-based, real-time computing, where I spent many months coding low-level assembler language to modify an application suite called PIMS, for the monitoring and control of plastic injection molding machines), IBM mainframe communications (SNA, VTAM, NCP, APPC, the 3741 Communications Controller,etc). Starting in the mid 1970s I got to work with System/3 (from the Rochester Development Lab in Minnesota) and its descendants: System/32, System/34, System/36 ("stick them in a corner and forget about them, they run and run, with minimal IT support") and the RPG programming language (a little weird but extremely effective for running the commercial apps back then, and still so as an enormously-improved language to this day).
In August 1978 I made my first ever Qantas flight across the wide Pacific Ocean to the USA, heading for IBM's Rochester Lab, for an intense two-week briefing on the the system code-named "Pacific" which was released as the IBM System/38. This was one of a two "epiphanies" that I experienced in the commercial IT world (more about the second one a little later). The S/38 was conceived and architected in the earlier 1970s by some brilliant IBMers at Rochester, some of whom had moved there when another leading-edge system architecture project (the FS, or "Future System") was canceled. These architects joined the Rochester L:ab and helped come up with the amazing architecture of the S/38, which later morphed (together with the best features of the highly-popular S/36) into the
Application System/400. In typical IBM product naming fashion, as the AS/400 was improved it was rebranded as "i Series" and currently goes under the moniker "System i". The original outstanding architectural foundations live on in today's models: single-level storage, technology-independent machine interface, object-based architecture, machine-level security implementation, and much more. Oh, if only some of this brilliance could make its way into the stunted PC architecture!
I had a second epiphany when I came across Lotus Notes in early 1993, soon after Release 3 had been announced. I attended a Lotus roadshow event that really opened my eyes: document-oriented architecture, seamless replication of documents across Notes network, and more. Lotus had succeeded in getting working at the PC cost level things that IBM had spent well over a decade in developing for its mainframes and (to a lesser extent) midrange systems, but still hadn't managed to make them all that popular even with its enterprise customers much less the broader constituency. A year or two later IBM took the excellent step of acquiring Lotus, and with IBM's deeper pockets the ongoing development of Notes was assured. Many new features were added in subsequent releases.
For Release 4.1 an experimental Internet capability, called Internotes, was added to the "Lotus Notes Server" and this was seen as such a big deal that, for Release 4.5, the server component was rebranded the "Lotus Domino Server." From then on, when you talk about "Domino" you're essentially referring to the Web-serving capabilities. that is, the terms "Domino apps" and "Web apps" are synonymous.
The term "Notes apps" usually signifies the original rich style of "fat client" applications, which in my opinion to this day are to be preferred since they're usually more functional than Web apps. Yes, of course I can see the side of the argument that talks about the ubiquity of the Web. but any Web application architect/designer will be well aware of the lack of standardization of browsers, the limitations of the architecture for handling applications (issues with handling the browser's "Back" key being just one example), the issues with Web pages that are served out dynamically (via DHTML, or AJAX, or whatever) not being search engine friendly, and a host of other things. Even though it is proprietary, at least the Lotus Notes Client is a single, controlled development target compared with the zoo that is the Web application world!
Well, I've certainly rambled on a bit too far today, eh. I fully understand that Web applications are essential. IBM has been putting much effort into enhancing Lotus Notes and Domino, witness the snazzy Eclipse-based Lotus Notes 8.0 client.
Domino-based Web apps will continue to be developed and deployed for the foreseeable future, therefore again I exhort you to go read Ethann's article for a very nice summary of important considerations.
An attempt to scrub the gathering moss off some stones and help them keep rolling smoothly along ... Thoughts on information technology and anything else, by Tony Austin, after a career in Science and the IT industry, and now somewhat contemplative retirement
Saturday, February 16, 2008
Friday, February 01, 2008
SOA in a Nutshell
I'm still struggling to get my head around Service Oriented Architecture and all that it implies. So far, it has only been very peripheral to what I do, so I'm ever on the outlook for pearls of wisdom about SOA.
Neil Ward-Dutton of Macehiter-Ward-Dutton has come up with a very nice visual summary diagram of the key benefits of an SOA approach at SOA's five benefits in one picture (click on the image there to see a legible enlargement, below is merely a thumbnail).
Neil Ward-Dutton of Macehiter-Ward-Dutton has come up with a very nice visual summary diagram of the key benefits of an SOA approach at SOA's five benefits in one picture (click on the image there to see a legible enlargement, below is merely a thumbnail).
Labels:
Service Oriented Architecture,
SOA
Subscribe to:
Posts (Atom)