Интероперабельность (англ. interoperability) — способность системы к взаимодействию с другими системами. Обычно термин применяется для информационных систем.
К чему это я ..
Делал клиента для веб службы на Delphi. Клиент прислал WSDL, который произвел JAX-WS. С помощью средств Delphi из него был быстро сделан тестовый класс веб службы и клиент. Веб служба была развернута на Apache2 и клиент быстро сообщил об успехе целевой операции. Радость, на которую в общем ушло не более двух часов.
Отправили клиенту - радуется - тестовая среда отлично себе работает .. Но целевой сервис молчит - не принимает внутренние параметры авторизации...
Клиент просит сделать на .Net и вызывать из приложения Delphi... Вооружился SharpDeveloper, wsdl.exe из поставки .Net SDK, сделал интерфейс для развернутого на Apache веб-сервиса ..
Exception System.Web.Services.Protocols.SoapException was thrown in debuggee:
Possible SOAP version mismatch: Envelope namespace http://schemas.xmlsoap.org/wsdl/ was unexpected. Expecting http://schemas.xmlsoap.org/soap/envelope/.
и хоть ты тресни ... что делать ума не приложу, причем Delphi SOAP шлет правильный заголовок сообщения - http://schemas.xmlsoap.org/soap/envelope/
Читать далее »
Работа с СУБД
Стандартов доступа к данным развелось порядочно - фиксирую то с чем встречался: ODBC; BDE - Borland Database Engine; JDBC - Java: ADO - MS; ODA - Eclipse DataTools Platform; SDBC - OpenOffice.org Base.
Интересен вопрос "стандартные драйвера доступа vs драйвера прямого доступа". В свете таких мыслей - (1) 90% времени OLTP приложение ожидает ввода пользователя; (2) что нам нужно от драйвера для работы; (3) инструменты проектирования БД.
Проектирование: таблицы, связи, триггеры, хранимые процедуры, логическая организация БД, хранение истории. Удобство инструментов работы с БД - общие подходы, специализированные функции конкретных БД.
Разработка приложения: соединение, выполнение запросов, возврат набор данных; технологические возможности - кэширования данных на клиенте; подготовленных запросов; репозитория ограничений на значения полей; стандартные подходы к реализации интерфейса пользователя.
---------
Как правило, стоимость такой услуги, как монтаж кондиционера зависит от мощности и веса последнего. Узнать актуальные расценки на установку кондиционера в Москве вам поможет сайт ds21.ru компании «Система Климата».
Составление ТЗ на разработку/внедрение
Пишу для проекта Информационной системы торгового предприятия такие документы, как Use Case, Business Glossary, SRS. Интересно, что хотя постановка задачи общая и не привязана к конкретной системе. На самом деле рассматривается пока два варианта реализации - 1С 8.1 и Adempiere. И та и другая поддерживают необходимый набор бизнес-сущностей - компания, контакт, счет, накладная, приходный кассовый ордер, e.t.c, а также набор стандартных отчетов и идиом взаимодействия (RFQ -> Invoice -> Payment, ...)
Можно ли сделать так, чтобы никого не обидеть (1С 8.1 и Adempiere) и вместе с тем не писать большого количества требований, т.к. они вроде общие для любого бизнеса. И при этом сконцентрироваться на детальной проработке ключевых сценариев взаимодействия, тех что стоят над стандартной поставкой выбранных подуктов, т.е. то что прийдется дорабатывать. Нужно принимать во внимание, что писатель возможными целевыми системами не владеет, а разработчик будет продавливать стандартное уже реализованное в системе решение.
Вспоминаю ТЗ на адаптацию продукта TSCRM ... ТЗ имеет стандартное строение и побито по разделам - Клиенты, Контакты, Продукты, ... В разделах указываются кастомные атрибуты, кастомные справочники и кастомные процессы по главным разделам. Кроме того описывается наполнение стандартных справочников.
XForms с которого все началось
Решил просветить для себя вопрос с XForms и попал как обычно на много чего интересного по дороге ...
Столкнулся с проектированием схем при освоении Intalio|BPMS - взаимодействие на веб-сервисах и описание схем данных на каждом углу. Потом как-то взявшись за проектирование БД задумался, а ведь XML проектирование схем возможно выйдет на первое место при разработке систем ориентированных на интеграцию, да и схемы должны быть стандартные для классов приложений ...
Проектирование XML-схем для корпоративных данных
... основные типы корпоративных приложений и их требования к обмену данными
... почему для корпоративных XML-данных требуется определять схему
... применение шаблонов для разработки общих бизнес-документов и XML-структур
... Как определять и расширять сложные типы
... Когда и как определять абстрактные сложные типы и абстрактные элементы;
... Как применять регулярные выражения (строковые шаблоны), перечисления, объединения, списки и группы подстановки.
... как разрабатывать схемы нескольких файлов и как применять внешние схемы для проектирования корпоративных данных. Наконец, данные операции будут объединены для разработки общих бизнес-документов.
В общем статья интересная и большая - есть что почитать и над чем подумать, попробовать соотнести с моделированием БД.
Второй была собственно статья по теме с реальными примерам Using JSF technology for XForms applications. Есть даже Pdf на ! 184 страницы, правда датирована статься началом 2005 года, так что многое могло измениться.
Ну и мне попалась на глаза расширенное описание работы с JSF таблицами, которое мне встречалось в начале года и немного подросло.
Интересный каталог XML шаблонов XML Design Patterns Index
Внушительный LGPL проект реализации XForms для J2EE Orbeon
Pre: XForms с которого все началось
В общем это начало прошлого поста XForms с которого все началось. И, что самое забавное, я уже точно не помню с чего все началось... Встал вчера в 22:30 и как раз успел на "Рим" по 1+1. Получил почту с просьбой нарисовать в BPMN "процесс планирования расписаний учебных встреч в ВУЗе" с набросками процесса, и около часа начал пытаться рисовать и естественно углубился ... Хотя по плану я должен был писать ТЗ, на BPMN отвлекся с удовольствием, хоть так ничего и не получилось из-за описания. Затем я начал создавать в OpenOffice шаблон SRS на основе IEEE-830, но списывал у Вигерса
... И все это время в голове крутится идея проекта быстрого создания UI на основе объектов БД, что уже два раза начинался на Delphi и теперь появилось желания сделать на Java, с учетом прошлого опыта, в концепции интеграции с BPMS, BRMS и конечно же BIRT. По интеграции с BIRT есть книжка на английском - Integrating and Extending BIRT, по остальным же нету ничего, но это пока не так важно. Но основная задача это UI, и если стандартный UI сделать можно и он уже делался, то с кастомизацией его были проблемы и в Delphi проектах (в SWT Snippets есть примеры таскания мышкой кнопки по форме).
... Тут я уперся в мелкую проблему с нумерацией разделов в OpenOffice.org Writer и полез в мануал. Ничего по моей проблеме не увидел (все-таки сказывается ночной график), но увидел, что он работает с XForms. И почему бы не попробовать его для построения UI - пусть себе какие-либо продвинуты пользователи рисуют себе формы в других редакторах. По XForms помню, что и интерфейс Intalio|Workflow построен на XForms. В общем так я и полез в Google. Как все это продолжается можно судить по датам последних постов.
И тут попался Nuxeo - http://www.javalobby.org/java/forums/t63868.html
Nuxeo , a french open source ISV specialised in Enterprise Content Management, has just published the code for an XForms engine for SWT and Eclipse .
Я сразу отметил "SWT", подробнее я смотрю только сейчас и по дороге пишу этот пост. Apogee Project проходит сейчас процесс рассмотрения включения в Eclipse Foundation. Смотрим подробнее что он может:
Documentation
- Apogée XForms Engine: Viewers
- Apogée XForms Engine: developer guide
В общем понравился он мне - если посмотреть приведенные выше документы, то все довольно просто. А если еще заглянуть в SVN то можно увидеть плагин к OO (Для редактирования?) Скачал ... еще бы время на наего найти. Проект оформлен хорошо - и документация присутствует и модели Together Designer (наверное его уже не найдешь - был такой бесплатный тугезе года три назад, ну и UML 1.4 кажется там)
ЗЫ. А вот кстати и информация о том, что Intalio использует для Front-End именно Orbeon, о котом есть в начале-продолжении. Также возьму на заметку и посмотрю что там с UI для десктопа... нету UI для десктопа но демонстрации тоже поражают - посмотрите сами - особенно первую. Правда на PHP было быстрее 
OASIS UBL
Итак кажется я нашел самый что ни на есть интересный документ для изучения XML Shema. И это OASIS Universal Business Language. Документ вообще интересный, т.к. рассматривает такие вопросы как бизнес-процессы, каталоги, заказы, счета, платежи, перевозки. Приводятся Use Case диаграммы и диаграммы процессов на UML... Стандарты XSD и примеры XML документов.
Да что распинаться, если интересно смотрите сами! Тут думаю мои вопросы с ключами уйдут после изучения. Да и вообще интересный документ для любой разработки бизнес ПО.
Описание релиза UBL 1.0
UBL определяет общую XML-библиотеку бизнес-документов, таких как заказы на поставку и счета-фактуры, а также компоненты данных многократного использования, с помощью которых можно создавать различные бизнес-документы. UBL является первой стандартной реализацией технической спецификации "ebXML Core Components" ("Базовые компоненты языка ebXML").
.. библиотека опирается на концептуальную модель информационных компонентов, известную как информационные сущности бизнеса (Business Information Entities, сокр. BIEs). Эти базовые элементы собираются в модели конкретных документов, как, например, Заказ на поставку (Order) и Счет-фактур (Invoice). Затем эти собранные модели документов трансформируются в соответствии с правилами наименования и проектирования UBL (UBL Naming and Design Rules) в синтаксические структуры XML-схемы W3C. Благодаря этому можно создавать типы документов, основанные на UBL, отличные от определенных в спецификации языка UBL 1.0. Таким образом, можно говорить о модульности, практичности и расширяемости схем UBL.
Комплект документов UBL 1.0 содержит 244 файла, которые объединены в zip-архив, и содержит документацию, нормативные XML-схемы, UML-диаграммы, примеры электронных документов и другие документы:
XML-схемы для восьми основных бизнес-документов: Заказ (Order), Ответ на заказ (Order Response), Простой ответ на заказ (Order Response Simple), Изменение заказа (Order Change), Аннулирование заказа (Order Cancellation), Извещение об отправке (Despatch Advice), Извещение о получении (Receipt Advice) и Счет-фактура (Invoice);
описание общего процесса закупки по схеме заказ-счет, для которого разработаны типы документов UBL;
библиотека, состоящая из более чем 400 элементов данных XML (с определениями, основанными на технической спецификации "Core Components"), с помощью которых строятся схемы документов UBL;
" описание методологии разработки UBL 1.0;
UML-диаграммы всей модели данных UBL и модулей составляющих ее компонентов: Модуль адреса (Address Package), Модуль контракта (Contract Package), Модуль доставки (Delivery Package), Модуль указания документа (Document Reference Package), Модуль опасного изделия (Hazardous Item Package), Модуль изделия (Item Package), Модуль партии (Party Package), Модуль платежа (Payment Package), Модуль закупки (Procurement Package), Модуль налога (Tax Package);
диаграммы компоновки документов, демонстрирующие отношения между каждым типом документа UBL и его составляющими компонентами;
электронные таблицы Excel и OpenOffice, показывающие модель данных каждого документа UBL и библиотеку компонентов UBL.
ЗЫ
Утопия - бизнес-приложение мирового уровня и опыта за 10 минут. Все бизнес-процессы, документы, возможность интеграции через веб-сервисы, работа через веб и толстый клиент. XSD готовы из XForms и схему БД ... или XML СУБД
И немного ссылок
UBL: Another Opportunity for FOSS in the Enterprise
UBL: Ready for Prime Time
Free UBL на sourceforge
www.freebxml.org
freebxmlbp
______________
Автосалоны и компании, производящие срочный выкуп автомобилей в Липецке можно найти по адресу А48.RU.
XML OLTP Утопия
Сказка ложь, да в ней намек
Добрым молодцам урок
Продолжая тему Карра работаю над утопией быстрого построения OLTP приложений. ИТ становится дешевым товаром и XML здесь играет свою роль.
Брукс кончено был прав, что в ближайшие Икс лет (не помню цифр, кажется книга была в 75, прогнозировалось 15 лет и в 95 его же статься подтверждающая прогнозы) не произойдет взрыва производительности труда программистов. Однако в дополнение к разнообразным компонентам и библиотекам появляются целые стандартизированные области и законченные структуры данных, готовые к употреблению из коробки. К таким вещам можно отнести UBL - бесплатную библиотеку стандартных электронных XML бизнес-документов. Напомним немного что это такое ссылкой.
Если сегодня строить бизнес-систему, то почему бы не взять за основу UBL? Что нам это даст? Сначала конечно стандартные XSD схемы бизнес-документов. Вторым важным готовым элементом будут XForms произведенные на основе UBL схем (free-ubl-kit).
Постоянное хранение - Xml СУБД. Исключительно в качестве эксперимента хочу пробовать в ближайшее время Sedna и Xml-Xindice. Отображение XFroms Apogee / Orbeon. Apogee немного потрогал - довольно просто получается. Пугает пока только, что вестей по проекту нету. Из основного осталось построить списки, но думаю, что это самая простая из проблем.
Процессы и Бизнес-правила пока под вопросом, т.к. UBL определяет свои схемы процессов, с которыми пока не ознакомился, но связи с BPEL какие-то существуют и думаю со временем будут укрепляться (сладкое слово стандарты).
И конечно же бизнес-приложению нужны отчеты на основе Xml, и они тоже есть - это BIRT (JDBC, XML, Web Services, and Flat File support, as well as support for using code to get at other sources of data).
Довольно перспективная идея автоматической генерации мощных приложений, т.к. все технологии для этого как бы уже есть. XSD, XForms, XMLDB вообще не вызывают проблем (разве что с производительностью). Сомневающимся предлагаю посмотреть простой кусок кода по отображению XForms из SWT и небольшую статейку по использованию Xindice.
Вот почему таких приложений пока нету, хотя все технологии готовы? Никому не нада? Никто не верит? Ни у кого нету комплекса необходимых знаний? Как по Карру, так такое бы рынок ИТ в плане бизнес-приложений то и пообрушило ... Ищу спонсоров
----------
Фитнесс и бодибилдинг сделают ваше тело стройным, избавят от болезней и помогут освободиться от излишков веса.
Оставляя Delphi
Сидя на красивом холме
видишь ли ты то что видно мне
в игре наверняка что-то не так
(С) Б.Г.
Смотрю со стороны за своей блого-деятельностью и вижу как она постепенно превращается из развлечения в какую-то обязанность. Просто чувствую, что нужно высказаться по определенному вопросу ...
Появилось несколько интересных новостей, звезды выстроились в необходимом порядке и вот случился этот пост. Давно не заходил на delphiplus.org (когда-то посещал его постоянно) но вот недавно зашел и увидел две интересные новости - (1) появился наконец официальный dbExpress драйвер под Firebrid (2) Peter Morris бросает свои открытые Delphi-проекты и переходит на C#. И вот закончилось оценкой Eclipse Foundation совместно с IDC Обзор итогов работы сообщества Eclipse.
Еще менее года назад я был просто программист Delphi. Вокруг бушевали страсти по .Net и Java, Borland становился CodeGear и давно подсел на .Net, многие знакомые свернули Delphi проекты и пересели на C#. И глядя на статистику предложений о работе казалось вполне естественным экономическим шагом тихонько перейти на C# ... Немного поразмышляв об этом я понял простую истину - деньги там где Enterprise. На Delphi его никто его не делает и значит денег здесь гораздо меньше. Кстати забегая на перед скажу что никто из оставивших Delphi и ушедших в C# не жалел, а наоборот, восхищался даже просто возможностями среды.
Сегодня кстати наступила некоторая Delphi усталось что-ли ... В СНГ было сделано много внутренних проектов, программисты потихоньку мигрировали в Java и С#, и сегодня найти адекватных Delphi программистов становится проблемой. Вспоминается Cobol и С++ пару лет назад. Это хорошо для delphi разработчиков - наконец они могут немного покачать права и добиться большего вознаграждения. В Киеве уже например вполне реально получит зарплату в 1200 у.е. или может даже больше.
Но речь не о С#. Что самое неприятное, оставаясь на Delphi вы просто игнорируете огромные возможности производительности просто за счет использования готовых и часто открытых решений, которые не успевает или не хочет внедрять CodeGear. Размер сообщества среды и технологий разработки дает о себе знать, как никогда раньше. А в Delphi с этим Застой.
На самом деле до момента денег я не рассматривал всерьез перехода на новую платформу разработки. В конце концов появился Turbo Explorer и можно было наконец заниматься разработкой бесплатно.
Подсел на Borland я еще в школе - во времена TurboPascal 5.5 и Turbo C 2.0. В институте в 1992 компьютеров было мало и доступ был сильно ограничен. Да и после школьных IBM PS2/30 на Искре даже неприятно было на кнопки нажимать ... Я забросил программирование на несколько лет и вернулся уже где-то в 97-98 уже немного на Delphi 4.0 и потом как-то сразу на 5.0. Тогда я конечно был поражен и засел за изучение VCL... В общем дальнейшие почти 10 лет были плотно связаны с Delphi, но прозрение все-таки наступило, пусть и не так скоро как хотелось бы.
Манил веб и кросс-платформенность и перед отпуском я скачал Eclipse 3.2 SDK. Никаких быстрых движений я тогда особо не планировал, но потихоньку пробовал делать тоже самое что и на Delphi. Начал я с изучения справки по Eclipse JDT - читаю справку и повторяю в среде то что там написано. Кстати есть русский перевод 2005 года может кого заинтересует. И чесно сказать был поражен возможностями и удобством среды по работе с исходным кодом. Именно этот тот предпоследний день отпуска, потраченный на изучение Eclipse JDT, наверное и есть та точка в пространстве и времени, которая отвратила меня от Delphi. Потом уже были RCP, менеджер обновлений, огромное количество подключаемых модулей ... потом - для первого же увлечения хватило возможностей редактора кода! После этого, особо не обращая внимания на Eclipse, я поработал с Delphi еще пару месяцев и затем уволился... немного поработал с J2EE и JSF, сделал пару мелочей на C# Developer и стал аналитиком.
Сегодня я мало программирую, но технологиями немного интересуюсь. Как видно из моих последних постов мне интересны XML технологии - BPM, XSD, XForms, XML DB - и мне кажется это естественным. Даже если бы я и захотел делать свои изыскания на Delphi то просто не нашел бы поддержки этих технологий в самом продукте. Это даже без обид Petera Morisa ...
Однако хочу также заметить что Together остается передовым средством моделирования, JGear тоже выглядит довольно приятно. Т.е. не стоит сбрасывать Borland и CodeGear со счетов вообще, но целиком они уже не поспевают. Ну и конечно OpenSource ... в мире караоке-капитализма капиталист должен что-то давать обществу и IBM, Sun, много кого еще дают, а Borland как-то не очень.
Service Data Objects (SDO) 2.0
Даже странно подумать, что раньше
Каждый шел как хотел, а теперь
Паровоз, как мессия, несет нас вперед
По пути из Калинина в Тверь.
(С) Аквариум
Последнее время много времени провожу в поисковой строке гугла. Дай людям поиск и что они будут делать? Конечно же искать!
Последними XML постами я пытался показать одну мысль - современные корпоративные приложения обмениваются данными, и в 99% случаев это XML - стандарт де-факто для взаимодействия приложений через web. Сказать только одно слово "XML" будет слишком большим упрощением здесь нужно добавить немного страшных слов типа XSD, WSDL, XSL, XFoms, XPath и XQuery. И это далеко не полный список... а еще недавно хватало простого SQL и он пока не отменяется. XML сегодня определяет не только данные, но и метаданные, а также стандартные способы манипуляции этими данными и метаданными.
В общем натолкнулся на статью - Service Data Objects (SDO) 2.0: Создание и чтение документа XML на основе схемы XML. Понравился мне там примерчик - как легко в стиле RowSet можно работать с XML экземплярами не отвлекаясь на DOM/SAX.
Интерфейсы SDO 2.0 предоставляют единообразный способ создания данных и доступа к ним, а также избавляют разработчиков от необходимости подробной разработки процедур парсинга и поддержки целостности данных. На сегодняшний день SDO 2.0 является инкубаторным субпроектом (под названием Tuscany) организации Apache Software Foundation, цель которого - стать де-факто стандартным интерфейсом программирования моделей данных для разработки SOA.
.. интерфейсы SDO 2.0 полностью избавляют вас от необходимости знания и использования API парсера XML для чтения, записи и управления данными. Если вы создаете на Java DataObject, представляющий данные XML в соответствии с определенной вами схемой XML, SDO 2.0 обеспечивает вам удобство и гибкость, позволяя сконцентрироваться непосредственно на работе с данными. В результате этот API предоставляет значительные преимущества, заключающиеся в повышении производительности разработки и качества продукта.
Затем сходил на сайт продукта Apache Tuscany и это не только прозрачная работа с XML - файлами а еще с Data Access Services (DAS) и Service Component Architecture (SCA)... В общем всем кто работает с XML на Java рекомендую посмотреть. Хочу обратить внимание на простоту работы - оказывается для всей работы хватает всего трех элементов
---
Холодильные шкафы, камеры морозильные и льдогенераторы для магазина или склада продуктов вы всегда можете купить у компании «Холод-Торг»
Улетное секс видео со страстными латинками, сисястыми азиатками и крикливыми ниггершами ждет тебя на эротическом портале ebemsa.com. Просмотр всех роликов бесплатен, здесь нет никаких платных аккаунтов и доступа через СМС!
Принципы независимости бизнес-правил
Вчера попал на Манифест бизнес-правил - решил что это довольно важный документ для понимания темы BRMS и попытался перевести. Замечания и предложения по переводу приветствуются.
The Business Rules Manifesto
Статья 1. Первичные требования, а не вторичные
1.1. Правила это элита граждан мира требований.
1.2. Правила неотъемлемая, а не дискретная часть, бизнес-моделей и технологических моделей.
Статья 2. Отдельны от процессов и не заключены в них
2.1. Правила - четкие ограничения на поведение и/или оказывают поддержку поведения.
2.2. Правила не являются процессом или процедурой. Они не должны включаться в эти понятия.
2.3. Правила применяются вокруг процессов и процедур. Должен быть один последовательный свод правил, исполняющийся последовательно во всех соответствующих областях бизнес-деятельности.
Статья 3. Хорошо продуманные знания, а не побочный продукт
3.1. Правила опираются на факты, а факты опираются на понятия выраженные в условиях.
3.2. Условия выражают бизнес-концепции; факты утверждают эти концепции, правила ограничивают и поддерживают эти факты.
3.3. Правила должны быть ясными. Правило не всегда предполагает какую-либо концепцию или факта.
3.4. Правила являются базовыми для понимания бизнесом самого себя - то есть, основным бизнес-знанием.
3.5. Правила должны быть развитыми, защищенными и управляемыми.
Статья 4. Декларативные, не процедурные
4.1. Правила должны выражаться в описательных предложениях на естественном языке деловой аудитории.
4.2. Если что-либо не может быть выражено, то это не правило.
4.3. А набор высказываний декларативный, только если набор не поразумевает последовательность.
4.4. Любые утверждения о том, что правила требуют других конструкций, помимо терминов и фактов, означают предположения о внедрении системы.
4.5. А правило не зависит от каких-либо воздействий, определенных для него. Правило и его воздействие - отдельные проблемы.
4.6. Правила должны определяться независимо от ответственности за то "кто", "где", "когда" и "как" их выполняет.
4.7. Исключения из правил выражаются другими правилами.
Статья 5. Правильно-сформированные выражение, не специальные
5.1. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены на корректность деловыми людьми.
5.2. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены в отношении логичность друг к другу.
5.3. Формальная логика, например, логика предикатов, имеет основополагающее значение для правильно-сформированных выражений правил в терминах бизнеса, также как и технологий, обеспечивающих реализацию бизнес-правил.
Статья 6. Архитектура основанная на правилах, не косвенная реализация
6.1. Приложения бизнес-правил намеренно построена с учетом непрерывных изменений в бизнес правилах. Платформа, на которой запускается приложение должна поддерживать такие непрерывные изменения.
6.2. Непосредственно выполнение правил - например, в машинах в правил - лучше реализации стратегии переписывания правил в различные процедурные формы.
6.3. Система бизнес-правил должна всегда быть в состоянии объяснить рассуждения, с помощью которого она приходит к заключения или принимает решения.
6.4. Правила основаны на значениях истинности. Определение или поддержка значение истинности скрыто от пользователей.
6.5. Отношения между событиями и правилами, обычно, как многие-ко многим.
Статья 7. Процессы ведомые правилами, а не программирование основанное на исключениях
7.1. Правила определяют границу между приемлемой и неприемлемой деловой деятельностью.
7.2. Правила часто требуют особой или выборочной обработки обнаруженных нарушений. Такие правила нарушения деятельности есть деятельность, такая же как и любая другая.
7.3. Для обеспечения максимальной согласованности и повторного использования, обработки неприемлемой деловой деятельности должна быть неотделима от обработки с приемлемой деловой деятельности.
Статья 8. Во имя бизнеса, а не технологии
8.1. Правила касаются бизнес практики и руководства; поэтому, правила диктуются бизнес-целями и задачами, и формируется под влиянием различных воздействий.
8.2. Правила всегда стоят что-то бизнесу.
8.3. Стоимость исполнения правила должна быть сбалансирована с бизнес-рисками, и в отношении упущенных коммерческих возможностей.
8.4. Обычно меньшее количество "хороших правил" лучше чем "больше правил" вообще.
8.5. Эффективная система может основываться на небольшом количестве правил. В дополнение, большеинство специфический правил можно добавить потом, так что со временем система будет становиться умнее.
Статья 9. От бизенса, к бизнесу, и для людей бизнеса, не для людей ИТ
9.1. Правила должны возникать от знающих людей бизнеса.
9.2. Люди бизнеса должны иметь инструменты, помогающие им формулировать, утверждать и управлять правилами.
9.3. Люди бизнеса должны иметь инструменты, помогающие им проверять логичность бизнес-правил по отношению друг-к-другу.
Статья 10. Управление бизнес-логикой, а не аппаратно-программной платформой
10.1. Бизнес-правила являются жизненно важных бизнес-активом.
10.2. В долгосрочной перспективе, правила являются более важными для бизнеса, чем аппаратно-программные платформы.
10.3. Бизнес-правила должны быть организованы и храниться таким образом, чтобы их можно было легко перевести на новые аппаратно-программные платформы.
10.4. Правила, а также возможность эффективного изменения, имеют основополагающее значение для улучшения адаптивности бизнеса.
Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
Copyright, 2006. Business Rules Group.