SOALIB - SOALIB

Библиотека сервис-ориентированной архитектуры (SOALIB) используется для распространения многоразовых Сервис-Ориентированная Архитектура (SOA) программное обеспечение[1][2] аналогично другим вычислениям библиотеки. SOA состоит из слабо связанный совместимые службы, использующие обмен сообщениями на основе обоих Простой протокол доступа к объектам (SOAP) и Изобразительное State Transfer (ОТДЫХ). А библиотека in computing - это набор скомпилированных модулей, которые протестированы и готовы к повторному использованию. Аналогичная концепция используется для SOA в том смысле, что любая технология, используемая для разработки сервиса, также может распространяться в виде библиотеки. А Ява SOA-библиотека может распространяться в Веб-архив (ВОЙНА) или Корпоративный архив (EAR) форматы файлов. C, C ++, и .СЕТЬ приложения могут распространяться как общий объект (в Unix и Linux ), а Библиотека динамической компоновки (в Windows) или как исполняемый файл файл.

История

Сервис-ориентированная архитектура обычно связана с перепроектированием всей программной системы и определяет, как разложить единый программный модуль на слабосвязанные компоненты, в которых каждый слабосвязанный компонент действует как взаимодействующий сервис. Такая задача огромна и может занять значительное количество времени, хотя на атомарном уровне (где атом определяется как один автономный слабо связанный сервис), большинство сервисов можно использовать повторно независимо от приложения. Например, вся материя состоит из атомов, но все материальные вещи разные. Однако на атомном уровне они кажутся единообразными. Точно так же все программное обеспечение может быть построено на слабосвязанных сервисах, которые служат «атомами» процесса редизайна. Поскольку слабую связь трудно определить, обратное неверно. Это означает, что проще построить полную программную систему, используя доступные слабосвязанные службы.

Создавая библиотеки сервис-ориентированной архитектуры, каждая из которых является слабо связанной службой, можно разрабатывать сложные приложения, используя эти службы. Поскольку новые приложения зависят от всех слабо связанных сервисов, пока одно из них придерживается слабой связи, окончательное приложение также будет слабосвязанным. Хотя это правда, что окончательное приложение зависит от многих иерархических слабосвязанных систем, оно остается слабосвязанным, поскольку вся иерархия основана на атомарных службах.

Цели

Для построения SOA требуется Слабая связь услуг в качестве отправной точки. Их называют атомный Сервисы. Первый шаг - определить атомарные службы. Затем создайте эти атомарные сервисы для повторного использования. Можно создать большое количество таких атомарных сервисов, на которых будут построены составные сервисы. Составные сервисы - это сервисы, построенные только на атомарных сервисах.

Шаги

  • Выявление, создание и тестирование слабосвязанных атомный Сервисы.
  • Выявление, создание и тестирование слабосвязанных составных сервисов, где каждый составной сервис состоит только из атомарных сервисов.
  • Создавайте интегрированные сервисы, где каждый из интегрированных сервисов состоит из составных и атомарных сервисов.
  • Создавайте сложную программную систему за счет повторного использования атомарных, составных и интегрированных сервисов. Эта сложная система остается слабосвязанной.

Независимость от платформы

Рассмотрение кросс-платформенный это важно. В настоящее время существует множество способов сделать платформу хоста сервисов независимой от платформы. Примерами являются создание сервисов на Java, где JVM доступен для хоста, на котором сервер будет работать как служба. Альтернативой является создание приложений с полным соответствием ANSI C / C ++ так что ни один из компонентов кода не зависит от сторонних библиотек. Обычно это означает создание приложений C / C ++ с использованием GNU инструменты и компиляторы GNU C, потому что компиляторы GNU портированы на большинство операционных систем и платформ. Другая альтернатива - использовать C # .СЕТЬ как язык веб-службы, где общеязыковая среда выполнения [3] переносится на целевую операционную систему и платформу. Доступно множество других вариантов, но наиболее распространенные подходы к независимости платформы уже упоминались.

Шаги

  • По возможности полная независимость от платформы.
  • Автоматические тесты на каждой платформе.

Мультивендорная база данных

Объем библиотеки ограничен, если она не поддерживает базы данных. Составные и интеграционные сервисы должны быть построены так, чтобы использовать слабосвязанные атомарные сервисы, которые работают с базами данных. После добавления поддержки доступа к базе данных метаданные слой должен быть добавлен для сопоставления различных типов форматов данных в базе данных в единый набор типов данных, которые будут иметь одинаковое значение для всех баз данных. Это сложная часть, но в настоящее время JDBC,[4] ODBC, ADO и другие стандартные драйверы баз данных уже выполняют часть этой задачи. Каждая база данных может хранить данные в разных форматах. Некоторые данные могут быть зашифрованы, некоторые могут храниться с прямым порядком байтов. Порядок байтов, или другие с прямым порядком байтов и т. д. Следовательно, данные должны быть преобразованы в какой-то момент службами, и это должно быть выполнено во время выполнения из-за изменяющегося характера данных. Все базы разные, поэтому единой API может воспользоваться всеми функциями всех баз данных. Следовательно, сервисы также должны использовать специфические особенности базы данных.

Шаги

  • Полная поддержка всех основных баз данных - мобильных, ПК и серверных.
  • Создание слоя метаданных для равномерного доступа к данным.
  • Весь доступ к базе данных через служебные библиотеки.
  • Автоматическое преобразование данных во время выполнения.
  • Поддержка специфических функций внутренней базы данных.

