Многие, читая новости, статьи, книги и т.п., видят аббревиатуру SOA (Service Oriented Architecture – архитектура, ориентированная на оказание услуг). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса». Здесь мне хотелось бы немного рассказать о SOA, о том, как я ее понимаю.
Сначала необходимо понять, что такое SO (Service Orientation – ориентация на оказание услуг, сервис для клиента). Тут мы должны понять, что рассматривать SO мы будем с точки зрения бизнеса, а не программирования, т.е. сервис – это предоставление некоторой услуги клиенту, который запрашивает ее у бизнес-единицы. SO – это принцип создания сервисов по оказанию услуг, при котором некоторые бизнес-процессы группируются вместе и имеют единую точку входа (например, дверь в комнату отдела).
Для примера возьмем некоторую абстрактную торговую компанию, занимающейся реализацией товаров со своего склада. Естественно, мы будем рассматривать очень упрощенную модель.
В соответствии с SO мы изначально можем разбить компанию на следующие отделы: отдел продаж, отдел закупок и склад. Отдел продаж занимается общением с покупателями. Отдел закупок взаимодействует с поставщиками по вопросам приобретения необходимых товаров на склад. Ну а склад (как отдел компании) в свою очередь отвечает за текущее состояние склада, прием и выдачу товаров. Таким образом, мы смогли разбить нашу компанию на отделы, но каждый из отделов выполняет свой набор функций, в том числе взаимодействие с другими отделами.
Дальнейшее определение функций каждого из отделов даст нам набор услуг отдела. При этом при оказании какой-либо услуги возможно взаимодействие с другим отделом, т.е. использование услуги другого отдела. Для примера приведу покупку товаров покупателем у компании.
Покупатель намеревается приобрести необходимые товары. При этом он обращается в отдел продаж компании и предоставляет свои реквизиты, а так же список товаров, которые он хотел бы приобрести. В данном случае покупатель использует соответствующий сервис, предоставляемый отделом продаж. При этом, при поступлении такого запроса от покупателя, в отделе продаж продавец начинает выполнять последовательность действий, связанных с обработкой запроса покупателя:
Первоначально необходимо проверить наличие товаров на складе из списка покупателя. Для этого продавец связывается с работником склада и запрашивает у него необходимую информацию, а в ответ получает скорректированный список товаров в соответствии с их наличием на складе.
Следующим шагом будет согласование цен на товары в наличии с отделом закупок. При этом продавец отправляет работнику отдела закупок список товаров, а в ответ получает цены на них.
Заключительным шагом для продавца будет простановка резерва на складе, для чего он опять воспользуется услугами работника склада, передав ему список необходимых товаров, а в ответ получит список зарезервированных товаров.
В результате этих действий продавец передаст покупателю некоторую информацию, в соответствии с которой покупатель сможет получить необходимые товары на складе компании. Здесь мы видим взаимодействие покупателя с сервисом, предоставляемым отделом продаж. При этом сотрудник отдела продаж так же пользуется сервисами других отделов.
Теперь вернемся к программированию. Все выше сказанное можно реализовать в программном коде. Но сначала нам необходимо определить некоторые понятия и принципы реализации.
SOA – это программная архитектура, построенная в соответствии с SO, которая позволяет построить программное обеспечение, взаимодействующее между разными частями с соблюдением некоторых принципов (которые я опишу далее). Очень часто SOA ассоциируют с возможной технологической реализацией в виде веб-сервисов (WS – Web Service), что является неправильным.
Технологии, с помощью которых может быть реализована SOA, могут быть совершенно различные, при этом их выбор делается на основе физического взаимодействия различных компонентов системы. Так для компании, которая работает в рамках одной локальной сети, реализация SOA через веб-сервисы была бы достаточно затратной по скорости работы системы и объемам передаваемой по LAN информации. В данном случае я бы посоветовал при реализации на платформе Windows + .NET воспользоваться Enterprise Services (ES, COM+). Если организация имеет распределенную структуру или имеет место взаимодействие нескольких организаций, то тут логичнее было бы сделать взаимодействие между компонентами в виде веб-сервисов при взаимодействии через границы сетей (LAN <--> WAN <--> LAN).
Итак, каким же принципам должна соответствовать SOA?
Отсутствие сохранения состояния при взаимодействии – сервис не должен сохранять внутри себя состояние между вызовами, т.е. любой из методов сервиса можно вызвать независимо от остальных. Это же может относиться и к взаимодействию между сервисами.
Четкое определение доверительных отношений – необходимо четко определить, каким компонентам или системам на сколько мы можем доверять. Если взаимодействие происходит между разными организациями, то это явный признак поставить самый низкий уровень доверия, при котором должна проверяться вся информация. Если компоненты системы взаимодействуют в рамках одной локальной сети только одной организации, то здесь можно поставить самый высокий уровень доверия, говорящий об отсутствии необходимости проверять полученную информацию (за исключением проверки уровня доступа пользователя).
Агрегация – сервис может представлять собой подобие швейцарского ножа, т.е. некоторый универсальный инструмент, который работает с некоторым количеством более простых и специализированных сервисов, разделяя свой запрос и группируя ответы используемых сервисов. Агрегирующий сервис выступает в виде паттерна Facade.
Независимость от протокола взаимодействия – при взаимодействии между уровнями (layer) и между узлами (tier) в большой системе часто необходимо обеспечить независимость от протокола взаимодействия. Для этого используют Enterprise Service Bus (ESB), для которой делают подключение необходимых протоколов передачи данных. Так же используют для взаимодействия с другими компонентами такие паттерны как Business Delegate, Remote Proxy, Adapter, Broker, Factory и другие.
Автономность – недоступность другого сервиса не должна фатально отражаться на работоспособности системы в целом. Это можно реализовать путем реализации некоторых принципов Smart Client для обеспечения автономности: кэширование данных сервиса на клиентской стороне, при недоступности сервиса сохранение запросов в очереди, которая передается сервису при его доступности.
Слабая связанность – клиент не должен зависеть от сервиса в случае модификации сервиса. Это можно обеспечить путем позднего связывания в процессе выполнения и/или передачей атрибутов вызова с версионностью каждого сложного атрибута, а так же использованием паттернов: Remote Proxy, Adapter, Broker.
Определение и регистрация сервисов – информация о списке сервисов, его методах и местоположении должна быть доступна в виде списка, который может храниться в любом доступном источнике и формате данных (БД, XML, UDDI и т.д.). Сервис должен зарегистрировать себя в таком списке, а клиент сервиса должен иметь способ получить необходимую информацию, чтоб можно было вызвать сервис.
Здравствуйте, stasukas, Вы писали:
S>архитектура, ориентированная на оказание услуг
Архитектура, ориентированная на сервисы.
S>). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса».
Это собственно почему? Вот к примеру определение от MS
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>Сначала необходимо понять, что такое SO (Service Orientation – ориентация на оказание услуг, сервис для клиента). Тут мы должны понять, что рассматривать SO мы будем с точки зрения бизнеса, а не программирования
Да, интересный подход к архитектуре программного обеспечения, ничего не скажешь.
S>, т.е. сервис – это предоставление некоторой услуги клиенту, который запрашивает ее у бизнес-единицы.
Сервис это автономная и атомарная единица распределенной системы, географически расположенная в одно месте и управляемая как единое целое, снабженная исчерпывающим формальным описанием своего контракта (как структурным, так и семантическим) и доступная другим частям распределенной системы.
S> SO – это принцип создания сервисов по оказанию услуг, при котором некоторые бизнес-процессы группируются вместе и имеют единую точку входа (например, дверь в комнату отдела).
А это вобще неправда. Нет такого требования в SOA. См. 4 фундаментальных принципа в первом определении. Все остальное это уже специфика конкретных решений.
S>[list=1] 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.
Здесь мне хотелось бы немного рассказать о SOA, о том, как я ее понимаю.
S>>архитектура, ориентированная на оказание услуг AVK> Архитектура, ориентированная на сервисы.
Термин "оказание услуг" был специально выбран, чтоб не делать сразу ассоциации с веб-сервисами. Еще раз скажу, что веб-сервисы — это частная реализация общего понятия. SOA можно применять и для других технологий.
S>>). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса». AVK>Это собственно почему? Вот к примеру определение от MS
[Skipped] AVK>А вот определение от википедии
Многие ли знают об этих местах?
S>>Сначала необходимо понять, что такое SO (Service Orientation – ориентация на оказание услуг, сервис для клиента). Тут мы должны понять, что рассматривать SO мы будем с точки зрения бизнеса, а не программирования AVK>Да, интересный подход к архитектуре программного обеспечения, ничего не скажешь.
Правильная архитектура выбирается еще на этапе бизнес-анализа (как бы дико это не звучало). Если начать сразу с программирования, то, скорее всего, получится "помойка" и постоянная переделка. В данном случае намного легче перенести структуры, полученные при бизнес-анализе, на общую архитектуру решения.
S>>, т.е. сервис – это предоставление некоторой услуги клиенту, который запрашивает ее у бизнес-единицы. AVK>Сервис это автономная и атомарная единица распределенной системы, географически расположенная в одно месте и управляемая как единое целое, снабженная исчерпывающим формальным описанием своего контракта (как структурным, так и семантическим) и доступная другим частям распределенной системы.
Я писал про веб-сервис? Или про программирование? Этот кусок относится к бизнес-анализу.
S>> SO – это принцип создания сервисов по оказанию услуг, при котором некоторые бизнес-процессы группируются вместе и имеют единую точку входа (например, дверь в комнату отдела). AVK>А это вобще неправда. Нет такого требования в SOA. См. 4 фундаментальных принципа в первом определении. Все остальное это уже специфика конкретных решений.
Извините, но разве MS сильна в бизнес-анализе? У нее много своих бизнес-приложений? Я тут говорю про программную архитектуру?
Может надо было назвать это анализом? http://www-106.ibm.com/developerworks/webservices/library/ws-soad1/
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>Вобщем на удивление удачно ты не попал ни разу
Может мы говорим о разных вещах? Я о сервисах, а Вы о веб-сервисах?
Здравствуйте, AndrewVK, Вы писали:
S>>). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса».
AVK>Это собственно почему? Вот к примеру определение от MS
Замечательно. Я тоже не смог найти единого и общепризнаного определения SOA. Поэтому выдумал такое:
SOA — модульная архитектура с обязательным деплоингом в различные серверные сущности . ВСЕ!!!!
Под модульной архитектурой подразумевается горизонтальное разбитие бизнес-логики на слои. Серверные сущности подразумевает независимость функционирования модулей на физическом уровне.
Замените понятие сервис на модуль в любой статье, и все станет на свои места. То есть, станет так, как все привыкли испокон веков. Без всяческого маркетингого налета.
Здравствуйте, AndrewVK, Вы писали:
AVK>Вобщем на удивление удачно ты не попал ни разу
Знаешь что самое удивительное? То что вы оба правы, но говорите о совершенно разных вещах
Ты говоришь о WS v. 2.0 или даже 1.5, завёрнутых в новое модное название, а stasukas о попытке найти замену, сподскользнувшейся на распределённых и слоёных системах объектной ориентированности. Кто из вас больше имеет право на использование термина SOA сказать трудно. Понятное дело, что MS может узурпировать всё, что захочет, но насколько мне известно этот термин использовался ещё лет 5 назад за пределами MS, когда о WS никто не говорил и даже XML мало кто использовал.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, GlebZ, Вы писали:
S>>>). Но найти точное определение данному термину практически невозможно, хотя он достаточно широко используется для придания «веса».
AVK>>Это собственно почему? Вот к примеру определение от MS GZ>Замечательно. Я тоже не смог найти единого и общепризнаного определения SOA. Поэтому выдумал такое: GZ>SOA — модульная архитектура с обязательным деплоингом в различные серверные сущности . ВСЕ!!!!
Я специально не стал говорить про "серверные сущности", т.к. SOA прекрасно подходит и в рамках одной локальной машины. Естественно, если это делать не через WS.
GZ>Под модульной архитектурой подразумевается горизонтальное разбитие бизнес-логики на слои. Серверные сущности подразумевает независимость функционирования модулей на физическом уровне.
GZ>Замените понятие сервис на модуль в любой статье, и все станет на свои места. То есть, станет так, как все привыкли испокон веков. Без всяческого маркетингого налета.
Я же специально заменил на "услугу" по такому же принципу относительно бизнес-анализа.
Здравствуйте, IT, Вы писали:
IT>Знаешь что самое удивительное? То что вы оба правы, но говорите о совершенно разных вещах
Да, собственно, см. конец моего поста
.
IT>Ты говоришь о WS v. 2.0 или даже 1.5, завёрнутых в новое модное название,
Жертва buzzword
IT>а stasukas о попытке найти замену, сподскользнувшейся на распределённых и слоёных системах объектной ориентированности.
Нет, я пытаюсь дать понятие о том, что можно SOA реализовывать как через WS, так и другими средствами. Все зависит от аппаратной архитектуры.
Технологии, с помощью которых может быть реализована SOA, могут быть совершенно различные, при этом их выбор делается на основе физического взаимодействия различных компонентов системы. Так для компании, которая работает в рамках одной локальной сети, реализация SOA через веб-сервисы была бы достаточно затратной по скорости работы системы и объемам передаваемой по LAN информации. В данном случае я бы посоветовал при реализации на платформе Windows + .NET воспользоваться Enterprise Services (ES, COM+). Если организация имеет распределенную структуру или имеет место взаимодействие нескольких организаций, то тут логичнее было бы сделать взаимодействие между компонентами в виде веб-сервисов при взаимодействии через границы сетей (LAN <--> WAN <--> LAN).
IT>Кто из вас больше имеет право на использование термина SOA сказать трудно. IT>Понятное дело, что MS может узурпировать всё, что захочет, но насколько мне известно этот термин использовался ещё лет 5 назад за пределами MS, когда о WS никто не говорил и даже XML мало кто использовал.
Согласен
Здравствуйте, stasukas, Вы писали:
S>Я ж писал: S>
S>Здесь мне хотелось бы немного рассказать о SOA, о том, как я ее понимаю.
Ну а я написал что понимаешь ты ее абсолютно неправильно. В чем проблема?
AVK>> Архитектура, ориентированная на сервисы. S>Термин "оказание услуг" был специально выбран, чтоб не делать сразу ассоциации с веб-сервисами.
Играться с терминами не стоит, это приведет только к запутыванию.
S> Еще раз скажу, что веб-сервисы — это частная реализация общего понятия. SOA можно применять и для других технологий.
А я вроде и не спорил. Зачем повторять?
S>Многие ли знают об этих местах?
О википедии? Думаю очень многие.
AVK>>Да, интересный подход к архитектуре программного обеспечения, ничего не скажешь. S>Правильная архитектура выбирается еще на этапе бизнес-анализа (как бы дико это не звучало).
Сразу? Или может все таки выбирается прототип?
S> Если начать сразу с программирования, то, скорее всего, получится "помойка" и постоянная переделка.
Во-первых я этого не предлагал, во-вторых архитектура, которую не надо переделывать это миф.
S> В данном случае намного легче перенести структуры, полученные при бизнес-анализе, на общую архитектуру решения.
Вобще то обычно структура бизнес-процессов отображается на архитектуру программного продукта веьсма опосредовано. Если ты будешь еще переносить тупо и не задумываясь — получишь большие проблемы с реализацией.
AVK>>Сервис это автономная и атомарная единица распределенной системы, географически расположенная в одно месте и управляемая как единое целое, снабженная исчерпывающим формальным описанием своего контракта (как структурным, так и семантическим) и доступная другим частям распределенной системы. S>Я писал про веб-сервис?
А я писал?
S> Или про программирование?
Да. SOA это вобще то программирование
AVK>>А это вобще неправда. Нет такого требования в SOA. См. 4 фундаментальных принципа в первом определении. Все остальное это уже специфика конкретных решений. S>Извините, но разве MS сильна в бизнес-анализе?
Мягко говоря это не так.
AVK>>Нет такого. Есть понятие федеративной идентификации (для WS есть специальный протокол, WS-Federation), но это не является обязательным требованием к сервисам. Более того, все та же индига поддерживает federative identity только под лонгхорном. S>Кто говорил, что я пишу все применительно к веб-сервисам? Это всего-лишь, доверяешь ты источнику или нет, проверяешь пришедшие данные или нет.
Однако в SOA ничего на эту тему нет.
S>Все, больше не могу. Везде вижу с Вашей стороны только WS.
И в этом твоя проблема. Уж не знаю в чем причина такого твоего видения, но я WS ввиду не имел.
S> А я утверждаю, что реализовывать SOA можно и без них.
А я с этим и не спорю.
AVK>>Вобщем на удивление удачно ты не попал ни разу S>Может мы говорим о разных вещах? Я о сервисах, а Вы о веб-сервисах?
Здравствуйте, IT, Вы писали:
IT>Ты говоришь о WS v. 2.0 или даже 1.5, завёрнутых в новое модное название,
И ты туда же. Нет, я не говорю о WS. Перечитай то определение, которое я привел в самом начале. Разве там про WS? Более того — основное с чем я не согласен с автором топике — слишком узкая трактовка термина SOA.
Здравствуйте, GlebZ, Вы писали:
GZ>SOA — модульная архитектура с обязательным деплоингом в различные серверные сущности . ВСЕ!!!! GZ>Под модульной архитектурой подразумевается горизонтальное разбитие бизнес-логики на слои. Серверные сущности подразумевает независимость функционирования модулей на физическом уровне. GZ>Замените понятие сервис на модуль в любой статье, и все станет на свои места. То есть, станет так, как все привыкли испокон веков. Без всяческого маркетингого налета.
Здравствуйте, AndrewVK, Вы писали:
IT>>Ты говоришь о WS v. 2.0 или даже 1.5, завёрнутых в новое модное название,
AVK>И ты туда же.
Нет, я ни туда ни сюда. Я пока стою и смотрю чем всё закончится и пытаюсь понять зачем и кому все это надо.
AVK>Нет, я не говорю о WS. Перечитай то определение, которое я привел в самом начале. Разве там про WS?
Подставь туда WS вместо SOA и найди 10 противоречий. Новый виток развития существующей технологии, ничего более. Причём довольно амбициозный виток. Вопрос — найдёт ли SOA своё место под солнцем в том виде в каком его трактует MS? Ведь по этой трактовке получается что CustomerService.GetCustomerDetails(id) завёрнутый в SOAP — это сервис, а не завёрнутый — не сервис.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, stasukas, Вы писали:
IT>>а stasukas о попытке найти замену, сподскользнувшейся на распределённых и слоёных системах объектной ориентированности. S>Нет, я пытаюсь дать понятие о том, что можно SOA реализовывать как через WS, так и другими средствами. Все зависит от аппаратной архитектуры.
AVK тебе уже сказал, что ты не прав в трактовке это термина
Но если по существу, то хотелось бы узнать зачем тебе вообще нужен SOA, в том понимании как ты его трактуешь? Какую проблему ты решаешь?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, stasukas, Вы писали:
S>Я специально не стал говорить про "серверные сущности", т.к. SOA прекрасно подходит и в рамках одной локальной машины. Естественно, если это делать не через WS.
Вот! Я же говорю, что вы с AVK просто по разному трактуете один и тот же термин. Вот когда ты дорастёшь хотя бы до двух машин, прикрутишь к ним контракты, то тогда и будешь иметь право называть свою систему сервис-ориентед. А пока забудь это слово
Ну не бред ли?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну а я написал что понимаешь ты ее абсолютно неправильно. В чем проблема?
Думаю, что наши векторы перпендикулярны
S>>Термин "оказание услуг" был специально выбран, чтоб не делать сразу ассоциации с веб-сервисами. AVK>Играться с терминами не стоит, это приведет только к запутыванию.
Посмотрев в словарь можно найти перевод service в двух видах, но одном или очень схожем значении — сервис и услуга. Я выбрал то, что позволило бы не запутаться сразу, т.к. в русском программистском очень часто сервис равноценен веб-сервису.
S>>Многие ли знают об этих местах? AVK>О википедии? Думаю очень многие.
Голосование покажет правду.
S>>Правильная архитектура выбирается еще на этапе бизнес-анализа (как бы дико это не звучало). AVK>Сразу? Или может все таки выбирается прототип?
Игра слов... Естественно прототип архитектуры, который в дальнейшем развивается.
AVK>... во-вторых архитектура, которую не надо переделывать это миф.
Нет, правильно выбранная архитектура подразумевает расширение, но не переделывание.
S>> В данном случае намного легче перенести структуры, полученные при бизнес-анализе, на общую архитектуру решения. AVK>Вобще то обычно структура бизнес-процессов отображается на архитектуру программного продукта веьсма опосредовано.
Сильно зависит от бизнес-аналитика и архитектора. Везде может присутствовать "человеческий фактор". AVK>Если ты будешь еще переносить тупо и не задумываясь — получишь большие проблемы с реализацией.
Никто не спорит.
AVK>>>Сервис это автономная и атомарная единица распределенной системы, географически расположенная в одно месте и управляемая как единое целое, снабженная исчерпывающим формальным описанием своего контракта (как структурным, так и семантическим) и доступная другим частям распределенной системы. S>>Я писал про веб-сервис? AVK>А я писал?
Явно нет, но в общем контексте ответа это именнт так.
S>> Или про программирование? AVK>Да. SOA это вобще то программирование
Мне кажется, что я достаточно четко разделил текст на 2 части. В рамках первой части я про SOA не говорил, только про SO анализ. SOA — это вторая часть, основанная на первой.
S>>Сейчас нашел http://www-128.ibm.com/developerworks/library/ws-soaintro.html#N10098 применительно к SOA. Ну а про индиго я премного наслышан — всего-лишь следующее развитие WS. AVK>Мягко говоря это не так.
Готов поспорить отдельным тредом.
AVK>>>Нет такого. Есть понятие федеративной идентификации (для WS есть специальный протокол, WS-Federation), но это не является обязательным требованием к сервисам. Более того, все та же индига поддерживает federative identity только под лонгхорном. S>>Кто говорил, что я пишу все применительно к веб-сервисам? Это всего-лишь, доверяешь ты источнику или нет, проверяешь пришедшие данные или нет. AVK>Однако в SOA ничего на эту тему нет.
Где четкое единое определение того, что такое SOA? Я написал о своем вИдении со своими дополнениями или исключениями того, что мне кажется несущественным.
AVK>>>Вобщем на удивление удачно ты не попал ни разу S>>Может мы говорим о разных вещах? Я о сервисах, а Вы о веб-сервисах? AVK>Нет, я о SOA, а вот ты непонятно пока о чем.
Я скорее о практическом применении. Мой текст как входная точка для дальнейшего изучения и применения.
Здравствуйте, IT, Вы писали:
AVK>>Нет, я не говорю о WS. Перечитай то определение, которое я привел в самом начале. Разве там про WS?
IT>Подставь туда WS вместо SOA и найди 10 противоречий.
Их по идее не должно быть, поскольку WS разрабатывались с оглядкой на SOA. Другое дело что SOA это нечто большее, нежели WS. SOA не привязаны к конкретному транспорту и протоколу, SOA не лимитирована конкретными форматами метаданных и т.д.
IT> Новый виток развития существующей технологии, ничего более. Причём довольно амбициозный виток.
Ну это второй вопрос. Если говорить о моей имхе, то, по крайней мере в России, толку от SOA примерно 0. По тем же причинам, по которым практически не востребован здесь BizTalk. Просто нет задач сверхгибких, сверхгетерогенных и сверхраспределенных систем, а на иных SOA это бессмысленный наворот.
IT> Вопрос — найдёт ли SOA своё место под солнцем в том виде в каком его трактует MS? Ведь по этой трактовке получается что CustomerService.GetCustomerDetails(id) завёрнутый в SOAP — это сервис, а не завёрнутый — не сервис.
Нет, не получается. Indigo, к примеру, превосходно обходится без SOAP. При этом ее сервисы сервисами быть не перестают. Я вобще не понимаю откуда такая странная реакция — я ни сном ни духом веб-сервисы не поминал. Еще раз перечислю ключевые моменты SOA:
Boundaries are explicit.
Services are autonomous.
Services share schema and contract, not class.
Service compatibility is determined based on policy.
Где здесь веб-сервисы? Более того — по четвертому пункту WS вобще без дополнительной работы в чистом виде для SOA не подходят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
GZ>>SOA — модульная архитектура с обязательным деплоингом в различные серверные сущности . ВСЕ!!!! GZ>>Под модульной архитектурой подразумевается горизонтальное разбитие бизнес-логики на слои. Серверные сущности подразумевает независимость функционирования модулей на физическом уровне. GZ>>Замените понятие сервис на модуль в любой статье, и все станет на свои места. То есть, станет так, как все привыкли испокон веков. Без всяческого маркетингого налета.
AVK>Только вот в такой трактовке SOA не существует.
А я считаю, что SOA — как самостоятельное понятие архитектуры не существует. В действительности, немного подверну определение. SOA — горизонтально распределенная архитектура деплоинга. При этом, если мы говорим — горизонтально распределенное, то оно автоматически становится SOA. При этом я четко разделяю понятия layer и tier. Layer — понятие архитектуры на логическом уровне. tier — понятие архитектуры при деплоинге. SOA — понятие определяющее только построение tier. Оно как бы подразумевает наличие слоев интеграции автоматически. Но в то же время, наличие слоев интеграции (то бишь модульная структура) отнюдь не обозначает наличие tier.
Это очень похоже на разделение трехзвенной и многослойной архитектуры. Трехзвенная подразумевает многослойность (если конечно архитектор не дебил). И иногда можно довести до n-звенной архитектуры.
Возьмем твое определение(точнее определение Microsoft). Если по правде говорить, то процентов 80 "правильных" серверов приложений, которых больше одного в системе, подходят под это определение. Я не говорю о прямых вызовах некоторых классов (что есть неэффективно, доказывать не буду). Я говорю о системах с выделеным и определенным интерфейсом. Обзывать их SOA, по моему, много чести.
Еще.
То определение которое ты дал, в последних двух пунктах подразумевается (или прямо указывается) SOAP. Не уверен, что это есть good.
Здравствуйте, stasukas, Вы писали:
S>>>Термин "оказание услуг" был специально выбран, чтоб не делать сразу ассоциации с веб-сервисами. AVK>>Играться с терминами не стоит, это приведет только к запутыванию. S>Посмотрев в словарь можно найти перевод service в двух видах, но одном или очень схожем значении — сервис и услуга.
А hardware еще как скобяные изделия переводится. Компьютерные скобяные изделия. Непонятно, зато как звучит! А какую шикарную демагогию на основании этого можно развить!
S> Я выбрал то, что позволило бы не запутаться сразу, т.к. в русском программистском очень часто сервис равноценен веб-сервису.
Вот видишь — тараканы с веб-сервисами твои, а обвиняешь меня. Я бы на твоем месте внимательно читал, что написано, а не обвинял бы сразу, не разобравшись.
AVK>>... во-вторых архитектура, которую не надо переделывать это миф. S>Нет, правильно выбранная архитектура подразумевает расширение, но не переделывание.
no comments.
AVK>>Вобще то обычно структура бизнес-процессов отображается на архитектуру программного продукта веьсма опосредовано. S>Сильно зависит от бизнес-аналитика и архитектора. Везде может присутствовать "человеческий фактор".
Ну если аналитик вобще никакой настолько, что никогда не слышал об объектной или реляционнной декомпозиции, к примеру, то конечно.
S>>>Я писал про веб-сервис? AVK>>А я писал? S>Явно нет
И неявно тоже.
S>, но в общем контексте ответа это именнт так.
Это всего лишь твое заблуждение. Попробуй перечитать еще раз мое сообщение, забыв про веб-сервисы.
AVK>>Да. SOA это вобще то программирование S>Мне кажется, что я достаточно четко разделил текст на 2 части. В рамках первой части я про SOA не говорил, только про SO анализ. SOA — это вторая часть, основанная на первой.
SOA в общепринятом понимании это именно архитектура программной системы, к бизнес-аналитике этот термин никакого отношения не имеет. Поэтому, коль скоро ты используешь этот термин, используй его по назначению, а не как тебе больше нравится.
AVK>>Мягко говоря это не так. S>Готов поспорить отдельным тредом.
Ну поспорь. Только не стоит. Indigo это много больше чем развитие WS.
AVK>>Однако в SOA ничего на эту тему нет. S>Где четкое единое определение того, что такое SOA?
Я парочку привел.
AVK>>Нет, я о SOA, а вот ты непонятно пока о чем. S>Я скорее о практическом применении. Мой текст как входная точка для дальнейшего изучения и применения.
Если ты о практическом применении, то первое, с чего ты должен был начать, это слова о том нафига это вобще нужно.
Бред, потому что ты тоже похоже определение, что я привел, не читал.
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.
Здравствуйте, GlebZ, Вы писали:
AVK>>Только вот в такой трактовке SOA не существует. GZ>А я считаю, что SOA — как самостоятельное понятие архитектуры не существует.
Ну а в трактовке МС существует. Вопрос в том кому больше доверять, тебе или МС.
GZ>SOA — понятие определяющее только построение tier.
Services are autonomous.
С этим вроде бы большинство не спорит. А автономность это в том числе и логическое понятие. В трактове МС сервис это и tier и layer одновременно.
GZ>Возьмем твое определение(точнее определение Microsoft). Если по правде говорить, то процентов 80 "правильных" серверов приложений, которых больше одного в системе, подходят под это определение.
Нифига. Практически ни один не подходит. Более того 99% вебсервисов тоже неподходят. Например по отсутствию compatibility policy, описывающей семантическую совместимость сервиса.
GZ> Я не говорю о прямых вызовах некоторых классов (что есть неэффективно, доказывать не буду). Я говорю о системах с выделеным и определенным интерфейсом. Обзывать их SOA, по моему, много чести.
Потому что это не SOA. Прочти все таки то, что я привел, полностью, воды там не много.
GZ>Еще. GZ>То определение которое ты дал, в последних двух пунктах подразумевается (или прямо указывается) SOAP.
Архитектура, ориентированная на сервисы.
)
Одинаковые ошибки необязательно делать каждый раз, достаточно сделать одну, а затем обращаться к ней по мере необходимости из любого места программы.
Если нам не помогут, то мы тоже никого не пощадим.
Давай без демагогии.
