SOLA Promises Rapid SOA-fication for Big-Iron Environments
SOLA purports to be a one-stop shop for mainframe service enablement -- complete with design studio, testing workbench, and registry support
Service-enabling your mainframe assets can sound intimidating, especially as many mainframe shops are just now dipping their toes into the SOA water. SOA Software Inc. says it doesn't have to be that complicated -- provided you're using the right tools.
The right tool, they say, is the company's Service-Oriented Legacy Application (SOLA) suite. Last week SOA introduced SOLA version 6.0, the latest revision of its one-stop shop for mainframe service enablement -- complete with design studio, testing workbench, UDDI registry support, policy enforcement capabilities, and Web services support. It integrates with popular change management software tools from Serena Software and other vendors, according to SOA officials. More to the point, they argue, SOLA provides the most straightforward access to service-enable your mainframe assets.
According to the company, many IT shops are still cautious even though IBM Corp. markets several mainframe service-enablement solutions, including its Rational Developer for System z, Rational Developer Extension, and Rational Transformation Workbench. Jim Crew, a vice president with SOA software, notes that "what you get with IBM is many different products which are not integrated together. You have Rational Developer for [System z], which seems to be targeted to … well, I don't really know who it's targeted to. It's really not targeted to the mainframe programmer, and it's really not targeted to the Java programmer.
"Rational Developer for [System] z is a renaming of what used to be called WebSphere Developer for zSeries. The point is, in the IBM space, you have all of these separate components. You have a registry [WSRI], which isn't really integrated all that well into the runtime environment. You have lots of different solutions supported by lots of different groups."
What SOA touts is a one-stop shop for service-enablement, Crew says. Its major competition isn't Big Blue but a pair of third-party players: GT Software and the DataDirect division of Progress Software. "IBM isn't really in the space -- they just have the big name."
What makes a one-stop SOA shop? SOLA 6.0 includes a Web 2.0 development environment (the aptly-titled SOLA Development Studio), that ships with a services registry, supports the business process execution language (BPEL), boasts a WS Security implementation which runs natively on the mainframe, and delivers a number of other SOA must-haves, according to Crew.
"It's easy to create a single service, but many [organizations] are taking these small services and combining them, so you need a registry [to publish and keep track of them]. You need workflow -- which is why BPEL is so important -- to manage them," Crew explains.
"One of the goals behind SOA is [service] reuse, and the only way you can get effective reuse is by means of a registry. SOLA also supports the WS Security specification [and does so] natively on the mainframe. For many customers, this is preferable to hosting [WS Security] off the mainframe, where you have to send plain-text, unsecured messages, across the network to your middle-tier destination, [which introduces] last-mile security issues."
When it comes to service-orientation, IBM and other vendors like to tout the overall ease of service enablement: Service enablement isn't a snap, they concede, but in many cases it can be automated to a surprising degree. This is a theme that Crew and SOA also highlight: the SOLA Development Studio's drag-and-drop interface and Web 2.0 user context, which they say make it easy for mainframe programmers to service-ify COBOL code.
"It's designed for the mainframe COBOL programmer. We made it easy from a paradigm point of view for them to understand what they have to do," Crew explains. "[A COBOL programmer can] import the program [into the SOLA Development Studio], and SOLA reads the procedural statements of the program, and figures out a signature -- it knows what data fields are used and identifies input and output -- so in a lot of cases, 90 percent of the work is done right there," he continues.
Crew concedes that in many (if not most) situations, programmers are going to have to use SOLA's analysis feature to drill down into the code; but for a number of programs, one-click service enablement is a distinct possibility.
"We actually offer a one-click capability. Once you've imported the program into the tool, you can automatically publish it. If you choose to go into the analysis tool, you can [publish it manually]."
Once a service gets published, SOLA takes care of the rest. "The tool automatically documents the service in the UDDI directory, creates runtime data for you that gets propagated into production using your change management tool, and it creates a test target for you," Crew says. "If you're a COBOL programmer, you don't have to write Java [to test your service] -- you can do a fill-in-the-blanks test instead. It also automatically inherits a policy, so it becomes a secure service from the moment it's created."
SOLA is written in Assembly, says Crew, who himself came to SOA Software from Merrill Lynch (ML), where he was a director. "It's written in Assembly to maximize its performance, because we know that [in mainframe environments], MIPS consumption is a crucial issue.”
Software licensing is also a crucial issue for most Big Iron shops. In this respect, Crew argues, SOLA 6.0 offers a more straightforward route to service enablement. "There's no need to integrate multiple vendor products -- separate registries, separate security, a separate development environment. With SOLA, you're dealing with one and only one vendor to solve your mainframe SOA problems. You can service-enable your mainframe [assets] and manage [these services] along with your services on the distributed side."