SOA May be Manufacturers’ Missing IT Link
Manufacturers working to improve their technology often run into a seemingly insurmountable problem: how to integrate multiple existing applications with new programs so that everything runs smoothly and is readily available to everyone who needs it. Often, existing systems are a patchwork of individual applications added over time to fit individual department requirements. Even though your IT staff usually can find a way to make them interact, the result is often cumbersome operationally and difficult to adjust when new needs arise.
Web-based applications have helped, but can’t solve all connectivity and programming language problems. In addition, many legacy systems — which often are too expensive to replace — aren’t Internet compatible. And yet, the Internet may prove to be the missing link in the struggle for compatibility. If nothing else, Web service projects have demonstrated that it’s possible to create service-oriented architecture (SOA) that doesn’t care whether an application is local or remote, or even what language it uses.
Let’s get technical
Business systems developers are taking notice of SOA as they continue to use existing technologies such as extensible markup language (XML), simple object access protocol (SOAP), Web services description language (WSDL) and universal description, discovery and integration (UDDI ) to build more flexible systems.
Greatly simplified, SOA is an application architecture independent of and yet compatible with numerous sets of technology. In SOA, all functions are independent services. They operate through interfaces that allow the functions to “call” each other, using a universal protocol, such as XML or SOAP, to resolve any communications barriers. The interface defines the service, rather than the technology, that is used to access it.
In with the old
One of the biggest attractions of SOA is that it uses existing resources, including software languages, hardware platforms, databases and applications, thereby reducing the cost and risk associated with a full-scale system change. Even aging legacy systems can be encapsulated and accessed through Web services interfaces.
Another significant difference between SOA and standard systems is that SOA is process oriented. Typically, today’s program-oriented applications require copying code and incorporating libraries or other program-oriented tasks to expand access. SOA, by contrast, deconstructs component functions into a series of steps it then links to create a flow of information that satisfies the business’s needs.
A typical SOA infrastructure uses WSDL to describe the service, UDDI to look up services and SOAP to send messages between the services. While J2EE and .NET are the dominant SOA platforms, they’re not the only ones available.
Some important considerations in developing SOA include security and reliability. Because SOA systems can be built on existing components, risk is lower, but standards organizations such as the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS) have developed specifications to ensure security and reliability.
An application whose time has come
Manufacturers continue to grapple with basic business needs, including the need to lower costs, reduce cycle times, improve ROI and speed time to market. SOA, while still in its relative infancy, may be the solution that helps them meet those needs.
Proponents claim that SOA is the best way to carry existing assets forward while still allowing rapid deployment of future applications. Even though the languages and other elements now used in SOA will undoubtedly continue to improve, IT research firm Gartner predicts that SOA will be a prevailing software engineering practice within five years.