Технически аспекти на разработката

Технически аспекти на разработката

Заложените в модела изисквания към порталната среда следва да са съобразени със следните минимални технически изисквания:

• 
  да поддържа и позволява разработка и изпълнение на портални компоненти (портлети) съгласно спецификациите JSR-168, JSR-268, WSRP 1.0 и WSRP 2.0;
  
• 
  да предлага механизъм за публикуване на функционалност на база портлети, предоставяна от приложения, разработени върху Java Server Faces. Механизмът да е съвместим с JSF Portlet Bridge (JSR-301 и JSR-329) спецификацията;
  
• 
  да предлага базова рамка за разработка на портлети, базирана на Model-View-Controller принципа като свързването (binding) на модела с останалите слоеве да става декларативно. Механизмът на свързване да е съвместим с JSR-227 спецификацията;
  
• 
  да предлага готов набор от портлети за интеграция с външни портални, уеб базирани приложения и уеб сайтове. За статично съдържание интеграция следва да се извършва посредством „изрязване” на сегменти от изходния HTML код, които по време на изпълнение се вграждат в портала;
  
• 
  в случаите на защитени отдалечени ресурси механизма на „изрязване” да предлага начин за предаване на информация за автентикация, както и да осъществява връзка по криптиран канал (HTTPs);
  
• 
  да предлага готов набор от портлети за директно извличане и визуализация на данни, намиращи се в XML файлове, CSV файлове и таблици, web services, релационни структури от СУБД, RSS и др.;
  
• 
  да предлага механизъм за създаване и използване на портални компоненти от тип Pagelet, съвместими с различни платформи – Java, .NET и др. Наличието на компоненти от тип pagelet ще даде възможност ЕПДЕАУ и прилежащите портални приложения да се интегрират с различни уеб сайтове и портали;
  
• 
  за целите на подобрен и усъвършенстван жизнен цикъл на порталните приложения порталната рамка следва да предлага механизъм за създаване и редакция на страници и компоненти, комбиниращи информация от различни източници – т.нар. mashups – по време на изпълнение (run time), т.е. без необходимост от намеса на разработчици и преинсталация на приложенията;
  
• 
  описаната по-горе възможност следва да се добавя като компонент декларативно при изграждане на приложението и следва да предоставя следната функционалност като минимум:
  
  • 
    управление, настройки и параметри на отделните портални страници;
    
  • 
    добавяне на съдържание/компоненти към порталните страници;
    
  • 
    управление, настройки и параметри на компонентите в порталните страници;
    
  • 
    свързване на компоненти с параметрите на порталните страници;
    
  • 
    управление на разположението (layout) на компонентите в рамките на порталните страници.
    
• 
  компонентът за редакция на портални страни по време на изпълнение (run time) трябва да може да се добавя към всеки портален компонент като в изходния код това става чрез библиотека от т.нар. tag-ове;
  
• 
  основна част от порталните приложения е работата със неструктурирана информация – съдържание. За целите на достъп, публикуване и редакция на съдържание в рамките на порталните приложения порталното решение следва да се интегрира с широк набор от системи за управление на съдържанието;
  
• 
  интеграцията трябва да се извършва декларативно и базирана на стандарта JCR-170. Това ще даде възможност на разработчиците бързо и ефективно да свързват различни области от порталните приложения със системи за управление на съдържание по еднакъв начин и при нужда да променят източниците на съдържание;
  
• 
  друг важен компонент е среда за търсене на информация. Предлаганата порталната среда следва да предлага унифициран и разширяем компонент за търсене и индексиране на информация, намираща се не само в порталните приложения, но и извън тях – в произволни хранилища. Разширяемостта ще гарантира възможност интеграция с неограничено множество от хранилища;
  
• 
  резултатите от заявките за търсене на крайните потребители следва да бъдат съобразени с техните права на достъп върху съответната информация;
  
