SOA I POSLOVNA PRAVILA

SAŽETAK

Iako je IT tehnologija uvijek bila (ili trebala biti) vezana uz poslovnu tehnologiju koju podržava, SOA još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Poslovni procesi (Business Processes, BP) su zato (uz pojam servis) jedan od fundamentalnih pojmova u SOA arhitekturi. Poslovni procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese. U spoju SOA arhitekture i poslovnih pravila, stroj za poslovna pravila (rules engine) postaje odvojena komponenta (odvojeni servis) koji izvršava neka poslovna pravila - ona koja su zajednička za više procesa, a neka poslovna pravila – ona koja su vezana samo za jedan proces, izvodi sam proces.

ABSTRACT

Although the IT technology has always been (or should be) related to business technology that supports, SOA further emphasizes the connection between business processes and IT applications that supports them. Business Processes (BP) are therefore (beside the term of service) one of the fundamental terms in SOA architecture. Business processes are carried out with the satisfaction of certain business rules (BR), some of which are closely tied to a particular business process, while other can be applied to different business processes. In combination of SOA architecture and business rules, business rules engine (rules engine) becomes a separate component (separate service) that executes some business rules - those that are common to several processes. Some business rules - those that are related only to one process, runs the process itself.

1. Uvod

IT industrija je oduvijek tražila način kako da poveća produktivnost i smanji rizik kod izrade softvera. Od samih početaka su se rješenja tražila u drugim, starijim i razvijenijim industrijama / inženjerskim područjima, kod kojih se izrada novih proizvoda temelji na već izrađenim komponentama (dijelovima, poluproizvodima). Softversko inženjerstvo je prošlo put od špageti programiranja, preko strukturiranog programiranja, modularnog programiranja, objektnog programiranja i dr. Može se reći da SOA arhitektura (Service-Oriented Architecture, servisno-orijentirana arhitektura) nije nikakvo revolucionarno rješenje, već je nastavak tog puta (napomena: izraz "SOA arhitektura" je redundantan, dovoljno bi bilo reći samo SOA, ali čini nam se da je pogodniji za uporabu od same skraćenice). Kako organizacije mogu uvoditi nove mogućnosti u svoje IT aplikacije? Jedan način je pokušaj zamjene starih rješenja s novima, tj. bacanje starih rješenja. Takav način ponekad ima svojih opravdanja, npr. ako su postojeća rješenja takva da ih je praktički nemoguće (ili neisplativo) mijenjati. No, bacanje starih rješenja je generalno riskantna i/ili skupa strategija. U većini slučajeva bolja je strategija - izrada novih funkcionalnosti i njihova integracija u postojeći sustav. Takav (evolucijski) pristup u pravilu smanjuje rizik i troškove. SOA arhitektura je okvir (framework) koji je danas prihvaćen u IT industriji za proširivanje postojećih aplikacija, ali i za izradu novih aplikacija. Iako je IT tehnologija uvijek bila (ili trebala biti) vezana uz poslovnu tehnologiju koju podržava, SOA arhitektura još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Poslovni procesi (Business Processes, BP) su zato (uz pojam servis) jedan od fundamentalnih pojmova u SOA arhitekturi. Poslovni procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese. U radu se prikazuju implementacije poslovnih pravila u SOA arhitekturi. U 2.točki se prikazuju poslovni procesi, tj. modeliranje / upravljanje poslovnim procesima. U 3.točki se daje kratki prikaz SOA arhitekture. U 4.točki se prikazuju poslovna pravila (neke definicije, klasifikacije, implementacije izvan SOA arhitekture). U 5.točki prikazuje se implementacije poslovnih pravila u SOA arhitekturi, pomoću alata Oracle SOA Suite.

2. Poslovni procesi

Postoje različite definicije pojma "poslovni proces", a jedna od njih je i ona navedena u [8]. Prema toj definiciji, poslovni proces je:

- skup aktivnosti i zadaća podržan resursima; - koje (aktivnosti) koriste različite vrste informacija (strukturirane i nestrukturirane); - nalaze se u međusobnim interakcijama (predviđenim i nepredviđenim); - upravljane su menadžerskim politikama i principima (poslovna pravila i kriteriji odlučivanja); - s ciljem da proizvedu izlaz koji je u skladu s finalnim rezultatom (strategije i ciljevi).

Dalje se u [8] navodi da procesi mogu biti sastavljeni od potprocesa, da proces može biti servis i da servis može biti proces, i da postoje dva tipa procesa – automatski (koje izvodi neki stroj) i neautomatski (temeljeni

na ljudskoj intervenciji). U [8] se radi striktna razlika između procesne logike (process logic) i logike odlučivanja (decision logic), gdje je procesna logika ona koja je usko vezana za određeni proces (čini njegov dio), a logika odlučivanja (koju čine menadžerske politike i principi) se ne odnosi na jedan proces, već se može primijeniti u više procesa i implementira se pomoću poslovnih pravila (business rules). U [7] se navodi da se aktivnosti vezane za dizajniranje i izvršavanje poslovnih procesa nazivaju upravljanje poslovnim procesima (Business Process Management, BPM). Često se skraćenica BPM koristi za izraz Business Process Modeling (modeliranje poslovnih procesa), a u [7] se kaže da ta dva izraza mogu značiti jedno te isto (no, moglo bi se reći i da je modeliranje poslovnih procesa samo podskup od upravljanja poslovnim procesima). U [7] se navode sljedeći najvažniji termini vezani za upravljanje poslovnim procesima:

- definicija procesa (process definition): osnovni algoritam ili ponašanje procesa; - instanca procesa (process instance): jedna pojava procesa za specifični ulaz; - aktivnost ili zadaća (activity or task): korak procesa; - automatska aktivnost / zadaća (automated activity / task): korak u procesu koji se direktno izvršava

pomoću nekog stroja (execution engine); - ručna (manual) aktivnost / zadaća: korak u procesu koji se izvršava uz pomoć čovjeka.

U [7] se naglašava da BPM nije podesan za sve aplikacije, već samo za one aplikacije koje su procesno orijentirane. Aplikacija je procesno orijentirana ako ima sljedeće karakteristike:

- aplikacija ima dugo trajuće (long-running) procese: od starta do cilja procesa prolaze sati, dani, pa čak i tjedni, mjeseci, ili još dulje vrijeme;

- procesi (aplikacije) posjeduju perzistenciju: budući da procesi dugo traju, njihovo se stanje pohranjuje u bazu podataka;

- procesi najveći dio vremena "spavaju": najveći dio vremena procesi provedu u neaktivnom stanju, čekajući na neki događaj koji će ih okinuti;

- orkestracija sistemske ili humane komunikacije: procesi su odgovorni za upravljanje i koordinaciju komunikacije između različitih sistemskih ili humanih aktora.

