Ale i přesto bylo potřeba do této implementace doimplementovat několik požadavků. Rozhodl jsem se nejprve stávající implementaci pokrýt testy tak, abych tím, co tam doplním nerozbil to, co již funguje. A zde jsem trochu narazil. Implementace tohoto modulu je velice těsně spjata s JMS implementací Weblogicu a navíc tak, že se jedná o několik front, které jsou vzájemně propojeny a zpráva zkrze ně postupně „propadává“ podle definovaných pravidel.

Abych to celé byl tedy schopen spustit jako unit test, musel jsem vyřešit pár „drobností“, a to poskytovatele JNDI kontextu, transaction manager a vlastní implementaci JMS. Pro JNDI kontextu jsem jednoduše využil prostředků Springu. Pro transakční manager jsem využil Bitronix Transaction Manager a pro messagingové služby padlo rozhodnutí na Apache ActiveMQ.

JNDI kontext

Vytvoření vlastního JNDI kontextu je ve Springu triviální úloha. Já jsem si pro to napsal jednoduchou utilitku, která mi ji ještě více zjednodušuje:

package eu.kratochvil.utils.spring;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.mock.jndi.SimpleNamingContextBuilder;

import java.util.HashMap;
import java.util.Map;

/**
 * Simple implementation of JNDI context that should be used in unit-tests
 * within Spring context.
 * 

 * Basic usage is simple:
 * 
 * <bean id="jndiContext" class="cz.isvs.reg.ros.ws.repository.util.MockSpringJndiContext">
 *   <property name="jndiContext">
 *      <map>
 *          <entry key="ros.VstupniFronta" value-ref="destinationVstupniFronta"/>
 *          <entry key="ros.VystupniFronta" value-ref="destinationVystupniFronta"/>
 *          <entry key="weblogic.jms.XAConnectionFactory" value-ref="activeMQConnectionFactory"/>
 *      </map>
 *   </property>
 * </bean>
 *
 * There isn't needet to use something like jndi.properties because jndi context is define
 * directly inside spring context. 
 *
 * @author Jiri Kratochvil (jiri.kratochvil@jetminds.com)
 */
public class MockSpringJndiContext implements InitializingBean {

    public static final Logger logger = LoggerFactory.getLogger(MockSpringJndiContext.class);

    Map jndiContext = new HashMap();

    public void setJndiContext(Map jndiContext) {
        this.jndiContext = jndiContext;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        logger.info("Initializing JNDI context");
        SimpleNamingContextBuilder builder = SimpleNamingContextBuilder.emptyActivatedContextBuilder();
        for (Map.Entry entry : jndiContext.entrySet()) {
            logger.debug("Binding {} in JNDI context", entry.getKey().toString());
            builder.bind(entry.getKey().toString(), entry.getValue());
        }
    }
}

Použití je pak naprosto triviální:

Inicializací tohoto springového beanu se vytvoří JNDI kontext, který obsahuje dvě JMS fronty a ještě connection factory, o které budu mluvit dále. Pokud použijete Spring není potřeba dále definovat jak se k JNDI kontextu připojit, což se běžně dělá pomocí property souboru jndi.properties umístěném na classpath.

JMS server

Dále tedy potřebujeme vytvořit instanci embedovaného JMS serveru. Pro mé účely jsem zvolil Apache ActiveMQ, který jde snadno inicializovat pomocí Springu, kde to vypadá následovně:

Popis co a proč je použito v předchozím listingu jsou přímo v něm, tedy ve stručnosti. Vytvořili jsme si instanci message brokeru, který nám nahrazuje vlastní JMS server v aplikačním serveru, následně jsme zadefinovali jednotlivé fronty, které jsou použity ve vlastní implementaci business logiky a konečně connection factory, která nám umožní napojení vlastních listenerů JMS front a zároveň přes ni budeme posílat testovací zprávy z našit unit testů.

Nyní bych se ještě vrátil k tomu, proč jsem do JNDI kontextu umístil weblogic.jms.XAConnectionFactory. Důvod je takový, že aplikace, které využívají JMS ve Weblogiku by měli referenci na connection factory získávat právě z JNDI.

Transaction Manager

Poslední věc, kterou musíme vyřešit bez aplikačního serveru je transaction manager – tedy „něco“, co nám bude řídit vlastní transakce. Na to jsem použil Bitronix Transaction Manager což je celkem mocná implementace transakčního manažeru. Pro naše účely bude použití triviální:

Závěrem

Kouzlo tohoto použití je v tom, že nyní stačí spustit unit test, který inicializuje springový kontext a zároveň načte definici kontextu vlastní aplikace, která právě využívá JNDI pro získání referencí na fronty a vše by mělo fungovat stejně, jako kdybychom tuto implementaci měli deployovanou přímo na aplikačním serveru. Pro úplnost dodávám ukázku definice kontextu přímo v aplikaci:

Na celém tomto cvičení je pěkné to, že jednoduchou springovou konfigurací jsme schopni rozchodit určitou část aplikace, která za normálních okolností nelze bez aplikačního serveru spustit, a my si tak můžeme napsat testy, které lze snadno spouštět bez neustálého a otravného redeploymentu na aplikační server.

   ...
    
   ...
        
            javax.xml
            jaxws-api
            2.0EA3
            provided
        
        
            com.sun.xml
            jaxws-rt
            2.0EA3
            provided
        
   ...
    
 

Jako scope těchto knihoven uvedeme, že jsou provided, což v praxi znamená, že knihovny budou použity pro kompilaci, ale nezaintegrují se do výsledného balíku. To proto, že Weblogic má tyto knihovny vlastní a naším cílem je použít právě implementaci aplikačního serveru.

Implementace webových služeb

Nyní si vytvořime a vystavíme vlastní webové služby. Služby budou definovány svým rozhraním a implementací. Rozhraní webové služby pak může vypadat třeba takto:

package eu.kratochvil.clanky.ws;

import javax.jws.*;

@WebService(targetNamespace = "http://schema.kratochvil.eu", name = "TestService")
public interface TestService {

    @WebMethod
    String sayHello(@WebParam(name = "name") String name);

}

A ještě implementace vlastní „business logiky“:

package eu.kratochvil.clanky.ws;

import javax.jws.WebService;

@WebService(endpointInterface = "eu.kratochvil.clanky.ws.TestService")
public class TestServiceImpl implements TestService {

    @Override
    public String sayHello(String name) {
        return "Hello " + name + "!";
    }
}

Z implementace je zřejmé, co naše služba dělá a není potřeba nějak složitě popisovat. Důležité jsou anotace WebService a WebMethod, které nám popisují vlastní rozhraní webové služby. Další anotace, jako je například WebParam a podobně složí k přesnému popsání a definici kontraktu webové služby a v budoucnu o tom napíšu nějaký článek. Do té doby doporučuji použít dokumentaci.

Posledním krokem je konfigurace našeho webového archívu. K tomu slouží znamý web.xml, který je klasicky umístěn v adresáři WEB-INF naší aplikace a ještě sun-jaxws.xml.

Soubor _web.xml_ bude obsahovat následující:

    
        
            com.sun.xml.ws.transport.http.servlet.WSServletContextListener
        
    
    
        jaxws
        com.sun.xml.ws.transport.http.servlet.WSServlet
    
    
        jaxws
        /testService
    