Синхронизация данных

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

Шаги

  • Любая синхронизация.
  • Механизм захвата изменений.
  • Однонаправленная и двунаправленная синхронизация данных.
  • Пользовательское сопоставление с ссылочной целостностью.
  • Гетерогенная синхронизация.

Безопасность

Все библиотеки должны быть безопасными. Если библиотеки имеют реализацию SOA в виде веб-сервисов, тогда они должны иметь WS-Безопасность,[5] WS-Политика[6] и другие стандарты WS-типа. Если он основан на REST или других протоколах, он должен соответствовать соответствующим стандартам. Все библиотеки должны как минимум поддерживать SSL.

Шаги

  • Поддержка всех основных архитектур безопасности на основе стандартов.
  • Поддержка Secure Socket Layer.
  • Вариант для зашифрованного хранилища на сервере.

Совместимость

Функциональная совместимость - одна из наиболее важных причин, почему SOA так важна. Библиотека SOA также должна включать необходимый API, который можно было бы использовать для быстрой разработки для конкретной платформы.

Шаги

  • Поддержка всех основных языков программирования: Ява, Java ME, C, C ++, C # .NET,[7] VB.NET.,[8] PHP[9]
  • Поставляется со всеми необходимыми клиентскими API.
  • Все API-интерфейсы должны быть протестированы с привязкой к службам SOA.

Создание приложений атом за атомом

Атомарный сервис - это слабо связанный сервис, который не зависит от каких-либо предположений, абсолютно предсказуем и не имеет других зависимостей от сервисов или других атомарных сервисов. В качестве примера операцию с файлом на диске можно рассматривать как атомарную службу, в которой единственными операциями, выполняемыми службой, являются операции чтения, записи, удаления или добавления файла. Поскольку единственная информация, которая может понадобиться для файла на диске, - это полный путь к файлу и, возможно, некоторые параметры доступа (например, имя пользователя и пароль), других зависимостей не будет. Если составной сервис разработан на основе атомарных сервисов, он по-прежнему слабо связан, но не атомарный сервис. Затем каждый интегрированный сервис можно построить вместе, чтобы создать более крупное SOA-приложение. Построив слой за слоем, можно создать большое приложение SOA, которое останется слабо связанным.

Общие рекомендации

Чтобы интегрированные сервисы оставались слабосвязанными, потребовалось бы, чтобы все сервисы были построены на атомарных и составных сервисах. Как только интегрированная служба использует другую службу, которая в некоторой степени тесно связана, все приложение службы становится тесно связанным. Это аналогично тому, как атомные структуры становятся «заряженными», если отсутствует только один электрон. По этой причине при использовании сторонних сервисов разработчик должен гарантировать, что сервис остается слабосвязанным.

  • Если служба зависит от сторонних служб, эти службы также должны быть слабо связаны.
  • Если третья часть предлагает атомарные сервисы, то составные сервисы могут быть созданы путем смешивания библиотек сервис-ориентированной архитектуры, а также сторонних атомарных сервисов.
  • Если какая-либо из услуг считается тесно связанной, что может потребоваться, когда задействовано промышленное оборудование (например, роботизированные манипуляторы, бытовая техника и т. Д.), Это должна быть последняя услуга, и никакая услуга не должна быть получена на их основе. . Если другие сервисы построены на сильно связанных сервисах, производные сервисы также тесно связаны. Эти производные службы могут использоваться в специализированных приложениях, где требуется тесная связь (например, в точных машинах).

Ниже представлена ​​иерархия, в которой должны разрабатываться все сервис-ориентированные приложения.

Иерархия

В идеале подход к разработке приложений SOA должен быть следующим:

  • Интегрированные услуги - на основе составных и атомарных сервисов
    • Композитные услуги - основанный только на атомных сервисах
      • Атомные услуги - нет зависимости, эта услуга - атом

Структуры, которых следует избегать

В некоторых случаях слабая связь может оказаться невозможной из-за использования оборудования, механических систем или специализированных инструментов. Например, если есть служба, созданная для перемещения манипулятора, мониторинга промышленных генераторов или оборудования больниц скорой помощи. Тогда требуются тесно связанные услуги. Сильно связанные службы должны быть наверху в иерархии, чтобы никакая другая служба не могла повторно использовать тесно связанные службы, если это возможно. Если существуют производные сервисы, основанные на сильно связанных сервисах, то все производные сервисы также становятся тесно связанными. Такая система, если она разработана, должна быть ограничена рамками цели приложения.

Смотрите также

Рекомендации

  1. ^ Корпорация Microsoft, январь 2004 г. [1] Понимание сервис-ориентированной архитектуры, Архитектурный журнал
  2. ^ Sun Microsystems, апрель 2005 г. [2] Сервисно-ориентированная архитектура (SOA) и веб-службы: путь к интеграции корпоративных приложений (EAI)
  3. ^ Корпорация Майкрософт. [3] общеязыковая среда выполнения
  4. ^ Sun Microsystems. [4] Источник для разработчиков Java
  5. ^ Оазис [5] OASIS Web Services Security (WSS) TC
  6. ^ Консорциум World Wide Web (W3C) [6] Политика веб-служб 1.2 - Framework (WS-политика)
  7. ^ Корпорация Майкрософт. [7] Обзор возможностей Visual C #
  8. ^ Корпорация Майкрософт. [8] Начало работы с Visual Studio
  9. ^ php.net [9] Препроцессор гипертекста

внешняя ссылка