GT Software BLOG

When companies and products win various awards, there is often no individual associated with the recognition. That’s why it is especially noteworthy to report that Dusty Rivers, our IMS SOA Evangelist, has been named a “data champion” as part of the IBM Information Champion Program.

Regular visitors to our blog see Dusty’s posts. At this time of distinction, I just wanted to take a few lines to introduce him and show why we agree that he is worthy of this honor.

With an extensive 33-year background in global mainframe systems integration primarily focusing on IMS, Dusty has played an integral role in the design and implementation of distributed mainframe projects for a distinguished list of FORTUNE companies throughout the finance, government, manufacturing and insurance industries. Well-regarded within the technology community, he is a frequent presenter at conferences in the US, as well as in Europe, South Africa, and Australia.

Nominated by IBM’s Ann Sheridan for his outstanding contributions to the Data Management community, Dusty has worked on the initial design of many products that integrate the IMS systems to the distributed world – first at BellSouth in the IMS and DB2 groups, then with IONA with the Orbix Mainframe Integration (IMS), then the Artix mainframe product. Dusty now works with global organizations to extend the use of IMS into the world of Web services.

A Share IMS Committee member and former relational data base project officer at Share, Dusty was one of the founding members of the Alabama DB2 users group.   Chosen for this recognition for 2010, his membership places Dusty among a small (dare we say elite?) group across all of IBM Information Management and Business Analytics communities.

Congratulations to our colleague Dusty Rivers for a well-deserved honor.

Last week at CA World in Las Vegas, GT Software formally announced Ivory 4.2.    Most prominently, in this release, you will see a major commitment from GT Software to providing support for CA Ideal, CA IDMS, and CA Datacom.   By preserving and web-service enabling CA Ideal-based applications, Ivory 4.2 allows you to derive even more business value from your investment in mainframe systems.  Features like an intelligent panel analyzer for CA Ideal panels and the ability to exploit the 3270 bridge facility in CICS makes CA integration fast, easy and efficient.

The latest version of Ivory Service Architect also contains a substantial list of other exciting enhancements.  Most notably is the ability to use the Delegate Node processing on both the Ivory Server for Windows and the Ivory Java Server.  Allowing the execution of custom .NET and Java programs greatly increases the coverage and scope of functionality by including routines like: compression, un-compression, data manipulation routines, or custom functions

Click here to read the full press release or visit www.gtsoftware.com for more details.

Maybe I shouldn’t admit this on a public technology forum, but I am not really a big Star Trek fan. I am however a HUGE fan of Linux on System z. Think about it…the hyperdrive allowed the starship to fly through space faster than the speed of light, virtually un-throttled in earthly terms. You also don’t see huge fuel tanks to power this unleashed speed, almost like it’s free. Imagine now having un-throttled speed on the mainframe that will allow you to get work done faster than on your GPP (general purpose processor) and as an extra incentive, the MIPS on the IFL (Integrated Facility for Linux) are free! Linux on System z, the Hyperdrive for the mainframe.
GT Software has extended its Ivory Service Architect product to run on Linux on System z. This means that you can now host your mainframe SOA infrastructure on the IFL. Take advantage of the power and stability of the mainframe without impacting your GPP or your bottom line. If you would like to learn more, please attend this live webcast to learn how you can save money, reduce MIPS, and expand your mainframe SOA strategy without impacting your GP. For more information, view the following Webcast: Mainframe Integration with Linux on System z

Before we start, I must acknowledge that this is in fact my first BLOG ever. I know, I know, I’m a real trendsetter, but I’ve often felt that you need to be committed to the “cause” and ensure consistent BLOGing or simply don’t do it at all. Well after much self-reflection (and prodding by some ‘friends’) – I’m ready to give it a go!

I’ve have been working in the integration space, most recently mainframe integration, for well over 15 years. The last 5 years with GT Software. We all know that the mainframe is a pricey, though extremely effective, platform and integration is key to ensuring the mainframe’s current and future viability.

Over my career, I’ve witnessed raging mainframe integration successes, and miserable mainframe integration failures. It’s always interesting to reflect on what causes success or failure and try and boil it down to a few simple ideas that are easy to understand and implement. Over the next few weeks I will do just that and provide what I believe to be the 5 guiding principles that can be the difference between success or failure for your mainframe integration projects.

Here’s the roadmap we will cover to ensure your raging success for mainframe integration projects:

Foreword: Before We Start, What is the Real Problem We’re Trying to Solve?

1. Defining the service
2. Assembling the service
3. Deployment
4. Time to deliver
5. Flexibility to change

I hope you’ll take the time to follow this thread and share your experiences and comments as we refine the integration problem to its core elements ensuring you make informed decisions about your future.

Rob

I took the Ivory Service Architect and created a very nice service based on IMS transactions. I then went into the Oracle BPEL process manager and created a BPEL process that included the aforementioned service.

So in a matter of ten minutes I had a BPEL business flow that call the IMS service as a partner-link(BPEL – Speak). I also created a composite service in Ivory that actually orchestrated multiple IMS transactions , then included that into a BPEL flow, which means the orchestration takes place on the mainframe where it belongs and does not require the BPEL tool to have to deal with multiple mainframe transactions. So yes you can easily include “ANY” mainframe artifact in a service that can be included into a BPEL flow…in minutes, not days or weeks.

One of the biggest  integration challenges  many developers have faced over the years is what to do about the data.   Especially when that data resides on the mainframe.   Over the years, programs have been written, FTP processes executed, ODBC/JDBC based applications created, none really providing a seamless and straight forward way of integrating data.

With the increased popularity and acceptance of web services, one must not forget about the data.  Having a strategy for providing data access from within a coarse grained service, or as part of a fine grained or business service, is crucial to the success of an SOA strategy.   By using a standard web services interface to the data, no programs need to be written, no FTP processes created, and there is absolutely no need for ODBC or JDBC.    This capability adds a dimension to composite services that lends a great deal of flexibility.   Imagine doing a database lookup and passing that data into another application without writing an application to get that data.   This is the nirvana of data integration.

So many times we hear that bigger is better. I would argue that when it comes to web services, smaller is better. It is very easy to be drawn in by the idea of taking a copybook, creating a service, without any regard for what is in the copybook. When we need a gallon of milk, we don’t go and buy the entire store! We get only what we need. The same should hold true for web services. Too many times we try to create services that cover all the possibilities anticipated. I would argue this type of approach is too broad and would incur a significant amount of unnecessary overhead. That is not to say that every service needs to be absolute either. Tacking on an extra field or two for the sake of reusability would not be a bad idea. When thinking about the size of the service, remember size does matter, and that is the right size.