Tech traffic cop: SOA tries the enterprise system on for size
Having just completed an acquisition that doubled the company’s size, Cohoes, N.Y.-based Mohawk Fine Papers needed to rationalize a diverse collection of enterprise applications, a manufacturing network that doubled to six sites, and a distribution network that quadrupled to four warehouses.
“With a larger network comes more pressure on us to do effective advanced planning and forecasting,” explains Paul Stamas, Mohawk’s VP of IT.
Assimilating the acquired operations within 90 days, Mohawk established itself as the leading supplier in its niche in the premium fine papers segment of the market. Contending with a much more complex supply chain, the company sought to integrate its existing BPCS enterprise system with the Infor ShipLogix transportation management solution deployed recently to replace an older Logility application. And with a much larger production network, Mohawk also wanted to tie BPCS into the Datastream enterprise asset management system—also from Infor.
This wasn’t Mohawk’s first foray into integrating enterprise systems, but on this go-round, it wanted to avoid the pain of custom development that characterized its earlier efforts.
“The biggest problem was managing all the interfaces,” recalls Stamas. “The failures in the previous integration were point-to-point connections that nobody owned.”
Admittedly, Mohawk’s experiences aren’t all that unusual for companies attempting custom integration. But in today’s less-forgiving market, Mohawk couldn’t afford a repeat of the same risks. Instead, it took a different path, adopting Infor’s Event-driven Service-Oriented Architecture (SOA) to integrate systems using a vendor-supported architecture.
SOA represents a new way of architecting software. Whereas applications tightly couple their functionality as part of a software module or package, SOA decouples it by making the service independent of the underlying application, database, or platform; and makes the service available over a distributed network through a request/response mechanism. By exposing more granular services in standard fashion, SOA could conceivably increase reuse, improve business agility, and hopefully provide a more straightforward, vendor-neutral path to integration.
The resulting services may expose a piece of a single application, or compound bits and pieces of functionality from multiple sources. For instance, a service that generates a profile of a customer may involve extracting account payment status from Oracle Financials, and interaction history from Salesforce.com .
Given the vast consolidation of the enterprise software market over the past few years, it isn’t surprising that vendors such as Oracle and Infor are looking to SOA to leverage industry standards as a basis for integrating their increasingly diverse portfolios. Likewise, it’s not surprising that other household names like SAP also are tapping SOA to solidify their positions as de facto enterprise application hubs for their installed bases.
The “standards” of SOA
SOA often is confused with Web services, but the two are not synonymous. The comparison has come about due to emerging Web services standards that have drawn vendor support to make it a common architectural strategy across the enterprise software industry.
Admittedly, support for standards may not be universal, but virtually the entire enterprise software industry has embraced several key XML-based building blocks ratified by the W3C and OASIS standards bodies. They include SOAP, a message format for building Web services requests; WSDL, protocol for describing Web services; UDDI, for specifying Web services registries; WS-Security, specifying how to attach signature and encryption headers to SOAP messages; and the WS-I profiles for testing interoperability.
Beyond these building blocks, the standards picture gets more muddled, with more than 100 proposals either ratified or making their way through the specifications process, and widely varying prospects for adoption.
Not surprisingly, in some cases—such as how to communicate trust in distributed networks and virtual business environments where intermediaries are likely to play major roles in vouching for service requests—there are several competing specifications that are only now beginning to converge. Meanwhile, other proposals cover areas such as workflow and orchestration, which are not yet in common use at the Web services level.
With the core foundations in place, most enterprise software providers are in the midst of SOA-enabling their applications—in most cases through support of Web services.
“Previously, integration vendors hard-coded their links,” notes Amlan Debnath, VP of server technology for Oracle. “This time, the integration points will be standards-based, migratable, and supported.”
Oracle’s SOA strategy is built around its Fusion middleware, which is comprised of its JDeveloper Java development tools, plus business rules engine, BPEL process manager, and business activity monitoring (BAM). Oracle also is offering an Enterprise Service Bus (ESB) as part of Fusion, plus a Web services management tool for enforcing policies on exposing Web services and applying security.
Meanwhile, Enterprise SOA (ESOA) comprises SAP’s blueprint for exposing services from ERP 6.0 and R/3 through the SAP NetWeaver midtier platform.
“The idea of ESOA is that we provide bus building blocks and reusable processes so customers can more easily adapt to respond,” says Fergus Griffin, VP of platform marketing. To date, SAP has defined hundreds of service blueprints, although Griffin says SAP isn’t necessarily service-enabling its entire set of functionality.
“Customers are telling us they need processes like order-to-cash or procure-to-pay service-enabled,” says Griffin.
Infor has taken a different approach that uses different sets of standards than from Oracle or SAP.
“We’ve hidden as much of the SOA as we possibly can,” explains Jeremy Suratt, senior product marketing manager for Infor. “If you are a customer, you won’t need to know the internals of SOAP or WSDL.”
Unlike SAP, which is generating its own service blueprints, Infor is relying on canonical business document definitions from the Open Applications Group Integration Specification (OAGIS) to model the services that are exposed from its applications. And rather than relying on SOAP messages and BPEL—which Oracle and SAP are using to build business processes by orchestrating multiple services—Infor will leverage an event-driven publish/subscribe model that uses JMS messages, as well as a data-driven REST model for communicating between applications and the ESB.
Unlike Oracle, which offers its own ESB, Infor will rely on Progress Software ‘s Sonic bus.
By contrast, Software-as-a-Service (SaaS) providers Salesforce.com and Workday are using SOA under the covers. Salesforce customers typically will see the results of SOA integration as a choice of sharing data.
|Event-driven service-oriented architecture (SOA) is an approach whereby interoperable applications and software components can be deployed and upgraded with little or no disruption to other enterprise systems.|
For instance, customers of the new Salesforce 2 Salesforce B2B service simply choose which trading partners are entitled to gain access to which data, as opposed to having to build WSDL service definitions or SOAP request messages. Alternatively, if they have on-premises systems that are not part of Salesforce’s AppExchange, they can use Salesforce’s Web services to forge new composite applications that run on Salesforce’s platform.
In turn, Workday—which recently acquired ESB provider Cape Clear—will offer a mix of packaged and custom integrations that are managed, not by the customer, but by Workday.
“We really don’t notice SOA,” says Joe Graves, CIO of Stratus Computer and a Salesforce.com customer. In the past six years, Stratus has replaced most of its stand-alone legacy applications—some of which dated back 15 years. And with applications such as SpringCM ‘s Web-based document management and workflow system, the Web services integration is strictly under the covers.
“You provide a login and they readily integrate with your instance of Salesforce. The only time we worry about the interface is ensuring it’s not a batch interface if we want something that is relatively real time,” notes Graves, referring to integration between an on-premise instance of Oracle with FT Quote, where Stratus has opted for 15-minute refresh cycles.
But one place where SOA is more visible is in Stratus’s B2B integration with contract manufacturers. There Stratus uses an on-premise version of the Cape Clear ESB, where an EDI-like system is implemented by exposing requests-for-proposals using WSDL, which enforces a bid workflow with suppliers.
“We do not expect Cape Clear’s acquisition to impact our deployment,” concludes Graves, “however, we can switch to Oracle’s SOA solution should there be a need to move away from Cape Clear.”
Mashups may lend simpler alternatives to SOA
Five years after the emergence of Web services that propelled service-oriented architecture (SOA) to the front line, the question is: Are formal alternatives such as mashups now threatening to steal the show?
“SOA hasn’t materialized like the experts predicted,” claims Cameron Purdy, VP of development for Oracle’s Fusion middleware.
Providers like Serena Software, Nexaweb, JackBe, and other promising frameworks suppliers now offer the controls to make mashups enterprise-ready. Proponents such as Rene Bonvanie, Serena’s senior marketing VP, view mashups as providing the Web 2.0 front end that services lack. But, claims Bonvanie, “SOA is just one of many sources that you mash up on a page.”
SOA promises unencumbered access to apps functionality
Unlike conventional enterprise and EDI systems, service-oriented architecture (SOA) simply specifies information or service requests, yet doesn’t indicate which system must answer it. Conceived to abstract functionality or business processes that are otherwise embedded inside the business logic of enterprise applications, SOA promises a means for accessing functionality without relying on proprietary APIs or programming languages. With network-independence, SOA is seen as a more open alternative to EDI.
SOA typically operates on a request/response basis, where the request is automatically generated by an application through an intermediary to a service provider. Alternatively, the service provider could publish a service to which authorized requestors could subscribe, or dispense services as the result of an event.
SOA is the direct descendant to the object-oriented and distributed component architectures such as CORBA, and more recently with Java and Microsoft .NET components. Like well-formed software components, services are “declarative,” meaning they provide headers containing metadata identifying the component and its behaviors.
Like software components, services are designed to expose the functionality of large applications in bite-size modules. For instance, an SOA implementation would not expose an entire human resources application, but instead encapsulate a function or process such as “Employee vacation day request.”
However, SOA ventures beyond traditional component architectures with an extensible header that can—optionally—identify information relating to service contracts, indicate what kind of authentication and encryption are required, and deliver information regarding reliability and service levels. It also indicates which classes of requestors are entitled to the service, under which conditions, and at what levels of service and reliability.
Although often mentioned interchangeably, SOA and Web services are not synonymous. SOA is an architecture, while Web services comprise a set of standards that have been approved by certain standards bodies that provide a way to implement SOA. These standards have become the basis by which most vendors are supporting SOA.
Underlying the fact that Web services standards are not synonymous with SOA, well-known Web service providers such as Google and Amazon.com are supporting Representational State Transfer (REST)—a nonstandard alternative to SOA, for Web services requests—as a simpler way for requesting data services.