more liveblogging: Robert LeBlanc on zSeries SOA

From the IBM SOA on z industry analyst conference:

I have known Robert LeBlanc for a few years now. He did a good job at Tivoli, turning the organisation once and for all into a true IBM division, rather than a maverick Austin outpost. Now he is running WebSphere as SOA kicks into high gear at IBM.

Robert claims IBM was able to spin out its PC business to Lenovo seamlessly, without interrupting the supply chain, by taking a SOA approach, which is a story I hadn't heard before.

So this mainframe SOA thing. What are the numbers?

He said CICS saw the fastest version to version upgrade by customers in 35 years… to take advantage of new XML and Web Service functionality.

WebSphere Application Server (WAS) on System z grew 21% in 2005. That is pretty impressive growth. IBM also claims 25% of z accounts are now running WAS.

What is the news?

CICS Transaction Server v 3.1 has been enhanced. Who knew this product would hot enough to justify six month revs?

One enhancement is to integrate CICS Service Flow runtime with Websphere Process server. That potentially means "workflow virtualisation" between the two environments.

I had a short conversation yesterday with John Shedletsky, "Mr Mainframe TCO", about language. One big problem for the mainframe is that mainframe people speak a different language from distributed people. Many architects literally don't know what their mainframe people are talking about. John pointed out something very insightful.

CICS is just a container. Say that to a Java architect and they are going to grok it straight away. Sounds simple doesn't it? I would like to see John pursue this line. Maybe we need a mainframe to distributed translation wiki?

But back to Robert.

He spoke to IMS enhancements: IBM last year offered an IMS SOAP interface. The new announcement is an XML adapter on IMS connect, enabling direct connection to IMS without needing WAS an an intermediary. Expose the transactions. Note: I need to get some clarification here. SOAP is one thing-but in many respects native XML is more interesting because it potentially enables more RESTFUL development and data access models. If I am a mainframe shop that wants to offer an online information service, its likely to get more consumers if I offer a more lightweight API, rather than forcing everything through SOAP. SOAP is anathema to many Web 2.0 developers, and IBM definitely needs to position z for Web 2.0. IBM needs to think more about XML data sources not just XML Web Services.

But for those that do like WS-* and metadata-driven development Robert said IBM is going to bring Registry/Repository to the mainframe by year end.

Its also interesting to hear IBM's approach in that regard. While IBM has been saying that its Reg/Rep architecture is federated, what does that mean in practice, and why is it relevant to mainframe?

("The return of the data dictionary" -is this one for the mainframe to distributed babelfish wiki)

The point is that IBM plans to position z as a master registry manager (like master data management), across multiple SOA end points. Maybe it’s a "Registry of Record" but I think 37Signals already owns that acronym ;-)

All in all it seems z and SOA is really happening. Wachovia, a customer, also came in and presented. More on that soon.

by James Governor May 4, 2006 in Application Development


TrackBack URL for this entry:

Listed below are links to weblogs that reference more liveblogging: Robert LeBlanc on zSeries SOA:


James my friend!!! It is great that you are blogging real time from the Summit - there is so much going on with SOA. We hosted over 200 customers yesterday at our SOA executive summit!

But onto today! As Robert says, What have you done for me lately! SOA and System z. System z is benefitting big time!

Why is there so much buzz about SOA and z? I think its because our Customers have such significant investment in their existing z environments and SOA provides a natural extension and investment protection of those environments. Rip and replace options are not feasible (and there are many failed attempts that have been left roadside that support this thought ).

SOA enables mainframe customers to reuse their existing investments, significant investments that have been made over decades ( estimated are up to about $3 trillion (USD) in investments!!).

The growth in WebSphere Application Server for z/OS is indicative of this. and Yes we are delighted with the 21% growth!!!, but we aim to do better. We are off to a great start in 2006 with significant double digit growth rates. Customers are looking to WAS z/OS because of the ability to hit the TCO "sweet spot" which is further enhanced by zAAPs. Within first 6 quarters of in market availability, zAAPs exceeded IFLs in sheer volume by about 20%.
WAS for z/OS customers have seen off-load rates of Java MIPS fall anywhere from about 40 to 80%, with cost savings in the millions. This cost savings and the ability to hit a "sweet spot" by deploying high volume, heavy transactional application to WAS z/OS is why our biggest customers are moving more applications to this great platform. In fact Version 6 is the fastest growing WAS z/OS version to date, from 2005 to date, our Version 6 adoption rate has already doubled.

