Архитектурные принципы: интеграция

Интеграция, базирующаяся на стандартах
Формулировка	Интеграция между системами должна базироваться на стандартах (протоколы, форматы и т.п.)
Основная причина	Интеграция, базирующаяся на стандартах, улучшает интероперабельность (т.е. способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации) не только с существующими системами, но и с системами, которые будут внедрены в будущем. Это облегчает целостное управление и мониторинг, а также увеличивает стоимость поддержки и усложняет развитие интеграции между системами.
Следствия/выводы	·         Поддержка промышленных стандартов таких как SOAP, REST, JMS, MQ и т.п. ·         При разработке избегать подхода в интеграции «точка-точка», т.к. этот подход имеет тенденцию становиться негибким и более дорогом в поддержке и развитии. См. принцип «Избегать интеграции по принципу Точка-Точка»

Логическая модель данных
Формулировка	Сообщения и форматы данных должны базироваться на логической модели бизнес объектов вместо нативных структур данных конкретных приложений
Основная причина	Основная цель сервис-ориентированной интеграции – это способствовать созданию композитных приложений. Распространение форматов данных специфичных конкретным приложениям негативно влияют на возможность композиции.
Следствия/выводы	·         Архитектура должна предоставлять возможность создания и использования логической модели данных ·         Формат данных должен базироваться на логической модели бизнес-сущностей

Нормализованные форматы данных
Формулировка	Трансформация данных «из» и «в» нормализованные форматы данных.
Основная причина	Нормализованные форматы данных способствуют композиции и снижают количество трансформаций, которые должны быть созданы и поддерживаться.
Следствия/выводы	·         Если нормализованных форматов данных нет, то они должны быть созданы; ·         Архитектура должна предоставлять возможности по трансформации данных из одного формата в другой.

Избегать интеграции по принципу Точка-Точка
Формулировка	Интеграцию по принципу Точка-Точка следует избегать
Основная причина	Интеграция по принципу Точка-Точка негибкая и более дорогая в поддержке. Хотя существуют случаи, когда интеграция по принципу Точка-Точка необходима и такие случаи нужно считать исключениями. Пример исключений включает требования к производительности, которые могут быть достигнуты используя Точка-Точка и когда передаётся большой объём данных.
Следствия/выводы	·         Архитектура должна предоставлять средства для отделения (т.е. отсутствия жесткой связи) участников интеграция; ·         Архитектура должна предоставлять механизм для передачи большого объёма данных, когда это необходимо; ·         Следует избегать интеграции по принципу Точка-Точка.

Техническая оркестровка
Формулировка	Техническая оркестровка должна быть отделена от бизнес-процессов
Основная причина	Явное разделение между техническими и бизнес аспектами способствует улучшению поддержки и развития. Технические аспекты меняются, когда происходит изменение конкретной системы, а бизнес аспекты, когда меняется бизнес-процессы.
Следствия/выводы	·         Архитектура должна поддерживать оба вида процессов (техническая оркестровка и бизнес процессы) ·         В документации (руководства) должны быть описаны различия между технической оркестровкой и бизнес-процессами, а также возможные подходы к их реализации.

Выделение бизнес-сервисов
Формулировка	Бизнес-сервисы реализовывают бизнес уровень функциональности и данных
Основная причина	Бизнес уровень функциональности и данных необходим для создания ценных для бизнеса композитных приложениям, а также возможности реализации и поддержки бизнес-процессов подготовленными бизнес пользователями. Также могут быть низкоуровневые сервисы, которые переиспользуются в бизнес-сервисах.
Следствия/выводы	·         Сервисы должны быть созданы в соответствии с слоями архитектуры; ·         При разработке сервисов должно учитываться разделение сервисов на технические и бизнес; ·         Архитектура должны поддерживать бизнес-сервисы.

Доступ через сервисы
Формулировка	Доступ к данным или функциональности должен осуществляться через сервисы.
Основная причина	Сервисы предоставляют основу для гибкой композитной разработки.
Следствия/выводы	·         Архитектура должны предоставлять механизм для доступа к данным через сервисы; ·         Архитектура должна предоставлять механизм для доступа к функциональности через сервисы.

Непрозрачная реализация сервиса
Формулировка	Реализация сервиса не должна быть прозрачной для всех потребителей сервиса.
Основная причина	Потребители сервиса должны быть в состоянии успешно вызывать сервисы без необходимости понимания внутреннего устройства вызываемого сервиса.
Следствия/выводы	·         Интерфейс сервиса должен быть создан таким образом, чтобы детали реализации не были видны через интерфейс; ·         Архитектура должны поддерживать возможность непрозрачной реализации сервисов.

Версионность сервисов
Формулировка	Может быть одновременно несколько версий сервиса в промышленной эксплуатации.
Основная причина	Как правило, сервисы изменяются для подключения новых потребителей и расширения функциональности.
Следствия/выводы	·         Должна быть описана стратегия версионирования сервисов; ·         Архитектура должна поддерживать несколько параллельных версий сервиса.

Архитектурные принципы: инфраструктура

Внешний технологический мониторинг и управление
Формулировка	Функциональность технологического мониторинга и управления должна быть внешней и не встроенной в инфраструктурный компонент
Основная причина	Встроенная в инфраструктурный компонент функциональность технологического мониторинга и управления ухудшает гибкость, а также имеет ограниченные возможности (т.е. ограничена отдельным инфраструктурным компонентом)
Следствия/выводы	·         В сервисах не должны быть жестко закодированы правила и политики управления ·         Поддержка промышленных стандартов (например, SNMP)

