System iNetwork

Sharon,
Let me reverse your structure. SOA is the
concept or architecure, Web Services just one implementation.

IBM has just, in the last week, launched a major campaign to promote SOA. I don't think the concept is particularly fuzzy, just the implementation details. I think of SOA doing for monolithic applications and application suites, what dynamic call did for monolithic programs.

It's not so much lego like as it is IP network like. Not only should I be able to offer or consume a service (an application function or component as you describe, but the service should have a self describing interface and an abstract location. For self describing, think of what database and SQL did for data access compared to internally described files. For abstract location, look a what URL's did for the Internet.

Today, if I want to replace an application, the number of point-to-point connections makes it almost impossible. Even if I just want to re-host an application, how much code must be modified
to so the interfaces can find the application at its new location?

SOA and web services propose to solve this problem by dynamically locating the service through
a directory services protocol (UDDI). Also note that although much of the liturature talks about SOA and web services as solutions to intercompany transactions, I think this technology is
equally important in a single server, internally complete application environment.

iSeries customers should be tracking this technology closely as it matures.

Somebody explain to me why I should invest (spend money, resources and affect my companies bottom line) when current technologies such as RPGCGI work just fine?

Then you say: "Well, then you are platform dependent." And I say: "Heck yes, I am, have been, and probably always will be unless IBM totally screws up the i5."

Then you say "But you need to use XML because it will save your life." I say: "Save my live from what? Java was supposed to save my live from being a poor RPG programmer, but here I am (still!). No Java in my life, but lots of good, working, efficient applications in RPG."

Then you say "But you need XML for trading data between applications and partners." I say: "No problem, I use XML structured data with trading partners already ... with RPGCGI!"

Maybe we get all of this stuff becuase it is just difficult to make things work on other platforms?

Considering CGIDEV2 involves more than just looking at its adequacy or a company's need for multi-platform solutions.

What's the current support and future support/development status of CGIDEV2?

Is the source code available?

Is it comparable in functionality to JSPs, Struts, and other evolving higher-level Web app frameworks?

Is there tooling to aid development? (Not just Web page layout, but application flow, as with Struts.)

Are application generator products including CGIDEV2 as a target option?

How does the performance scale for high-volume (typically public) Web sites?

Is there now and will there be a reasonable supply of programmers who can competently maintain and develop with CGIDEV2?

From what I can see, CGIDEV2 may be adequate as a short-term, lightweight solution (which can be a valuable tactical choice), but it would be high-risk for significant investment or for a long-term strategy.

-- Paul

Had a client that was heavily into the iSeries and J2EE platform. They acquired a company that was also iSeries but used .Net platform.

They were having problems in that they wanted to start integrating the J2EE/.Net platforms with iSeries applications - so they were looking at using Web Services from a single WAS instance for both companies - thereby saving on development and deployment of duplicate functionality.

- Raz Daz

The way I look at SOA’s are as follows: You are doing them right now in your RPG programs! Unless you have one single program running your entire organization (which I hope isn’t the case), then you have different “services� available for people/programs to utilize to meet an end business need. In reality that is what a Service Oriented Architecture is, programs talking to programs. Now there are ugly SOA’s and there are well thought out SOA’s. The best, in my mind, are ones that consider the other programs that are going to be calling them and what those programs will need in the immediate future and in the long term.

How would you go about designing a new Shipping system in RPG ILE? You would design for reuse and ease of maintenance. Once you have your reusable RPG ILE code written you can slap an HTTP XML interface on the front of it and you now have a web service (just RPG programs and text). This web service is most likely going to be cataloged so people know it is out there and therefore becomes part of a bigger picture (say architecture). And you now have a Service Oriented Architecture written entirely in RPG ï?Š

To end my comment I would say that SOA is what programmers have been doing for years, it is just the same concept with a new face. The only challenge is figuring out how the minds that thought up the next generation of architectures thought it should work vs. how current architectures work.

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog

Sharon,

I have been working with web services for a good amount of time now... Love them...

Examples of use

1. We get referrals in our firm with property information. For court purposes our documents have to be 100 percent correct and our firm was having to deal with county issues. Split counties which means 1 city could have multiple counties in it. So my users would have to verify county via MapQuest and if the property was right on the boarder would call the post office... Well the post office emp's are not the most helpful and those steps could take a good amount of time. So found a service that validates the address and passes back the correct county. So user hits a function key on the maintenance screen to validate address and get correct county. They love it and the service is cheap...

2. 80 percent of our system integration with our clients are via web services. No batching all real-time. Users use to have to hit client sites to pull referral information and then type of that information into the iSeries. Well now using web services the application gets referrals validates the referrals and places on the iSeries and notifies user via email that new referral was created.

3. Updating our client websites have become a big issue with our firm on time and accuracy in the data since its double entry. So via web services the iSeries gets updated via user then the iSeries sends that data to the correct Client site for update.

What made my ablity to do this with more ease and help was Scott K. information on Expat Parser and the help of CGIDEV2....

-John Major

Web Services offer a great value proposition for reusing code in an any-2-any scenario. As has been suggested .NET and J2EE interoperability with RPG begs for a Web Services solution. I suspect though that many iSeries shops have the same problem as our organization has. We are following IBM's Websphere mantra and need to integrate RPG and Java specifically. While Web Services are probably the most flexible integration architecture, we found that it does not meet the needs of high performance transaction processing between a J2EE Struts based front end and RPG back-ends. We also experimented with Stored Procedures. These also left us with the problems (primarily stale connections at times of peak iSeries paging). The solution that is really working for us is to integrate using the iSeries Toolbox for Java's PCML classes. PCML used to be a resource hog that did not release threads back to the pool in a consistent and predictable manner. The November 2005 update of JTOPEN from IBM seems to have address all of the old performance issues. I'm not saying that the Java Toolbox is better than Web Services as an approach to SOA, but that in some cases it will yield significant performance benefits if all you need is Java and RPG integration.