Two Canadian companies say Web services have brought easy and cost-effective integration into their respective organizations – but they still recommend users break down such implementations into manageable pieces.
Brad Hudon, director of IT development for Future Electronics, an electronic components maker in Pointe-Claire, Que., said his company had been using custom-developed Cobol-based systems, but in the last few years had “strayed from that recipe,” creating satellite systems with disparate technologies running on them.
The integration problem became obvious after Future bought a software package and realized there was no platform to connect the product to the rest of its applications. “We got into this big mess where we had a whole slew of point-to-point proprietary vendors,” Hudon said.
Future looked into the middleware offerings from application vendors like SAP, but decided it didn’t want to go that way. “We started to get the feeling that we’re going to get locked in here,” Hudon explained. “It means you’re getting (your integration) and your ERP from a single source, and you have to go back to them for all your problems.”
As part of its search for a solution, Hudon brought Fairfax, Va.-based integration platform vendor webMethods in for a test run. The three test scenarios included: real-time database synchronization; the use of an application programming interface (API) to connect an HP NonStop Himalaya server to Future’s legacy systems; and connection of business logic on five legacy servers to Future’s systems using SOAP (simple object access protocol), via Web services. It was through this third test that Future found the value of Web services “by accident,” Hudon said.
The “skeleton” of the Web services implementation was finished in five days, not including what was completed during the proof-of-concept stage, which concentrated mostly on opening up the firm’s legacy order processing system to the Web. “We then had to flesh out some business rules and add some complexity,” Hudon said.
Four to six weeks of analysis followed, during which Future did some digging into technical problems. “There were some minor irritants – like the SOAP adapter that we were using was relatively new, and it was accepting and returning invalid characters.” But in the end, the technology wasn’t much of an issue, Hudon maintains.
Vendors usually tout the benefits of external integration, said Hudon. Although Future now offers some Web services outside the enterprise, the real value has been found internally. He said Web services has helped Future accelerate its product delivery schedule and save time by not requiring its internal developers to write the integration code themselves.
Shell finds its voice
Another customer says Web services has indirectly added another layer of security in his company’s systems.
Calgary-based Shell Canada Inc. uses an interactive voice response (IVR) system that dealers and customers call into to find out gas prices. It exists on Shell’s internal LAN, but Shell doesn’t maintain the actual software or the machine it sits on – so the company has to treat the IVR system as an outside component, said Kevin Sullivan, head of webMethods integration in Shell’s information and computing department.
Shell wanted to make the gas price information and updates available on the Web, but realized that directly connecting an outward-facing application to its back-end systems could increase security risks – so it brought in webMethods as a middle layer that acts as a communication moderator between the front and back end.
“If you want to do a price inquiry, the IVR sends the query to webMethods…(which) does the program calls to a variety of systems it’s interfacing with,” said Sullivan. The back end sends webMethods a message containing the information, and then webMethods returns the response to the front-end application – that way the back-end isn’t accessed directly.
Shell also selected webMethods because it wanted to save itself some third-party maintenance headaches. “One big advantage is that …with passwords and rules, we can actually modify them without getting the company that maintains our IVR involved,” he said.
Web services was a familiar term to Shell’s IT department, but it had no practical experience with the technology before this project, said Sullivan. He was skeptical about how appropriate Web services would be for heavier-weight applications, but since Shell only gets about 1,000 pricing calls a day, he felt he could relax. “If it was 100,000 calls a day, we would not have chosen Web services.…In the literature I’ve looked at, I haven’t seen any evidence of it working with such high volumes. Web services is a good for fairly lightweight applications.”
Sullivan said it took a couple of weeks to get things working, because of initial glitches and “silly mistakes” made during the test phase where a Web services server was set up to facilitate communication between systems.
The replacement system is “a lot more robust,” said Sullivan, with a response time of one or two seconds. “Once it’s been up and running, it’s been very stable.”
Sullivan advises users to look out for the “normal caveats around new technology” when trying out Web services. “Pick an application that you can afford to make mistakes on,” he said.
Hudon added, “Don’t put everything on hold just so you can a Web services project up and running….Take it in chewable chunks,” and only stay on course if productivity results are noticeable.
