По пути к онтологии верхнего уровня SAP SOA

Нечитайлов Юрий Вячеславович

Исследование зарубежного опыта


Нечитайлов Юрий Вячеславович 9 марта 2011, 18:39

Автор: Тобиас Трапп (Tobias Trapp)

SAP очень силен в моделировании данных предприятия. Это не удивительно потому что SAP имеет большой опыт  работы в этой области, начиная с системы R/3. SAP создал методологию структурированной модели отношений между сущностями (Structured Entity Relationship Model, SAP SERM) и разработал инструменты, такие, как разработчик моделей данных (Data Modeler) (см. серию статей в моем веблоге, начиная с  http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/5006. SAP был одной из первых компаний, которая стала использовать хранилища бизнес-объектов (Business Object Repository, BOR) в комбинации с моделями данных.

Позже SAP стал использовать объекты  BOR как основу своей стратегии сервис-ориентированной архитектуры (SOA). Таким образом, методология немного изменилась:

  • унифицированный язык моделирования (Unified Modeling Language, UML) был улучшен концепцией  SAP SERM и получил название UMLplus
  • с точки зрения концепции, была проведена доработка, потому что интерфейсы программирования бизнес-приложений (Business Application Programming Interface, BAPIs), как методы BOR объектов, не имеют общей детализации
  • типы данных BAPI были связаны с теми понятиями, которые мы знаем из ebXML
  • модель программирования BAPI была заменена моделями коммуникации SOA.
  • многие продуманные и сформировавшиеся понятия были перенесены из ALE  в контекст SOA

Что такое концептуальная модель SOA предприятия?

Она руководствуется сложной методологией SOA, которую Вы можете найти на сайте SCN (SAP Community Network):

  • Enterprise SOA Object & Service Operation Design: Руководство по моделированию бизнес-объекта (Часть 2 из 6)
  • Enterprise SOA Object & Service Operation Design: Руководство по проектированию сервисных операций (Часть 3 из 6)
  • Enterprise SOA Object & Service Operation Design: Руководство по проектированию глобального типа данных (Часть 4 из 6)
  • Enterprise SOA Object & Service Operation Design: Руководство по документации и именованию  (Часть 5 из 6)

Эти понятия лежат в основе SOAP (Simple Object Access Protocol) веб-сервисoв в контексте A2A и B2B:

  • co стандартизированными типами данных
  • со стандартизированными моделями коммуникации
  • с моделью базовых бизнес-объектов

Данные концепции являются основой для семантической модели (структуры, называемой SOA предприятия, хотя название SOA@SAP подошло бы больше), которую я описал в статье "Семантика веб-сервисов" (Semantics of Web Services). SAP предоставил мощные инструменты, такие, как Enterprise Service Workplace, которые помогают пользователям использовать веб-сервисы SAP Business Suite.

Однако иногда этого бывает недостаточно: Как корпоративный архитектор (Enterprise Architect), Вы должны работать с различными структурами и методологиями SOA, а также преодолеть разрыв между различными сферами. Это также справедливо, если Вы хотите внедрить собственные сервисы предприятия (Enterprise Service). По моему собственному опыту, вышеупомянутые стандарты являются достаточно сложными, ввиду того, что они полностью проработаны и охватывают множество деталей.

Онтологии как инструмент для документирования

Enterprise SOA Object & Services Modeling guidelines (прим. ред.: см. предыдущий раздел) определяют множество концепций. Приведем лишь несколько:

  • подтипы бизнес-объектов (Business Objects): Dependent Object (зависимые объекты), Transformed Object, Technical Object, Mass Run Data Object, Template Object
  • Dependent Objects (Зависимые объекты): Access Control List (список контроля доступа), Accounting Clearing Object History,  Accounting Coding Block Distribution, Address, Attachment Folder, Business Folder, Business Plan Foundation, Business Process Assignment
  • подтипы  Service Operation Categories: Сложные операции (Compound Operations), такие, как операции B2B, A2A и A2X, Основные оперции (Core Operations), такие как создание, выборка, изменение, удаление (CRUD), запрос (Query) и Action Operations.
  • Business Document Objects, Message Types, которые имеют тип такой, как Message Data Types
  • Actions, Action Data Type и Action Data Type Elements
  • Global Data Types (Глобальные типы данных), такие, как Amount, Binary Objects, Code, Date, DateTime, Duration, Graphic, Identifier, Measure, Name, Numeric, Percent, Quantity, Ration, Sound, Text, Time, Value и Video
  • Типы данных: Node Data Type, Intermediate Data Types, Filter Data Type, Key Data Type, Action Data Type, Query Data Type, Query Intermediate Data Type, Extension Data Type, Basic Global Data Types, Aggregated Global Data Types
  • подтипы  Service Operation Categories: Сложные операции (Compound Operations), такие, как операции B2B, A2A и A2X, Основные оперции (Core Operations), такие как создание, выборка, изменение, удаление (CRUD), запрос (Query) и Action Operations.
  • Однако этого ещё не достаточно для понимания методологии eSOA - нам необходимы:
  • классификация этих понятий
  • текстовое определение (возможно как ссылки)
  • комментарии
  • определения отношений между понятиями
  • примеры, т.е. экземпляры этих понятий
  • ссылки на другие источники информации

На самом деле, мы стандартизировали инструменты, чтобы формально выразить эти понятия, обращаясь к онтологиям, использующим  стандарты W3C, такие, как OWL. Я уже писал в своей серии веб-статей "Введение в семантику" о применении онтологий для создания  экспертных систем, но мы можем использовать их в качестве преемника или тематических карт (topic maps). Однако мы также можем использовать эти инструменты для создания, запроса и виртуализации концептуальных моделей. Таким образом, они полезны как фактические данные, формальное определение и могут быть также использованы в качестве ориентира чтобы найти свой путь в текстовом определении.

Онтологии были успешно применены в медицине и медико-биологических науках для выражения сложных предметных областей. Как пример можно привести классификацию

По пути к онтологии верхнего уровня SAP SOA

Благодаря следующим свойствам онтологии могут вывести управление базами знаний на более высокий уровень:

  • они обладают возможностями дескриптивной логики, что означает наличие средств отслеживания непротиворечивости определяемых понятий
  • они могут содержать ссылки на другие ресурсы и служить центральным узлом, связывающим различные информационные ресурсы: библиотеку SAP, техническую документацию (whitepapers),  информацию о версиях (Release Notes), приложения, такие, как Enterprise Service Place, соответственно Solution Composer и даже нестандартные ресурсы, такие, как блоги и т.п.

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

Тобиас Трапп - руководитель SAP и разработчик структуры программного обеспечения для AOK систем GmbH. Его можно найти на Twitter под именем  @ttrapp.


Перевод выполнен издательством ООО "Эксперт РП" для портала www.SAPLand.ru Английская версия была размещена на сайте «SAP Community Network»

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/23562

← Назад