Oracle SOA: управление композитами через WLST

Все команды выполняются из wlst.cmd или wlst.sh находящегося в SOA_HOME, у меня например это:

 C:\Apps\Oracle\Weblogic\10.3.6\Oracle_SOA1\common\bin\wlst.cmd  

• Просмотр развёрнутых композитов и их статусов:

  wls:/offline> 
   sca_listDeployedComposites('bpm-dev.mycompany.com',
                              '8001',
                              'weblogic',
                              'welcome1') 
  

  где weblogic - логин административного пользователя;
  welcome1 - пароль административного пользователя;
  bpm-dev.mycompany.com - хост SOA-сервера;
  8001 - порт SOA-сервера.
  
  Пример результата:

   Following 4 composites are currently deployed to the platform:  
   1. AsyncProc[1.0], partition=default, mode=active, state=on, isDefault=true, deployedTime=2013-07-25T11:26:03.309+04:00  
   2. SimpleApproval[1.0], partition=default, mode=active, state=on, isDefault=true, deployedTime=2012-10-17T18:55:11.333+04:00  
   3. SimpleHT[1.0], partition=default, mode=active, state=on, isDefault=true, deployedTime=2012-12-21T13:23:24.345+04:00  
   4. AgreementApproversService[1.0], partition=prod, mode=active, state=on, isDefault=true, deployedTime=2013-02-22T17:51:30.971+04:00  
  

• Старт композита:

  wls:/offline> 
   sca_startComposite('bpm-dev.mycompany.com',
                      '8001',
                      'weblogic',
                      'welcome1',
                      'AsyncProc',
                      '1.0',
                      partition='default') 
  

  где AsyncProc - имя композита;
  1.0 - версия композита;
  default - раздел.
  
  
• Стоп композита:

  wls:/offline> 
   sca_stopComposite('bpm-dev.mycompany.com',
                     '8001',
                     'weblogic',
                     'welcome1',
                     'AsyncProc',
                     '1.0',
                     partition='default') 
  

• Активация композита:

  wls:/offline> 
   sca_activateComposite('bpm-dev.mycompany.com',
                         '8001',
                         'weblogic',
                         'welcome1',
                         'AsyncProc',
                         '1.0',
                         partition='default') 
  

• Деактивация композита:

  wls:/offline> 
   sca_retireComposite('bpm-dev.mycompany.com',
                       '8001',
                       'weblogic',
                       'welcome1',
                       'AsyncProc',
                       '1.0',
                       partition='default') 
  

Формат полей типа Date в Oracle SQL Developer

Проблема:
При выборке и экспорте (в формате insert) данных формат колонки типа Date:

 15-NOV-11  

Вариант решения:

1. В SQL Developer перейти в меню "Tools"->"Preferences"
2. В окне Preferences выбрать "Database"->"NLS" в левой панеле
3. В списке NLS параметров найти "Date Format" и для него ввести следующее значение

   DD-MM-YYYY HH24:MI:SS

   
4. Нажать "OK" и пользоваться.

Кратко о архитектурной модели "4+1"

Достаточно важную роль в развитии подходов к описанию архитектуры предприятия сыграла модель "4+1" (точнее "The 4+1 View Model of Architecture"), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational еще в 1995 году. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.

Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных категорий или представлений (views). Четырьмя основными представлениями в этой методике являются следующие:

• Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
• Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
• Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
• Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.

Описание архитектуры системы на основе этих четырех представлений иллюстрируется и проходит проверку путем использования еще одного представления, которое содержит некоторые отобранные сценарии использования (use cases). Архитектура системы во многом определяется этими сценариями. Каждое представление отражает специфические аспекты моделируемой системы.

Основной целью логического представления в данной методике является описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.

Процессное представление учитывает некоторые нефункциональные требования (NFR) к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.

Представление уровня разработки описывает фактическую организацию модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.

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

Сценарии объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:

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

Ссылки для более подробного изучения данной модели здесь.

Источник: http://www.intuit.ru/department/itmngt/entarc/9/entarc_9.html

Oracle SOA Poster-BPEL Process 2.0

Коллеги из EAIESB опубликовали BPEL 2.0 Poster (оригинал здесь):

Кратко о методике RM-ODP

Архитектурная методика RM-ODP (Reference Model of Open Distributed Processing), на которую также ссылаются как на ISO/IEC 10746, была принята международной организацией стандартизации ISO в качестве стандартов в четырех частях X.901, X.902, X.903 и X.904.

В основе этой модели лежат принципы анализа систем в разрезе нескольких представлений и объектно-ориентированная парадигма создания систем. Заметим, что это методика – одна из наиболее полных с точки зрения набора различных представлений, которые могут применяться для описания архитектуры системы, и она используется, в частности, при описании архитектуры электронного правительства Германии.

Важными для этой модели понятиями являются представления, функции и средства обеспечения прозрачности распространения (distribution transparencies).

В целом модель определяет пять представлений (viewpoints):

• Корпоративное представление (enterprise viewpoint) описывает цели, масштабы (границы), процессы и политики, связанные с созданием прикладных систем.
• Информационное представление (information viewpoint) описывает характеристики и семантику обрабатываемых данных, т.е. модель данных.
• Вычислительное представление (computational viewpoint) описывает декомпозицию прикладной системы на функциональные модули и интерфейсы взаимодействия.
• Проектировочное представление (engineering viewpoint) определяет распределение отдельных элементов системы по физическим ресурсам и связи между ними.
• Технологическое представление (technology viewpoint) описывает технологии, используемые для создания прикладных систем.

Кроме представлений, RM-ODP содержит так называемые функции.

Всего выделено четыре функции:

• управление;
• координация; 
• репозиторий;
• безопасность.

Функция безопасности описывает вопросы управления безопасностью в системе, а также методы авторизации доступа, обеспечения целостности, аудита, управления правами доступа.

Функция управления определяет то, как системой управляют, начиная с уровня узлов (серверов) и вплоть до объектов, выполняемых на этих узлах.

Функция координации детализирует вопросы взаимосвязи событий в системе.

Функция репозитория описывает, как информация организована и хранится.

RM-ODP выделяет восемь так называемых средств обеспечения прозрачности распространения: прозрачность доступа, сбоев, местоположения, миграции, сохранения, перераспределения, репликации и транзакций.

Ссылки для более подробного изучения данной методике здесь.

Источник: http://www.intuit.ru/department/itmngt/entarc/9/entarc_9.html