--- In [email protected], A W <ashra...@...> wrote: > > The following definition is from the same source (wikipedia.org) > > SOA provides methods for systems development and integration where > systems package functionality as *interoperable* > *services*.
SO principles provide guidance for defining an architecture where the predominant components are services which are relatively coarse-grained business-oriented capabilities. > A SOA infrastructure allows different applications to exchange data > with one another. IMO, there is no such thing as "SOA infrastructure." And pretty much everything in IT is about exchanging data--so how would this characteristic distinguish SO from anything else? > Service-orientation aims at a *loose coupling* of services with > operating systems, programming languages and other technologies > that underlie applications. SO principles specify loose-coupling between service providers and service consumers. Service implementations are abstracted away via explicitly defined service interfaces, hiding the details of the service implementation from consumers (OS, programming language, etc.) > SOA separates functions into distinct units, or services > which developers make accessible over a network in order that users > can combine and reuse them in the production of > applications. SOA separates capabilities into distinct units, or services, which developers make accessible via explicitly defined interfaces in order that users can combine and use them in the production of applications. > These services communicate with each other by passing data from one > service to another, or by coordinating an activity between two or > more services. Service consumers communicate with service providers via explicitly defined interfaces, passing data between them to initiate activity/real-world effects. A service provider might also be a service consumer (a service implementation calling another service to perform the contracted capability). I think service-to-service interaction is sometimes overemphasized. The focus should be on consumers (wide and varied) interacting with providers, not so much on service-to-service activity. Too much service-to-service activity might point to an incorrect segregation of service responsibilities/capabilities. > SOA can be seen in a continuum from older concepts of distributed > computing and modular programming, through to > current practices of mashups, SaaS, and Cloud Computing (which > some see as the offspring of SOA. > > *Service-orientation* is a design paradigm that specifies > the creation of automation logic in the form of services. > It is applied as a strategic goal in developing a service-oriented > architecture (SOA). SO principles *can* be applied as a style to achieve strategic goals. Developing a service-oriented architecture should never be the goal in and of itself. -Rob
