Г.4.2.4. Проблемы стандартизации



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

Г.4.2.4. Проблемы стандартизации



 

Для сборки прикладных систем из гетерогенных модулей необходимы стандартизованные интерфейсы, особенно для связи со средами клиент-сервер. В настоящее время попытки такой стандартизации предпринимают различные организации, в том числе Группа по технологии управления объектами (Object Management Group — OMG) и Группа по разработке открытых приложений (Open Application Group — OAG). Ту же цель преследуют промышленные стандарты, разрабатываемые крупнейшими поставщиками (Microsoft, SAP и другие).

Консорциум OMG объединяет поставщиков разной продукции. В начале 1998 года эта организация насчитывала более 800 членов. Предложенная ею архитектура управления объектами (ОМА) представляет собой инфраструктуру для распределения и обеспечения взаимодействия объектно-ориентированных программных модулей в сетевых гетерогенных системах (см. рис. 55).

Рис. 54. Связывание аплетов со зданием ARIS

Рис. 55. Архитектура управления объектами

Центральным элементом этой архитектуры является брокер запросов к объектам (ORB), предназначенный для обмена сообщениями между объектами на гетерогенных платформах в соответствии со стандартом CORBA (Common Object Request Broker Architecture — Общая архитектура брокера запросов к объектам).

CORBA — это стандарт, устанавливающий взаимодействие клиентских и серверных объектов. Клиентский объект может активизировать тот или иной метод с помощью ORB. При этом ему совершенно не обязательно «знать» местонахождение серверного объекта.

Одна из задач OMG заключается в описании стандарта CORBA. Конкретную реализацию оставляют на усмотрение различных поставщиков. Среди существующих коммерческих реализаций можно выделить ORBIX фирмы IONA Technologies, Ltd.

Дальше этого попытки стандартизации объектов приложений пока не идут. Ведется, однако, работа по определению так называемых «общих бизнес-объектов» (СВО), о которых речь пойдет далее. Службы CORBA (CORBA services) предоставляют базовые услуги, например, проверку целостности. Средства CORBA (CORBA facilities) можно сравнить с универсальной библиотекой классов: они включают стандартные функции, наиболее часто встречающиеся во многих приложениях, что существенно экономит время и силы пользователей при работе с приложениями. Домены CORBA (CORBA domains) предлагают специализированные функции, например, для систем автоматизированного проектирования.

Корпорация Microsoft разработала стандарты для связывания объектно-ориентированных компонентов. Стандарты СОМ (компонентная объектная модель) для однопользовательских систем и DCOM (распределенная компонентная объектная модель) для распределенных систем обеспечивают взаимодействие между объектами. В настоящее время разрабатываются интерфейсы со стандартом CORBA.

Рис. 56. Бизнес-объект SAP

Компания SAP также разработала концепцию взаимодействия с бизнес-объектами, которая называется BAPI (интерфейс программирования бизнес-приложений). Интерфейсы BAPI реализуются в качестве методов работы с бизнес-объектами SAP, предоставляя открытый доступ к бизнес-функциям. Структура бизнес-объектов SAP представлена на рис. 56.

Ядро бизнес-объекта SAP заключает в себе базовую бизнес-логику. Второй слой содержит бизнес-правила, отвечающие за целостность. Третий слой охватывает объектные методы, атрибуты, а также средства управления входными событиями, выходные события и описания BAPI. В качестве интерфейсов поддерживаются стандарты СОМ/ DCOM, CORBA и Java.

В расширенной версии этой концепции бизнес-объекты группируются в пакеты — так называемые бизнес-компоненты. На первом этапе вся система R/3 включала лишь три компонента (HR — человеческие ресурсы, LO — логистику и FI/CO — финансы/контроллинг). Впоследствии было добавлено еще с десяток вновь разработанных компонентов (например, Business Engineer и Business Information Warehouse). Взаимодействие между этими компонентами, осуществляемое при помощи технологии ALE (возможность связи приложений), можно сравнить со способом взаимодействия между независимыми системами R/3 и между системами R/3 и R/2(см. рис. 57). Концепция ALE поддерживается Группой OAG, что является залогом продолжения разработки общего стандарта Она также обеспечивает взаимодействие с Интернет-приложениями.

Рис. 57. Бизнес-компоненты

Рис.58. Встраивание общих бизнес-объектов

Интерфейсы BAPI и сообщения ALE служат методами доступа к бизнес-объектам или компонентам Главное различие между ними заключается в степени структурированности. В то время как сообщение ALE способно активизировать через Интернет сложное приложение, например, всю процедуру обработки заказа, интерфейсы BAPI предполагают более детальные методы, скажем, проверку доступности. Сообщения ALE могут обрабатываться асинхронно в отличие от синхронной работы интерфейсов BAPI.

Рис. 59. Рабочее пространство с взаимозаменяемыми компонентами

Опираясь на результаты CORBA, Группа OMG также выступила поборником стандартизации бизнес-объектов. В 1996 году она опубликовала документ RFP-4, приглашая специалистов высказать свои идеи относительно стандартизации общих бизнес-объектов (СВО — Common Business Objects). Задача заключалась в том, чтобы создать описание базовых приложений, из которых можно было бы конструировать конкретные объекты. Принцип встраивания СВО показан на рис. 58. Например, СВО может представлять собой объект, используемый для обработки информации о продажах или данных финансового учета. Некоторые предложения были связаны с проблемами расчета обменных курсов валюты (этот вопрос был поднят корпорацией IBM), другие относились к приложениям workflow. Описание объектов должно создаваться в соответствии с рекомендациями (OMG. Common Business Objects. 1996, с. 17), разработанными по следующим аспектам:

обозначение СВО,

атрибуты объектов

отношения между СВО,

условия, необходимые для СВО и их взаимоотношений,

правила бизнес-процесса, применяемые к СВО и их взаимоотношениям,

спецификация интерфейсов и методов СВО на языке описания IDL, принятом Группой OMG.

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

Рис. 60. Промышленная производственная система

 

Г.5. Рабочее пространство (инфраструктура)

 



Последнее изменение этой страницы: 2016-06-19; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.236.16.13 (0.023 с.)