Ogrodja In Smeri Razvoja

Ogrodja v IRC okolju in smeri razvoja (v1) 1/28 _________________________________________________________________________

Uvod

9. junija 2006 so pri Oraclu objavili dokumentacijo za ADF (Aplication Development Framework) v sestavi, kot ga priporočajo uporabnikom, ki izhajajo iz Forms/4GL okolij. Tako je zaokrožena priprava novosti, ki jih je v začetku leta 2006 prinesel jDeveloper 10.1.3 s JSF in ADF Faces. S tem je Oracle: -

izvedel novo sinhronizacijsko fazo pri uresničevanju svoje strategije. ponudil razvijalcem oprejemljivejše oblike iz novih smeri.

S temi novostmi sem se seznanjal prek OTN – a in prek enostavnih primerov v okviru takoimenovane »lokalne razvojno podporne točke« vzpostavljene na PC-ju. Pri tem sem bil osredotočen na same novosti in vzpostave. O tem sem napravil kratek delovni zapis »Zlivanja na začetku leta 2006«. V tem zapisu bom poskušal to problematiko izpostaviti v širšem smislu celotne situacije. Pri tem se lahko naslonim le na svoje okvirno poznavanje celote in na nekatera razmišljanja o nadaljnih smereh.

IRC v 2006 IRC se sooča: z vedno hujšo konkurenco globalnih ponudnikov programskih rešitev s problemom kako ujeti trende prehoda na splet s problemom obdržanja obstoječih rešitev v delovanju s problemom zahtev po novih funkcionalnostih programskih rešitev s problemom osvajanja in uvajanja novih tehnologij in metodologij …………… s problemom reorganiziranja in novih usmeritev IRC ponudba je sestavljena iz: -

-

Programskih rešitvev zasnovanih na enostavni aplikacijski arhitekturi (odjemalec/strežnik) nadgrajenih za namestitve v večnivojski arhitekturi. Te rešitve predstavljajo večinski del ponudbe. Programskih rešitev zasnovanih na zahtevnejši aplikacijski arhitekturi (J2EE, večplastna, SOA). Te rešitve predstavljajo manjši del ponudbe.

Programske rešitve so naslonjene na Oraclovo tehnologijo tako v tradicionalnem ( baza ), kakor novem smislu ( aplikacijski strežnik, forms strežnik,…. ). V nadgradnii obstoječih rešitev za pogon na forms strežniku je IRC sledili Oraclovim priporočilom – selitev na splet prek aplikacijskega strežnika in nato vstop v J2EE. V tem smislu so se razvijale tudi Oraclove aplikacije. O hitrosti, obsegu in globini uvajanja novosti se odloča na osnovi ocen predvsem glede na naslednja vprašanja: • • • • •

ali ali ali ali ali

imamo potrebne izkušnje imamo potrebne kadre lahko uporabi obstoječe kadre in pridobljene tehnološke izkušnje lahko dovolj hitro razvijemo programe in spreminjamo tehnologijo lahko zagotavljamo ustrezno kakovostno podporo in vzdrževanje

In če te odgovore položimo v matriko poslovnih priložnosti, dobimo ob neki oceni spodjo sliko.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 2/28 _________________________________________________________________________

privlačnost

Rešitve na zahtevnejši aplikacijski arhitekturi Rešitve na enostavni aplikacijski arhitekturi

zmožnost

Takšna ocena bi pomenila: -

da je pred nami obdobje, kjer bo potrebno predvsem obstoječe odjemalce servisirati z obstoječimi rešitvami na enostavni aplikacijski arhitekturi

-

da je potrebno povečat zmožnost razvoja rešitev na zahtevnejših aplikacijskih arhitekturah.

Vzrok za povečanje privlačnosti rešitev na zahtevnejši aplikacijski arhitekturi je v povečanju kompleksnosti problemov v domenskih vsebinah. Ta kompleksnost se povečuje. Temu povečevanju kompleksnosti lahko sledijo rešitve na enostavni aplikacijski arhitekturi le do določene mere. Potem začne kompleksnost tako zasnovane rešitve neprimerno hitreje naraščati od naraščanja kompleksnosti samega problema. Danes problem ni več tako »enodimenzijski«, ampak se hitro znajdemo v »večdimenzijskem« zahtevnostnem problemskim polju. In v kolikor vztrajamo le v eni oblikiki načina reševanja problema, se lahko pozicioniramo le v nek zahtevnostni interval obravnave problemov. Torej v kolikor imamo širok zahtevnostni interval, bo verjetno smiselno poseči tudi po različnih prijemih pri razreševanju problema. Kako razdelimo problemski prostor je odvisno od kriterijev. Če se vprašamo kaj je enostavno in kaj zapleteno in nato kaj se dogaja znotraj in kaj zunaj, dobimo štiri specifična področja različnih zahtevnostnih kategorij. Teh ne moremo pokriti le z neko ekstenzijo obstoječega, ampak moramo rešitev nasloniti na širše ogrodje. To je ponazorjeno v spodnji skici.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 3/28 _________________________________________________________________________

zunaj

zapleteno

enostavno

znotraj

Oracle 2006

Oracle je že nekaj časa v intenzivnem strateškem preoblikovanju tako v poslovnem kot tehnološkem smislu. To preoblikovanje gre v smeri spleta in J2EE. Skupni imenovalec je Oracle aplikacijski strežnik. Z ofenzivnim nastopom Oracle sedaj nagovarja različne skupine uporabnikov in praktično pokriva vse segmente od tradicionalnih Formskih do čistih Javanskih. Segmentne zgodbe imajo različne poudarke. Osrednje mesto ima problematika tradicionalnih uporabnikov ( Designer, Forms, Reports ), kar se nanaša tudi na same Oraclove aplikacije, oziroma razvojno skupino. Za ta segment uporabnikov je osnovno priporočilo: -

migracija obstoječega na Web oziroma namestitev na trinivojsko arhitekturo

-

z novim (J2EE) začeti v jDeveloperju z ADF (aplikacijsko razvojno ogrodje)

Aplikacijski strežnik zagotavlja skupne servise in nudi interoperatibilnost med starim in novim rešitvam. ADF je zasnovan tako, da s svojo deklarativnostjo in vizualnostjo olajšuje prehod razvijalcev iz 4GL okolij v J2EE okolje. Oracle zagotavlja nadaljno podporo na tradicionalnih razvojnih orodij in napoveduje le možnost namestitve na aplikacijski strežnik. Na tradicionalnih orodjih bo predvsem poskrbljeno za stabilizacijo in sinhronizacijo z novimi verzijami aplikacijskega strežnika. Manj ali zelo malo bo storjeno v smislu razvitja novih funkcionalnosti. Na drugi strani J2EE in jDeveloperja, ter predvsem ADF, doživljajo izredno intenziviran razvoj. Tempo novosti otežuje doseg stabilnosti oziroma praktične uporabljivosti. Zaenkrat se uresničujejo napovedi analitikov o sinhronizacijskih problemih zaradi raznovrsnosti vhodnih elementov. Gledano s strani manjših uporabnikov, torej tudi iz našega zornega kota, se odpira vprašanje zmožnosti osvajanja novosti in obvladovanja velike kompleksnosti. Za slovenske razmere so to elementi, ki lahko zmanjšajo potencialno število namestitvenih mest z Oracle

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 4/28 _________________________________________________________________________ aplikacijskim strežnikom. V najbolj neugodnem dogajanju bi ostali s programsko opremo na nepodprtih starejših verzijah. Prav tako predvsem ostajajo v naj dale v

je pomembno dejstvo, da sama migracija tradicionalnih rešitev v Web okolje prinaša ugodnosti v smislu upravljanja z rešitvijo, medtem ko same aplikacijske funkcionalnosti dometu stare aplikacijske arhitekture. Šele združljive in interoperabilne J2EE aplikacije bi sodelovanju z obstoječimi rešitvami nov učinek.

Splošen pogled na razvijanje programskih rešitev in programja Poznano je, da obstoja množica različnih teorij in metodologij o tem problemu. Prav tako je znano, da je v praksi najpogostejša metodologija »Code and fix«. V zadnjem času so v razvijalskih krogih v ospredju agilne metodologije. Njijova glavna značilnost je, da so usmerjene bolj »adaptivno« kot »prediktivno« ter da so bolj »people-oriented« kot »process-oriented«. Spodaj navedena naslova sta možen vstop v to področje: http://www.agiledata.org/essays/differentStrategies.html http://martinfowler.com/articles/newMethodolog…

Na netehnične vidike razumevanja spiralne dinamike opozarja naslenja skica:

V IRC-u smo se pred leti v sklopu vzpostavitve IRCORA/IRC2000 nekateri seznanili z Oraclovo metodologijo CDM oziroma izvedenko CDM Fast Track. (http://www.oracle.com/technology/consulting/idelivery/cdma/index.html ).Ta je skladna z DSDM http://www.dsdm.org/ .

V spodnji skici je prikazana sprememba od tradicionalnega pogleda na razvijanje rešitev k novemu pogledu. Pri te veljajo nekateri principi : http://www.dsdm.org/tour/principles.asp

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 5/28 _________________________________________________________________________

čas

funkcionalnosti

funkcionalnosti

čas konstantno

2 1

1 viri

čas

viri

3

1 viri

variabilno funkcionalnosti

funkcionalnosti

viri

viri

viri

čas

konstantno 4

6 1

1

funkcionalnosti

funkcionalnoti

funkcionalnosti čas viri

5

1 K V V

2 K K V

variabilno

čas

3 V K V

4 V K K

čas

5 V V K

6 K V K

MoSCoW

Realnost možnega je potrebno iskati med IZVEDLJIVIM in SPREJEMLJIVIM v okviru nekega časovnega intervala ( time box ) in razpoložljivih virov. To nas prisili k zmanjšanju obsega prvega koraka. Na drugi strani pa nam to daje občutek za možna kasnejša nadaljevanja. To je znani MoSCoW.

MoSCoW Mast

Should

Could

Won't

čas Funkcionalnosti

Viri Celoto moramo umestiti tako da: -

Dosežemo ali presežemo tisto kar »mora biti« (must) Ne presežemo maximalnega časa v katerem moramo imeti rezultat Ne presežemo razpoložljive moči

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 6/28 _________________________________________________________________________

Uporabljamo ga na različnih nivojih. Prioritete na nižjem nivoju so v odnosu s prioritetami na višjem nivoju. Na katerem koli nivoju se nahajamo in če imamo neko širšo zamisel, je ta objektivno podvržena prioterizaciji. Če tega ni, težko govorimo o širši zamisli, ampak le o neki izvedbeni aktivnosti. Na oblikovanje celote ima velik vpliv izziv s katerim se spopademo. Imamo dva različna izhodišča:

• •

napraviti nekaj z merjenjem učinka v uporabi napravljenega ("SW na metre") napraviti nekaj z merjenjem učinka ob predaji napravljenega ("SW na kile")

AIM je Oraclova aplikacijsko implementacijska metoda za uvajanje Oracle aplikacij:

Opravilo je enota dela, ki se zaključi z izdelavo izhoda (poročila, rezultati testiranja….). Opravila so v soodvisnosti. Proces je skupek opravil s sorodno vsebino. Faze so skupine opravil, ki vodijo k pomembnejšim naravnim mejnikom napredovanja. Metoda je preiskušen sklop opravil in orodij.

Proces

Opravilo

Faza

Opravilo / Opravilo

V nadaljevanju so podana le ključna opravila kot »podsetnik« na kaj je vse res potrebno biti pozoren. Povezave delujejo le ob namestitvi AIM.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 7/28 _________________________________________________________________________ TASKS AND DELIVERABLES PO FAZAH od A do F [BP] Business Process Architecture A

BP.070 Develop High-Level Process Designs

B

BP.080 Develop Future Process Model

C

BP.090 Document Business Procedures

[RD] Business Requirements Definition A

RD.010 Identify Current Financial and Operating Structure

A

RD.020 Conduct Current Business Baseline

B

RD.040 Gather Business Volumes and Metrics

B

RD.050 Gather Business Requirements

B

RD.060 Determine Audit and Control Requirements

B

RD.070 Identify Business Availability Requirements

B

RD.080 Identify Reporting and Information Access Requirements

[BR] Business Requirements Mapping B

BR.010 Analyze High-Level Gaps

B

BR.020 Prepare Mapping Environment

B

BR.030 Map Business Requirements

B

BR.040 Map Business Data

B

BR.070 Conduct Reporting Fit Analysis

B

BR.090 Confirm Integrated Business Solutions

C

BR.100 Define Application Setups

C

BR.110 Design Security Profiles

[TA] Application and Technical Architecture A

TA.010 Define Architecture Requirements and Strategy

B

TA.050 Define System Availability Strategy

D

TA.110 Define System Capacity Plan

D

TA.120 Define Platform and Network Architecture

D

TA.140 Assess Performance Risks

D

TA.150 Define System Management Procedures

[MD] Module Design and Build A

MD.010 Define Application Extension Strategy

[CV] Data Conversion E

CV.120 Install Conversion Programs

E

CV.130 Convert and Verify Data

[DO] Documentation A

DO.010 Define Documentation Requirements and Strategy

A

DO.030 Prepare Glossary

[TE] Business System Testing A

TE.010 Define Testing Requirements and Strategy

C

TE.040 Develop System Test Script

D

TE.060 Prepare Testing Environments

D

TE.100 Prepare Key Users for Testing

D

TE.110 Perform System Test

E

TE.130 Perform Acceptance Test

[AP] Adoption and Learning

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 8/28 _________________________________________________________________________ A

AP.020 Conduct Initial Project Team

A

AP.030 Develop Project Team Learning Plan

A

AP.040 Prepare Project Team Learning Environment

A

AP.050 Conduct Project Team Learning Events

A

AP.070 Develop Project Readiness Roadmap

A

AP.080 Develop and Execute Communication Campaign

C

AP.140 Develop User Learning Plan

D

AP.160 Prepare User Learning Environment

E

AP.170 Conduct User Learning Events

F

AP.180 Conduct Effectiveness Assessment

[PM] Production Migration B

PM.010 Define Transition Strategy

D

PM.020 Design Production Support Infrastructure

D

PM.030 Develop Transition and Contingency Plan

E

PM.040 Prepare Production Environment

E

PM.050 Set Up Applications

E

PM.060 Implement Production Support Infrastructure

E

PM.070 Verify Production Readiness

E

PM.080 Begin Production

F

PM.100 Maintain System

Po tem delajo pri Oraclu na globalnem nivoju. Pri manjših zadevah (100 x in več) je veliko že storjeno, če se upošteva osnovne principe iz celotnega sklopa neke «lahke« metodološke družine. ( iterativnost, inkrementalnost, time box, MoSCoW …) in da si ustvarimo neko sliko oziroma zamisel o celoti, ki ji potem sledimo v praksi. Podal bom nekaj sestavnih delov in nato celotno skico. To je seveda ena izmed možnih interpretacij. Naslonjena je na principe lahkih metodologij z modifikacijami in dopolnitvami v smeri določenega razumevanja problema v neki konkretni situaciji

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 9/28 _________________________________________________________________________

BSM ( Beseda, Skica, Model )

BESEDA

SKICA

MODEL

Besed, skica, model so sredstva, ki jih uporabljamo pri oblikovanju in delanju rešitev. Pri tem izhajamo iz »besede« in gremo proti modelu. Uporaba samo besede lahko vodi v razdvajanje. Skica osredotoči pozornost, model domisli zamisel. Obratno velja, da uporaba le modela lahko vodi v izgubo komunikativnosti navzven. Skica to razbistri in beseda pojasni. Pri tem uporabljamo konceptualne kategorije, ki so priznane in razumljene v področju našega temeljnega zanimanja. Te konceptualne kategorija se danes oblikujejo globalno. S tem se veča sposobnost komunikacije in pospešujejo pretoki. To zahteva več naslonitev na izvorna mesta, ter izbrane in primerne uporabe najdenega. Povečan razpon med potrebnim razumevanjem in možno uporabo je značilnost novega časa.

SKLAD VEDNOSTI BESEDA

SKICA

MODEL

PRESLIKAVA ZNANJ

Zapisana beseda, narisana skica in napravljen model so rezultat preslikave določenih znanj v sklad vednosti. Tega hranimo, negujemo, upravljamo in uporabljamo skozi izbrano podporno obliko. Ta mora zagotavljati potrebno koordinacijo skladnosti celote in integracijo posameznih delov iz celote. Znanja in sklad vednosti se medsebojno bogatita in olajšujeta in vzpodbujata komunikacijo v iskanju in oblikovanju novih konceptov. Znana je misel, da znanje odhaja domov »na spanje«, sklad vednosti ostaja na svojem mestu in je strateški element organizacije. Dosedanji repozitorij je odigral delno funkcijo sklada vednosti. Novo dinamično stanje bi zežko ujeli v neke predefinirane notranje strukture – potrebna je širša osnova, ki bo strukturalno lahko sledila potrebnim oblikam.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 10/28 _________________________________________________________________________ Model

Osrednje mesto ima model. Model je ponazoritev neke stvarnosti ali zamisli. V modelu imamo običajno dva nivoja: o

pogonski nivo obravnava problematiko primarnih poslovnih prvin, ki je dobro znana vsem v nekem okolju delovanja.

o

Opisni nivo obravnava problematiko znanja. Preko tega dela nosilci znanj v okolju delovanja krmilijo obnašanje sistema. Razpon tega dela je velik. Sega od preprostih šifratvov do zapletenih poslovnih pravil.

S številkami je ponazorjeno zaporedje prevzemanja nadzora nad obnašanjem modela. Kako globoka je generalizacija je odvisno od:
od sposobnosti razvijalcev in njihov znanj iz problemske domene, kar je predpogoj za izvedljivost generalizacije
od uporabnikov, ki morajo podajati opisne podatke v delujoč sistem.
od ekonomike ( cena vzpostave / število namestitev ) Znano je, da se s povečano generalizacijo povečuje prilagodljivost. Cena je večja kompleksnost in če ta preraste prag razpoložljive potenciala znanja v uporabniškem okolju, se lahko zmanjša preglednost delovanja ali celo izgubi nadzor. Prenizka stopnja prilagodljivosti vodi s strani uporabnikov v oceno o togosti sistema.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 11/28 _________________________________________________________________________

D4 (1D =Define, 2D=Design, 3D=Develop, 4D=Deploy) Razvoj programskih rešitev gre skozi različne faze. Vsako faza ima ključni rezultat. V spodnji skici so prikazani trije tipični primeri odvijanja faz.

a./ zaporedni

Faze se zaključujejo same v sebi nakar sledi »pogajanje« o predaji/prevzemu Motiv je uspešna predaja faznega rezultata.

a./ prekrivalni

Faze se med sabo delno prekrivajo. Razdeljene so v fazne inkremente, ki se razrešujejo bodisi v samostojni krožni iteraciji ali pa v medfazni iteraciji v »sodelovanju« Motiv je uspešno delovanje programske rešitve v uporabi. .

c./ hkratni

Faze se odvijajo praktično hkrati. To je predvsem takrat kadar smo sami soočeni s celotno problematiko (»house keeping«) Motiv je uspešna lastna uporaba programske rešitve

V nadaljevanju se bom osredotočil na prekrivalni potek faz (reverzibilnost ! ).

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 12/28 _________________________________________________________________________

Imamo fazne in medfazne iteracije. Korakoma izboljšujemo rezultat fazne iteracije.

1D

1D

4D

2D

3D

4D

2D

3D

Povratki v predhodne faze so odvisni od izbranega načina dela ter stopnje formalizacije prehodov. Kako daleč nazaj moramo poseči določa stopnja pomankljivosti predhodne faze. V skici je z debelino črte določena stopnja običajnosti poti . S črtkanimi pravokotniki je ponazorjeno nekaj možnosti širine vključitve v izvebe faz. Število iteracij je omejeno. Preveliko število iteracij vodi v izgubo osredotočenosti in konciznosti.Vsaka iteracija ima svoj povdarek.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 13/28 _________________________________________________________________________ Ena izmed možnosti je npr:. da izberemo tri iteracije: 1. pripravljalna iteracija

• • • •

seznanimo se z rezultati predhodne faze dokažemo naše razumevanje problema (npr prototip) pokažemo na pomankljivosti predhodne faze v predhodni fazi se izvrši zaključna konsolidacija z odpravo pomankljivosti

2. izvedbena iteracija

• •

z razumevanjem zaključne konsolidacije predhodne faze se posvetimo izvedbi izvedbo posredujemo predhodni fazi v preizkus

3. konsolidacijska iteracija

• • •

na podlagi ugotovljenih pomankljivosti in že doseženem rezultatu se lotimo konsolidacije rezultata konsolidiran rezultat preverimo v pripravljalni iteraciji nasledne faze izvršimo zaključno konsolidacijo

Konsolidacijska iteracija

Pripravljalna iteracija

Izvedbena iteracija

Rezultat zadnje faze je nameščena programska rešitev ( verzija produkta ). Spiralna iteracija produkta z produktnim inkrementom daje nove vrednosti produktu.

Prej opisane medfazne iteracije potekajo v primeru kadar prevladuje princip sodelovanja. V tem primeru je prioritetna lista višjega nivoja vidna tudi iz nižjih nivojev. Z njo se dokazuje in preverja širina zamisli in podaja splošna orientacija vsem sodelujočim.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 14/28 _________________________________________________________________________ Skica osredotočanja pri razvoju programskih rešitev : D4 & BSM & IS

Fazna iteracija (krožna)

Produktni inkrement

Medfazna iteracija 1D

2D

3D

4D 1D

2D

3D

4D

I Z V E D L J I V O S T

Produktna iteracija (spiralna) D4………( 1D = Define, 2D = Design, 3D = Develop, 4D = Deploy )

Čas za začentno verzijo produkta

Čas za naslednjo verzijo produkta

MoSCoW Mast

Should

Could

Won't čas

Funkcionalnosti

Viri SKLAD VEDNOSTI BESEDA

SKICA

MODEL

Gubi 4.7.06

PRESLIKAVA ZNANJ

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

S P R E J E M L J I V O S T

Ogrodja v IRC okolju in smeri razvoja (v1) 15/28 _________________________________________________________________________

D in jD D označuje konkretnost »tradicionalne« orodjarne (Designer, Forms, Report). JD označuje jDeveloper situacijo z geslom »produktivnost z izbiro«. Kako bomo iskali nek rezultat ?

?

D

R(D)

R(D + jD)

+

jD

R(jD)

Odnos med bazami in aplikacijami je prikazan v spodnjih skicah (Scott Ambler):

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 16/28 _________________________________________________________________________

ADF in ADFBC ( aplikacijsko razvojno ogrodje )

Oraclova ADF aplikacijska arhitektura je prikazana v spodnji skici.

Oracle je sedaj oblikoval in dokumentacijsko podprl dve smeri: -

za uporabnike iz Forms/4GL okolij (na kratko ADFBC) za naprednejše uporabnike (na kratko ADF )

Na skici so povdarjeni elementi ADFBC smeri. Kjučni element predstavlja plast ADF Model, ki je implementacija standarda JSR 227. Novsost je ADF Controler in ADF Faces - izvedenih iz UIX. ADF Business Components so izvedeni iz BC Business Components

V dokumentaciji : Application Development Framework Developer’s Guide For Forms/4GL Developers 10g Release 3 (10.1.3.0) - B25947-01 / June 2006, je tako sedaj prvič celovito podan opis ADFBC smeri ( nekaj čez 1000 strani ). Pri tem so vključene vse novosti in dopolnitve. ( http://download-uk.oracle.com/docs/html/B25947_01/toc.htm ) Iz kazala so spodaj navedena poglavja, ki podajajo osnove. Z njimi se je najbolje seznaniti na izvornem mestu. 1 Introduction to Oracle ADF Applications

• • • •

1.1 1.2 1.3 1.4

Introduction to Oracle ADF Framework Architecture and Supported Technologies Declarative Development with Oracle ADF and JavaServer Faces Highlights of Additional ADF Features

2 Overview of Development Process with Oracle ADF and JSF

• • • • • • • • • • •

2.1 Introduction to the Development Process 2.2 Creating an Application Workspace to Hold Your Files 2.3 Thinking About the Use Case and Page Flow 2.4 Designing the Database Schema 2.5 Creating a Layer of Business Domain Objects for Tables 2.6 Building the Business Service to Handle the Use Case 2.7 Dragging and Dropping Data to Create a New JSF Page 2.8 Examining the Binding Metadata Files Involved 2.9 Understanding How Components Reference Bindings via EL 2.10 Configuring Binding Properties If Needed 2.11 Understanding How Bindings Are Created at Runtime

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 17/28 _________________________________________________________________________

• • •

2.12 Making the Display More Data-Driven 2.13 Adding the Edit Page and Finishing the Use Case 2.14 Considering How Much Code Was Involved

4 Overview of ADF Business Components

• • • • • •

4.1 4.2 4.3 4.4 4.5 4.6

Prescriptive Approach and Reusable Code for Business Services What are ADF Business Components and What Can They Do? Relating ADF Business Components to Familiar 4GL Tools Overview of ADF Business Components Implementation Architecture Understanding the Active Data Model Overview of ADF Business Components Design Time Facilities

• 11 Getting Started with ADF Faces

• •

11.1 Introduction to ADF Faces

12 Displaying Data on a Page 13 Creating a Basic Page

• •

13.1 Introduction to Creating a Basic Page

14 Adding Tables

• • • • • • •

14.1 14.2 14.3 14.4 14.5 14.6 14.7

Introduction to Adding Tables Creating a Basic Table Incorporating Range Navigation into Tables Modifying the Attributes Displayed in the Table Adding Hidden Capabilities to a Table Enabling Row Selection in a Table Setting the Current Object Using a Command Component

15 Displaying Master-Detail Data

• • • •

15.1 Introduction to Displaying Master-Detail Data 15.2 Identifying Master-Detail Objects on the Data Control Palette 15.3 Using Tables and Forms to Display Master-Detail Objects

16 Adding Page Navigation

• • • •

16.1 16.2 16.3 16.4

Introduction to Page Navigation Creating Navigation Rules Using Static Navigation Using Dynamic Navigation

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 18/28 _________________________________________________________________________ ADFBC smer in variante

ADFBC smer je oblikovana tako, da olajšuje prehod razvijalcem iz tradicionalnega Oracele razvojnega okolja v J2EE okolje.

Možnosti uporabe ADFBC lahko uvrstimo v tri variante: a./ varianta samostojnih ADFBC aplikacij V tej varianti startamo na samostojne aplikacije. Te niso navezane na dosedanje rešitve in prav tako niso povezane med seboj. Celoten razvoj lahko poteka in se oblikuje v smislu potreb posameznih aplikacij. b./ varianta združljivih ADFBC aplikacij z obstoječimi rešitvami V tej varianti startamo na postopno razširjanje in preoblikovanje aplikacijske podpore za širši problemski sklop. Obstoječe rešitve zadržimo v uporabi. Te dopolnimo z ADFBC aplikacijami, predvsem v primerih podpore za tiste funkcionalnosti, za katere je stara arhitektura preslabotna ( npr. samopostrežne aplikacije ). Načrtovanje in vzdrževanje baznih objektov je vodeno z vidika potrebnosti celotnehga problemskega sklopa. Prevladuje torej bazno centrična orientacija. Varianta baze z »nadgradnjo«

Obstoječe aplikacije

ADF aplikacije ADF aplikacije

Poslovne komponente

Skupna deljena shema (baza)

Varianta baze z »dogradnjo«

Obstoječe aplikacije

ADF aplikacije ADF aplikacije

Poslovne komponente

Obstoječa shema

Nova shema

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 19/28 _________________________________________________________________________

c./ varianta nove družine ADFBC aplikacij V tej varianti startamo na novo družino aplikacij. Med aplikacijami so povezave in aplikacije tvorijo neko celoto. Najmanj je to »look and feel«. Ta varianta prihaja v poštev v primeru odločitve o opustitvi sedanjih rešitev in prehodu na novo družino aplikacij. Bazno zasnovo se preoblikuje v smislu novega koncepta. Celoten razvoj poteka v okviru novega razvojnega okolja skozi jDeveloper. Ta varianta je v sedanjem stanju naše usposobljenosti težko izvedljiva. Prav tako je tudi v smislu praktične stabilnosti smeri še mnogo odprtega.

Vsaka varianta ima svoje specifike in uporabnosti. Izbira je pogojena z želenim ciljnim stanjem in z izvedljivostjo. Pri tem veljajo naslednje predpostavke:

•

naše rešitve bodo naslonjene na Oraclova razvojna ogrodja in tehnologijo

•

večina naših rešitev ostaja kratkoročno v dosedanjih arhitekturalnih oblikah

•

naša ciljna zahtevnejša namestitvena platforma je Oracle aplikacijski server

•

z ADF oziroma ADFBC sledimo razvoju pri Oraclu.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 20/28 _________________________________________________________________________

Primer napravljen s ADF Faces V naslednih nekaj slikah so podani prikazi iz enostavnega primera razvitega v okolju : baza 10 XE, Jdev 10.1.3, OC4J 10.1.3 .Prikazi podajajo zunanji pogled na problem dinamičnega določanja načina in vsebine prikaza določene poslovne prvine.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 21/28 _________________________________________________________________________

Izsek iz baze

Izsek iz navigacije

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 22/28 _________________________________________________________________________

Osnovni prikaz

Dinačna izbira prikaza kolon

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 23/28 _________________________________________________________________________

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 24/28 _________________________________________________________________________

Različni izhodni prikazi

Primer napravljen z Application Express

Application Express (APEX) je novo ime za HTML DB. To je ne-javanska Oraclova linija. Začetni korak v to smer je bil WebDB ( leto 1999 ), ki je bil uporabljen tudi pri nas v okviru G2. O zaznanih novih momentih (tržnih in tehnoloških), ki so nastopili z objavo xe baze sem posebej opozoril v začetku leta 2006. O teh možnostih se manj piše in govori, ker nima širše »akademske« podpore, oziroma jo ta označuje kot »Oracle igračko«. Njena bazno centrična naravnanost, velika deklarativnost, dober interface in »enostavnost« uporabe in še kaj, ji dajeta praktično vrednost v različnih situacijskih kontekstih. To velja predvsem v primerih, ko se osredotočimo na rešitev problemskega pojava in v primerih, ko nimamo na razpolago širše kompleksnejše podpore, ali pa ta vodi v »knedeljske reference« ter v preslabo odzivnost. Kljub svojemu manjšemu dometu, lahko v »enostavnih« in »malih« problemskih situacijah deluje učinkovito. Uporaba lahko sega od enouporabniško-večnamenske (ad hoch) situacije, do večuporabniškeožjenamenske (enonamenske) načrtovane situacije .

Napravljen ilustrativni primer je zasnovan za dinamično delo v manjši skupini, zato je naslonjen na tabelno vodeno ogrodje za upravljanje dodeljevanja aplikacij različnim uporabnikom, glede na njihovo vlogo v delovni skupini. To odpira možnost graditve konsistenejše celote z potrebno gibkostjo ter odzivnostjo na spremembe delovanja. V novih pogojih, ko so viri in čas konstanti in je funkcionalnost spremenljivka, predstavlja »apex« v informacijsko osveščeni sredini možno alternativo.

Spodje tri slike ilustrirajo zapisano.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 25/28 _________________________________________________________________________

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 26/28 _________________________________________________________________________ Zaključek ADF je sedaj relativno koncepcijsko jasen in lahko pričakujemo hitro zorenje in migracije v tej smeri. ADFBC s svojo večjo stopnjo deklarativnosti in vizuelnosti je lažje osvojljiv za razvijalce iz Forms/4GL okolij in jim ponuja možnost postopnejšega prehoda v nove oblike. IRC je z odločitvijo o nadgradnji obstoječih rešitev v smeri možnosti nameščanja le teh na Oracle aplikacijski server oziroma forms server, že izvedel korak postopnosti v smislu prehoda na Oraclovo namestiveno platformo. Za temi rešitvami je števična usposobljena ekipa. Zato so ADFBC aplikacije kot združljive aplikacije z obstoječimi rešitvami logično nadaljevanje. Manjša skupina se je že seznanila z ADF in ima za seboj prve izkušnje. Z temi apliakcijami se predvsem razrešujejo tisti problemi, za katere je prejšna oblika prešibka . V nove oblike se ne spuščamo zaradi večje produktivnosti ( ta je manjša ), ampak zaradi doseganja novega aplikacijskega potenciala. Predvsem pa moramo ostati kompatibilni z dogajanji in preprečiti prevelik zaostanek, ki bi se prelevil v nendomestljivega. Novosti bodo postopno izrinile starejše oblike. Če že ne zaradi potrebe, bo to zaradi globalnega razvojnega pritiska.

Aplikacijski potencial Krizni interval

Privlačnost nove aplikacijske arhitekture Zahtevnejši segment

Privlačnost stare aplikacijske arhitekture Potreben potencial na nekem segmentu

Manj zahteven segment

Uporaba starega Priprava novega

čas Uporaba novega

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 27/28 _________________________________________________________________________

P O T R E B E

MOŽNOSTI Staro

Novo

Staro

Preteklost

Vsebinska zastarelost

Novo

Tehnološka zastarelost

Sodobnost

Programske rešitve bodo uspešne, če bomo na prav način ( glede na možnost) reševali prave problemske vsebine ( glede na potrebe ). Naslonitev na ogrodja je danes nujnost (glej dodatek). Izbira pravega ogrodja je ključnega pomena za nadaljna odvijanja. ADF ogrodje je ena izmed možnosti. V naših razmerah stanja programskih rešitev in obstoječih povezav, je uporaba te možnosti na meji imperativa poti v sodobne oblike in vsebine. Application Express je alternativa za manj zahtevne situacije in bolj klasično (PL/SQL) reševanje. Pogojno ga lahko uporabimo tudi za dopolnilne in pomožne rešitve v različnih kombinacijah. Ko enkrat vemo kam hočemo priti, je zožen nabor sredstev (arhitektur) tako, da imamo optimalni odnos med problemom in rešitvijo. Zavedati pa se je potrebno tudi dejstva, da ko prestopimo nek prag kompleksnosti problema vstopimo tudi v svet drugih zakonitosti. To naj za konec ilustrira geometrijska primerjava. Trikotnik v lokalnosti, je "ravninski" problem. Trikotnik v globalnosti je "sferni" problem. V novi kompleksnosti je vsota kotov v trikotniku večja od 180 stopinj. In ko se srečujemo z problemi preslikav "sfere" na "ravnino", pač enostavno ni možno istočasno dobiti komforno in ekvidistančno sliko stanja preslikave.

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek

Ogrodja v IRC okolju in smeri razvoja (v1) 28/28 _________________________________________________________________________

Priloga 1- poudarki iz članka »AJAX« V prilogi so podani odlomki iz članeka v Monitorju 06/2006 - Uroš Mesojedec - AJAS, ki dodatno pojasnujo sedanje razmere hitrega odzivanja ponudnikov razvojnih ogrodij. V tem sklopu so tudi ADF Faces. ....Še več, počasi se skozi globalno telekomunikacijsko omrežje, storitveno usmerjene arhitekture in programske gradnike spet selimo v svet zmogljivih strežnikov in bolj ali manj preprostih odjemalcev, "terminalov"..... Omrežje je torej ključni element računalniške izkušnje, ki precej spreminja uveljavljene načine rabe strojne in programske opreme. Uveljavljenim monopolistom je sicer skoraj desetletje in pol uspevalo zavlačevati to revolucijo, a je kljub temu na nezaustavljivem pohodu. Da je prihodnost programske opreme v storitvah, je danes že povsem jasno. Še starejša modrost računalništva pa je, da uspeh vsake podlage odločujoče krojijo njene aplikacije. In tu so ključni člen razvijalci. Zato se je eden najpomembnejših mož programske industrije tudi tako mučil s kričanjem: "Razvijalci, razvijalci, razvijalci...". Še posebej presenetljivo pa je to, da razvijalce v množicah pritegne predvsem poenostavitev pri izgradnji uporabniških vmesnikov. Zdi se nenavadno, toda dokazov imamo na pretek. Najbolj priljubljeno razvojno okolje je še vedno Visual Basic. Predvsem zato, ker je ponudil učinkovit, vizualni urejevalnik za izdelavo uporabniškega vmesnika..... Učinkoviti uporabniški vmesniki, ki jih je mogoče izgraditi na čim lažji način, so tudi ključ do uspeha preglednic. Ta prototipna ubijalska aplikacija je še danes eno najbolj priljubljenih računalniških orodij in v sodobnih različicah omogoča izdelavo zelo zapletenih, a hkrati zelo vizualnih programov. Zato ne čudi, da se ravno po modelu preglednice zgledujejo številni raziskovalci, ki želijo spremeniti način razvoja programske opreme tudi za druge "problemske prostore", ne le za računovodje, ki z veščim obvladovanjem preglednic lahko sami, brez vmešavanja programerjev, rešijo marsikateri problem. Pomen uporabniškega vmesnika se še povečuje z vedno večjo "komponentizacijo" programja. Programerska ogrodja so ves bolj zmogljiva in vseobsegajoča in dejanski izziv je izbrati prave gradnike, jih med seboj povezati in ponuditi uporabniku skozi čim bolj učinkovit uporabniški vmesnik. Seveda, ključ je v storitvah. Toda v vsakem primeru jih bo treba ponuditi končnim uporabnikom.... ....Enostavnost priprave spletnih strani, ki jih lahko gradimo že s preprostimi urejevalniki besedila, in prizanesljivost spletnih brskalnikov, ki odpuščajo številne malomarnosti v "programu", so za priljubljenost spleta naredili skoraj toliko kot preprosto kombiniranje oblikovanega besedila in grafike v poenostavljenem označevalnem jeziku. Vendar je splet trpel za pomanjkljivostjo, ki je pri običajni, namizni programski opremi nismo opazili. Spletne strani so za vsako posodobitev vsebine morale na posvet k strežniku in ta je pripravil novo stran in jo poslal nazaj odjemalcu. Spletni programi so zato vezani na odzivnost omrežja in kot takšni neprimerni za marsikatero dejavnost. Dokler ni nekdo odkril, da je spletni brskalnik v resnici precej več kot členitelj označenega besedila. Vnovično odkritje skriptnega jezika, ki zna krmiliti vsak drobec spletne strani, je rodilo Ajax.... ....Ajaks je torej predvsem priljubljena kratica, ki obljublja učinkovito prenovo poglavitnega uporabniškega vmesnika današnjih dni. To pa nas znova pripelje do razvijalcev, ki morajo takšne uporabniške vmesnike pripraviti. Tako ne sme nikogar presenetiti neverjetna odzivnost glavnih ponudnikov programskih ogrodij, ki so drug drugega prehitevali v "ajaksifikaciji" spletnih gradnikov. Atlas iz Microsofta in JSF 1.2 iz javanskega tabora sta le dve najbolj sveži napovedi..... "Razvijalce v množicah pritegne predvsem poenostavitev pri izgradnji uporabniških vmesnikov."

_________________________________________________________________________________ interno delovno gradivo / poletje 2006 Marjan Gubenšek