Автор: Тобиас Трапп (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 (список