|
Service-Oriented Architecture
Originally, service-oriented architecture (SOA) concepts arose in response to demands for better ways to cost-effectively integrate large-scale business processes. The concept was simple: applications and automated processes access information resources through standard service interfaces, without requiring programming or knowledge of lower-level systems. Web services, in particular, provide the open standards needed to implement ubiquitous, reusable business functions, which enable complex business processes to be broken down and implemented as simplified, manageable entities.
Collaboration and agility are enabled by a few primary SOA principles and their associated benefits:
- Alignment of IT with business requirements - Management gains better visibility into business processes by defining the services they need, while application managers, integration specialists, and other experts retain control over service implementation.
- Shielding complexity - Developers and integrators need not understand low-level systems in order to build and maintain composite processes. Applications can be maintained and modified independently since low-level functions can be masked behind high-level services.
- Specialization - Best-of-breed applications and processes can be developed by experts, and deployed in a fashion that makes them accessible by developers in other areas.
- Enabling collaboration - By shielding the details of application implementation from other applications, standard interfaces allow otherwise incompatible applications to cooperate as they perform the tasks needed in higher-level business processes.
- Broadly adopted services - Any application or process can provide services to any other applications or processes, allowing broad reuse of existing software and the design of innovative solutions to business problems.
Deploying a new application or process utilizing SOA constructs and making its resources available through services requires a basic understanding of SOA principles. Services must be designed in such a way as to provide the required functionality while eliminating dependencies on low-level application interfaces as much as possible. When properly designed, a service becomes usable over any established service channel in the enterprise. Limiting services to Web service standards is a strategic mistake: Services should be available using a variety of interfaces, including J2EE
Connector Architecture (JCA), XML, electronic data interchange (EDI), simple object access protocol (SOAP), Web service definition language (WSDL), and message queuing - or combinations of these standards. In addition, services should be reusable with existing proprietary application and integration technologies, which often require specialized plug-ins.
Integrating large, complex legacy applications with emerging services presents perhaps the most challenging aspect of the migration toward an SOA. These applications require expertise that can be scarce and costly. Businesses need affordable solutions that protect existing software investments without slowing the introduction of SOA approaches into their infrastructure and business processes.
Organizations seeking to migrate to SOA can choose from a variety of platform and developer tools offered by software vendors. Many people have adopted the term "enterprise service bus,"or ESB, to indicate a collection of functionality needed to create an SOA, including the following:
- Transformation - When applications work together to respond to events or provide services, a sophisticated transformation engine must provide the mapping between their different representations of business entities - and although XML transformations are important, the engine must also handle non-XML formats like EDI, SAP IDocs, flat files, and much more
- Intelligent routing - Service calls and other events enable collaboration by stimulating action in applications and other parts of the enterprise, which requires a comprehensive mechanism for identifying messages types, recognizing data values in them, knowing the possible endpoints for messages, and routing messages to where they're needed - without burdening developers with the complexity of communication mechanisms or application manipulations
- Optimized runtime engine - A scalable, distributed service engine must run on a variety of operating platforms and offer customizations for unique business needs
- Service monitoring tools - As organizations move to a more distributed architecture, they must be able to see who is using their services and whether service-level agreements (SLAs) are being met
|