Many of our large enterprise customers have found that consolidating on WAS z/OS for new and enhanced business critical applications with high volume throughput to mainframe assets can save them anywhere from 5 to 30% cost savings (GAD, BMO). In fact one of our customer Insurance Services Organization (ISO) based in New York recently reported that they saved approximately $3M by implementing zAAP engines.

Another area of focus is on the SOA and Web Service enablement of CICS and IMS becoming SOA enabled and exposed as services, so that building solid composite applications has never been easier. Connecting these resources is easier as well. A great and talented employee of mine told me recently - The real answer to the RESTFUL versus SOAP discussion is not one or the other, but both. True that using REST can be is a good thing, but a SOAP compliant binding also serves it's purpose. Both provide "binding" to business logic -- REST provides a very simple binding, and SOAP/WS a more full function binding with support for Reliable Messaging among others.

With the introduction of our process management portfolio ( we see BPM at the heart of many successful SOA implementations) on System z and the abilitiy to integrate to core resources, System z is indeed positioned well to be a strategic and long term player in any SOA environment.

Sorry so much .... but as you know me, I am also so energized with SOA adding value to customers!

Hope to see you soon!

Sandy Carter
VP, SOA and WebSphere for IBM

Posted by: Sandy Carter | May 4, 2006 4:34:49 PM

James, interesting, I first pitched the idea of XML to CICS and IMS back in the spring of 1999, oh yeah those were the good old days.

The question I yet to hear asked, or even much better answered, is what data do IMS and CICS have that would be of interest to WEB 2.0 via REST only interfaces?

While its exciting imagine that you can easily stream thousands of terrabytes of mainframe data out through a connector using only XML/HTTP, you apply a little thought to how it is accessed, by whom, for what, how long for, data currency etc. etc.

I'm not suggesting thats a reason not to do it, heck my presentation of spring 1999 started this thinking and I'm scheduled to teach the XML/Web Services/SOA workshop ate the z/Expo in October for the 4th year running... just interested in your thoughts.

Posted by: Mark Cathcart | May 5, 2006 10:51:44 AM

i have been wondering that myself Mark.

All I know is that many developers are SOAP dodgers. Its not clear to me that making SOAP necessary answers the questions you ask though...

SOAP is a barrier to entry, without offering a throttle mechanism for the data being front-ended.

Developers are smarter than us. Who would have expected that Chicago crime data, for example, would prove to be some interesting in a mashup context. If you don't let Web 2.0 and mashup types in you're not going to find out...

that's a big glib, but i have only had about three hours sleep. Lets think about some use cases.

Posted by: James Governor | May 5, 2006 11:07:38 AM

I agree, it just requires some thoughts. The DB2 folks have the web services cracked to a degree for Web Services with DB2, this was recently bought to my attention:

and it obviously still looks less than simple, for someone that doesn't know the tool, but increasingly enterprise developers are getting to grips with WebSphere Developer for zSeries and so this isn't a massive hurdle.

I think we need to do is try to workout if there is a market for people who want to do a mashup of parts catalogues, flight details, account balances, store inventory, share trades etc. with only cursory security, and what the issues are with data consistency, update etc.

Perhaps this is a good time to get my corner going again, I'm being asked to help with a M/F SOA customer project and I can see lots of simple answers to what in seems to be common confusion. Its that "language" problem you and John discussed.

Posted by: Mark Cathcart | May 5, 2006 2:58:55 PM

When it comes to finding a market for mashups, the first thing that comes to mind is the BEA case of Pratt & Whitney ( I believe). I heard about them first at the BEA Analyst Summit this year. Essentially, Pratt & Whitney created a mashup of all their parts, inventory, and realtime repair data. Customers could watch and provide input for engine repairs as they went through the repair chain.

Posted by: Cote' | May 9, 2006 5:47:23 PM

Cote, thanks I read the reference story on Pratt and Whitney and I bet thats based on SOAP rather than simple REST style web services.

Unfortunately the brief doesn't provide any technical details, asides from it obviously is based on a BEA middleware stack, which means its a 3-tier solution with BEA running off the mainframe. That in itself I assume would require some stateful service to hold connections etc.

The RESTful services that James is getting so excited about, run directly into IMS via an Apache web server and IMS Connect. In this case IMS Connect is managing the connection to IMS TM and thus would handle security, transaction scope, data locking etc.

I don't doubt the value of exposing M/F data via the Internet. After all I built the first ever CICS Connector and HTTP Server on the M/F and demoed it at WWW5 in Paris in the spring of 1996... the question here is would a stateless get/put type interface via some form of RESTful interface be useful? If so, what for ??

Posted by: Mark Cathcart | May 14, 2006 6:43:10 PM

The comments to this entry are closed.

The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.