• 
  за улесняване работата на експертите от страна на Възложителя при поддръжка и нужда от допълнително развитие предлаганата рамка следва да предоставя на потребителите достъп до каталог (ресурсен каталог) с всички портални ресурси (компоненти за разположение, портлети, pagelet-и, документи, източници на информация и др.). Достъпът до ресурсите следва да се съобрази с правата на потребители;
  
• 
  комбинацията от ресурсния каталог и компонента за редакция на портални страници и компоненти следва да интегрира в обща визуална среда/средство за поддръжка и развитие на порталната рамка, достъпна и налична като минимум за експертите от страна на Възложителя;
  

По отношение на информационната сигурност, управлението на потребители и роли и защита на порталните ресурси предлаганото портално решение следва да реализира следните минимални технически изисквания:

• 
  налагането/залагането на политики за управление достъпа до портални ресурси да се базира на декларативен подход, съвместим със стандарта JAAS (Java Authentication and Authorization Service), а не на програмен подход, който предполага кодиране на правилата в изходния код на порталните компоненти;
  
• 
  порталното решение трябва да предлага среда за дефиниране на политики за достъп на ниво портално приложение, йерархия от портални страници, части от йерархии, навигационни компоненти и отделни страници;
  
• 
  при интеграцията на порталните решения с наличните back-end услуги и модули, налични в КТЦЕП (ел. поща, системи за управление на съдържанието и др.) предлаганото решение трябва да поддържа механизъм за предаване (propagation) на удостоверенията за идентичност (credentials) на крайните потребители;
  
• 
  в случая на интеграция чрез уеб услуги (web services) предаването (propagation) на удостоверенията за идентичност (credentials) на крайните потребители трябва да е съвместимо със стандарта WS-Security;
  
• 
  предвид необходимостта от интеграция на ЕПДЕАУ, предлаганото портално решение следва да се интегрира с наличните KTЦЕП директорийни (LDAP) услуги;
  
• 
  като минимум решението следва да поддържа следните директорийни сървъри за съхранение на идентичностите на крайните потребители:
  
  • 
    Microsoft Active Directory;
    
  • 
    Novell eDirectory;
    
  • 
    OpenLDAP;
    
  • 
    Oracle (SUN) Java System Directory Server;
    
  • 
    Oracle Unified Directory;
    
  • 
    IBM Tivoli.
    
• 
  при интеграцията на приложните роли и групи потребители трябва да се извършва свързване с, а не пренасяне на роли и групи потребители от наличните в КТЦЕП директорийни услуги;
  
• 
  за улесняване на интеграцията предлаганото портално решение трябва да предлага готов модул с уеб базиран потребителски интерфейс за дефиниране на роли, свързване на ролите с тези, описани в директорийната услугата и управление на потребители;
  
• 
  за улесняване процеса по защита на порталните ресурси предлаганото портално решение трябва да предлага готов модул за задаване на политики за достъп на ниво портално приложение, йерархия от портални страници, части от йерархии, навигационни компоненти и отделни страници;
  
• 
  предвид интеграцията с външни системи и портали чрез портлети и pagelet-и, предлаганото решение трябва да предлага механизъм за Single Sign-On;
  
• 
  в случаите, когато външното приложение поддържа собствено хранилище с потребители и удостоверения за идентичност (credentials) за потребителите, предлаганото решение следва да предоставя потребителски интерфейс за свързване (mapping) на двете удостоверения – тези, с които се автентицира пред портала и тези, с които се автентицира пред външната система, портал и др.
  

Предвид разширените нужди от споделяне и публикуване на информация от различни потребители към целевите групи на ЕПДЕАУ, съвместната работа на различни експертни групи от страна на Възложителя, предлаганото портално решение следва да предлага като минимум следните, готови за интеграция в портала, модули:

• 
  граф на активностите – създава предпоставки за формиране на социални мрежи, относно и/или фокусирани върху проблемите, свързани с ЕП. Като функционалност модулът следва да събира информация за всички действия на потребителите в портала и след анализ да идентифицира и предлага свързване между потребителите;
  
• 
  среда за анализ ползваемостта на порталното приложение – предназначена за бизнес потребители, тя следва да предлага широк набор от интуитивни справки и отчети за ползваемостта и достъпа на крайните потребители до порталните компоненти;
  
• 
  обявления – средство за публикуване на кратки съобщения до потребителите на портала;
  
• 
  уеб журнал (weBLOG) – среда за публикуване на съдържание от даден потребител, относно дадена тема (blog);
  
• 
  дискусии – среда за събиране на мнение по определени въпроси и теми от по-широк кръг потребители. Тук комуникацията от тип форум (forum) като всяко изказване на потребител се регистрира в системата към повдигната тема; информационни връзки – за целите на оптимално индексиране на информацията в портала, предлаганото решение трябва да предоставя механизъм на крайните потребители да реализират логически връзки между порталните компоненти (документи, записи в уеб журнала, дискусии във форум и др.);
  
• 
  електронна поща – интеграция със сървър за електронна поща, посредством протоколите IMAP, SMTP. Чрез този модул крайните потребители ще могат да четат и изпращат съобщения (с прикачени файлове) директно от порталната среда;
  
• 
  известяване – за улесняване крайната работа на потребителите трябва да се реализира функционалност, чрез която те да се „абонират” за определен източник на информация. При наличие на ново съдържание модулът следва да извести конкретния потребител;
  
• 
  анкетни карти – за събиране на информация за обратна връзка ЕПДЕАУ да реализира средство за дефинира и публикуване на анкетни карти. По отношение на управлението порталната среда трябва да предоставя на администраторите подмодул за дефиниране на анкетните карти и преглед на резултатите;
  
• 
  етикети - за целите на оптимално индексиране на информацията в портала, предлаганото решение трябва да предоставя механизъм на крайните потребители да маркират съдържание, документи, публикации и др. С етикети. На база етикетите, порталът трябва да изгради общ индекс на етикетите, който може да се ползва като алтернативен механизъм за търсене;
  
• 
  съвместни публикации – официални материали и публикации, свързани с ЕП трябва да се формират от вътрешни експертни групи. ЕПДЕАУ следва да предлага среда за подобен род съвместна работа, където повече от един потребител работят върху документ, статия, наредба, публикация, инструкция и т.н.;
  
• 
  персонални/екипни задачи – среда за дефиниране/задаване на и изпълнение на задачи. В личното виртуално пространство от портала всеки потребител следва да получи достъп до онази част/стъпки от бизнес процесите, които касаят него персонално или ролята му в организацията като цяло. По-важните моменти тук са възможностите за ескалация, делегиране (reassignment), приоритизация и др. Всички задачи, които конкретен потребител трябва да извърши, следва да са достъпни през портала като се предоставя потребителски интерфейс за взаимодействие и участие в задачата/процеса.
  
• 
  интеграцията на описаните по-горе модули в рамките на общото предложение трябва да се извършва чрез:
  
  • 
    набор от портлети на ниво потребителски интерфейс;
    
  • 
    REST (REpresentational State Transfer) извикване на функционалност – порталното решение трябва да предлага набор от REST програмни интерфейси за работа с модулите, описани по-горе;
    
  • 
    уеб услуги (web services) на ниво пренос на данни и информация.
    
• 
  от друга страна въпросните модули следва да са достъпни като минимум на администраторите на портала през ресурсния каталог.
  

• 
  порталната среда следа да е достъпна през стандартни уеб браузъри, работещи на различни устройства (работни станции, преносими компютри, киоски и др.);
  
• 
  за работа с работните пространства за съвместна работа следва да се предложат мобилни приложения, които ще дадат възможност на вътрешните потребители да работят отдалечени през мобилните си телефони.
  