Tímto donutíme weblogic, aby vystavil servlet, který bude handlovat naše webové služby. Samozřejmě je možné použít v definici patternu znaky wildcard například takto:

    
        jaxws
        /ws/*
    

Pak budou servletem pro webové služby zpracován jakýkoliv požadavek, podle zadané masky (například /ws/users nebo /ws/loans).

Poslední konfigurační soubor, který musíme vytvořit, aby nám začaly korektně fungovat webové služby je sun-jaxws.xml, který je také umístěn v adresáři WEB-INF naší aplikace. Jeho podoba je následující:

Zabezpečení webové služby

Nyní se konečně dostáváme k tomu, jak zabezpečit webové služby pomocí standardních prostředků aplikačního serveru Weblogic. Nejprve se přihlásíme do konzole aplikačního serveru, kde se proklikáme na správu uživatelů přes menu pomocí položky Security Realms. Následně vybereme konkrétní realm (defaultně myrealm). Na záložce Users and Groups si založíme uživatele, kterým se chceme autentizovat pro využívání našich webových služeb.

V našem případě jsme si vytvořili uživatele test, kterého zařadíme do nějaké, námi vytvořené skupiny (například TestGroup).

Tímto máme základní konfiguraci aplikačního serveru hotovou a dalším krokem bude nastavení naší aplikace. Úplně nejjednodušší cestou je přidání následujících několika řádků do souboru web.xml:

    
        Security for WS
        
            WSPOST
            
            
            /testService
            POST
        
        
            TestGroup
        
    
    
        BASIC
        myrealm
    
    
        TestGroup
    

Zde definujeme, co chceme zabezpečit, jaká skupina uživatelů je oprávněna používat naše služby apod. Pokud náš projekt nyní zkompilujeme a nasadíme na aplikační server, měli bychom být dotázání na heslo ve chvíli, kdy se pokusíme zavolat naši webovou službu, což si můžete vyzkoušet například pomocí skvělého nástroje SoapUI.

V článku jsem záměrně nepoužíval nic jiného než jen JAX-WS, tedy žádný Spring Security ani nic podobného. Výhodou je, že se vám tímto přístupem zjednoduší deployment a hlavně získáte skvělé možnosti, jak vaší aplikaci zaintegrovat do firemní infrastruktury, bez složitého nastavování. Weblogic vám totiž nastaví admin serveru, který Vám zároveň vytvoří i nějakou roli, kterou pak následně budete ve své aplikaci využívat. No a správa uživatelů a hesel pro aplikace, které vaše služby budou využívat je také věc administrátora. Navíc lze samozřejmě aplikační server klientské aplikace nastavit tak, aby autentizaci prováděl pro aplikaci transparentně, takže odpadá složitá správa hesel na obou stranách, ale o tom zase někdy příště.

import ...

@WebService(targetNamespace = "http://schemas/wsdl")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
public interface Documentation {

    @WebMethod
    @WebResult(name = "receiveDocument")
    @XmlMimeType("application/octet-stream")
    DataHandler getDocument(
            @WebParam(name = "documentId",
                    targetNamespace = "http://schemas/wsdl",
                    mode = WebParam.Mode.IN) Integer documentId);
}

a následná implementace:

import ...

@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Pokud chceme používat SOAP attachmentů, můžeme využít implementace od SUNu (vlastně teď Oraclu). Souhrnně se této technice říká Message Transmission Optimization Mechanism (zkráceně MTOM) a právě SUN nabízí pro tyto účely implementaci pro JAX-WS (upozorňuji, že třeba v AXISu to funguje úplně jinak).

Vše se tváří naprosto triviálně – stačí jako jeden výstupní parametr použít s typem javax.activation.DataHandler, nastavit u tohoto parametru pomocí javax.xml.bind.annotation.XmlMimeType správný content type a celou třídu oanotovat pomocí @MTOM. Vše by mělo zázračně začít fungovat. Jenže ono to nefunguje.

Ač o tom není v dokumentaci ani zmínka záleží na tom, kde se anotace umístí. Tato anotace se totiž neumisťuje do interface, kde bych to očekával, ale přímo do třídy, která implementuje naše rozhraní této webové služby. Abychom nám začali fungovat attachmenty, upravíme příklad, který jsem uvedl na začátku tohoto článku:

import ...

@MTOM
@StreamingAttachment(parseEagerly = true, memoryThreshold = 40000L)
@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Přidal jsem dvě anotace: @MTOM a @StreamingAttachment(...). Ta první aktivuje tuto funkčnost a od nyní se všechny atributy typu DataHandler budou přenášet jako SOAP attachment. Anotaci @StreamingAttachment(...) využijeme v případě, že budeme přenášet skutečně velké soubory a posílání souboru nám bere moc paměti. A ještě jedna chytrá věc-v anotaci @MTOM je parametr threshold, který říká, od jaké velikosti se daný element pošle jako SOAP attachment a kdy se pošle přímo v elementu samotné zprávy.

Na závěr ještě ukázku, jak pak vypadají data ze služby:

HTTP/1.1 200 OK
Date: Sat, 06 Feb 2010 07:46:28 GMT
Transfer-Encoding: chunked
Content-Type: multipart/related;start="";type="application/xop+xml";boundary="uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e";start-info="text/xml"
X-Powered-By: Servlet/2.5 JSP/2.1

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: 
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Transfer-Encoding: binary



  
    
      
        
      
    
  

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: <383e4726-8e85-4a46-a917-23811ec4ef3e@example.jaxws.sun.com>
Content-Type: application/pdf
Content-Transfer-Encoding: binary

%PDF-1.4
.
.
.
%%EOF

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e-

javax.xml.ws.WebServiceException: javax.net.ssl.SSLKeyException: 
[Security:090477]Certificate chain received from mw.company.com - 10.0.0.1 
was not trusted causing SSL handshake failure.

Jak z toho wen? Musíme náš server naučit pracovat s certifikátem protistrany. Weblogic pro práci s certifikáty využívá několik cest. Já si pro dosažení kýženého cíle zvolil standardnější cestu, a to přes java key store.

Začneme s tím, že si vytvořime náš serverový certifikát:

keytool -genkey -file ./app_server.jks

Tím se nám na aplikačním serveru vytvoří keystore s naším serverovým certifikátem. Následně musíme získat veřejný certifikát protistrany. Buď nám jej pošle hodný správce serveru nebo si jej stáhneme (například pomocí webového browseru). Tento server si naimportujeme do jiného key store:

keytool  -keystore ./micros_trust.jks -import -file ./alsb.cer

(soubor alsb.cer obsahuje veřejný klíč protistrany)

Nyní už nám nezbývá nic jiného, než nakonfigurovat Weblogic. V menu zvolíme Enviroment->Servers. Vybereme si node, na kterém máme nadeployovanou aplikaci a následně zvolíme záložku Keystores.

V combo boxu zvolíme volbu Custom Identity and Custom Trust.

Následně si nastavíme cesty v jednotlivým keystore, vyplníme typ (JKS) a hesla.

A to je vše. Od této chvíle bude Weblogic věřit pouze certifikátům, které máme v našem keystore. Navíc budou SSL spojení na náš server zabezpečena certifikátem, který jsme si vyrobili v prvním kroku.