SOA World Magazine serves as the Internet technology industry's journal of first resort for technical and strategic insights on the new distributed computing paradigm that is transforming use of the Internet by business and by individuals.

Cover Story: Redefi ning the Economics of Mainframe SOA
BY GREGG WILLHOIT

Next-generation middleware exploits IBM System z specialty engines, redefi ning mainframe total cost of ownership and spurring expanded legacy participation in Service Oriented Architectures

Of all the wonders Service Oriented Architecture has wrought in the business world, one of the most valuable has been to unlock legacy data, applications, and processing resources for new and profi table use. Residing on mainframe platforms, such assets have been notoriously tricky and costly to change and adapt to new, typically web-centric, purposes. On the other hand, they often excel at the critical functions they have provided, typically for decades, and are highly reliable. Replacing them outright would be extremely costly as well as disruptive to operations that are com-monly mission-critical to an organization.

The rapid adoption of SOA in business and government organizations has radically changed this picture, and has opened the door to almost unlimited ways of mining the riches of the legacy assets contained in those organizations’ mainframes. It has dramatically altered the perception and role of the mainframe, making it considerably more capable of participating in loosely coupled, standards-based cross-platform environments. To be more agile and competitive, organizations with tremendous investments in legacy mainframes are turning to SOA to provide more infrastructure flexibility with reduced development cycles and lower costs.

With a heavy reliance on the industry-standard Simple Object Access Protocol (SOAP) and Web Services Description Language (WDSL), SOA’s role in enabling the mainframe’s participation in modern distributed and web-centric applications is largely a function of the middleware software. ...

Download SOA World Magazine, February 2008

PDF format, 3.2MB.

3 Simplicity by Design
SEAN RHODY

6 SOA Made Easy
ROB DAVIES AND JAMES STRACHAN

10 Sanity, Strategy, Sustainability
MARK UNDERSETH

12 Estimating & Budgeting for SOA
Projects the Iterative & Incremental Way
NANDAN DASGUPTA

22 Using Integration Appliances To Reduce Complexity in SOA and Increase Business Value
CHANDAR PATTABHIRAM

26 The SaaS Superhighway
ASH MASSOUDI

30 Redefining the Economics of Mainframe SOA
GREG WILLHOIT

34 When You Need to Cancel a SOA Project
DAVID S. LINTHICUM

Visit SOA World Official Web Site

Simplicity by Design (From the Editor)
WRITTEN BY SEAN RHODY

As a student of physics, Albert Einstein is one of my personal heroes. Aside from being one of the most brilliant minds to ever contemplate the universe, Albert had a way with words. One of his quotes strikes me as particularly apropos for this month’s issue – “Any intelligent fool can make things bigger, more complex, and more violent.

It takes a touch of genius – and a lot of courage – to move in the opposite direction.”

This month we’re focusing on two subjects that actually tie in together much more than most people actually anticipate – SOA Testing and Service Design. I’ll get to how they tie together in a moment, but let’s see how Einstein relates to SOA first.

With SOA, it’s very easy to buy the plumbing. You go out and get an ESB, a rules engine, something to do BPEL or BPML, and something to do basic services management and you’re ready to tackle that great big world of SOA.

Of course, at that point you are in the same circumstance as you were 20 years ago when you finally made that step away from ISAM and selected your first relational database. You bought all the goodies, got it installed and then you sat. And then you realized that your great big shinny database was empty. So you started designing tables. Maybe you thought about normalizing, maybe you didn’t, but before you knew it you had umpteen tables and performance was in the toilet. What was so great about RDBMS anyway?

Naturally, there was a learning curve, and some bitter experience with normal forms and what level is reasonable.

The question then was, and yes, I’m finally getting back to the point, what was the right approach to database design?

Fast forward to today and we’re asking the same questions about service design – is it a customer service or a customer edit service? Maybe it’s all part of the account service. Because after we get over learning about what WSDL is, we still have to figure out what to make with it. We still have the same issues – if we make the service too fine-grained, we have too many of them and eventually someone will come along and aggregate them anyway – and perhaps not in a way that’s optimal. If we make the service too coarse-grained, we risk creating EDI all over again – one method with 80 parameters, all optional. There’s even the added complexity of standards such as ACORD – importing and using the whole schema adds tons of elements, many of which you may never use. Like the man said – it’s easy to make it bigger and more complex; it’s hard to go the other way.

One way to try to swim against that tide is to start designing with the concept of testing in mind. Rather than wait until the service is coded before you begin to design the test cases that will check to see if it works, why not start with them. Do the design from the perspective of testability and functional completeness, and you may have a jump start on how to handle your actual service design.

There’s no silver bullet that I’m aware of to magically adjust your service designs until they’re optimal. Service Management provides needed tools to take a look at QoS and establish service SLAs that will allow for meaningful investigation of your service design, but the fact of the matter is you won’t get it right the first time, so allow yourself time and budget for refactoring. You should also note that conditions will change over time and what was once optimized and working properly is now in need of some TLC. This is where performance testing and predictive modeling can help in anticipating capacity planning for services. Once again, an ounce of testing is worth a pound of code. You can quote me on that – I may not be Einstein, but I did stay in a Holiday Inn Select last night.

Comments (0)

Name

Email

Comment

smaller | bigger

Add Comment