Архитектурные принципы

  Архитектурные принципы представляют собой фундаментальные «аксиомы» (или правила), которые используются в качестве «отправных точек» для принятия архитектурных решений. В свою очередь, архитектурные принципы являются подмножеством более общего понятия ИТ-принципов, которые определяют основные аспекты всей деятельности, связанной с применением информационных технологий.

В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как «минимизация числа поставщиков программного обеспечения», может быть в дальнейшем конкретизирован в зависимости от особенностей компании, как требование «единой СУБД для всех критичных для бизнеса приложений» или же как «использование той же СУБД, что и уже применяемая».

Принципы являются взаимозависимыми и должны применяться целостно. Обычно число принципов для реализации решения не превышает 7-8 (а лучше 4-5), это необходимо, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые не приносят пользы на практике.

Использование принципов при работе над архитектурой доказало свою эффективность. В следующих постах будут приведены примеры архитектурных принципов, а в этой статье начнём с принципов безопасности:

Принцип наименьших полномочий
Формулировка	Пользователи и потребители ресурсов должны иметь минимальные полномочия необходимые для выполнения действий (работы).
Основная причина	Когда пользователю и потребителю ресурса предоставлены большие полномочия, чем требуется, то риски в части безопасности возрастают.
Следствия/выводы	Пользователям должен быть предоставлен доступ к функциям и данным на основе их ролей в системе; Должен предоставляться только минимально необходимый для выполнения функций доступ.

Также смотрите:

• инфраструктурные принципы
• интеграционные принципы
• принципы разработки и тестирования

Резервное копирование Skype-переписки для Windows

Давно задумывался об сохранении всей истории переписок в Skype при переустановке ОС или при переходе на новый ноутбук.
На этот счёт есть полезная статья на сайте поддержки Skype - Can I back up my chat history and transfer it from one computer to another?. Но выполнять данные действия вручную для меня не удобно, поэтому сделал скрипт позволяющий автоматизировать данный процесс и сохранять переписку в файловое хранилище (в моём случае Dropbox).
Нужно запустить cmd от Администратора:

REM Script creation
echo REM Article https://support.skype.com/en/faq/FA392/how-do-i-manage-my-conversation-history-in-skype-for-windows-desktop  > BackupSkype.cmd
echo title SkypeBackup  >> BackupSkype.cmd
echo SET SKYPE_ACCOUNT_NAME=stanislav.devyatov>>BackupSkype.cmd
echo SET SKYPE_BACKUP_FOLDER=C:\Users\Stanislav\Dropbox\Backup>>BackupSkype.cmd
echo SET ARCH_7ZIP_HOME="C:\Program Files (x86)\7-Zip">>BackupSkype.cmd
echo taskkill /f /IM skype.exe  >> BackupSkype.cmd
echo sleep 10 >> BackupSkype.cmd
REM Create new file
REM echo %7Zip_HOME%\7z.exe a %SKYPE_BACKUP_FOLDER%\skypeBackup_%date%.zip %appdata%\Skype\%SKYPE_ACCOUNT_NAME% -mx9>>BackupSkype.cmd
echo %ARCH_7ZIP_HOME%\7z.exe a %SKYPE_BACKUP_FOLDER%\skypeData.zip %appdata%\Skype\%SKYPE_ACCOUNT_NAME% -aoa>>BackupSkype.cmd
echo start skype >> BackupSkype.cmd

REM Copy script
move /Y BackupSkype.cmd %appdata%\Skype\

REM Create task
SchTasks /Create /F /SC DAILY /TN MySkypeBackup /TR %appdata%\Skype\BackupSkype.cmd /RL HIGHEST /ST 12:00

Требуется установить 7-Zip и изменить значение полей выделенных желтым.

Ошибка при создании домена по умолчанию в JDeveloper 12.2.1 на платформе Windows 10

Ошибка:

 wlst >   
 wlst > Initializing WebLogic Scripting Tool (WLST) ...  
 wlst >   
 wlst > Welcome to WebLogic Server Administration Scripting Shell  
 wlst >   
 wlst > Type help() for help on available commands  
 wlst >   
 wlst > Failed to get environment, environ will be empty: (0, u'Failed to execute command ([\'sh\', \'-c\', \'env\']): java.io.IOException: Cannot run program "sh": CreateProcess error=2, \u041D\u0435 \u0443\u0434\u0430\u0435\u0442\u0441\u044F \u043D\u0430\u0439\u0442\u0438 \u0443\u043A\u0430\u0437\u0430\u043D\u043D\u044B\u0439 \u0444\u0430\u0439\u043B')  
 wlst > Error: ADRS_DOMAIN_PASSWORD environment variable not set.  
 wlst >   
 wlst >   
 wlst > Exiting WebLogic Scripting Tool.  
 wlst >   

Варианты решения:
1. Изменить архиве
%JDEVELOPER_HOME%/wlserver/common/wlst/modules/jython-modules.jar следующий файл \Lib\javashell.py (добавленное выделено красным):

   ...
   os = str(os or sys.registry.getProperty( "python.os" ) or \  
         System.getProperty( "os.name" ))  
   _osTypeMap = (  
     ( "nt", ( 'nt', 'Windows NT', 'Windows NT 4.0', 'WindowsNT',  
          'Windows 2000', 'Windows 2003', 'Windows XP', 'Windows CE',  
          'Windows Vista', 'Windows Server 2008', 'Windows 7', 'Windows 8',   
          'Windows 10', 'Windows Server 2012' )),  
     ( "dos", ( 'dos', 'Windows 95', 'Windows 98', 'Windows ME' )),  
     ( "mac", ( 'mac', 'MacOS', 'Darwin' )),  
     ( "None", ( 'None', )),  
     )
   ...  

2. Открыть сервисный запрос (SR) в поддержку и получить официальный патч.