Service oriented architectures (SOA) have been evolving for many years. Technologies such as CORBA, RMI, JINI, etc. all have roots in providing a service-based approach. The main idea behind SOAs is to provide a service layer that hides the underlying implementation from the consumer of the service. Because the service is abstract, requests and responses can be made independent of the location, storage, or presentation mechanism. The power of the architecture comes not from large complex subsystems but rather through small, flexibly coupled services which are orchestrated into a cohesive solution.
Two alternatives briefly evaluated and rejected for architecture were a monolithic application and a distributed object system. While it would be possible to implement a reasoning framework using either of these architectures, they are both more primitive and less capable than a SOA. Some of the benefits derived by using a service-oriented architecture include:
• More Dynamic - Late binding allows for a dynamic behavior not possible in statically defined systems.
• More Reuse - Standard libraries of service components can be implemented out of which solutions can be assembled.
• Better Maintainability - The service interface encapsulates the underlying functionality and additional services can be added without disturbing existing functionality.
• Better Parallelism in Development - Services can be defined and implemented separately. Developers can code to interfaces of services before their implementation has been completed.
• Better Scalability/Location Transparency - Additional services can be brought on line for scaling in terms of performance or capability.
• Higher Availability - Part of scalability. Multiple instances of the same service can transparently be brought on line to enhance response time.
• Better Testing - Individual services can be automatically unit tested individually against their published interfaces. The inherent nature of the architecture means that all services must have well defined interfaces using uniform access mechanisms.
• Focused Developer Roles - SOAs provide for natural layering of roles. Developers of a service only need to be an expert in the domain relevant to that particular service. Likewise application developers will need to know less about the internal operation of each service.
• Support for Multiple Client Types/ Platform Independence - Each service is free to operate on the most effective platform.
In recent history, when service oriented architectures are discussed, it is often in relation to Web Services. Web Services are a stack of standards that define protocols and create a loosely coupled framework for programmatic communication among disparate systems. These standards allow services to be described (WSDL), discovered (UDDI), and remotely invoked (SOAP) over a network. Note that web services are only one example of how a SOA can be implemented and simply using SOAP, WSDL, and UDDI is not equivalent to SOA. While many of the underlying technologies used to implement web services can be leveraged in the implementation of the reasoning framework, not all are necessary or even desirable. In many situations where the framework is likely to be deployed, the various services will likely be running within the same local area network as opposed to randomly across the Internet. Although a distributed architecture is of value for this application for the reasons described above, it does not necessarily need to be widely distributed.
A.W. Brown and S. Johnston , " Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications " , Submitted for Publication, September 2002