Treba naglasiti kako nije nužno da procesno orijentirana aplikacija ima sve ove karakteristike. Kao primjer aplikacije koja npr. ima kratkotrajne procese koji nikad ne spavaju, a ipak je podesna za BPM, [7] navodi Message Broker aplikaciju. Za razliku od toga, [7] navodi ATM aplikaciju (Automated Teller Machine, bankomat) kao nepodesnu za BPM. BPM je podržan različitim standardima, kako navodi [7] možda i sa previše njih. Najvažniji od tih standarda su sljedeći:

- Business Process Execution Language for Web Services (BPEL4WS, ili WS-BPEL, ili skraćeno samo BPEL), je BPM specifikacija koja je bila inicirana od strane velikih IT firmi (IBM, Microsoft, Oracle, BEA – BEA je danas u vlasništvu firme Oracle), a koju danas podržava neprofitna organizacija OASIS (Organization for the Advancement of Structured Information Standards); BPEL process je web servis sa pridruženom procesnom definicijom definiranom u XML-temeljenom jeziku BPEL; BPEL for Java (BPELJ) je BPEL ekstenzija koja omogućava da se Java kod ugradi u definiciju procesa;

- sličan standard je Business Process Modeling Language (BPML), koji je napravila organizacija Business Process Modeling Initiative (BPMI); ta je organizacija napravila i Business Process Modeling Notation (BPMN); za razliku od BPEL-a ili BPML-a, koje su XML notacije, BPMN je sofisticirana grafička notacija; njen daljnji razvoj preuzela je organizacija OMG (Object Management Group), koja danas vodi brigu i o standardima kao što su CORBA, UML i drugi; postoje mapiranja između BPMN (grafičke) i BPEL (XML) notacije, ali ta mapiranja nisu savršena - BPEL definicija koja se dobije automatskom pretvorbom (pomoću odgovarajućeg softverskog alata) iz BPMN dijagrama, često je praktički nečitljiva (za čovjeka);

- Web Services Choreography Description Language (WS-CDL) je standard organizacije World Wide Web Consortium (W3C); za razliku od procesne orkestracije, koja se odnosi na unutarnja zbivanja (unutar jednog procesa) i opisuje se pomoću jezika kao što je BPEL, koreografija opisuje zbivanja između više procesa, tj. web servisa.

Kako navodi [7], dobro BPM rješenje trebalo bi raditi sljedeće:

- modelirati (design) procese: pojednostavljeno rečeno, rezultat je dijagram toka koji prikazuje korake koji se izvršavaju za rješavanje određenog poslovnog problema; za razliku od najvećeg broja objektno-orijentiranih modela, koji prvenstveno služe IT timu, model procesa služi i poslovnim i tehničkim analitičarima;

- izvršavati (run) procese: na temelju modeliranog procesa, BPM rješenje trebalo bi omogućiti automatsko izvršavanje procesa, na taj način da se model mapira u izvršnu notaciju, koja se izvršava na stroju za izvršavanje (runtime engine);

- nadgledati i administrirati (monitor and administer) procese: nadgledanje procesa važno je zbog detekcije iznimaka i zbog mogućnosti postavljanja real-time upita na stanje procesa; administracija procesa obuhvaća real-time instaliranje novih procesa, izmjenu procesa, suspendiranje, ponovno pokretanje ili terminiranje procesa.

Slika 1. Komponente dobrog BPM dizajna; Izvor: [7] Slika 1. prikazuje kako bi trebalo izgledati "dobro" BPM rješenje po [7]. U centru rješenja je stroj za

izvršavanje (runtime engine), koji izvršava programe pisane u jeziku BPEL. No, poslovni i tehnički analitičari dizajniraju procese grafički, pomoću alata koji podržava BPMN. Taj alat uključuje dio koji pretvara (mapira) BPMN dijagrame u BPEL XML kod. Izvršavanje procesa vođeno je ljudskim i računalnim interakcijama. Postoje dva tipa računalnih interakcija: interne i eksterne. Interne interakcije temelje se na integracijskim tehnologijama kao što su web servisi, ali i na Java EE, COM ili drugim tehnologijama. Pritom se može, ali i ne mora koristiti XML kao format za razmjenu poruka. Eksterne interakcije su, tipično, temeljene na web servisima, vođene preko koreografije ili B2B suradnje. BPM sistem administratori koriste grafičku konzolu za monitoriranje i administraciju procesa. Stroj za izvršavanje koristi bazu podataka za realizaciju perzistencije.

Kako navodi [7], tri su teoretska izvora za BPM:

- pi-kalkulus (pi-calculus), kojega je izmislio škotski matematičar Robin Milner u 90-tim; to je algebarski sustav za izgradnju procesa koji međusobno komuniciraju preko kanala; pi-kalkulus procesi se pišu kao skupovi jednadžbi, koristeći specifičnu sintaksu; kada jedan proces šalje informaciju drugom, uključuje i ime kanala koji će se koristiti da drugi proces pošalje odgovor; to je ime varijabla, što znači da se kanal može dinamički mijenjati u ovisnosti od promjenjivih uvjeta – to se naziva mobilnošću;

- Petrijeve mreže (Petri net) je izmislio matematičar Carl Adam Petri u 60-tim; Petrijeva mreža je proces, čiji su glavni dijelovi lokacije (places), tranzicije (događaji koji upravljaju razvojem procesa), oznake (tokens) i lukovi (koji spajaju tranzicije s lokacijama); glavno pravilo klasičnih Petrijevih mreža je jednostavno: tranzicija se okida samo onda kada sve ulazne lokacije (koje vode do tranzicije) sadrže token, a nakon što se tranzicija okine, token se miče sa svake ulazne lokacije na svaku izlaznu lokaciju (lokaciju do koje vodi luk koji izlazi iz tranzicije);

- stroj (konačnih) stanja, ili stroj sa (konačnim) stanjima ((finite) state machine) ima bogatu povijest, u razvoju su sudjelovali i Turing, Moore, Mealy, Harel (zadnji je zaslužan za UML dijagram stanja); za razliku od dijagrama toka procesa, dijagram stanja je čišći i kompaktniji način prikaza procesa, jer je deklarativan, a dijagram toka je proceduralan; zanimljivo je da je UML dijagram akcija mješavina dijagrama toka procesa i dijagrama stanja; smatra se da je stroj stanja imao manje utjecaja na BPM nego pi-kalkulus i Petrijeve mreže.

