Service-oriented architecture (SOA) evolved through intelligent design at Con-way Inc.
The antecedents of SOA at the $4.7 billion freight transportation company began with mainframe integration to Java systems and a commitment to component-based development, explained Shibashis Mukherjee, Con-Way lead enterprise architect.
He started in 1996 using the automated code generation capabilities in CA Gen, which he is still using today, for converting "monolithic" COBOL applications to Java. In 1998, the IT department adopted the component-based development methodology.
"We started with the component-based development methodology," he recalled. "At that time SOA wasn't the big thing yet. We realized it would help us develop faster if we had reusable components to build applications. As our development process matured and SOA came into play, we figured out how to compose the services. Another thing that was important is we defined a canonical model, so all services use the canonical model. That way we have a common language for integration."
At first, projects focused on converting legacy backend functionality into components, Mukherjee said.
"Each component offered a set of operations," he explained. "You can think of them as sort of primitive services. At that point in time they were only used by mainframe applications, but they were offered through an interface. As we built more and more components we assembled applications using the services offered by these components."
As use of Web services emerged in the early part of this decade, Mukherjee said Con-Way developers started generating Java proxies from the mainframe component operations and wrapping them as EJB methods, thus providing J2EE services.
"Basically the discipline that we had for the component model using CA Gen extended those services into the distributed world," he explained. "Our services on the J2EE side were also offered as interfaces and components."
As the SOA approach began at Con-Way, a taxonomy for the components was created to keep "all the services clean and organized," Mukherjee said. This avoided problems with rogue services. The next step was to use SOA to link legacy mainframe business logic to the Java and Microsoft .NET applications that make up Con-Way's heterogeneous environment.
"Then as we needed those services for other platforms we took those EJB methods and wrapped them as Web services so they could be consumed by .NET platforms or mobile applications," he explained.
The original conversion to SOA from developing components used in a Web services environment started with some basic projects. For those starting out on the SOA path, Mukherjee counsels patience based on his past experience.
"It took a couple of projects to see all the benefits," Mukherjee said. "You don't generally see the benefits in the first project you do. We also had executive management buy-in and we had a long-term vision. So as project after project is done, our development time was cut as we reused components built by the previous projects.
He credits much of Con-Way's success with SOA to having the discipline of putting a governance process in place for how the services will be used, and setting the component boundaries for keeping all of the services clean.
The reduction in subsequent development time he credits to an all-out commitment to reuse that began with the first initial projects.
"When we built services at that point in time, we built every piece of functionality as a reusable piece of code," Mukherjee said. "We had no idea whether it was going to be reused or not."
That way developers starting a new project can check the registry/repository to see if there are components they can reuse in a new application.
Mobile SOA is the next step in the evolution as applications are being extended to truck drivers and workers on loading docks.