Service-Oriented Architecture Introduction, Part 1
The Service-Oriented ApproachA service is behavior that is provided by a component for use by any other component based only on the interface contract. A service has a network-addressable interface. A service stresses interoperability and a service may be dynamically discovered and used.
Web Services consist of four technologies in combination that provide an implementation of an SOA. You can use Web Services to provide all of the properties necessary to build a service. Web Services include HTTP as the primary network protocol, SOAP/XML for the payload format, UDDI for service registry, and WSDL to describe the service interfaces.However, a service-oriented architecture does not require Web Services. An SOA is a design and a way of thinking about building software components.
Use-Based Solely Published ContractContract design between components is a critical activity in a service-oriented architecture. The difference between a public interface and a published interface comes into play. A public interface is an interface that can be used by components within a system. The public interfaces of a component are easier to change, because they are only used by known clients. A published interface is one that is exposed to the network and may not be changed so easily, because the clients of the published interface are not known. The difference is analogous to an intranet-based site only accessible by employees of the company and an Internet site accessible by anyone. Languages and tools have not stepped up yet to enforcing this concept, but it is important to understand the distinction when building published service interfaces.
Network Addressable InterfaceA service must have a network addressable interface. This means that a client on a network must be able to invoke a service. A service may be configured for use by a component in the same machine. However, the service must also support a network configuration.
Stresses InteroperabilityA service-oriented architecture, first and foremost, stresses interoperability. That means that each component must provide an interface that can be invoked through a payload format and protocol that is understood by all of the potential clients of the service.
Dynamically Discovered and UsedA service must be dynamically discovered. This means that a third party mechanism must be used to find the service. Hard coding of a machine location is not consistent with a service-oriented approach.
ConclusionThere are a lot of benefits to using a service-oriented architecture approach, but there are also some risks involved. In future installments, I will discuss these and more.
- L. Bass et al., "Software Architecture in Practice," Addison-Wesley, 1998
- M. Fowler, "Public versus Published Interfaces," IEEE Software, Vol. 19, No. 2, March/April 2002, pp. 18-19.
About the AuthorMichael Stevens is an independent consultant specializing in service-oriented architectures for the enterprise. He has over fourteen years of experience in information technology architecting and developing software systems, most recently focusing on J2EE solutions. He founded a software company that developed solutions for the mailing industry. He is a certified Java programmer, a member of the IEEE Computer Society, and of the ACM. He may be reached at firstname.lastname@example.org.
Page 2 of 2