3. Servisno orijentirana arhitektura Kako se navodi u [2], organizacije u privatnom i javnom sektoru sve su ovisnije o informacijskoj tehnologiji (IT), a u nekim područjima (npr. telekomunikacijske usluge, bankarstvo) je kompetitivnost organizacija primarno vezana uz informacijska rješenja koja koristi. Menedžeri koji upravljaju IT sustavima u tim organizacijama danas su često suočeni s kontradiktornim zahtjevima. S jedne strane, korisnička očekivanja u odnosu na raspoloživost, pouzdanost i performanse sve su veća, vrijeme u kojem treba razviti nove mogućnosti sve je kraće, od IT sustava se očekuje da budu na raspolaganju ubrzo nakon neplaniranih događaja (nezgoda) i sl. S druge strane, budžet koji je na raspolaganju IT sektoru je sve manji i manji. Organizacije mogu uvoditi nove mogućnosti u svoje IT aplikacije na taj način da zamijene stara rješenja s novima, tj. bace stara rješenja. Takav način ponekad ima svojih opravdanja, no, bacanje starih rješenja je generalno riskantna i/ili skupa strategija. U većini slučajeva bolja je strategija - izrada novih funkcionalnosti i njihova integracija u postojeći sustav. Takav (evolucijski) pristup u pravilu smanjuje rizik i troškove. SOA arhitektura je okvir (framework) koji je danas široko prihvaćen u IT industriji za proširivanje postojećih aplikacija, ali i za izradu novih aplikacija. SOA arhitektura počiva na jednostavnoj ideji, po kojoj postoje davatelj usluge (service provider) i primatelj usluge (service consumer). No, za razliku od uobičajenog pristupa da je primatelj usluga čovjek, u SOA arhitekturi su i davatelj i primatelj softverski entiteti. SOA arhitektura nije samo IT tehnologija, već je ona i pristup po kojem poslovni korisnici sudjeluju u razvoju i nadgledanju softverskih rješenja. Servis treba podržati prije svega poslovnu funkciju, a ne čistu tehničku funkciju. Kao davatelji usluga u SOA arhitekturi često se koriste web servisi, ali to nije jedina tehnologija koja se može/smije koristiti. U [2] se navode sljedeće karakteristike davatelja usluga:

- nezavisan je od bilo kojeg primatelja usluge; može se promatrati kao crna kutija, kod koje nije važna unutrašnjost (npr. u kojem jeziku je servis pisan), već samo ono što daje;

- specificira točno definirani skup funkcija koje pruža i način kako se pozivaju, tj. ima strogo definirano sučelje (interface);

- ima određeno ime i može se locirati pomoću određene vrste registra (registry); - ima mehanizam oporavka (recovery) u slučaju grešaka; - u toku svog rada može pozvati druge davatelje usluga, odnosno davatelj usluge u tom slučaju postaje

primatelj usluge. Razmjena poruka između SOA servisa najčešće se radi pomoću XML-baziranih jezika. Inače, u [6] autori navode kako je XML (eXtensible Markup Language) možda najvažniji programski jezik ikada napravljen. No, XML zapravo nije jezik (unatoč svom imenu), već je samo šablona za izradu XML-temeljnih jezika ili protokola. Na XML-u se temelji i najpoznatiji protokol za opis poruka (koje se šalju između SOA servisa) – SOAP. U [2] se navodi kako je SOAP, kada je prvo definiran, bio akronim za Simple Object Access Protocol, ali se u međuvremenu to značenje izgubilo, jer protokol nije niti jednostavan, niti se odnosi na vezu među objektima, tako da je to danas ime bez posebnog značenja. Nekad se smatralo da je SOAP nužan za "pravu" SOA arhitektu, tj. da svaka razmjena poruka između servisa mora ići preko SOAP protokola. No, iako se SOAP protokol u načelu može koristiti za svaku interakciju, postoje slučajevi kada je zbog efikasnosti bolje odabrati drugi protokol, i pri tome i dalje ostajemo unutar SOA arhitekture. Npr. ako se koristi neki Java EE (Java Platform, Enterprise Edition) aplikacijski server, tada JMI (Java Method Invocation) ili Java Messaging uobičajeno predstavljaju bolji izbor nego SOAP, zbog boljih performansi, ali i zbog boljeg uklapanja tih protokola u Java okolinu. Osim SOAP protokola, nekad se smatralo da je za "pravu" SOA arhitektu neizostavno nužan i SOA UDDI registar (Universal Description, Discovery, and Integration). Tu se još javlja i WSDL (Web Service Description Language), XML-temeljeni jezik pomoću kojeg se kreira XML dokument koji opisuje web servis, njegovo sučelje i način korištenja. Sljedeća slika prikazuje kako dva servisa komuniciraju na "idealan" SOA način:

Slika 2. Interakcija servisa u SOA arhitekturi; Izvor: [6]

Slika 2. pokazuje kako se servis Credit Checking prijavljuje u UDDI registar (pri čemu se koristi jezik WSDL), čime stavlja na znanje okolini svoje postojanje i prikazuje funkcije koje može pružiti. Servis Order Processing traži usluge nekog servisa kao što je Credit Checking, a to traži na način da koristi usluge infrastrukturnog servisa Service Broker, koji traži informacije o traženom servisu u UDDI registru. Nakon što ih nađe, Service Broker šalje informaciju o traženom servisu (Credit Checking) prema servisu tražitelju usluge (Order Processing), preko WSDL definicije. Nakon toga servis primatelj usluge (Order Processing) komunicira preko poruka pisanih u SOAP protokolu sa servisom davateljem usluge (Credit Checking). Treba naglasiti da je uloga UDDI registra da pruža informacije o raspoloživim uslugama u realnom vremenu, bez obzira na dinamičnost okruženja. U relativno statičnom okruženju (gdje se servisi rijetko dodaju, uklanjaju ili mijenjaju), sa relativno malim brojem davatelja usluga, UDDI registar ne bi bio nužan, jer bi se informacije o davateljima usluga mogle međusobno "podijeliti" između servisa. Na slici se vide i adapteri (prilagođivači). U [6] se daje lista različitih vrsta adaptera:

- web servis adapteri; - adapteri za emulaciju terminala; - dokument-bazirani adapteri, npr. oni za Electronic Data Interchange (EDI); - adapteri za middleware; - adapteri za transakcijske strojeve (transaction engine), npr. adapteri za IBM CICS, BEA (sada Oracle)

Tuxedo i sl.; - adapteri za podatke (često se baziraju na standardima ODBC i JDBC) i drugi.

Razvoj i održavanje softvera nikad nije bio lagan posao, zato jer jedino što je stalno kod softvera jesu – stalne promjene! Promjene u SOA arhitekturi još su kompleksnije. Zbog toga (ali ne samo zbog toga) se u [6] zagovara postojanje SOA repozitorija (repository). Iako se na prvi pogled čini da repozitorij kopira neke funkcije koje ima registar, glavna razlika između registra i repozitorija je u tome da je registar vrlo dinamičan – promjene koje se dešavaju sa/u servisima moraju se odmah odraziti u registru (u realnom vremenu). Promjene u repozitoriju nisu tako dinamičke. Kako se navodi u [6], SOA repozitorij trebao bi sadržavati i izvorni kod aplikacija (koje je firma napravila) i zapise o svim promjenama na aplikaciji (change management). Repozitorij bi trebao sadržavati i podatke o poslovnim procesima, pa bi služio i kod modeliranja poslovnih procesa. Također, služio bi i za SOA testiranje, te za SOA upravljanje (governance):

Slika 3. Razvoj SOA softvera pomoću tradicionalnih alata i specifičnih SOA alata; Izvor: [6]

Bitno je to da se zadržavaju svi postojeći softverski alati (na slici 3. prikazani u pravokutniku Software Development), ali se nadopunjuju sa specifičnim alatima za SOA arhitekturu, kao što su alati za BPM, alati za SOA testiranje i SOA governance, sve podržano sa registrom i repozitorijem.

4. Poslovna pravila

Krajem 70-tih pojavili su se opisi slojevite arhitekture informacijskih sustava, tzv. troslojne arhitekture (three-tier architecture). U to je vrijeme pojam "tier" imao poprilično drugačije značenje od onoga kojeg (pretežno) ima danas. Danas se "tier" (obično) upotrebljava kao oznaka za fizički sloj, dok je nekad to bila oznaka za logički sloj. Kad se govori o logičkim slojevima, danas se obično upotrebljava termin "layer". Troslojna arhitektura poprimila je veliku popularnost tek 90-tih, dobrim dijelom zahvaljujući promociji koju je napravila Gartner grupa. "Klasičan" opis troslojne arhitekture navodio je tri sloja: sloj korisničkog sučelja (User Interface), sloj aplikacijske logike (Application Logic) i podatkovni sloj (Storage). Tijekom vremena se broj (logičkih) slojeva povećavao, pa npr. Java EE specifikacija navodi četiri sloja: sloj korisničkog sučelja (Client Tier), sloj prezentacijske logike na serveru (Web Tier), sloj poslovne logike, tj. poslovnih objekata i poslovnih pravila (EJB Tier) i podatkovni sloj (Data Tier). Neke klasifikacije navode pet ili više slojeva. U svakom slučaju, svugdje se javlja sloj (ili podsloj) poslovnih pravila.

U [4] se navodi da je pristup razvoju aplikacija na temelju poslovnih pravila, ili skraćeno BRA pristup (Business Rules Approach), nastao evolucijom iz tri izvora:

- umjetna inteligencija (Artificial Intelligence, AI), i to naročito iz dijela AI koji se bavi ekspertnim sustavima (Expert Systems);

- modeliranje podataka (Data Modeling); - reinženjering poslovnih procesa (Business Process Reengineering, BPR), koji je kasnije evoluirao u

upravljanje poslovnim procesima (Business Process Management, BPM). Navodi se da je nakon prestanka buma oko umjetne inteligencije (krajem 80-tih) veliki broj proizvođača ekspertnih sustava prešao na područje izrade rules engine-a. Što se tiče utjecaja vezanih oko modeliranja podataka, taj je utjecaj dolazio iz područja SQL baza podataka, naročito kada su autoriteti iz područja modeliranja podataka (među kojima i Barbara von Halle, autorica knjige [17]) osnovali sredinom 90-tih Business Rules Group (BRG). Ta se grupa inicijalno fokusirala na poslovna pravila koja se mogu direktno implementirati u informacijskoj tehnologiji, naročito u SQL bazama podataka. Kasnije je Ron Ross (autor knjige [16]) usmjerio BRG na poslovni aspekt poslovnih pravila, što je danas dovelo do OMG standarda Semantics of Business Vocabulary and Business Rules (SVBR) i Business Motivation Model (BMM).

Postoje brojne definicije pojma "poslovno pravilo". Npr. u [16] se navode tri (kratke) definicije, sa različitih polazišta:

- poslovna definicija (business definition): Propis namijenjen da utječe ili upravlja poslovnim ponašanjem; - definicija sa stanovišta analitičara poslovnog sustava (business system definition): Atomičan (atomic) dio

višestruko uporabljive (reusable) poslovne logike, specificiran deklarativno; - formalna definicija (formal definition): Koncept reprezentiran pomoću terma (term), fakta (fact) ili pravila

(rule). U [16] se navode i ovi temeljni principi BRA pristupa (The Basic Principles of the Business Rule Approach):

- pravila trebaju biti izražena i napravljena eksplicitno; - pravila trebaju biti izražena na jasan način; - pravila trebaju postojati nezavisno od procedura i radnih tokova (workflows); - pravila trebaju biti izgrađena na faktima, a fakti pomoću terma; - pravila trebaju voditi ili utjecati na ponašanje u željenom smjeru; - pravila trebaju nastati iz identificiranih i važnih poslovnih faktora; - pravila trebaju biti pristupačna autoriziranim korisnicima; - pojedino pravilo smije imati samo jedan izvor (single-sourced); - pravila trebaju biti specificirana direktno od ljudi koji posjeduju relevantna znanja; - pravilima se mora moći upravljati.

U [16] se navodi i funkcionalna klasifikacija poslovnih pravila (Functional Categories of Rules: The BRS Rule Classification Scheme), koja se temelji na tome kako pravila reagiraju na događaje. Budući da određeno pravilo može reagirati na jedan od moguća tri načina, po ovoj klasifikaciji postoje tri osnovne vrste pravila:

- pravilo koje odbacuje (rejector): pravilo koja odbacuje događaj ako bi njegovo izvršavanje rezultiralo povredom pravila; to su pravila koja štite sustav od pogrešnih podataka (ili pogrešnih stanja);

- proizvođač (producer): pravilo koje izračunava ili derivira vrijednost na temelju neke matematičke funkcije; ima podvrste (computation rule, derivation rule);

- projektor (projector): bilo koje pravilo koje pokreće neku akciju (koja nije odbacivanje) kada se desi relevantni događaj; ima podvrste (enabler, copier, executive, koje imaju svoje podvrste).

U [17] se može naći nekoliko definicija pojma poslovno pravilo, uključujući i one drugih autora. Treba naglasiti da se tamo u poslovna pravila ne ubrajaju tzv. pravila radnog toka (workflow rules), već samo pravila koja se odvijaju unutar individualne transakcije baze. Mnogi zagovornici primjene poslovnih pravila drže da je pristup razvoju aplikacija na temelju poslovnih pravila (Business Rules Approach to Application Development) sljedeći glavni evolucijski korak u razvoju aplikacija, koji slijedi iza objektno-orijentiranog pristupa (Object-Oriented Approach). Takvo je mišljenje prikazano i u [17], s tim da se zagovara posebna komercijalna tehnologija za pravila, tj. specijalizirani softver za upravljanje pravilima (rules engine), koji može omogućiti:

- manju potrebu za pisanjem programskog koda; - kraće vrijeme razvoja; - reduciranje grešaka kod programiranja; - brzo proširivanje; - isporuku pravila nezavisno od SUBP-a, srednjeg i prezentacijskog softvera; - isporuku vidljivih pravila (nesakrivenih); - omogućavanje višestrukog korištenja pravila; - omogućavanje specifikacije pravila samo na jednom mjestu; - automatsko izvršavanje pravila.

No, ne slažu se svi da softver za poslovna pravila treba biti striktno odvojen od ostalog softvera, pa i od softvera baza podataka. U [3] Date (jedan od najvećih autoriteta za relacijske baze podataka) navodi 12 odredbi za "stroj za pravila" (rules engine) i navodi da stroj za pravila može (i mora) biti nezavisan od "podatkovnog" SUBP-a, ali kaže da stroj za pravila mora biti sam po sebi također SUBP (5.odredba), i to relacijski SUBP (6.odredba). Pravila moraju biti izvršna, tj. moraju biti programski kod, a ne tekst (1.odredba) i moraju biti deklarativno navedena, a ne proceduralno (2.odredba). No, iako je današnji SQL standard relacijski potpun u podršci deklarativnih ograničenja (jer dozvoljava bilo koji izraz u CHECK klauzuli za deklaraciju ograničenja), u praksi rijetko koji SUBP to realizira (npr. Oracle RSUBP ne realizira). Najčešća je izlika (proizvođača SUBP-a) da bi to jako usporilo rad sustava. Zbog takvog stanja u praksi, Date nije protiv proceduralnih rješenja, pa ni protiv okidača baze podataka – treba ih koristiti ako ne postoji (deklarativna) alternativa. Naime, nepodržavanje poslovnih pravila na bazi rezultira time da je integritet podataka u bazi ovisan o aplikaciji. Jedna aplikacija se može pridržavati poslovnih pravila, a da pritom druga aplikacija to ne radi (najčešće nenamjerno). Nepodržavanje

poslovnih pravila na bazi znači i to da netko zlonamjeran može mijenjati podatke u bazi podataka izvan kontrolirane aplikacije, i na taj način namjerno narušiti integritet podataka.

Kod rada sa bazama podataka, čini se adekvatnom definicija (i klasifikacija) poslovnih pravila iz [12] (bez obzira što je riječ o Oracle publikaciji, čini nam se primjenjivom i na druge relacijske baze podataka): "Poslovna pravila su ograničenja koja se primjenjuju na stanje sustava ili na promjenu stanja sustava (Constraint Rules), autorizacijska pravila, koja određuju koji korisnici mogu raditi i što mogu raditi u sustavu (Authorization Rules), ili akcije koje se automatski pokreću nakon promjene stanja sustava (Change Event Rules)". Oracle navodi da se ta njihova klasifikacija može izraziti i u terminima UML metode. Invarijantama (Invariant) se mogu nazvati ograničenja na stanje sustava, pretkondicijama (PreCondition) se mogu zajedno nazvati ograničenja na promjenu stanja sustava i autorizacijska pravila, a postkondicijama (PostCondition) se mogu nazvati akcije koje se automatski pokreću nakon promjene stanja sustava. Ova (alternativna) Oracle klasifikacija je bliska (barem po terminologiji) metodi Design By Contract (DBC). Pojednostavljeno rečeno, DBC se zasniva na ideji da svaka metoda klase (procedura ili funkcija), uz "standardni" programski kod, treba imati još dva dodatna dijela - pretkondiciju (precondition) i postkondiciju (postcondition). Klasa treba imati još jedan dodatni dio - invarijantu (invariant). Ugovor (contract) se zasniva na tome da metoda "traži" od svog pozivatelja (neke druge metode) da zadovolji uvjete definirane u pretkondiciji (plus uvjete definirane u invarijanti), a ona (pozvana metoda) se tada "obvezuje" da će na kraju zadovoljiti uvjete definirane u postkondiciji (plus uvjete definirane u invarijanti). Ideja je na neki način upravo suprotna od tzv. defanzivnog programiranja, koje zagovora da se u svim mogućim trenucima pokušava što više toga provjeriti. DBC metoda je opisana u [10] , a realizirana je u programskom jeziku Eiffel (autor DBC metode i jezika Eiffel je isti). Kako se navodi u [5], svi BRMS sustavi (Business Rules Management System, sustavi za upravljanje poslovnim pravilima) poslovna pravila predstavljaju kao rečenice, koje obično sadrže riječi IF i THEN. Rečenica IF A THEN B tada predstavlja produkcijsko pravilo. Lijeva strana (u ovom slučaju A) se zove antecedent ili pretpostavka, a desna strana konzekvent ili posljedica, što je u skladu s terminologijom (matematičke) logike. Produkcijsko pravilo ima, dakle, oblik logičke implikacije, što se u logici obično piše kao A => B. Važno je to da BRMS sustav, kao i ekspertni sustav općenito, može stvarati nova pravila na temelju već poznatih pravila, odnosno može deduktivno zaključivati, što se obično naziva (deduktivno) inferenciranje (inference). Kako kaže [5], deduktivno inferenciranje nije jedini način zaključivanja u BRMS sustavima, ali je daleko najčešći. Drugi način zaključivanja je induktivan – stvaranje pravila na temelju konkretnih podataka. Data mining (rudarenje podacima) i strojno učenje su specifične varijante te metode. Kod deduktivnog inferenciranja, poznate su strategije povezivanja unaprijed, povezivanja unatrag i mješovitog povezivanja (Forward / Backward / Mixed Chaining Strategies). Strategija povezivanja unaprijed može se prikazati na ovom primjeru poslovnih pravila (iz [5]): Rule 1: A and B and C implies D Rule 2: D and F implies G Rule 3: E implies F Rule 4: F implies B Rule 5: B implies C Rule 6: G implies H Rule 7: I implies J Rule 8: A and F implies H Pretpostavimo da znamo kako su A i F istiniti, a želimo zaključiti (na temelju navedenih pravila) da li je H istinito. Uočimo da se odmah može iz 8. pravila zaključiti da je H istinito. No, povezivanje unaprijed radi krećući se od početka (a možemo zamisliti i da nema 8. pravila), pa bi krenulo od 4. pravila, jer je to prvo pravilo (po redu) kod kojeg je istinit antecedent (u ovom slučaju F), pa se na temelju toga izvodi istinitost konzekventa (u ovom slučaju B). Sada znamo da je uz A i F, istinit i B, pa krećemo ispočetka, opet od 1. pravila. Tablica 1. pokazuje zbivanje kroz korake (iteracije).

Tablica 1. Rezultati kod zaključivanja (naivnim) povezivanjem unaprijed; Izvor: [5] Vidimo da se već u 5. iteraciji došlo do potvrde istinitosti za H, a također vidimo i da 6. i 7. iteracija nisu donijele nikakve nove rezultate u odnosu na 5. iteraciju. Budući da su rezultati 5. i 6. iteracije isti, nije bilo potrebno raditi 7. iteraciju. Da smo u našem slučaju došli do toga da su rezultati dvije iteracije isti, ali da nismo potvrdili istinitost H, zaključili bismo da H nije istinito. Ovakvo zaključivanje povezivanjem unaprijed ima svojih prednosti. Ako pustimo da se iteriranje zbiva sve dok ne dođemo do dva stupca s istim rezultatima, time dobijemo sve moguće odgovore (za zadane ulazne podatke). Međutim, takav način zaključivanja bi kod velikog broja pravila bio jako spor. Istina, možemo prekinuti kod one iteracije koja daje potvrdan odgovor, ali ako polazna hipoteza nije točna, onda će tek postojanje dva ista stupca moći to pokazati. Za razliku od povezivanja unaprijed, povezivanje unatrag radi tako da pretpostavimo kako je ono što želimo dokazati već istinito. U našem prethodnom slučaju, pretpostavili bismo da je H točno (uz A i F) i vidjeli bismo da li tu pretpostavku možemo dokazati. Zaključivanje povezivanjem unazad na prethodnom primjeru izgledalo bi ovako [5]: Trying to prove H Try rule 6 Trying to prove G Try rule 2 F is true, trying to prove D Try rule 1 A is true, trying to prove B Try rule 4 It works. B is true Backtrack to trying rule 1 Trying to prove C Try rule 5, it works C is true Apply rule 1, D is true Apply rule 2, G is true Apply rule 6, H is true Goal achieved; stop. Povezivanje unatrag staje kod dokazivanja H i (općenito) ne nalazi sve rezultate (na temelju zadanih ulaza). Povezivanje unaprijed i povezivanje unatrag mogu se kombinirati (na različite načine), čime se dobiju strategije mješovitog povezivanja. Postoji puno bolji algoritam za povezivanje (naročito u odnosu na prikazani naivan algoritam povezivanja unaprijed), a zove se Rete algoritam (latinski i talijanski rete znači mreža). Dizajnirao ga je Charles L. Forgy sa Carnegie Mellon University, i publicirao ga 1974. Rete algoritam je osnova za skoro sve BRMS sustave, s tim da se koriste različite modifikacije izvornog Rete algoritma (naročito one koje smanjuju potrebu za količinom RAM memorije).

5. Implementacija poslovnih pravila sa Oracle SOA Suite Prvi komercijalni RSUBP pod imenom Oracle ponudila je 1979. godine kompanija Relational Software Inc. (osnovana je 1977.), koja se kasnije preimenovala u Oracle Corporation. Već 80-tih godina se Oracle nije bavio samo sustavima za baze podataka, već i izradom aplikacija uz pomoć vlastitih 4GL alata/jezika Forms i Reports. Ti su alati prvo služili za izradu mainframe aplikacija, od 90-tih i klijent-server aplikacija, a od 2000. podržavaju i Internet rad (ali ne kao servlet/JSP aplikacije). Oracle se rano uključio u Java "struju", pa već od (otprilike) 2000. nudi i vlastiti Java EE aplikacijski server. Oracle je rano krenuo i u SOA arhitekturu. Oracle je 2009. kupio firmu BEA, značajnu na području aplikacijskih servera i SOA arhitekture, a ove godine (2010.) i firmu Sun (koja je vlasnik Jave).

5.1. Oracle Fusion arhitektura i Oracle SOA Suite Na slici 4. je prikazano kako Oracle pokušava u svojoj Fusion arhitekturi objediniti tradicionalni model (web) aplikacija i SOA model:

Slika 4. Oracle Fusion arhitektura kao evolucija tradicionalnog modela; Izvor: [11] Zanimljivo je kako se u [11] objašnjava potreba za novom (fuzioniranom) arhitekturom, iako se poslovni procesi u svojoj biti nisu promijenili. Prema [11], dosadašnja rješenja često su temeljena na batch obradama, i to iz (barem) dva razloga. Prvo, prije SOA arhitekture Human Workflow se nije mogao (lako) uklopiti u tradicionalna softverska rješenja. Drugo, dosta transakcija je dugotrajno, i ne uklapaju se u standardne kratkotrajne transakcije baze podataka. SOA je tu dala svoj doprinos pomoću asinkronih transakcija i pomoću koncepta kompenzacije (compensation). Kompenzacija je postupak oporavka od grešaka, sličan po konceptu ROLLBACK operaciji u bazama podataka (nažalost, često kompleksan za programiranje). Oracle SOA Suite je (složeni) softver za SOA arhitekturu, koji se kupuje kao dodatna opcija iznad Oracle WebLogic Suite (aplikacijski server dobiven kupovinom firme BEA). No, na Oracle SOA Suite vežu se i drugi alati. Kako pokazuje slika 5., to su BPM Suite, alat za upravljanje poslovnim procesima (modeliranje, simuliranje, optimizacija procesa) i alat Governance. Ta dva alata dijele zajedničke komponente sa Oracle SOA Suite (postoji, ali nije prikazan na slici, i Data Integration Suite, koji čine servisi za integriranje podataka):

Slika 5. Oracle SOA, BPM i Governance: [15] Oracle SOA platforma (koju uglavnom čini Oracle SOA Suite) može se prikazati kao na slici 6. (BAM uobičajeno znači Business Activity Monitoring, a CEP znači Complex Event Processing tj. procesiranje složenih događaja; CEP komponenta monitorira streams, tj. potoke događaja i povezuje naizgled nepovezane događaje u uzorke, a aplikacije su obično risk management, fraud detection, intrusion detection, compliance):

Slika 6. Oracle SOA platforma; Izvor: [15] Kako je već rečeno, SOA Suite nije jednostavan alat. Za njegovo funkcioniranje potrebno je instalirati ove alate:

- Oracle RSUBP; - Oracle WebLogic Server; - Oracle SOA Suite; - Oracle JDeveloper (za razvoj); - SOA ekstenzija za JDeveloper (za razvoj).

Nakon toga je potrebno: - kreirati u Oracle bazi sheme za Oracle SOA Suite komponente; - kreirati repozitorij (pomoću Repository Creation Utility); - kreirati WebLogic domenu za SOA projekt (koristeći WebLogic Configuration Wizard).

Da bi olakšao rad sa različitim komponentama i smanjio potrebu za učenjem brojnih alata za dizajniranje, Oracle je u JDeveloper-u napravio Composite Editor, u kojem se različite SOA komponente (uključujući i poslovna pravila) mogu definirati na grafički način, kao na slici 7.

Slika 7. SCA (Service Component Architecture) Composite Editor; Izvor: [15]

5.2. Oracle Business Rules Što se tiče poslovnih pravila, Oracle tu ima dvije varijante. Starija varijanta, koja je nastala oko 1995. godine, kada se zahuktalo istraživanje oko poslovnih pravila (otprilike tada je nastala i organizacija Business Rules Group, BRG), bavi se implementacijom poslovnih pravila unutar (Oracle) RSUBP-a. No, budući da se Oracle vrlo brzo uključio u Java "struju" (koja je također krenula 1995.), napravio je rješenje poslovnih pravila i izvan baze. Zapravo, Oracle je iskoristio open source rješenje Jess. Kako se navodi u [5], Jess je pisan u potpunosti u Javi, a napravio ga je Ernest Friedman-Hill sa Sandia National Laboratories (Livermore, CA). Jess je originalno bio inspiriran CLIPS jezikom za ekspertne sustave. Koristeći Jess, može se napisati Java softver koji radi inferenciranje na temelju deklarativnih pravila. Jess koristi Rete algoritam, a podržava i povezivanje unaprijed i unatrag (forward / backward chaining). Oracle je preuzeo i prilagodio Jess kao vlastito rješenje za stroj za pravila (rules engine) - Oracle Business Rules. Oracle Business Rules može se koristiti i u SOA arhitekturi i izvan nje. Oracle Business Rules sastoji se od sljedećih komponenti, koje se koriste za vrijeme modeliranja ili izvođenja:

- Oracle Business Rules RL Language: jezik sličan Javi za pisanje poslovnih pravila;

- Oracle Business Rules SDK: Java biblioteka za manipulaciju poslovnim pravilima;

- Oracle Business Rules Designer: ekstenzija za JDeveloper IDE, vizualni alat za kreiranje i modificiranje poslovnih pravila; interno koristi Oracle Business Rules SDK;

- Decision Component: mehanizam za objavljivanje poslovnih pravila kao servisa u Oracle SOA aplikaciji;

- Oracle Business Rules Engine: namijenjen za Java EE aplikacije (ne-SOA). Decision Service komponente mogu raditi na dva načina, statefull i stateless, kao što pokazuje slika 8.

Slika 8. Decision Service arhitektura; Izvor: [13]

5.3. Modeliranje poslovnih pravila u Oracle Business Rules (OBR) Designeru Integracija poslovnih pravila sa BPEL-om i ostalim elementima SOA arhitekture počinje već za vrijeme modeliranja poslovnih pravila. Oracle JDeveloper je alat kroz koji se mogu modelirati poslovne činjenice (engl. business terms), poslovna pravila i poslovni procesi. Poslovna činjenica je bilo što od interesa za posao. U Oracle Business Rules (OBR), poslovne činjenice nazivaju se svojstva (engl. properties). U SOA aplikaciji, najveći broj poslovnih činjenica modelira se korištenjem XML shema editora u JDeveloperu, ili se preuzima iz definicije postojećih SOA servisa. Poslovna pravila imaju IF dio i THEN dio. IF dio testira jednu ili više poslovnih činjenica. Ako test prođe, izvršava se jedna ili više akcija iz THEN dijela, a akcija može biti dodavanje ili mijenjanje poslovnih činjenica. Primjer jednog složenijeg pravila je: IF (ako) je ukupni iznos artikala koji su označeni kao pogodni za besplatnu isporuku i koji se otpremaju na istu destinaciju veći od 40$ THEN (tada) isporuka tih artikala je besplatna. Na slici 9. prikazuje se kako se to pravilo definira u Oracle JDeveloperu, u alatu koji se naziva Oracle Business Rules (OBR) Designer.

Slika 9. Primjer jednog složenijeg pravila definiranog sa JDeveloper OBR Designerom; Izvor: [14] U nekim slučajevima je pogodnije poslovno pravilo umjesto u IF … THEN … obliku, definirati u obliku tablice odlučivanja. To su slučajevi kada nekoliko sličnih pravila koristi kombinacije vrijednosti za više poslovnih činjenica. Npr. pretpostavimo da želimo kreirati isporuku kada svi artikli za određenu destinaciju postoje na zalihi, ili kada su samo neki artikli na zalihi, ali je kupac ili visoko rangiran ili je to kupac koji plaća isporuku koja će uslijediti unutar 7 dana, ili kada je to kupac koji ne plaća isporuku ali će isporuka uslijediti unutar 14 dana (u pravilu). Trebamo odluke tipa da/ne za svaku kombinaciju narudžba/destinacija, temeljeno na 5 poslovnih činjenica:

1. svi artikli postoje na zalihi (da/ne oznaka) 2. neki artikli postoje na zalihi (da/ne oznaka) 3. kupac je visoko rangiran (da/ne oznaka) 4. kupac je onaj koji ne plaća isporuku (da/ne oznaka) 5. odgoda isporuke (definirana kao dani između datuma narudžbe i maksimalnog datuma kada će doći roba

koje nema na zalihi).

Te se poslovne činjenice mogu definirati koristeći XML shemu i importirati u OBR Designer, ili se mogu direktno implementirati u OBR Designeru, koristeći OBR Rule Language, kako pokazuje 10.

Slika 10. Definiranje fakta u OBR Designeru kroz OBR Rule Language; Izvor: [14] Te poslovne činjenice onda možemo koristiti u tablici odlučivanja, kako pokazuje slika 11.

Slika 11. Tablica odlučivanja (Decision Table) u OBR Designeru; Izvor: [14]

5.4. Definiranje poslovnih procesa korištenjem BPEL-a i poslovnih pravila Poslovni proces uobičajeno prima na ulazu XML dokument, poziva neke servise, te vraća XML dokument kao izlaz. Poslovni proces je također servis, za kojeg se kaže da orkestrira druge servise. Tipični servisi koje proces Narudžbe može pozivati jesu servis za poreze, servis za prikaz stanja zaliha, servis za isporuku i dr. Zapravo, poslovna pravila su isto ugrađena u BPEL kao servisi, sa XML dokumentima koji sadrže poslovne činjenice. Slika 12. prikazuje fragment BPEL procesa za narudžbe (interni procesi prikazani su žutom, a eksterni plavom bojom):

Slika 12. Fragment BPEL procesa za obradu narudžbi; Izvor: [14] Kada se odlučuje o tome koji dio poslovnog procesa modelirati kao BPEL dijagram, a koji dio kao poslovna pravila, uobičajeno se [14] poslovna pravila primjenjuju za rješavanje složenih odluka o tome što dalje raditi u poslovnom procesu i za deklarativni pristup, validaciju, spajanje i transformaciju XML dokumenata.

5.5. Testiranje, stavljanje u implementaciju i praćenje poslovnih pravila

Da bi se na pravi način testirali BPEL procesi koji koriste poslovna pravila, potrebno je testirati web servise koje proces poziva, poslovna pravila koja koristi, te sam proces koji orkestrira te servise i pravila. Poslovna pravila i tablice odlučivanja mogu se jedinično testirati (unit testing) kroz OBR Designer, bez potrebe da se modelira poslovni proces (koji ih koristi), a pogotovo ne treba ništa staviti u implementaciju (engl. deployment). To uveliko poboljšava produktivnost, jer se poslovna pravila i poslovni procesi mogu razvijati paralelno. Uobičajeno najteži dio kod testiranja BPEL procesa je simulacija eksternih procesa koje BPEL proces poziva. Oracle SOA radno okruženje (engl. framework) za testiranje olakšava taj dio testiranja. Nakon testiranja, SOA aplikacija se kroz JDeveloper priprema za stavljanje u implementaciju i implementira se na aplikacijskim serverima (jednom ili više), pri čemu se repozitorij XML dokumenata realizira kroz sustav za upravljanje bazom podataka. Više BPEL strojeva (BPEL engines) može raditi paralelno u grozdu (klasteru) aplikacijskih servera, omogućavajući lakšu skalabilnost i veću raspoloživost. S druge strane, stroj za BPEL i stroj za poslovna pravila (BR engine) rade unutar iste JVM, što ubrzava komunikaciju među njima. Za vrijeme izvršavanja se sa Oracle Enterprise Managerom može monitorirati stanje sustava. Što se tiče Decision Service komponenata, mogu se promatrati greške ili statistike o performansama na razini sustava, što prikazuje slika13.

Slika 13. Praćenje izvršavanja poslovnih pravila; Izvor: [14]

6. Zaključak Iako je IT tehnologija uvijek bila vezana uz poslovnu tehnologiju, SOA arhitektura još više naglašava povezanost poslovnih procesa i IT aplikacija koje ih podupiru. Neki drže da je SOA arhitektura sljedeća stepenica u razvoju softvera, jer postoji mišljenje da objektno-orijentirane metode nisu donijele obećani napredak na povezivanju IT tehnologije sa poslovnim sustavom. Neki navode da je jedno od mogućih objašnjenja i to da dosadašnje objektno-orijentirane metode nisu zaista bile prave OO metode. Poslovni procesi izvode se uz zadovoljavanje nekih poslovnih pravila (Business Rules, BR), od kojih su neka usko vezana za pojedini proces, a druga se mogu primijeniti na različite poslovne procese. Kako se navodi u [5], i SOA i poslovna pravila imaju jedan zajednički cilj – povećanje razine apstrakcije softverskih sučelja, jer ta sučelja moraju prije svega podržavati poslovni sustav, a ne informacijski sustav. Kako se navodi, ako nam je glavni cilj da IT bolje povežemo sa poslovnim sustavom, onda SOA arhitektura sama za sebe nije dovoljna, već trebamo separirati poslovna pravila od programskog koda. U takvom spoju SOA i poslovnih pravila, stroj za poslovna pravila (rules engine) postaje odvojena komponenta (odvojeni servis) koji izvršava neka poslovna pravila (ona koja su zajednička za više procesa), a neka poslovna pravila (koja su vezana samo za jedan proces) izvodi sam proces. Danas ima dosta proizvođača BRMS sustava (sustava za upravljanje poslovnim pravilima), a neki od njih su i proizvođači SOA rješenja (naročito se to odnosi na najveće igrače: IBM, Microsoft i Oracle). Što se tiče SOA rješenja, često ona sadrže (ili su bar vezana za) i BPM softver (softver za upravljanje poslovnim procesima). Takvi integrirani alati često su vrlo kompleksni i često traže poznavanje većeg broja formalnih jezika, koji nisu jednostavni (bez obzira da li su grafički ili negrafički). U toj kompleksnosti, javljaju se i takvi pristupi da se razvoj softverskih rješenja mora pojednostaviti, odnosno napraviti na način koji bi omogućio poslovnim ljudima (neinformatičarima) da (više) sudjeluju u razvoju softvera. Ti pristupi izgledaju obećavajući, s tim da vjerojatno vrijedi ova istina: jednostavnije stvari mogu se (ili bi se trebale moći) napraviti na jednostavan način, a teške stvari mogu se (nažalost) napraviti samo na težak način - ali ne teži nego što je nužno.

Literatura

[1] Buelow, H. i dr. (2009): Getting Started with Oracle SOA Suite 11g R1 – A Hands-On Tutorial, Packt Publishing [2] Bye, P. (2007): Service-Oriented Architecture: Delivering for Business (white paper), Unisys Corporation, www1.unisys.com:8081/eprise/main/admin/micro/doc/Service_Oriented_Architecture.pdf (lipanj 2010.) [3] Date, C.J. (2005), Database in Depth, O'Reilly Media [4] Debevoise, T. (2010): The Past, Present, and Future of Business Rules - Towards True Business Enablement (white paper), Innovations Software Technology Corp., www.visual-rules.com/white-paper-debevoise-business-rules-history.html (lipanj 2010.) [5] Graham, I. (2006): Business Rules Management and Service Oriented Architecture - A Pattern Language, John Wiley & Sons [6] Hurwitz, J. i ostali (2007): Service Oriented Architecture For Dummies, Wiley Publishing [7] Havey, M. (2005): Essential Business Process Modeling, O'Reilly Media [8] Martin, W. (2006): Role of Business Rules in SOA (white paper), Wolfgang Martin team, www.innovations-software.com/fileadmin/pdf-en/white-paper/business-rules-processes-soa.pdf (lipanj 2010.) [9] Martin, W. (2008): Rule-Based Composition of Agile Business Services (white paper), Wolfgang Martin team, www.wolfgang-martin-team.net/whitepaper.php (lipanj 2010.) [10] Meyer, B. (1997), Object-Oriented Software Construction, Prentice Hall

[11] Mills, D. i dr. (2010), Oracle JDeveloper 11g Handbook - A Guide to Oracle Fusion Web Development, McGraw-Hill [12] Oracle priručnik (2000): CDM Standards and Guidelines Library Volume 1 - Requirements Modeling using Oracle Designer [13] Oracle priručnik (2009): User's Guide for Oracle Business Rules 11g Release 1 [14] Oracle whitepaper (2008): Smart Business Processes using Oracle Business Rules [15] Oracle workshop materijal (2010): Oracle SOA Suite 11g (materijal s workshop-a održanog u Oracle Hrvatska, Zagreb, 08.-09.02.2010) [16] Ross, R.G. (2003): Principles of the Business Rule Approach, Addison Wesley [17] Von Halle, B. (2002), Business Rules Applied: Building Better Systems Using the Business Rules Approach, John Wiley & Sons [18] Vrček, N. (2009): Sigurnost otvorenih sustava (materijali s predavanja), FOI Varaždin

Podaci o autoru:

Zlatko Sirotić, dipl.ing. Istra informatički inženjering d.o.o., Pula e-mail: zlatko.sirotic@iii.hr Autor radi više od 25 godina na informatičkim poslovima. Najveći dio radnog vijeka proveo je u poduzeću Istra informatički inženjering d.o.o, Pula, gdje radi i sada. Radio je na svim poslovima u izradi softvera: analiza, dizajn, programiranje, uvođenje, obuka korisnika, održavanje. Oracle softverske alate (baza, Designer CASE, Forms 4GL, Reports, JDeveloper IDE, Java) koristi zadnjih 15 godina. Objavljivao je stručne radove na kongresima "Hotelska kuća", na konferencijama CASE, KOM, HrOUG (Hrvatska udruga Oracle korisnika), u časopisima "InfoTrend" i "Ugostiteljstvo i turizam", a neka njegova programska rješanja objavljena su na web stranicama firmi Quest i Oracle.