Aplikační vrstva javových aplikací

Nejde o nic jiného, než o zajištění, aby výsledný navržený program splňoval specifikaci, tj.:

K dosažení tohoto ideálního stavu vede budto čistě formální cesta:

Dále zmiňované nástroje však toto nedokážou; omezují se na běhovou kontrolu platnosti předpsaných podmínek

jass je preprocesor javového zdrojového textu. Umožňuje ve zdrojovém textu programu vyznačit podmínky, jejichž splnění je za běhu kontrolováno.

Podmínkami se rozumí:

Postup práce s jass:

Uvádíme pragmaticky jen to, co je potřeba zde (pro potřeby IoC), nechápat jako komplexní terminologii.

V komponentních systémech bývá tradičním problémem zajistit správnou inicializaci a provoz komponent závislých na ostatních.

Co je třeba udělat při nasazení jedné nové komponenty

Postup vypadá přímočaře, ale je bohužel rekurentní... v bodě 1 (připravit komponenty...) se opakuje rekurentně celý postup

V Inversion of Control obracíme tento (pro komponentního programátora) nepraktický, obtížný postup.

O řešení závislostí se postará rámec (kontejner), komponenta pouze deklaruje na čem závisí.

Historicky se postupně vyvinuly tři přístupy k "injektáži" potřebných závislostí; tedy k IoC:

Blíže viz popis k IoC v systému (rámci) vraptor a následující slidy.

Komponenta MUSÍ IMPLEMENTOVAT určité, rámcem/kontejnerem dané rozhraní (příklad z článku Intro. to AOP):

import org.apache.avalon.framework.*;

  public class JDBCDataManger implements Serviceable {
    DataSource dataSource;
    public void service (ServiceManager sm) 
          throws ServiceException {
      dataSource = (DataSource)sm.lookup("dataSource");
    }
    
    public void getData() {
      //use dataSource for something
    }
}

Nevýhoda: musí implementovat dané rozhraní, nelze vyvíjet zcela nezávisle.

Komponenta je jako objekt JavaBean, má setXXX metody:

public class JDBCDataManger {
  private DataSource dataSource;
  
  public void setDataManager(DataSource dataSource {
    this.dataSource = dataSource;
  }
  
  public void getData() {
      //use dataSource for something
  }
}

Rámec (kontejner), např. Spring musí vědět, jak komponentu vytvořit a na čem závisí:

<bean id="myDataSource" 
  class="org.apache.commons.dbcp.BasicDataSource" >
  <property name="driverClassName">
    <value>com.mydb.jdbc.Driver</value>
  </property>
  <property name="url">
    <value>jdbc:mydb://server:port/mydb</value>
  </property>
  <property name="username">
    <value>root</value>
  </property>
</bean>

a druhá komponenta:

<bean id="dataManager" 
  class="example.JDBCDataManger">
  <property name="dataSource">
    <ref bean="myDataSource"/>
  </property>
</bean>

Oproti Interface Injection: netřeba implementovat rozhraní

Je ale nezřetelné, které setXXX metody jsou pro účely nastavení závislostí přes Setter Injection a které ne.

Odpovídá přístupu "Good Citizen" (označení zavedl J. Bloch ze Sun):

public class JDBCDataManger {
  private DataSource dataSource;
  
  public JDBCDataManger(DataSource dataSource) {
    this.dataSource = dataSource;
  }
  
  public void getData() {
      //use dataSource for something
  }
}

Existují jednoduché (lightweight) kontejnery pro nasazení a provoz komponent s využitím IoC.

Tyto kontejnery mnohdy neumí nic navíc, jde jen o základní správu komponent.

Příkladem je PicoContainer a Spring, který je však komplexnější (a složitější).

Příklad převzatý z weblogu Jablok Pavla Kolesnikova (typický kód aplikační logiky):

public class KusAplikacniLogiky extends ObecnejsiKus {
  // data tridy;
  // jina pomocna data;

  // pretizeni rodicovskych metod

  public void provedNecoPodstatneho () {
    // autentizace
    // autorizace

    // dalsi nezajimavy kod
    // logovani zacatku operace

    // vlastni aplikacni logika — konecne!

    // logovani ukonceni operace
    // treba jeste neco
  }
}

Překlad článku Graham O'Regana Introduction to Aspect-Oriented Programming na onjava.com nastiňuje hlavní principy:

Postupy AOP řadíme mezi deklarativní programování.

Deklarativní programování pomocí anotací bylo zmiňováno u Java Persistence API.

Pomocí anotací lze technicky vyřešit i AOP.

AspectJ (použito i ve Springu - od 2.0 pomocí anotací)

Aspectwerkz

Kontejnery a aplikační servery

<beans>
    <bean id="nejakaFirma" class="cz.neco.Zamestnavatel" />

