Walt Davis's List: Service-Oriented Architecture

• Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability.

  • Interoperability – refers to the difficulty of software components to share responsibility and work together in solving a larger problem. A goal of service-orientation is to reduce system integration by increasing interoperability.
  Add Sticky Note
• A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration. In fact, integration as a concept begins to fade within service-oriented environments
• Interoperability is specifically fostered through the consistent application of design principles and design standards. This establishes an environment wherein services produced by different projects at different times can be repeatedly assembled together into a variety of composition configurations to help automate a range of business tasks.

1 more annotation...

• A service-oriented architecture is essentially a collection of services.  These services communicate with each other. The communication can involve either  simple data passing or it could involve two or more services coordinating some  activity. Some means of connecting services to each other is needed.

   

  Service-oriented architectures are not a new thing. The first  service-oriented architecture for many people in the past was with the use DCOM  or Object Request Brokers (ORBs) based on the CORBA specification. For more on  DCOM and CORBA
• A service is a function that is well-defined, self-contained, and does not  depend on the context or state of other services.

  • Distributed systems, except for the must simple and perhaps useless, are if nothing else made up of services that will depend on other services. Distributed computing is all about depenencies so just because you use services realize your interactions does not somehow magically simplify a solution to never requiring depence.
  Add Sticky Note
• The technology of Web  services (new window) is the most likely  connection technology of service-oriented architectures. Web services  essentially use XML (new window) to create a  robust connection.

1 more annotation...

• In the current marketplace, the technology platform most associated with the  realization of SOA is Web services.
• The popularity of Web services preceded that of service-oriented computing
• With service-oriented computing comes a distinct architectural model that has  been positioned by the vendor community as one that can fully leverage the open  interoperability potential of Web services
• Because service logic can now be accessed via a vendor-neutral communications  framework, it becomes available to a wider range of service consumer programs
• Web services provide a communications framework based on physically decoupled  service contracts allows a service contract to be fully standardized  independently from its implementation

3 more annotations...

• Service-oriented computing represents a new generation distributed computing  platform. As such, it encompasses many things, including its own design paradigm  and design principles, design pattern catalogs, pattern languages, a distinct  architectural model, and related concepts, technologies, and frameworks.
• To better understand the fundamental complexion of a typical service-oriented  computing platform we need to describe each of its primary parts, which we’ll  refer to as elements:
  
  -  Service-Oriented Architecture
  
  -  Service-Orientation
  
  -  Service-Oriented Solution Logic
  
  -  Services
  
  - Service Compositions  
  
  - Service Inventory

• The vision behind service-oriented computing is extremely ambitious and  therefore also very attractive to any organization interested in truly improving  the effectiveness of its IT enterprise. A set of common goals and benefits has  emerged to form this vision. These establish a target state for an enterprise  that successfully adopts service-orientation.
  
  The upcoming set of sections describe each of these strategic goals  and benefits
  
  - Increased Intrinsic  Interoperability
  
  - Increased Federation
  
  - Increased Vendor  Diversification Options
  
  - Increased  Business and Technology Alignment
  
  - Increased ROI  
  
  - Increased Organizational Agility  
  
  - Reduced IT Burden

• Before we can begin exploring the details of service-oriented computing, we  first need to establish some basic design terminology. The books in this series  use a common vocabulary comprised of the following design-related terms:  
  
  -  Design Characteristic
  
  -  Design Principle  
  
  -  Design Paradigm
  
  -  Design Pattern  
  
  -  Design Standard
  
  -  Best Practice

• Some qualify an SOA project by the fact that Web services technologies are being  used, while others classify SOA as a Web-centric variation of object-oriented  design.
• What has become more clear than the actual meaning of SOA is the strategic  vision that has emerged around it. This vision is comprised of a set of goals  and benefits that most stakeholders fully expect to see realized when they  support and commit to SOA initiatives.
• the common (and dangerous) assumption that a solution is service-oriented solely  because it uses Web services has led to much disappointment.
• While there is no one recognized definition of SOA, there is a baseline of  concepts and principles
• Although this site positions SOA within the service-oriented computing platform,  it only hints at what it means for solution logic to be considered  "service-oriented." That particular topic deserves a study of its own, which is  why I published www.SOAPrinciples.com
• service-oriented computing platform
• Note that this site and SOAPrinciples.com are further supplemented with two  additional sites: www.SOAMethodology.com provides a generic set of processes  for service delivery, analysis, and design, and www.SOAGlossary.com is a  master glossary established in support of the series books.

5 more annotations...

• flexible set of design principles used during the phases of systems development and integration
• loosely-integrated suite of services that can be used within multiple business domains
• XML is commonly used for interfacing with SOA services, though this is not required
• SOA defines how to integrate widely disparate applications
• SOA separates functions into distinct units, or services^[

  • From within an application all services (remote or local) should appear as if they are local. For remote services this means that from the application’s perspective, details of the service’s implementation and the technologies used is decoupled from the application. This protects the application making it more resilient to change by reducing risk associated with changes in technology or code refactoring of system functionality.

  • A SOA separates logic into sets of similar operations. Each set (a service) is to have a well defined role(s) that have well defined responsibilities. Services, like objects, should be highly cohesive and loosely coupled. If a service is tightly coupled to an application, then it belongs within the application as a local service, remotely surface only those operations needed by external clients. Non application specific services should exist on their own, i.e., outside of an application.
• coordinating an activity between two or more services

  • Model collaborations using activity diagrams, teams having trouble understanding everybody’s roles/responsibilities should play out each scenarios using CRC (Class Responsibility Collaboration Cards). 
• passing data

  • Within an application data should look the same regardless where it comes from, technologies used to store it, technologies used to transform it, or technologies used to move it around. This is possible using the concept of meta-data to build a standard/generic API for describing pieces of data. This is another one of my secrets to building application that are highly resilient to change and easier to refactor code from one iteration to the next, i.e., reducing the risk associated with change.
• Services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them.

  • To me this seem very limiting in design. It is like saying that an API can not make calls to other API's or an object can not call other objects or a function can not call other function .... I argue that there are different types of services and while some services will not call other services there may be some that do. Suppose you wrap a mail (SMTP) server into a web service, well even it makes calls to a DNS lookup service in order to figure out how mail is to be routed.
• Each service implements one action, such as filling out an online application for an account, or viewing an online bank-statement, or placing an online booking or airline ticket order.

7 more annotations...