Предвид организацията на работа на Възложителя при осигуряването на системите от ЕП, порталната рамка трябва да предоставя функционалност за управление на виртуални работни пространства за съвместна работа. Целта е различните експертни групи, екипи и т.н. да формират отделни портални пространства, в които споделят:

• 
  Задачи/активности;
  
• 
  Разпределение на задачите или общ календар;
  
• 
  Документи;
  
• 
  Публикации;
  
• 
  Коментари;
  
• 
  Събития;
  
• 
  Форум;
  
• 
  И др.
  

За успеха на ЕПДЕАУ и коректното му развитие в бъдеще порталната среда трябва да предлага механизъм за анализ на трафика от бизнес гледна точка. Анализът трябва да се осъществява като набор от справки. Решението трябва да предлага като минимум следните справки:

• 
  На ниво портално приложение:
  
  • 
    Общ трафик;
    
  • 
    Трафик по страници;
    
  • 
    Метрики по автентикация (logins);
    
• 
  На ниво виртуално работно пространство:
  
  • 
    Общ трафик;
    
  • 
    Време за отговор;
    
  • 
    На ниво портлет:
    
• 
  Общ трафик;
  
  • 
    Трафик към инстанция на портлет;
    
  • 
    Общо време за отговор/обработка;
    
  • 
    Време за отговор/обработка на инстанция на портлет.
    

Заложените в модела изисквания към сервизната шина следва да са съобразени със следните минимални технически изисквания:

• 
  да поддържа свързаност към разнородни системи посредством транспортните протоколи JMS (вкл. MQ чрез JMS, и JMS/XA), EJB/RMI, RMI/IIOP, JEJB, JCA, JDBC, XML/HTTP REST, Generic XML/HTTP, HTTP(S), (S)FTP, Email (POP/SMTP/IMAP), File, AQ, MQ (WebSphere MQ), TCP/IP Sockets, Tuxedo, WSRM (Web Services Reliable Messaging), както и да предоставя възможност за създаване на собствени транспортни протоколи;
  
• 
  да поддържа интеграция на услуги от хетерогенни системи описани чрез WSDL интерфейс, както и на такива, които не са описани чрез WSDL;
  
• 
  да поддържа следните типове съобщения: SOAP, XML, JMS, MFL, Text, E-mail, Raw Data;
  
• 
  да предоставя възможност за ползване на услугата от система-клиент чрез интерфейс различен от този на системата-доставчик на услугата;
  
• 
  да предоставя възможност за ползване на услуга от система-клиент като уеб услуга (Web Service), дори и системата-доставчик да няма възможност да я предостави като уеб услуга (Web Service);
  
• 
  да предоставя възможност за смяна в реално време на интерфейса и протокола за ползване на услугата от система-клиент, без това да налага смяна на интерфейса и протокола на системата-доставчик на услугата;
  
• 
  да позволява синхронно и асинхронно извикване на услуги;
  
• 
  да поддържа динамично маршрутизиране на всякакви SOAP и XML съобщения, базирано на съдържание;
  
• 
  да предоставя възможност за организиране на съобщенията в работен поток (Message Flow) и неговото контролиране;
  
• 
  да предоставя възможност за динамично публикуване на съобщения;
  
• 
  да предоставя възможност за обогатяване и трансформиране на съобщението (Message Enrichment и Message Transformation);
  
• 
  да предоставя възможност за валидиране на съобщението срещу дадена XSD схема;
  
• 
  да предоставя механизъм за устойчивост и приоритизация на съобщенията;
  
• 
  да предоставя възможност за прихващане и обработка на грешки;
  
• 
  да поддържа извикване/публикуване на дефиниции на услуги от/на UDDI регистър;
  
• 
  да предоставя възможност за импортиране и експортиране на ресурси, без да се нарушава тяхната зависимост;
  
• 
  да предоставя механизъм за кеширане на резултати (Result Caching);
  
