With the introduction of Web Services over the last year or so, there has been a renewed interest in service-oriented architecture (SOA). An SOA is an architecture that has special properties. It is an architecture made up of components and interconnections that stress interoperability and location transparency. The term service has been used for more than two decades. For example, leading transaction monitoring software has used the term “service” in the early 1990s. Many client-server development efforts in the 90s used the term “service” to indicate the ability to make a remote method call. Web Services has given the term service more prominence in the last few months. Services and service-oriented architectures are really about designing and building systems using heterogeneous network addressable software components. In this article, I will explore the evolution of SOA, make a case for SOA, and describe some of the properties of SOA.
Software Architecture in General
Before getting too far into the details of SOA, the term software architecture needs to be defined. Software architecture is a fairly new practice in the field of software engineering. The software architecture of a system consists of the large-grained structures of the software. It describes the components of the system and how those components interact at a high level. The interactions between components are called connectors. The configuration of components and connectors provide both a structural and a behavioral view of the system.
Brief History of Software Design
Over the last four decades, the practice of software development has gone through several different development methods. Each method shift was made in part to deal with greater levels of software complexity. The way we have managed complexity is to continuously invent coarser grained constructs, such as functions, classes, and components. We can think of these constructs as software “black boxes”. A software black box hides its implementation by providing controlled access to its behavior and data through an interface. Think of it as a software integrated circuit. At a fine level of granularity, we use objects to hide behavior and data. At a coarser level of granularity, we use components to do the same. Having information hiding only at the object level works well for small systems, and it allows us to create constructs in software that map onto the real world objects.
You can read more on the article at:
