Legacy Applications: Does SOA Mean "Save Our Assets?"

[Guest.Visitor]

I recommend that you look at ASNA's Visual RPG (asna.com - San Antonio, TX). You can write RPG code in the .Net environment to develop Windows and Web applications and leverage both your legacy system and your existing RPG programmers in that process.

[pclapham@core-mark.com]

We had some more auditors in last month, and one of them referred to the iSeries as a legacy system. But our manager who was at the meeting said something like "Legacy system? You mean because it's been around since the 1980's? Well, what else has been around since then? Oh look, Microsoft Windows has been around since then!"

[R.Daugherty]

We need more people like your boss speaking up. That was good. rd

[R.Daugherty]

Everything, and I mean everything, is in question concerning these SOA theses. I have yet to see any basis for it being any different beyond a more verbose protocol over what's been done before with CORBA, EDI, or MQ transaction messaging. There's nothing earth shaking here. And the interface independent stuff could be addressed across the board to nearly all existing software. When the SOA bandwagon rolled out, did you hear any particular business software platform jump up and say, yeah, we're plug and play SOA! No, you didn't. Very little software has been written interface independent. Even with the ever sickening web page hype, first of all, little of it is business software, but secondly, much of it is a huge step back from the object based display files of the iseries. Web pages written with script languages like PHP often contain the business logic within the web page. This would be equivalent for us to go into our DDS source and include SQL statements and business logic to populate the screen. For people that don't know better, this is considered a good thing. I would hope we have proven we know better by now. Precious few others understand it though. Even when the program isn't in the web page, another huge step back is embedding HTML syntax generation in the program. Imagine if all these years we programmed by generating the screen text, display attributes, colors, window borders, subfile lines, and everything else on the screen as we went along in a program getting data and applying business logic to it before displaying. Wouldn't we consider that pretty damn stupid if someone came along and said that's how we should be generating our screens instead of using DDS? Sure we would, because we know better. Or should. But that's what I'm seeing with these web page programs. It's the opposite of interface independent. Our DDS is more interface independent than that. On to this AS/400~iseries being isolated business. First of all, it's the Windows servers for each app that are isolated. They are the islands. The AS/400~iseries has every communications connectivity there is and all the data. It's not an island, it's a continent. As for real time, a couple quick examples I've done. Real time shop floor transaction system. The shop floor PC's sent a transaction for every shop floor event to the AS/400 and they were processed real time against BPCS. Screens reflected real time inventory, shop order statuses, etc. I'm sure this is done widely. Why would a suggestion otherwise be entertained? Another example is online to PC's for realtime information. I had a Delphi Windows program for customers to drill into their orders, statuses, comments, etc. Access was by dialup or internet. Program self-updated, instant screens, drill down and tabs for more info. All data and logic was on the AS/400. AS/400 shops have been doing this for years. Hardly an island. Lastly, a little bit on interface independent encapsulated business logic modules for SOA and the like. I've done this a number of ways. I would say this about it. It seems intuitive that this is a superior architecture in that a function is in one place accessible everywhere, but reality suggests that it isn't that intuitive. But more importantly, there is precious little solid analysis of the business transactions that would be performed via SOA or other schemes to access isolated business logic. Here's an example. What would an SOA transaction consist of? Move of inventory from one location to another would be an example, right? But the logic to perform an inventory move was an entire, complex interactive BPCS program. Can the logic be isolated and made interface independent, that is, called by the screen or by a batch transaction? Yes, I did it. But it turns out in my opinion that a 5250 screen is a much more natural source of a transaction than the other way around. In other words, it's exceedingly difficult to scope business transactions that can be called by anything for any reason and make it available for the enterprise via SOA and possibly other accesses, but RPG and a 5250 screen is a natural way to write business transactions with the right scope, the right logic, in the right order. XML'ing the screen is what I've been calling for all along. It applies to SOA as well. rd

[MCWebsite.Staff]

** This thread discusses the Content article: Legacy Applications: Does SOA Mean "Save Our Assets?" **
0

[tbear]

Mr. Nubla, I appreciate your article very much. It's one of the few I'll save to read again in the future. I also appreciate Mr. Daughterty's comments as well. There is a lot of wisdom in his words as well. These are ideas I have thought about, but these two men have elaborated on them quite well. I have nothing bad to say about SOA and I believe it can be a good thing, but these individuals have taught me that much care must be taken on how it is implemented.