    <bean id="franta" class="cz.neco.Zamestnanec" >
	<property name="jmeno"><value>František Novák</value></property>
	<property name="zamestnavatel" ><ref bean="nejakaFirma" /></property>
    </bean>
</beans>

V tomto případě by kontejner prostřednictvím reflexe provedl kód ekvivalentní tomuto:

Zamestnavatel nejakaFirma = new Zamestnavatel();
Zamestnanec franta = new Zamestnanec();
Franta.setJmeno = "František Novák";
Franta.setZamestnavatel(nejakaFirma);

Pojmenujeme-li tento definiční XML soubor "kontext.xml" a umístíme-li jej do classpath, pak kontejner nastartujeme například takto:

ApplicationContext context = new ClassPathXmlApplicationContext("/kontext.xml");

Vytvořeného zaměstnance s id "franta" získáme z kontejneru voláním:

Zamestnanec z = (Zamestnanec)context.getBean("franta");

Pomocí dalších deklarací v tomtéž XML souboru lze definovat, jakým způsobem budou dříve vyjmenované služby poskytnuty našim objektům. Naše třídy se tedy nemusí například transakčním či bezpečnostním managementem zabývat, vše zajistí Spring.

Přes JMX se řídí:

Vhodnými kandidáty na JMX (MBeans) jsou takové komponenty, které:

Model systému řízeného JMX zahrnuje:

Přes JMX se může řídit prakticky cokoli v javovém systému:

JMX ovládá zdroje prostřednictvím tzv. _rapperu_ který:

Jaké podoby může wrapper nabývat?

Komponenta koncipovaná jako MBean je často vytvářena takto:

FibonacciCounter.java - původní komponenta

CounterMBean.java - rozhraní

Counter.java - třída implementující rozhraní

Co odlišuje skriptování od "ostatních" pg. jazyků?

Kdy obvykle (nejen v Javě) cítíme potřebu skriptovat?

Proč je potřeba skriptovat silná právě dnes, když je tolik dokonalých programovacích jazyků s rychlými překladači?

	Poznámka
	Takové rychlovýtvory nezřídka mívají delší životnost než složitě a dlouho budované "pořádné" aplikace - přicházejí rychle a v pravý čas!

Bean Scripting Framework (BSF) je projektem jakarta.apache.org, původně však vytvořený v IBM T.J.Watson Laboratories (jako produkt "alphaWorks").

Jedná se o rámec umožňující:

	Poznámka
	To mj. dovoluje "save of investment" do stávajících skriptů - i z plnohodnotného prostředí (Java) je lze volat!

BSF obsahuje dvě hlavní komponenty:

Tři základní způsoby:

Iterace přes všechna celá čísla 1 až 10 s jejich výpisem:

for (i in 1..10) {
  println "Hello ${i}"
}

Definice mapy (asociativního pole) a přístup k prvku:

map = ["name":"Gromit", "likes":"cheese", "id":1234]
assert map['name'] == "Gromit"

Řízení toku pomocí switch s velmi bohatými možnostmi:

x = 1.23
result = ""
switch (x) {
    case "foo":
        result = "found foo"
        // lets fall through    
    case "bar":
        result += "bar"    
    case [4, 5, 6, 'inList']:
        result = "list"
        break
    case 12..30:
        result = "range"
        break
    case Integer:
        result = "integer"
        break
    case Number:
        result = "number"
    break    default:
        result = "default"
}
assert result == "number"

Protokolování je základní činností sledující běh software v

Protokolování má oproti klasickým přístupům

jasné výhody:

V zásadě dva možné přístupy:

Standardní API je však často ap. serverem také podporováno a má jasné výhody:

Existuje několik "standardních" protokolovacích API:

Obě řešení jsou srovnatelná, log4j je o něco elegantnější a propracovanější. Nejlépe (pokud to stačí) je použít zastřešujícího API:

Existuje několik "standardních" protokolovacích API:

Obě řešení jsou srovnatelná, log4j je o něco elegantnější a propracovanější. Nejlépe (pokud to stačí) je použít zastřešujícího API: