Service-orientation is an important complement to object-orientation that applies the lessons learned from component software, message-oriented middleware, and distributed object computing. Service-orientation differs from object-orientation primarily in how the term "application" is defined. Object-oriented development focuses on applications that are built from interdependent class libraries. Service-oriented development focuses on systems that are built from a set of autonomous services. This difference has a profound impact on the assumptions one makes about the development experience.

A service is simply a program that one interacts with by means of message exchanges. A set of deployed services is a system. Individual services are built to last—the availability and stability of a given service is critical. The aggregate system of services is built to allow for change. The system must adapt to the presence of new services that appear a long time after the original services and clients have been deployed, and these must not negatively impact functionality.

Four Fundamentals of Service-Oriented Development
Service-oriented development is based on the following four fundamental tenets:

Boundaries are explicit. A service-oriented application often consists of services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments. The cost of traversing these various boundaries is nontrivial in terms of complexity and performance. Service-oriented designs acknowledge these costs by putting a premium on boundary crossings. Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation. Compared to distributed objects, the service-oriented model views cross-service method invocation as a private implementation technique, not as a primitive construct. The fact that a given interaction may be implemented as a method call is an implementation detail that is not visible outside the service boundary.

The notion of explicit boundaries applies not only to interservice communication, but also to interdeveloper communication. Even in scenarios in which all services are deployed in a single location, it is commonplace for the developers of each service to be spread across geographical, cultural, and/or organizational boundaries. Each of these boundaries increases the cost of communication between developers. Service orientation adapts to this model by reducing the number and complexity of abstractions that must be shared across service boundaries. By keeping the surface area of a service as small as possible, the interaction and communication between development organizations is reduced. In service-oriented designs, simplicity and generality are not a luxury but rather a critical survival skill.


Services are autonomous. Service-orientation mirrors the real world in that it does not assume a controlling presence over all parts of a running system. This notion of service autonomy appears in several facets of development, the most obvious being the area of deployment and versioning.

Object-oriented programs tend to be deployed as a unit. Despite the efforts made in the past to enable classes to be independently deployed, the discipline required to enable object-oriented interaction with a component is impractical for most development organizations. Coupled with the complexities of versioning object-oriented interfaces, many organizations have become extremely conservative in how they roll out object-oriented code.

Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. While individual services are almost always deployed atomically, the aggregate deployment state of the overall system or application rarely stands still. In other words, it is common for an individual service to be deployed long before any consuming applications are even developed; then consuming applications can be developed ad hoc. In the service-oriented world, the creators of the service know nothing of the applications that consume the service whereas developers of an object-oriented application create both sides of the relationship.

The notion of autonomous services also impacts the way failures are handled. Objects are deployed to run in the same execution context as the consuming application. Service-oriented designs assume that this situation is the exception, not the rule. For that reason, services expect that the consuming application can fail without notice and often without any notification. To maintain system integrity, service-oriented designs use a variety of techniques to deal with partial failure modes.

Because many services are deployed to function over public networks (such as the Internet), service-oriented development assumes that incoming message data may be malformed or transmitted for malicious purposes. Service-oriented architectures protect themselves by placing the burden of proof on all message senders by requiring applications to prove that all required rights and privileges have been granted. Consistent with the notion of service autonomy, service-oriented architectures invariably rely on administratively managed trust relationships in order to avoid per-service authentication mechanisms common in classic web applications.

Services share schema and contract, not class. Object-oriented programming encourages developers to create new abstractions in the form of classes. Classes are convenient abstractions because they share both structure and behavior in a single named unit. Service-oriented development has no such construct. Instead, services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages. This strict separation between structure and behavior vastly simplifies deployment, because distributed object concepts like marshal-by-value require a common execution and security environment which is in direct conflict with the goals of autonomous computing.