• 
  да предоставя възможност за определяне на политики за сигурност на услугите и ресурсите;
  
• 
  да предоставя вградена уеб-базирана конзола за конфигуриране на услугите и ресурсите в реално време.
  

Заложените в модела изисквания към сървъра за управление на процеси следва да са съобразени със следните минимални технически изисквания:

• 
  да предоставя възможност за оркестриране и автоматизиране на разнородни услуги (services) в „end-to-end” бизнес процеси;
  
• 
  бизнес процесите да могат да се представят като уеб услуги (Web Service) с възможност за стартиране/взаимодействие с външни системи;;
  
• 
  да поддържа стандарта BPEL версия 1.1 и 2.0;
  
• 
  да поддържа дехидратация „dehydration” механизъм за устойчивост – запазване и възстановяване на състоянието на дълготрайни процеси;
  
• 
  да поддържа процеси с дистрибутирани транзакции и да предоставя възможност за компенсиране на логиката при “rollback”;
  
• 
  да предоставя възможност за засичане и управление на „timeouts” паузи/прекъсвания на определена стъпка от процеса;
  
• 
  да поддържа версиониране, ревизия (audit trail) и управление на промените на процесите;
  
• 
  да поддържа изпълнение на синхронни и асинхронни процеси;
  
• 
  да поддържа изпълнение на паралелни процеси;
  
• 
  да предоставя механизъм за приоритизиране на процеси;
  
• 
  да предоставя механизъм за управление на процесо-потока (process flow control);
  
• 
  да предоставя механизъм за автоматизирана двупосочна интеграция със системи поддържащи абстрактно описание на модела на бизнес процеси чрез стандарта BPMN чрез механизъм за автоматично генериране на BPEL код от BPMN модел и обратно, автоматично генериране на BPMN модел от BPEL код;
  
• 
  да предоставя механизъм за обработка на грешки и изключения при изпълнение на процесите;
  
• 
  да предоставя механизъм за автоматично известяване през различни канали: e-mail, JMS, SMS, Instant Messaging, Voice, Phone;
  
• 
  да предоставя механизъм за задаване на сензори и бизнес индикатори (KPI) на определени стъпки от процеса за събиране на бизнес метрики, с цел предоставянето им в реално време на система за бизнес наблюдение и анализ;
  
• 
  да предоставя вградено и готово за работа web-базирано приложение с визуални табла (dashboards) за наблюдение и анализи в реално време на изпълнението на бизнес процесите и тяхната производителност - Business Activity Monitoring;
  
• 
  да предоставя вграден механизъм за автоматизирана интеграция на хора и ръчни задачи (човеко-задачи – Human Task) в процесите – Human Workflow;
  
• 
  човеко-задачите (Human Task) да могат да се представят като уеб услуга (Web Service);
  
• 
  да предоставя вграден механизъм за управление на автоматизираните човеко-задачи чрез асоциирането им с потребител/група/роля, делегиране на права, ескалиране на приоритети, дефиниране на срокове за изпълнение на задачите;
  
• 
  да предоставя вграден механизъм за автоматично известяване за стартиране, състояние, срокове и изпълнение на задачите на съответните асоциирани участници;
  
• 
  да предоставя вградено и готово за работа web-базирано потребителско приложение за изпълнение на процеси и задачи от оторизирани/асоцирани потребители;
  
• 
  да предоставя вграден механизъм за създаване/дефиниране/интегриране на бизнес правила (Business Rules);
  
• 
  бизнес правилата да могат да се представят като уеб услуги (Web Service);
  
• 
  да предоставя механизъм за представяне на бизнес правилата чрез таблици за решения (Decision Tables);
  
• 
  да предоставя механизъм за валидиране, верифициране и разрешаване на конфликти на бизнес правилата;
  
• 
  бизнес правилата да могат да определят автоматично хода на процеса и възлагането на човеко-задачи;
  
• 
  горе-изброените компоненти – бизнес процеси, човеко-задачи и бизнес правила – да могат да се асемблират в композитна единица, базирана на стандарта SCA (Service Component Architecture), която да може да се представи като Web Service;
  
• 
  да предоставя графична визуална среда за лесно (без програмиране) проектиране и внедряване на бизнес процеси, човеко-задачи, бизнес правила и композитни единици;
  
• 
  да поддържа двупосочна интеграция с регистър съобразен със стандарта UDDI V3.
  

• 
  да предоставя графична визуална среда за моделиране и описание на бизнес процеси и модели;
  
• 
  да предоставя механизъм за анализи и симулация на изпълнението на бизнес процеси;
  
• 
  да предоставя механизъм за автоматизирано двупосочно конвертиране на BPMN-базирани модели в BPEL-базирани дефиниции на процеси;
  
• 
  да предоставя хранилище за бизнес моделите и техните метаданни;
  
• 
  да поддържа контрол на версиите и промените;
  
• 
  да предоставя вградено и готово за работа уеб базирано приложение за достъп до информация за бизнес модели (описание, доклади от анализи и т.н.).
  

• 
  да предоставя среда и механизми за обработка и управление на потоци от комплексни събития в реално време – Complex Event Processing;
  
• 
  да поддържа стандартите CQL (Continuous Query Language) и ANSI SQL;
  
• 
  да предоставя среда и механизми за разработка и развой на приложения, задвижвани от събития - Event Driven Applications;
  
• 
  да поддържа двупосочна интеграция с BPEL-базирани бизнес процеси и системи за наблюдение на бизнес процеси;
  
• 
  ядрото да е преносимо и да може да се разгърне в/у приложен сървър, както и да позволява резервиране и репликация.
  

• 
  системата да бъде преносима, поддържана и изпълнима в/у водещите платформи и операционни системи (вкл. UNIX, Linux и Windows);
  
• 
  всичките компоненти на системата да могат да се разгърнат и стартират в/у единен приложен сървър/клъстер;
  
• 
  системата да поддържа софтуерно клъстериране с load balancing и fault tolerance, както и възможност за автоматичен fail-over;
  
• 
  системата да позволява възможност клъстерирани и неклъстерирани инстанции да работят едновременно;
  
• 
  системата да е скалируема – да предоставя възможност за увеличаване/намаляване на клъстерния капацитет, както и добавяне/премахване на сървъри и машини в реално време;
  
• 
  системата да поддържа автоматична миграция – преместване и стартиране на друга машина на системни инстанции и компоненти в реално време;
  
• 
  системата да предоставя вграден механизъм за равномерно разпределение и резервираност на връзки към СУБД – при отпадане на установен възел към дадена СУБД, автоматично да се установи връзка към друг зададен такъв и това да е прозрачно за клиента;
  
• 
  системата да предоставя възможност да бъде управлявана и наблюдавана от единна централизирана точка.
  

Заложените в модела изисквания към регистратурата на услуги и процеси следва да са съобразени със следните минимални технически изисквания:

• 
  да предоставя механизъм за динамично публикуване, откриване и адресиране на web-базирани услуги;
  
• 
  да е съобразена с и да поддържа стандарта UDDI V3;
  
• 
  да позволява автоматична интроспекция на BPEL, WSDL и XSD дефиниции;
  
• 
  да предоставя механизъм за управление на промените и контрол на версиите;
  
• 
  да предоставя вградено и готово за работа уеб базирано приложение, позволяващо на оторизирани потребители да администрират и работят с регистратурата;
  
• 
  да предоставя механизъм за управление на таксономиите (класифицирани правила);
  
• 
  да предоставя механизъм за определяне на политики за сигурност върху регистрираните компоненти;
  
• 
  ядрото на регистратурата да е преносимо, да може да се разгърне върху приложен сървър, както и да позволява резервиране и репликация.