I get a number of business related trade newsletters everyday, more than I can really read. I do scan the headlines and try to look at the articles that interest me. In the e-stack today, was an article in “ComputerWorld” that actually addresses one of the initiatives going on where I’m working.
One of the newer industry buzzwords (or TLAs) is SOA (Service Oriented Architecture). To hear most folks talk you’d thing it was the next wiz-bang, going to solve the world’s problems, process.
It’s not all that new really; it’s more an extension of what many of us have been doing for well over a decade. Most of us in PC based development that is. The “mainframers”, those “big iron” guys, you see have been developing application under what they now call the ‘waterfall’ model. Large monolithic applications built with little or no component reutilization.
Us “PC” guys, using tools like Visual FoxPro, Visual Basic, C++, and now all the .Net languages have been building libraries of reusable components for years. Some, like me, started doing so out of self-preservation, and to construct a toolbox and framework, from which we could quickly, and cost effectively build custom applications for our clients.
At first, we called them Procedures, then Functions, UDF’s and now in the object world of application building they’re called ‘methods’. This next step in the evolution and it is evolution, not revolution, is placing these functions on a server where your application can place a ‘call’ to them, and receive back the desired result.
Ten years ago it was called “Client/Server” computing, today it’s been given a new lease, a fresh paint job, new terminology and some help from the server architecture and it’s been transformed into ‘Web Services” or SOA.
It’s always nice to be on the front lines, and this article isn’t at all far from the truth. There are folks embracing this fully, and folks dragging their heels, but SOA, is here to stay. It makes far too much sense, especially in companies who have large investments in mid-range and larger hardware.
Security and authentication for data access can be handled for the application at the server level (like the mainframe folks like), access to applications can be handled at the desktop level and the servers handle all of the, often complex, data location and retrieval for the application.
We’ve extracted the need for a developer to know ‘where’ the data store is, what driver is needed to get to it, and replaced it with a ‘black box’ that simply responds to a request. I’m sure when Greg stops in, he’ll remind me we were doing very similar things with PC networks in the 80’s… and we were… the point is, not much really changes, just what we call the process, and exactly how it’s put to work.
You can read the actual article here, in keeping with my stance on not naming my employer; I won’t mention which of the companies in the article it is. I think even the non-detectives among you will figure it out though.
The big central customer file and Dun and Bradstreet sync process I’ve been working on for nearly a year, kicked off in production mode today. The first day went flawlessly, we had a couple of tense moments very early this morning, but once we got everything restarted properly, all phases scheduled for today ran, completed normally and within our estimated time frames. We’ll start the message generation for distribution to the industry tomorrow, and that will run though mid-day on Sunday.
I have the Midnight to 8:00am shift Friday night, and, with any luck at all, I’ll be a pro at navigating the mainframe screens by morning!!
If I have a chance, I’ll update you all on our process and how my POL process worked in the final analysis. That tool has a lot of potential, even working on remote datastores, and making approximately 1000 character comparisons per record, it was still processing at a rate of five records per second. I’d estimate that 60% of that time had to do with the fact that ODBC remote data calls are on the very lowest tier of the priority list. That means that every other non-ODBC request to the server was processed before mine.
All in all, I’m very pleased!
Technorati Tags: FoxPro - Microsoft - SOA - Software Development
-IceRocket Tags: Software Development - Decisions - SOA - FoxPro
2 comments:
I'm a big proponent of the whole "service" idea, even though I have a big background in "big iron." I've actually known a number of mainframers who don't fit the mold and develop this way. In many ways, it's an exciting time to be in IT. In others, well...
I'm glad that your project is going well.
CA - Check your email.. It's a great idea, this SOA stuff, but until we 'library' all the existing components, and do half as good a kob as the average libray does at letting us find whar we need... I still think the overall process is flawed at the core, and the SOA does not do much to improve that more than marginaly.
Maybe I'll start working on a 'repository' applications that does that!
Post a Comment