Services deal only in contracts; that is, only with machine-readable and verifiable descriptions of the legal functions the service supports. Therefore, a service must be exceedingly careful about validating the input data that arrives in each message. Basing the architecture on machine-validated schema and contract gives both developers and infrastructure the hints they need to protect the integrity of an individual service as well as the overall application.

Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features like XML element wildcards (for example, xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.

Service compatibility is determined based on policy. Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing and validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.

Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions can also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility.

S>

Отсутствие сохранения состояния при взаимодействии

Нет такого. Более того — в случае Indigo (знаешь что это такое?) мы имеем встроенную поддержку сессий и транзакций.

S>

Четкое определение доверительных отношений

Нет такого. Есть понятие федеративной идентификации (для WS есть специальный протокол, WS-Federation), но это не является обязательным требованием к сервисам. Более того, все та же индига поддерживает federative identity только под лонгхорном.

S>

Агрегация – сервис может представлять собой подобие швейцарского ножа

Нет такого. Более того — есть обратное. Система должна оставаться по возможности работоспособной при отказе отдельных сервисов (второй принцип определения от МС — Services are autonomous). А твой "швейцарский нож" при отказе любого сервиса рассыплется как карточный домик. Чуть дальше ты на это противоречие наталкиваешься и начинаешь изворачиваться путем введения совершенно специфических заморочек, вроде оффлайн-режима или динамической генерации проксей.

S>

Независимость от протокола взаимодействия

Опять же важный момент, но к SOA отношения не имеет. Главное выдерживать заявленный контракт.

S>

Автономность – недоступность другого сервиса не должна фатально отражаться на работоспособности системы в целом. Это можно реализовать путем реализации некоторых принципов Smart Client для обеспечения автономности: кэширование данных сервиса на клиентской стороне, при недоступности сервиса сохранение запросов в очереди, которая передается сервису при его доступности.

Нет, нет и нет. Очень серьезная ошибка. Автономность должна обеспечиваться не реализационными ухищрениями, а архитектурой самого сервиса. Это ключевое требование SOA, все остальное проистекает из этого. А ты допустил изначально ошибку, а теперь постоянно получаешь противоречия.

S>

Слабая связанность – клиент не должен зависеть от сервиса в случае модификации сервиса. Это можно обеспечить путем позднего связывания в процессе выполнения и/или передачей атрибутов вызова с версионностью каждого сложного атрибута, а так же использованием паттернов: Remote Proxy, Adapter, Broker.

Опять ошибка. Это обеспечивается гибкой схемой описания контракта, позволяющей определенные маневры в структуре, а не теми наворотами, что ты описал. Еще раз процитирую нужный кусок:

Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features like XML element wildcards (for example, xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.

S>

Определение и регистрация сервисов

Нет такого требования в SOA.

Вобщем на удивление удачно ты не попал ни разу

... << RSDN@Home 1.1.4 beta 6 rev. 430>>

1. Первоначально необходимо проверить наличие товаров на складе из списка покупателя. Для этого продавец связывается с работником склада и запрашивает у него необходимую информацию, а в ответ получает скорректированный список товаров в соответствии с их наличием на складе.
   
   
2. Следующим шагом будет согласование цен на товары в наличии с отделом закупок. При этом продавец отправляет работнику отдела закупок список товаров, а в ответ получает цены на них.
   
   
3. Заключительным шагом для продавца будет простановка резерва на складе, для чего он опять воспользуется услугами работника склада, передав ему список необходимых товаров, а в ответ получит список зарезервированных товаров.

1. Отсутствие сохранения состояния при взаимодействии – сервис не должен сохранять внутри себя состояние между вызовами, т.е. любой из методов сервиса можно вызвать независимо от остальных. Это же может относиться и к взаимодействию между сервисами.
   
   
2. Четкое определение доверительных отношений – необходимо четко определить, каким компонентам или системам на сколько мы можем доверять. Если взаимодействие происходит между разными организациями, то это явный признак поставить самый низкий уровень доверия, при котором должна проверяться вся информация. Если компоненты системы взаимодействуют в рамках одной локальной сети только одной организации, то здесь можно поставить самый высокий уровень доверия, говорящий об отсутствии необходимости проверять полученную информацию (за исключением проверки уровня доступа пользователя).
   
   
3. Агрегация – сервис может представлять собой подобие швейцарского ножа, т.е. некоторый универсальный инструмент, который работает с некоторым количеством более простых и специализированных сервисов, разделяя свой запрос и группируя ответы используемых сервисов. Агрегирующий сервис выступает в виде паттерна Facade.
   
   
4. Независимость от протокола взаимодействия – при взаимодействии между уровнями (layer) и между узлами (tier) в большой системе часто необходимо обеспечить независимость от протокола взаимодействия. Для этого используют Enterprise Service Bus (ESB), для которой делают подключение необходимых протоколов передачи данных. Так же используют для взаимодействия с другими компонентами такие паттерны как Business Delegate, Remote Proxy, Adapter, Broker, Factory и другие.
   
   
5. Автономность – недоступность другого сервиса не должна фатально отражаться на работоспособности системы в целом. Это можно реализовать путем реализации некоторых принципов Smart Client для обеспечения автономности: кэширование данных сервиса на клиентской стороне, при недоступности сервиса сохранение запросов в очереди, которая передается сервису при его доступности.
   
   
6. Слабая связанность – клиент не должен зависеть от сервиса в случае модификации сервиса. Это можно обеспечить путем позднего связывания в процессе выполнения и/или передачей атрибутов вызова с версионностью каждого сложного атрибута, а так же использованием паттернов: Remote Proxy, Adapter, Broker.
   
   
7. Определение и регистрация сервисов – информация о списке сервисов, его методах и местоположении должна быть доступна в виде списка, который может храниться в любом доступном источнике и формате данных (БД, XML, UDDI и т.д.). Сервис должен зарегистрировать себя в таком списке, а клиент сервиса должен иметь способ получить необходимую информацию, чтоб можно было вызвать сервис.

IT> Вопрос — найдёт ли SOA своё место под солнцем в том виде в каком его трактует MS? Ведь по этой трактовке получается что CustomerService.GetCustomerDetails(id) завёрнутый в SOAP — это сервис, а не завёрнутый — не сервис.

Boundaries are explicit.
Services are autonomous.
Services share schema and contract, not class.
Service compatibility is determined based on policy.

Здесь мне хотелось бы немного рассказать о SOA, о том, как я ее понимаю.

AVK> Архитектура, ориентированная на сервисы.

S>>

Отсутствие сохранения состояния при взаимодействии
AVK>Нет такого. Более того — в случае Indigo (знаешь что это такое?) мы имеем встроенную поддержку сессий и транзакций.
Сейчас нашел http://www-128.ibm.com/developerworks/library/ws-soaintro.html#N10098 применительно к SOA. Ну а про индиго я премного наслышан — всего-лишь следующее развитие WS.

S>>

Четкое определение доверительных отношений
AVK>Нет такого. Есть понятие федеративной идентификации (для WS есть специальный протокол, WS-Federation), но это не является обязательным требованием к сервисам. Более того, все та же индига поддерживает federative identity только под лонгхорном.
Кто говорил, что я пишу все применительно к веб-сервисам? Это всего-лишь, доверяешь ты источнику или нет, проверяешь пришедшие данные или нет.

Все, больше не могу. Везде вижу с Вашей стороны только WS. А я утверждаю, что реализовывать SOA можно и без них.

[Skipped]

AVK>Вобщем на удивление удачно ты не попал ни разу
Может мы говорим о разных вещах? Я о сервисах, а Вы о веб-сервисах?

... << RSDN@Home 1.1.4 beta 6 rev. 422>>

IT>Знаешь что самое удивительное? То что вы оба правы, но говорите о совершенно разных вещах

Технологии, с помощью которых может быть реализована SOA, могут быть совершенно различные, при этом их выбор делается на основе физического взаимодействия различных компонентов системы. Так для компании, которая работает в рамках одной локальной сети, реализация SOA через веб-сервисы была бы достаточно затратной по скорости работы системы и объемам передаваемой по LAN информации. В данном случае я бы посоветовал при реализации на платформе Windows + .NET воспользоваться Enterprise Services (ES, COM+). Если организация имеет распределенную структуру или имеет место взаимодействие нескольких организаций, то тут логичнее было бы сделать взаимодействие между компонентами в виде веб-сервисов при взаимодействии через границы сетей (LAN <--> WAN <--> LAN).

IT>Ну не бред ли?

The notion of explicit boundaries applies not only to interservice communication, but also to interdeveloper communication.
...
By keeping the surface area of a service as small as possible, the interaction and communication between development organizations is reduced. In service-oriented designs, simplicity and generality are not a luxury but rather a critical survival skill.

Services are autonomous.

It is common for services to use features like XML element wildcards (for example, xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.

Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions can also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility.

AVK>Services share schema and contract, not class.

It is common for services to use features like XML element wildcards (for example, xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code.

The concept of a service is nothing new, but the notion of an SOA has evolved over the past couple of years. It's an architectural style of building software applications that promotes loose coupling between components so that you can reuse them. Thus, it's a new way of building applications with the following characteristics:

• Services are software components that have published contracts/interfaces; these contracts are platform-, language-, and operating-system-independent. XML and the Simple Object Access Protocol (SOAP) are the enabling technologies for SOA, since they're platform-independent standards. [/*]
  
• Consumers can dynamically discover services. [/*]
  
• Services are interoperable. [/*]

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, see Prior service-oriented architectures (new window).

Principles and Definitions
Looking around we see the term or acronym SOA becoming widely used, but there's not a lot of precision in the way that it's used. The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. We see similar definitions being used elsewhere; it's a very technical perspective in which architecture is considered a technical implementation. This is odd, because the term architecture is more generally used to describe a style or set of practices—for example the style in which something is designed and constructed, for example Georgian buildings, Art Nouveau decoration or a garden by Sir Edwin Lutyens and Gertrude Jekyll .

CBDI believes a wider definition of service-oriented architecture is required. In order to reach this definition, let's start with some existing definitions, and compare some W3C offerings with CBDI recommendations. We'll begin by looking at definitions of basic Service concepts.

Service
A Component capable of performing a task. A WSDL service: A collection of end points (W3C).
A type of capability described using WSDL (CBDI).
A Service Definition
A vehicle by which a consumer's need or want is satisfied according to a negotiated contract (implied or explicit) which includes Service Agreement, Function Offered and so on (CBDI).
A Service Fulfillment
An instance of a capability execution (CBDI).
Web service
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a format that machines can process (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards (W3C).
A programmatic interface to a capability that is in conformance with WSnn protocols (CBDI).
From these definitions, it will be clear that the W3C have adopted a somewhat narrower approach to defining services and other related artefacts than CBDI. CBDI differs slightly insofar as not all Services are Components, nor do they all perform a task. Also CBDI recommends it is useful to manage the type, definition and fulfilment as separate items. However it is in the definition of SOA that CBDI really parts company with the W3C.

Service-Oriented Architecture:
A set of components which can be invoked, and whose interface descriptions can be published and discovered (W3C).
CBDI rejects this definition on two counts: First the components (or implementations) will often not be a set. Second the W3C definition of architecture only considers the implemented and deployed components, rather than the science, art or practice of building the architecture. CBDI recommends SOA is more usefully defined as:

The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. (CBDI)

CBDI defines SOA as a style resulting from the use of particular policies, practices and frameworks that deliver services that conform to certain norms. Examples include certain granularity, independence from the implementation, and standards compliance. What these definitions highlight is that any form of service can be exposed with a Web services interface. However higher order qualities such as reusability and independence from implementation, will only be achieved by employing some science in a design and building process that is explicitly directed at incremental objectives beyond the basic interoperability enabled by use of Web services.

class Brush 
{
   virtual void Draw();
}

class SolidBrush : Brush
{
    override void Draw();
}

class Brush {};
class SolidBrush : Brush {}

class DrawingService 
{
    void Draw(Brush brush);
}

Services share schema and contract, not class. Object-oriented programming encourages developers to create new abstractions in the form of classes. Classes are convenient abstractions because they share both structure and behavior in a single named unit. Service-oriented development has no such construct. Instead, services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages. This strict separation between structure and behavior vastly simplifies deployment, because distributed object concepts like marshal-by-value require a common execution and security environment which is in direct conflict with the goals of autonomous computing.

class DrawingService : IDrawingService { }

ВВ>class DrawingService : IDrawingService { }
ВВ>

public BrushGraphicsAdapter : IGraphicsAdapter
{
  public void Draw(IDrawingService service, Brush brush)
  {
  }
  
  public void Register(Brush brush)
  {
  }
}