SOA Simple

Service-oriented architecture (SOA) has been part of the enterprise software market for about two decades, and has recently become a hot topic for developers and implementers--and thus for customers as well. Everybody's software maker's doing it, most claim to be leading the way, and even the fringe players claim to be enabling and integrating with SOA. Ask any vendor representative, and you'll hear that SOA, Web services, or some sort of common code interoperability is the new paradigm for application design. Terrific. So, what is SOA? More important, why should you care? Service, please A discussion of SOA won't get very far if we stick to the usual nebulous definitions that get thrown about. To get to the root meaning of SOA we must first know what a service is. Miko Matsumura, vice president of technology standards at Infravio, offers this definition: "A service is a network-accessible function, abstracted behind an interface." Bruce Cleveland, senior vice president of products for Siebel Systems, has another way of putting it: "A service is a function, one that is well defined and self-contained, and doesn't depend on the state of other services." His analogy is a VCR, which doesn't need the TV turned on to record a program. According to Matsumura, a function can be any process that is useful to a business, such as calculating interest rates, informing managers of newly uploaded sales reports, or plugging a set of entries in ledger A into a formula in spreadsheet B. How this happens and what the source might be are immaterial. "What is the delivery method? Don't know, don't care," Matsumura says. "All that matters is that when you call a function, the function returns a value." Often, you'll hear SOA and Web services used interchangeably. This is incorrect, though the two are closely related. A service by itself is just a piece of code all alone in the big city, looking for a job to do and other service friends to hang out with. Under this analogy Web services are the public transportation system. "You want different services from different implementations to work together for heterogeneity and reusability," Matsumura says. "That's interoperability, and a common way to get services talking is Web services." "An SOA is a collection of these services communicating with each other, either through simple passage of data or a coordinated effort to do a task. To get them to communicate, you need Web services," Cleveland says. He returns to the analogy of audio/video equipment to describe this. "We used to buy a stereo system as a single integrated unit, all hardwired together--the speakers, the receiver, the tuner, and the turntable. Some stereos had a better receiver, while some had a better turntable. One day somebody figured, 'Hey, wouldn't it be great if we could mix and match components?' Now the bits and pieces work together, connected by standardized wiring." Because of this it's easier to add more functions to a system than it was with single-unit equipment. Services are the components, and the architecture is the wiring and engineering standards. "There are two levels when we talk about services," says Andrew Leigh, director of solution strategy for mySAP CRM at SAP AG. "The first level is Web services, which have been very popular for a long time now. Web services are the common language and currency for applications and processes to communicate across platforms. Beyond that we have enterprise services, which take Web services and add business logic to put them in the context of business tasks." In other words, enterprise services are the applications built on Web-services code. This basic level of communication is usually accomplished with a standard like Simple Object Access Protocol (SOAP), which is a message format that serves as the common language to integrate any number of tools and languages, such as Java and .NET. Stretching the social analogy a bit further, it's hard to get in touch with other services if you don't know where they live. In comes the phone and address book--the Universal Description, Discovery and Integration (UDDI) specification. "UDDI is just another service, but its purpose is to look up other services," Matsumura says. A UDDI registry is the means for services to work together. While we're talking about transportation, it's worth mentioning Enterprise Service Bus (ESB). This is an integration model for exposing application components as services, and ensuring that all the disparate technology works well together. ESB accomplishes this by being a messaging system for services, reaching into directories and databases to call functions, queuing them up when requests exceed capacity. None of what goes into SOA is exactly revolutionary; applications have called on existing functions as long as computers have had operating systems. The big difference is that the architecture part of SOA is open enough to allow applications to rely on functions that are resident elsewhere on the network, or even outside it. "In a way SOA isn't new," notes Jake Freivald, director of marketing at iWay Software. "It's what we were pursuing with CORBA, for example," he says, referring to Common Object Request Broker Architecture, an attempt by Object Management Group in 1989 to create a system very similar to the current SOA. Note that open architecture is not used in the same sense as is open source. Services, and applications built from them, can be proprietary in nature, and you certainly don't want just anybody to be able to alter a service at will. "The point of SOA for application building," Matsumura says, "is that it provides a level playing field for technologies." Programming languages become the means of providing services. As long as an XML service can interact with a .NET service, and they both can talk to a Java service, it doesn't matter what your company's system is built on, because any of the above will work for you. SOA what's the point? Among SOA's strengths are its flexibility and ease of integration compared with conflicting suites of applications. "Proprietary apps, where each vendor could develop its own unique architecture and force customers to abide, don't please customers anymore," Cleveland says. "We have moved to a more open environment, and customers force us to adhere to the new standards. We can also keep them on the latest releases more easily, while maintaining interoperability with older instances." Not surprisingly, vendors are finding advantages beyond merely pleasing customers. "There's a big advantage in savings for the developer company," Cleveland says. "Because we spend less on building the plumbing, we can either pass the savings on to the customer or invest the savings in further innovations to add value." There are also several advantages for the end user to building applications from services instead of buying packaged software. According to Matsumura, the four basic value propositions for the customer are reuse, low cost of integration, business agility, and risk reduction. * Reuse comes in two flavors, according to Matsumura: Apps and services written in any computer language, resident on any machine from mainframe to desktop, will continue to be useful to the organization as long as the services themselves are worthwhile. "This aspect of legacy sharing makes the architecture like a library, where services can be taken out and shared no matter what they're written on," Matsumura says. The other aspect of reuse is composite applications, where services use other services to generate a desired result. * Lower cost of integration is easy to grasp--instead of building an entire suite, or even an individual application, all one needs to do is assemble the appropriate services to create applications, or acquire them prebuilt from other sources. At worst, a new service needs to be created--one that can be reused. * Business agility is, to some, the key benefit of SOA. With packaged software suites, or even on-demand software as a service, a company is pretty much stuck with whatever the vendor and VARs can provide, or must create homegrown applications to support new business processes. "Once you have an SOA in place, it's easy to create new business processes," Matsumura says. A handy example is the creation of a new credit card. To do so, all that is required is an agglomeration of services, such as an interest rate calculator, a means of paying creditors and collecting from customers, security (passwords, PINs, and the like), and promotional services such as frequent flyer miles or discounts on merchandise. Most important, any inefficiencies or errors can be changed before they cause extensive damage. * Risk reduction is somewhat counterintuitive, at least on the face of things. You're using services from all over the place, so how can you know what you're using is any good? What about malicious developers creating flawed services to sabotage your business? "Historically, mainframes had very little risk involved, since all the users worked in a highly managed environment," Matsumura says. The advent of the Web, with its open, distributed systems, increased vulnerability. But despite the concept of Web services, SOA is more like a mainframe than the Web. "With shared services, you create an operating system layer in the network to distribute and manage services," Matsumura explains. "It's like the top layer of bread on a sandwich." Service providers and service consumers have an intermediary between them, acting as a combination switchboard and traffic cop. "SOAP and XML are open code, so an intelligent intermediary can read service calls and messages, and censor them if there's an improper attempt," Matsumura says. The intermediary layer won't be used to spy on content, just the nuts and bolts of service interaction. "If you want access to the SOA, you have to follow certain rules--it's a managed environment all over again." Leigh sees the CRM angle very clearly. "If you look at SOA in the context of CRM, you realize that among the biggest issues in CRM are integration and flexibility of processes. Customers demand processes that can be changed," he says. "For too long CRM had focused too heavily on three core, siloed functions: marketing, sales, and customer service. By looking at them in relationship to one another and decoupling processes from those functions, vendors and their customers were able to improve business performance. SOA decouples it even further." SOA where are we going? Currently, SOA is still coming into its own, but there has been a true sea change in the software world. "Services are the present and future development trend for enterprise software," Leigh states. "We've all agreed to speak the lingua franca of services. This is immensely important to customers; just as HTML enabled the explosion of the Web, SOA is doing the same for business applications." According to Leigh, apps are becoming less important, platforms more important. Whether SAP, IBM, Oracle, Microsoft, or some other vendor, the core services they offer and the structure that pulls them together with other services are what drive their value. The numerous advantages of SOA are changing the way enterprise software gets built. Miko Matsumura suggests the following course of events will play out over the next several years. "Packaged applications vendors will expose their services as Web services," Matsumura suggests, and this has already begun to happen--it's why SOA is creating such a powerful buzz. As more services become part of the SOA gestalt, he continues, "this will enable hosted and nonhosted vendors to compete on an equal footing. Intermediaries will become specialized for verticals and business segments, and service registry repositories will grow into more full-featured catalogs and management interfaces." Contact Senior Writer Marshall Lager at mlager@destinationCRM.com Who's got SOA? Leaders are emerging in the SOA field. NetSuite released the NetFlex platform back in March 2005, including a Web Services element that provides a standardized way for existing NetSuite customers to access data and business processes, and makes integrating NetSuite with other SOAP-compliant systems fast and easy. SAP has put considerable effort into making SOA the new way to build software through its NetWeaver platform. Siebel Component Assembly is that company's SOA development tool, and Larry Ellison of Oracle made it clear that Siebel's work in SOA would not be lost when Oracle announced its planned acquisition of Siebel in October 2005. "We're very excited [about] what Siebel's done with SOA," Ellison said in a videotaped address when the takeover was announced. "That dovetails beautifully into Oracle's plans for [SOA-like middleware product] Fusion." Oracle Application Server is Ellison's homebrew SOA, which further supports the merged company's prowess in the field. Numerous other SOA and Web-services iterations are currently in the wild. Among them are Apple WebObjects; BEA Systems' WebLogic platform; Business Objects Enterprise; Cognos BI Platform; IBM WebSphere; Infravio (Miko Matsumura's company); Microsoft BizTalk; Onyx Web Services; and of course Sun Java Enterprise and Jini. This list is only partial, of course. Most other developers and vendors are at least making sure that their software is Web-services enabled for future integration. --M.L. Integration Through Services Below, the piecemeal integration of a typical enterprise data structure. The connections depend on individual systems, and don't guarantee easy communication with others. Security is compromised by exposing business operations directly to outsiders through the firewall.

SOA helps solve these problems by creating one secure integration layer. It serves as a common language for the business systems, and as a security guard to outsiders.