Korzystamy z profesjonalnych narzędzi takich jak Tibco, WebMethods, czasami Bea.

Co łączy wymienione produkty? Otóż wszystkie są rozwiązaniami z klasy EAI i … są płatne. Zdanie to usłyszałem w odniesieniu do Apache Service Mix, którym się interesuję. Wniosek z tej wypowiedzi jaki udało mi się wysnuć od razu stał się tematem tej noty, czyli jeśli coś nie jest komercyjne nie jest też profesjonalne. Tak jakby OSS był gorszym rozwiązaniem od kupienia licencji na pudełkowe rozwiązanie od jakiegoś producenta.

Trudno mi się z tym zgodzić ponieważ od początku swojej pracy obracam się w otwartym kodzie i niejeden raz korzystałem z wolnodostępnych narzędzi. Pamiętam jedną z sytuacji, gdzie w jednej z bardzo dużych międzynarodowych firm projekt przez pracowników był uważany za profesjonalny ponieważ był kupiony Oracle oraz licencja na jakiś przestarzały serwer. Kuriozalne, im więcej wydasz pieniędzy na licencję tym bardziej projekt jest profesjonalny. Klient dopiero wydając masę pieniędzy na licencję ma prawo powiedzieć, że kupił profesjonalny, będący na wysokim poziomie, produkt.

Zainspirowany tym wszystkim sięgnąłem do słownika języka polskiego PWN w poszukiwania hasła profesjonalny:

profesjonalny
1. będący specjalistą w jakiejś dziedzinie
2. uprawiany jako zawód
3. będący na wysokim poziomie w danej dziedzinie
4. spełniający wymagania profesjonalistów

Definicja słownikowa nie wspomina nic o pieniądzach, ale dodajmy ją w myśl pierwszego, zacytowanego zdania:
1. Jeśli chcesz być specjalistą w jakiejś dziedzinie musisz korzystać z komercyjnych rozwiązań.
3. Wysoki poziom w danej dziedzinie osiągniesz korzystając tylko z komercyjnych produktów.
4. Produkt jest profesjonalny jeśli spełnia wymagania profesjonalistów, a jednym z kryteriów doboru tego narzędzia zgodnie z punktem 1 jest płatność.

Czy zgadzacie się z takimi założeniami? Ja – w ogóle. Nie jestem maniakiem Open Source ani fanatykiem wolnego oprogramowania. Nie jestem też nadmiernym zwolennikiem komercyjnych rozwiązań, ale to co powinno być kluczowe dla każdego programisty a tym bardziej firmy świadczącej usługi programistyczne to szukanie skutecznego rozwiązania problemu a nie wydania pieniędzy.

Reasumując, moje zdanie to:

• Nie wszędzie pasuje OSS.
• Nie wszędzie konieczne są rozwiązania komercyjne.
• Nie zawsze nabycie produktu rozwiązuje wszystkie problemy. Czasami rodzi też nowe.

Warto zwrócić uwagę na to, że producenci oprogramowania czasami mamią i zarzucają nas całą masą marketingu, hasłami i wszelakimi buzzworld typu SOA, AJAX itp. podczas gdy rozwiązania oparte na OSS nie są reklamowane, a zdarza się sytuacje że mają funkcjonalność zbliżoną bądź nawet większą niż komercyjne.

Jakie jest, drodzy czytelnicy, wasze zdanie na temat – czy OSS może być profesjonalny? Co czyni produkt profesjonalnym?

Najważniejsze elementy

Log4j ma kilka składowych:

• Appender
• Layout
• Category

Dzisiaj skupię się tylko na dwóch pierwszych. Appender jest odpowiedzialny za zapis bądź wysyłanie komunikatów do wybranego miejsca podczas gdy Layout konwertuje wpis do określonego formatu.

Z najciekawszych Appenderów wymienię

• RollingFileAppender rotuje logi do określonego rozmiaru, po osiągnięciu np 10mb kopiuje stary plik zgodnie ze schematem i zaczyna zapisywać do nowego.
• DailyRollingFileAppender zachowuje się podobnie jak wyżej wymieniony z tym, że umożliwia zapis z podziałem na lata, miesiące, dni czy nawet minuty.
• SyslogAppender, który wysyła komunikaty do Sysloga
• LF5Appender wyświetlający logi w okienku tworzonym przy pomocy Swinga.
• SMTPAppender wysyłający maile z komunikatami. Jeśli się go źle skonfiguruje gwarantowane zapchanie skrzynki ;-)
• NagiosAppender przesyłający komunikaty do Nagiosa, narzędzia służącego do monitorowania.

Mając już appender, który wie gdzie zapisywać wypada powiedzieć Log4j też co powinien zapisywać.

• HTMLLayout produkujący tabelę HTML
• PatternLayout posiadający możliwość określenia “szablonu” wpisu.

Więcej Layoutów można znaleźć w Javadocu Log4j.

Jako, że zdecydowanie najczęściej używa się PatternLayout dodam parę słów na temat tego co potrafi. We wzorze który będzie później użyty do stworzenia komunikatu możemy używać następujących wyrażeń:

• %c kategoria zdarzenia
• %C nazwa klasy z której zostało wysłane zdarzenie
• %d data zdarzenia (przykład: %d{HH:mm:ss,SSS} )
• %m komunikat wysłany z aplikacji
• %n separator lini
• %p priorytet zdarzenia
• %r ilość milisekund, które zdążyły upłynąć od startu aplikacji
• %t nazwa wątku z którego zostało wysłane zdarzenie
• %x kontekst diagnostyczny powiązany z wątkiem (wie ktokolwiek co to znaczy?)
• %% pojedynczy znak %
• %M nazwa metody z której zostało wysłane zdarzenie (uwaga, bardzo wolne)
• %L numer linii z której zdarzenie pochodzi (uwaga, bardzo wolne)
• %F nazwa pliku z którego pochodzi zdarzenie (uwaga, bardzo wolne)
• %l informacja o wywołującym zdarzenie (uwaga, bardzo wolne, wskazuje na lokalizację z naszego kodu)

Przykłady modyfikatorów:

• %20c dodaje spacje z lewej strony jeśli nazwa kategorii jest krótsza niż 20 znaków
• %-20c dodaje spacje z prawej strony jeśli nazwa kategorii jest krótsza niż 20 znaków
• %.30c przycina kategorię pozostawiając ostatnie 30 znaków
• %20.30c wypełnia z lewej strony nazwę kategorię spacjami do 20 znaków oraz przycina początkowe znaki jeżeli jest dłuższa on 30 znaków
• %-20.30c analogicznie jak wyżej, z tym że znaki zostaną dodane z prawej strony. Ze swojej strony polecam używanie formatu np %-20.20, co zagwarantuje że element będzie miał zawsze 20 znaków. Jeśli pozostawimy -20.30 to element będzie miał 20 znaków jeśli kategoria jest zbyt krótka a 30 gdy będzie za długa

Przykład konfiguracji

Log4j można konfigurować na kilka sposobów. Programowo, przez plik properties oraz konfigurację XML. Zdecydowanie najpopularniejszy jest plik properties. Jego użycie jest banalnie proste. Włączamy log4j.jar do tak by był on dostępny w classpathu, a następnie tworzymy plik log4j.properties, który domyślnie jest poszukiwany przez bibliotekę jeśli nie została przekazana żadna konfiguracja. Aby jednak to się stało nasz kod musi spróbować wysłać jakąś wiadomość do Log4j.

log4j.rootLogger DEBUG, out

# loggery
log4j.logger.org.springframework INFO
log4j.logger.org.apache.activemq INFO
log4j.logger.org.apache.activemq.spring WARN
log4j.logger.org.apache.servicemix DEBUG, stdout

#appendery
log4j.appender.stdout org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern %d{ABSOLUTE} | %-5p | %t | %c | %m%n

log4j.appender.out org.apache.log4j.DailyRollingFileAppender
log4j.appender.out.DatePattern ‘-’yyyy-MM-dd’.log’”/>
log4j.appender.out.layout org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern %d{ABSOLUTE} | %-5p | %t | %c | %m%n
log4j.appender.out.file E:/fuse-esb/data/log/servicemix

Założenie powyższej konfiguracji jest następujące. Domyślny poziom logowania jest ustawiony na DEBUG a komunikaty są zapisywane do pliku (rootLogger). Zdefiniowane są dwa appendery stdout oraz out. Pierwszy jest użyty tylko dla paczki org.apache.servicemix. Pozostałe loggery mają określony tylko poziom logowania. Pliki z logami będą dzielone na dni, także w lokalizacji E:/fuse-esb/data/log/ po 3 dniach działania od 13 do 15 października będziemy mieli 3 pliki:

• servicemix – logi z bierzącego dnia
• servicemix-2008.10.14.log – logi z 14 października
• servicemix-2008.10.13.log – logi z 13 października

Mam nadzieję że od dzisiaj Log4j będzie Wam drodzy czytelnicy mówił więcej i prościej. Jeśli są jakieś kwestie które pozostają niewyjaśnione – proszę pytać.

Pierwszy z nich odpowiada za wczytanie wymaganych rozszerzeń CXFa oraz definicję bazowej konfiguracji fabryki z interceptorami. W interceptorach możemy skonfigurować logowanie, obsługę załączników czy standardów WS-Security etc. Wszystkie te ustawienia będą dziedziczone, a fabryki docelowych usług będą dodawać tylko adres, do odpytywania. Na koniec bean klienta będzie miał określony autowire by nie przekazywać mu wszystkich własności.

Oto najważniejsze wstawki kodu oraz ich opis:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <groupId>org.code-house.cxf</groupId>
        <artifactId>parent</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <groupId>org.code-house.cxf</groupId>
    <artifactId>client</artifactId>
    <version>1.0-SNAPSHOT</version>

    <name>Code House.Org - CXF - Client</name>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.12</version>
        </dependency>
        <dependency>
            <groupId>org.code-house.cxf</groupId>
            <artifactId>contract</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http</artifactId>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http-jetty</artifactId>
            <version>${code-house.cxf.version}</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${code-house.spring.version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>${code-house.spring.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>${code-house.spring.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

</project>

Deskryptor nie jest zbyt złożony, istotny jest tylko kawałek z kontraktem, który jak wskazuje nazwa jest definicją używanych typów:

<dependency>
    <groupId>org.code-house.cxf</groupId>
    <artifactId>contract</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

Teraz kolej na jedyną wstawkę Javy, która się pojawia w projekcie. Jest to zwykły bean, który będzie miał później wstrzykiwane obiekty pośredniczące w wywoływaniu usług.

package org.code_house.cxf.client;

import org.code_house.services.maven.MavenArtifactType;

/**
 * Klient usług Code-House.
 *
 * @author Łukasz Dywicki <a href="splatch@code-house.org">email</a>
 *
 * $Id$
 */
public class Client {

    /**
     * Usługa do obsługi wyszukiwania artefaktów Mavena.
     */
    private MavenArtifactType maven;

    /**
     * Pobranie wartości pola maven.
     *
     * @return Wartość maven.
     */
    public MavenArtifactType getMaven() {
        return maven;
    }

    /**
     * Ustawienie wartości pola maven.
     *
     * @param maven Nowa wartość pola maven.
     */
    public void setMaven(MavenArtifactType maven) {
        this.maven = maven;
    }
}

Resztę magii załatwia Spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/context
        http://www.springframework.org/schema/context/spring-context.xsd
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
    ">
    <!--  Konfiguracja placeholderów (znaczy wstawek ${}) -->
    <context:property-placeholder location="classpath:client.properties" />

    <!-- Importy rzeczy koniecznych do pracy CXF -->
    <import resource="classpath:META-INF/cxf/cxf.xml" />
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />
    <import resource="classpath:META-INF/cxf/cxf-extension-http-jetty.xml" />

    <!-- Konfiguracja poszczególnych usług wstrzykiwanych do klienta -->
    <import resource="classpath:services/*.xml" />

    <!-- Bean zawierający referencje do wygenerowanych klientów usług -->
    <bean id="client" class="org.code_.housecxf.client.Client" autowire="autodetect" />

    <!-- Bazowa konfiguracja fabryk - obiektów tworzących stuby klientów w runtime -->
    <bean id="baseClientFactory" abstract="true"
        class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
       <property name="username" value="${org.code_house.cxf.user}" />
        <property name="password" value="${org.code_house.cxf.password}" />
        <property name="inInterceptors">
            <list>
                <ref bean="logIn" />
            </list>
        </property>
        <property name="outInterceptors">
            <list>
                <ref bean="logOut" />
            </list>
        </property>
    </bean>

    <!-- Loggery dla CXF -->
    <bean id="logIn" class="org.apache.cxf.interceptor.LoggingInInterceptor" />
    <bean id="logOut" class="org.apache.cxf.interceptor.LoggingOutInterceptor" />

</beans>

Zgodnie ze wstawką w linii 20 konieczna jest jeszcze konfiguracja usługi. Sztuczka polega na użyciu części konfiguracji zdefiniowanej wcześniej – baseClientFactory.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
    ">

    <!-- Konfiguracja stuba dla usługi wyszukiwania artefaktów -->
    <bean id="mavenService" class="org.code_house.services.maven.MavenArtifactType"
        factory-bean="mavenServiceFactory" factory-method="create" />

    <!-- Fabryka usługi wyszukującej -->
    <bean id="mavenServiceFactory" parent="baseClientFactory">
        <!-- jedyne parametry jakich potrzebujemy -->
        <property name="serviceClass"
            value="org.code_house.services.maven.MavenArtifactType" />
        <property name="address" value="${org.code_house.cxf.service.maven}" />
    </bean>

</beans>

Ustawienia, które mogą ulec zmianie, to znaczy użytkownik, hasło oraz adres usługi są wyodrębnione do pliku client.properties:

# Placeholdery dla kontekstow springa
# Adresy uslug
server.port = 8080
host = localhost
org.code_house.cxf.service.maven http://${host}:${server.port}/webapp/services/maven

# Autoryzacja
org.code_house.cxf.user
org.code_house.cxf.password

No i na koniec opcjonalny test, który odpytuje usługę:

package org.code_house.cxf.client;
import org.code_house.services.maven.definition.ArtifactInfo;
import org.code_house.services.maven.types.FindArtifactRequest;
import org.code_house.services.maven.types.FindArtifactRespose;
import org.springframework.test.AbstractDependencyInjectionSpringContextTests;

/**
 * Proste wywołanie klasy klienta.
 *
 * @author Łukasz Dywicki <a href="ldywicki@pocztowy.pl">email</a>
 *
 * $Id$
 */
public class MainTest extends AbstractDependencyInjectionSpringContextTests {

    /**
     * Wstrzyknięty klient.
     */
    private Client client;

    @Override
    protected String[] getConfigLocations() {
        return new String[] {"classpath:client.xml"};
    }

    public void testOne() {
        FindArtifactRequest request = new FindArtifactRequest();
        ArtifactInfo artifact = new ArtifactInfo();
        artifact.setGroupId("org.code_house.cxf");
        artifact.setArtifactId("contract");
        request.setQuery(artifact);

        FindArtifactRespose respose = client.getMaven().findArtifact(request);
        System.out.println(respose.getDownloadURL());
    }

    /**
     * Ustawienie wartości pola client.
     *
     * @param client Nowa wartość pola client.
     */
    public void setClient(Client client) {
        this.client = client;
    }

}

To by było na tyle. Cały działający kod projektu jest już zamieszczony przy poprzedniej nocie, paczka ze wszystkimi listingami gotowa do pobrania.

Teraz chyba pora zacząć opisywać mechanizmy Springa. :)

CXF jest połączeniem kilku bibliotek - YOKO, Celtixa oraz XFire. Każda z nich wcześniej realizowała pewien fragment obecnej funkcjonalności CXF - YOKO obsługuje Corbę a XFire usługi sieciowe. Obecne CXF jest gotowy do używania "produkcyjnego", ponieważ niedawno wyszedł z fazy inkubacji. :)

Architektura

CXF ma dosyć elastyczną budowę. Zgodnie z dokumentacją można wyróżnić najważniejsze składowe:

• Bus, jest trzonem architektury CXF w którym definiuje i konfiguruje się rozszerzenia.
• Messaging & Interceptors, zapewniają niskopoziomowy dostęp do komunikatów oraz warstwę na której jest oparta większość funkcjonalności.
• Front ends, frontendy są interfejsami programistycznymi do tworzenia usług (np. JAX-WS).
• Services, usługi zapewniają model wraz z opisem
• Bidings, element ten jest odpowiedzialny za obsługę konkretnego protokołu (SOAP, REST, Corba etc).
• Transports, warstwa abstrakcji ułatwiająca zmianę sposobu transportu do/z usług.

Markieting :)

CXF oferuje infrastrukturę konieczną do budowania usług, z najważniejszy zalet można wymienić:

• Wsparcie dla różnych protokołów.
• Obsługa standardów WS-*, tj. WS-Addressing, WS-Security, WS-ReliableMessaging, oraz WS-Policy.
• Obsługa wielu transportów.
• Dołączane data-bindingi (np JAXB, Aegis).
• Jasny podział front endów takich jak JAX-WS od najważniejszego kodu.
• Wysoka wydajność.
• Możliwość osadzania w różnych środowiskach.

Z dodatkowych zalet, mogę dodać - bardzo łatwą integrację ze Springiem.

Pierwsza usługa

Do budowania projektów będziemy używać Mavena. Implementowana usługa będzie oparta o frontend JAX-WS z ręcznie pisanym deskryptorem usługi (WSDL first). Jakkolwiek w bardzo prosty sposób można odwrócić kolejność i przy pomocy pluginu CXF do Mavena wygenerować deskryptor.

Struktura projektów będzie następująca:

• parent
  Rodzic projektu ze zdefiniowanymi wersjami bibliotek i raportami.
• contract
  Definicje używane zarówno przez klienta jak i serwer - WSDL oraz konfiguracja pluginu CXF.
• client
  Prosta biblioteka kliencka oparta o mechanizmy CXFa (JaxWSProxyFactoryBean).
• server
  Przykładowa implementacja usługi z bardzo prostym wykorzystaniem Springa.
• webapp
  Konfiguracja transporty CXF - w tym konkretnym przypadku servletu CXF.

Parent

Poniżej znajduje się deskryptor projektu, który jest używany do budowania całości.

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <!-- Informacja dla Mavena -->
    <modelVersion>4.0.0</modelVersion>

    <!-- Identyfikacja projektu -->
    <groupId>org.code-house.cxf</groupId>
    <artifactId>parent</artifactId>
    <name>Code House.Org - CXF</name>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <description>Rodzic projektu, zawiera wszystkie moduly.</description>

    <!-- Składowe projektu -->
    <modules>
        <module>cxf-client</module>
        <module>cxf-contract</module>
        <module>cxf-server</module>
        <module>cxf-webapp</module>
    </modules>

    <!-- Definicje zmiennych dostępne również w modułach -->
    <properties>
        <code-house.cxf.version>2.1.1</code-house.cxf.version>
        <code-house.jaxb.version>2.1.3</code-house.jaxb.version>
        <code-house.spring.version>2.5.4</code-house.spring.version>
    </properties>

    <build>
        <plugins>
            <!-- Konfiguracja kompilatora -->
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <reporting>
    <!--Wycięte :) -->
    </reporting>

    <!-- Predefiniowane wersje bibliotek -->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-rt-frontend-jaxws</artifactId>
                <version>${code-house.cxf.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-rt-transports-http</artifactId>
                <version>${code-house.cxf.version}</version>
            </dependency>
            <dependency>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-rt-transports-http-jetty</artifactId>
                <version>${code-house.cxf.version}</version>
            </dependency>
            <dependency>
                <groupId>com.sun.xml.bind</groupId>
                <artifactId>jaxb-impl</artifactId>
                <version>${code-house.jaxb.version}</version>
            </dependency>
            <dependency>
                <groupId>javax.xml.bind</groupId>
                <artifactId>jaxb-api</artifactId>
                <version>2.1</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

</project>

Contract

Zgodnie z tym, co napisałem wcześniej - przyjąłem podejście, że WSDL jest pisany ręcznie, głównie dlatego że dla większych projektów można w prosty sposób narzucić jakąś organizację i podział plików, z których są następnie generowane źródła.
Najistotniejsza wstawka, która powinna znaleźć się w pomie:

<!-- Generowanie kodu z deskryptora WSDL -->
<plugin>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-codegen-plugin</artifactId>
    <executions>
        <execution>
            <phase>generate-sources</phase>
            <configuration>
                <sourceRoot>${basedir}/target/jaxws</sourceRoot>
                <wsdlOptions>
                    <wsdlOption>
                        <wsdl>
                            ${basedir}/src/main/resources/maven.wsdl
                        </wsdl>
                        <extraargs>
                            <extraarg>-quiet</extraarg>
                        </extraargs>
                    </wsdlOption>
                </wsdlOptions>
            </configuration>
            <goals>
                <goal>wsdl2java</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Po dodaniu tej wstawki do sekcji build/plugins możemy przejść do tworzenia deskryptora usługi. W moim przypadku przyjąłem następujący podział:

1. maven.wsdl - definicje metod oraz komunikatów w rozumieniu WSDL (messages). Można z powodzeniem wyłączyć z tego pliku same koperty i pozostawić metody a to co potrzebne włączyć dyrektywą wsdl:import.
2. types.xsd - typy używane do komunikacji - zazwyczaj pary request+response używane bezpośrednio w definiowaniu elementów wsdl:part.
3. definition.xsd - definicje typów złożonych, niezależnych od usług, tj. opis domain-modelu z którym usługa pracuje.

Każdy z tych plików ma inną przestrzeń nazw.

maven.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns:tns="http://code-house.org/services/maven"
    xmlns:types="http://code-house.org/services/maven/types"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://code-house.org/services/maven"
    name="MavenServices"
    >

    <wsdl:types>
        <xsd:schema targetNamespace="http://code-house.org/services/maven/types">
            <xsd:include schemaLocation="types.xsd" />
        </xsd:schema>
    </wsdl:types>

    <wsdl:message name="findArtifactRequest">
        <wsdl:part name="request" type="types:FindArtifactRequest" />
    </wsdl:message>
    <wsdl:message name="findArtifactResponse">
        <wsdl:part name="response" type="types:FindArtifactRespose" />
    </wsdl:message>

    <wsdl:portType name="MavenArtifactType">
        <wsdl:operation name="findArtifact">
            <wsdl:input message="tns:findArtifactRequest" />
            <wsdl:output message="tns:findArtifactResponse" />
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="MavenArtifactSOAP" type="tns:MavenArtifactType">
        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
        <wsdl:operation name="findArtifact">
            <wsdl:input>
                <soap:body use="literal" />
            </wsdl:input>
            <wsdl:output>
                <soap:body use="literal" />
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="MavenServices">
        <wsdl:port binding="tns:MavenArtifactSOAP" name="Maven Services">
            <soap:address location="http://localhost:8080/webapp/services/maven" />
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

types.xsd

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://code-house.org/services/maven/types"
    xmlns:tns="http://code-house.org/services/maven/types"
    xmlns:def="http://code-house.org/services/maven/definition"
    elementFormDefault="qualified">

    <import schemaLocation="definition.xsd"
        namespace="http://code-house.org/services/maven/definition" />

    <complexType name="FindArtifactRequest">
        <sequence>
            <element name="query" type="def:ArtifactInfo" />
        </sequence>
    </complexType>

    <complexType name="FindArtifactRespose">
        <sequence>
            <element name="downloadURL" type="anyURI" />
        </sequence>
    </complexType>

</schema>

definition.xsd

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://code-house.org/services/maven/definition"
    xmlns:tns="http://code-house.org/services/maven/definition"
    elementFormDefault="qualified">

    <complexType name="ArtifactInfo">
        <sequence>
            <element name="groupId" type="string" />
            <element name="artifactId" type="string" />
            <element name="version" type="string" minOccurs="0" />
            <element name="classifier" type="tns:Classifier" minOccurs="0" />
            <element name="packaging" type="tns:Packaging" minOccurs="0" />
            <element name="type" type="tns:Type" minOccurs="0" />
        </sequence>
    </complexType>

    <simpleType name="Type">
        <restriction base="string">
            <enumeration value="dll" />
            <enumeration value="so" />
        </restriction>
    </simpleType>

    <simpleType name="Classifier">
        <restriction base="string">
            <enumeration value="sources" />
            <enumeration value="javadoc" />
            <enumeration value="resources" />
        </restriction>
    </simpleType>

    <simpleType name="Packaging">
        <restriction base="string">
            <enumeration value="pom" />
            <enumeration value="jar" />
            <enumeration value="war" />
            <enumeration value="bundle" />
        </restriction>
    </simpleType>

</schema>

Po odpaleniu polecenia mvn:install powinniśmy otrzymać w konsoli fragment podobny do tego:

[INFO] [cxf-codegen:wsdl2java {execution: default}]

Jest to informacja, że plugin CXF został poprawnie skonfigurowany i uruchomiony.

Serwer

Sercem naszej usługi jest oczywiście jej implementacja dlatego też nie możemy obejść się bez niej. :) Projekt ten ma tylko dwie zależności - contract oraz artefakt cxf-rt-frontend-jaxws.

Konfiguracja serwera odbywa się w oparciu o springa:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://cxf.apache.org/jaxws
        http://cxf.apache.org/schemas/jaxws.xsd
    ">

    <!-- Dodatkowy bean zawierający właściwą implementację logiki związanej z wyszukiwaniem -->
    <bean id="service" class="org.code_house.services.maven.DummyMavenSearchServiceImpl" />

    <!-- Bean będący implementacją usługi jako takiej - obsługujący wejście/wyjście -->
    <bean id="mavenService" class="org.code_house.services.maven.MavenArtifactTypeImpl">
        <property name="service" ref="service" />
    </bean>

    <!-- Konfiguracja endpointu CXFa -->
    <jaxws:endpoint address="maven" id="jaxwsMavenService" implementor="#mavenService" />

</beans>

Serwer zawiera w zasadzie niewiele kodu, oto i on:

package org.code_house.services.maven;

import java.net.URISyntaxException;

import javax.jws.WebService;

import org.code_house.services.maven.definition.ArtifactInfo;
import org.code_house.services.maven.types.FindArtifactRequest;
import org.code_house.services.maven.types.FindArtifactRespose;

/**
  * Implementacja usługi.
  */
@WebService(serviceName = "MavenService",
    endpointInterface = "org.code_house.services.maven.MavenArtifactType",
    targetNamespace = "http://code-house.org/services/maven"
)
public class MavenArtifactTypeImpl implements MavenArtifactType {

    /**
      * Bean zawierający implementację logiki biznesowej.
      */
    private MavenSearchService service;

    public FindArtifactRespose findArtifact(FindArtifactRequest request) {
        ArtifactInfo info = request.getQuery(); // pobranie struktury przekazanej od klienta

        // sformuowanie odpowiedzi
        FindArtifactRespose response = new FindArtifactRespose();
        try {
            response.setDownloadURL(service.find(info).toURI().toString());
        } catch (URISyntaxException e) {
            throw new RuntimeException(e);
        }
        return response;
    }

    /**
     * Ustawienie wartości pola service.
     *
     * @param service Nowa wartość pola service.
     */
    public void setService(MavenSearchService service) {
        this.service = service;
    }
}

Dodatkowy kod, który nie jest konieczny do implementacji usługi to definicja interfejsu MavenSearchService. Dzięki zastosowaniu takiego rozwiązania można w prostszy sposób testować działanie usługi poprzez przekazywanie jej mocka stworzonego np. przy pomocy easy mocka. Kod takiego testu pominąłem ze względu na to, że notka i tak już jest za długa w tym momencie a jesteśmy ledwo w połowie drogi. :)

Przykładowa implementacja wcześniej wspomnianego intefejsu nie zawiera żadnej logiki i zawsze zwraca tą samą wartość.

package org.code_house.services.maven;

import java.net.MalformedURLException;
import java.net.URL;

import org.code_house.services.maven.definition.ArtifactInfo;

// Najprostsza implementacja tylko po to żeby sprawdzić działanie usługi
public class DummyMavenSearchServiceImpl implements MavenSearchService {

    public URL find(ArtifactInfo info) {
        try {
            return new URL("http://repo1.maven.org/maven2/org/apache/apache/4/apache-4.pom");
        } catch (MalformedURLException e) {
            throw new RuntimeException(e);
        }
    }

}

Zanim odpalimy serwer konieczna będzie jeszcze jedna rzecz - konfiguracja transporu, w naszym przypadku servletu CXF.

Webapp

Webapp posiada bezpośrednie zależności do 2 artefaktów CXFa: cxf-rt-transports-http oraz cxf-rt-bindings-http. Druga jest opcjonalna, bez niej CXF nie będzie wyświetlał dostępnych usług w postaci tabelki html.

Przydatna może być wtyczka jetty (sekcja build/plugins), która pozwala na uruchomienie aplikacji bez konieczności instalowania kontenera servletów:

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <version>6.1.11</version>
    <configuration>
        <scanIntervalSeconds>10</scanIntervalSeconds>
        <connectors>
            <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                <port>8080</port>
                <maxIdleTime>60000</maxIdleTime>
            </connector>
        </connectors>
    </configuration>
</plugin>

Ostatnia zależność odnosi się do implementacji usługi - czyli naszego artefaktu server. Najistotniejsze elementy konfiguracji webappa to web.xml oraz cxf-beans.xml.

web.xml

Warto zauważyć w poniższym listingu fajną możliwość, którą daje nam Spring w postaci wildcardów określających położenie konfiguracji - w tym przypadku classpath:/module/*-context.xml. Oznacza to, że Spring przeskanuje wszystkie biblioteki od których zależy projekt i dołączy ich konfigurację do głownej, dzięki czemu będziemy mogli uzyskać bardziej modułową i elastyczną budowę aplikacji. Może Dynamic Modules to nie jest ale na codzień w zupełności wystarcza :).

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="ocs" version="2.5"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="
        http://java.sun.com/xml/ns/javaee
        http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    >

    <!-- Informacje nazewnicze dla kontenera -->
    <display-name>Maven Search Services :: Webapp</display-name>
    <description>Frontend indeksera.</description>

    <!-- Lokalizacje plików konfiguracyjnych -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            <!-- Konfiguracja zabezpieczeń opartych o spring secuirty -->
            /WEB-INF/security.xml
            <!-- Konfiguracja CXF -->
            /WEB-INF/cxf-beans.xml
            <!-- Konfiguracja kontekstu -->
            /WEB-INF/applicationContext.xml
            <!-- Wczytanie konfiguracji modułów -->
            classpath:/module/*-context.xml
        </param-value>
    </context-param>

    <!-- Servlet obsługujący usługi sieciowe -->
    <servlet>
        <servlet-name>CXFServlet</servlet-name>
        <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <!-- Mapowanie adresu usług sieciowych -->
    <servlet-mapping>
        <servlet-name>CXFServlet</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>

    <!-- Inicjowanie kontekstu springa -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

</web-app>

cxf-beans.xml

Plik ten zawiera definicje konfiguracyjne CXFa. W poniższej formie włączana jest tylko część modułów CXF w celu zmniejszenia użycia zasobów.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:cxf="http://cxf.apache.org/core"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
        http://cxf.apache.org/core
        http://cxf.apache.org/schemas/core.xsd
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
    ">

    <!-- Moduły CXF-a -->
    <import resource="classpath:META-INF/cxf/cxf.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-extension-http-binding.xml"/>
    <import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>

</beans>

Pozostałe pliki konfiguracyjne są praktycznie puste, ponieważ tyczą się obszarów niezwiązanych z tematem tego wpisu. Po tym wszystkim możemy uruchomić naszą aplikację poleceniem mvn jetty:run. Po wejściu na adres http://localhost:8080/webapp/services naszym oczom powinna ukazać się lista podobna do poniższej:

Nie wiem niestety dlaczego CXF generuje zły adres usługi (pomijający mapowanie servletu) oraz ma problemy z wystawieniem WSDLa. Jakkolwiek i bez tego wszystko działa poprawnie - znaczy wywoływanie usług rzecz jasna. :)

W tym momencie możemy uruchomić Soap UI i wykonać jedyną dostępną metodę - findArtifact.

Client

Ostatnim z elementów, który pozostał do omówienia jest klient. Niestety z racji na to, że ta nota już się wystarczająco rozrosła zrobię to w kolejnym wpisie. Mam nadzieję, że nota ta nieco ułatwi przyszłym użytkownikom CXFa jego poznanie. :) Dla tych, którym nie chce się wpisywać tego wszystkiego w edytorze zamieszczam źródła razem z działającym klientem. Projekty nie są nadzwyczajnie dopieszczone, ale w zupełności wystarczą do startu. Znajduje się też tam w pełni działający klient stworzonej usługi. Pozdrawiam i życzę miłej zabawy!

Czym jest ESB

Jednoznaczne określenie terminu ESB nie jest łatwe, ponieważ wokół tego tematu rozpętana została burza marketingowa. Jedni uważają je za oś SOA (Service Oriented Architecture) inni jako zło konieczne w dużych instytucjach.

Dlatego pomijając teorię przejdźmy do najistotniejszych cech, jakie oferuje ESB, niezależnie od producenta oraz osoby definiującej pojęcie. Sam nie chciałbym wdawać się w dyskusję na temat postrzegania i ESB i SOA.

Źródło - CodePlex

Na załączonym wyżej obrazku widać typową strukturę logiczną w oparciu o ESB. Z lewej strony mamy komercyjne rozwiązanie – MQ Series firmy IBM, dalej idąc dołem, widzimy bazę danych, serwer pocztowy a na końcu mainframe. U góry natomiast pojawiają się klienci.

Ciąg dalszy

Na bazie tego obrazku można powiedzieć co nieco o tym, czym owa niebieska rurka symbolizująca ESB jest:

• Jest to z pewnością centralny rejestr usług firmy, dzięki któremu nie jest konieczne wiązanie aplikacji między sobą. Wiąże się je tylko i wyłącznie z jednym elementem – z magistralą.
• Kolejny ważny punkt, to most pomiędzy protokołami. W dobie, gdy wszyscy żyją już Web Services nie można zapomnieć o innych sposobach komunikacji – poczynając od poczciwej Corby po kolejki JMS czy też odczyt zasobów z FTP.
• Transformacja komunikatów to opcjonalna czynność, której nie widać na wyżej wymienionym obrazku. Jest ona wykonywana pod maską, wewnątrz magistrali, w zależności od potrzeb. W chwili gdy mamy komunikaty z systemu A do systemu B możemy wszystko sprowadzić do jednego uniwersalnego API danych.
• Inteligentny router informacji. Większość magistral ma coś wspólnego z pojęciem EIP, czyli Enterprise Integration Patterns. Jednym z tych wzorców jest Content Based Router, to znaczy w zależności od kształtu, zawartości komunikatu, nagłówka, fragmentu, czegokolwiek możemy odbijać komunikat w różnych kierunkach. Dalej z wzorców można wymienić Message Filter, Recipient List, Routing Slip, Wire Tap, Splitter, Resequencer itd.
• Integrator procesów biznesowych (bardziej marketingowo) – po pierwsze odwzorowanie usług magistrali do czynności biznesowych w organizacji a po drugie wsparcie dla procesorów reguł biznesowych (WS-BPEL).

Service Mix jako ESB

Mając zestaw wyżej wymienionych cech możemy przejść do omówienia projektu Apache Service Mix.
Może na początku kilka słów o tym, czym jest JBI, ponieważ pojawia się sam skrót, ale nie ma jego omówienia.
Otóż, JBI w rozwinięciu oznacza Java Business Integration. Jest to standard przyjęty w ramach Java Community Process w celu określenia norm budowania rozwiązań SOA (znów buzzworld). Pomijając politykę wielkich korporacji oraz marketing przejdźmy do elementów, które standard ten określa:

Źródło Open ESB Starter Kit

• Typy komponentów:
  1. Service Engine (SE) – backend do obsługi zapytań.
  2. Binding Components (BC) – frontend, do nasłuchiwania w danym standardzie.
  3. Shared Libraries (SL) – kod współdzielony przez w/w komponenty.
  5. Service Assembly (SA) – zbiór usług rozumianych jako jedność przez magistralę (zwykle para BC+SE).
• Normalized Message Router – jest to serce rozwiązania opartego o JBI, ponieważ w nim są transportowane komunikaty. To on zapewnia przepływ informacji z komponentów bindujących do silników.
• Message Exchange Patterns – w oparciu o definicję dla SOAP JBI przewiduje następujące typy komunikatów:
1. In-Only – tylko wejście, usługa nie zwraca żadnej odpowiedzi
2. Rebust In-Only – zwrócony zostanie status po obsłudze zapytania bądź wyjątek.
3. In-Out – standardowa obsługa wejście-wyjście.
4. In Optional-Out – wejście z niewiążącą (nieobowiązkową) odpowiedzią.

Dostępnych jest kilka implementacji JBI:

• Open ESB
• Apache Service Mix
• FUSE ESB (na bazie Service Mix)
• Bostech Chain Builder ESB
• Mule
• JBoss ESB
• Fusion Middleware
• ActiveMatrix Service Bus

Service Mix od środka

Wewnątrz Service Mix jest spięciem kilku potężnych projektów, rozwijanych od dłuższego czasu, które zdobyły już renomę i popularność. Między innymi można wyróżnić:

• Pierwszy z tych projektów to Spring Framework, rozwijany od bodajże 2000 roku, z powodzeniem rywalizujący z architekturami opartymi o EJB. Spring jest nie tylko mechanizmem konfiguracyjnym ale również zbiorem bardzo dobrych komponentów umożliwiających szereg operacji (bazy danych, JMS, przetwarzanie wsadowe, Web Services etc).
• Drugi, bardzo ważny projekt to Active MQ. Największa i najpopularniejsza otwarta implementacja standardu JMS. Jest on używany wewnątrz Service Mix-a jako transporter komunikatów w Normalized Message Router jak i do obsługi końcówek JMS.
  - Wymieniony nieco niżej pod-projekt Active MQ to Camel. Jest to szkielet przeznaczony do tworzenia reguł routingu. Wspiera różnorakie transporty (HTTP, JMS, JBI, MS MQ itp.).
• XBean jest fragmentem projektu Apache Geronimo (serwer aplikacyjny ze stajni Apache) przeznaczonym do tworzenia konfiguracji i zarządzania komponentami. Jest zbudowany w oparciu o Springa.
• Apache CXF jest stosunkowo nowym projektem, który jest używany poprzez Service Mix w celu obsługi zapytań SOAP (chociaż możliwe jest użycie innego komponentu).
• Apache ODE jest silnikiem reguł biznesowych w oparciu o WS-BPEL.
• JBoss Drools jest kolejnym procesorem reguł biznesowych. Może być użyty do routingu. Jest dostępny plugin pozwalający na łatwą pracę z tą technologią.

Możliwości Service Mix

Wyżej wymienione projekty są używane w Service Mix w celu uzyskania typowych funkcjonalności ESB:

• JMS, czyli obsługa kolejek
• WS-BPEL, obsługa reguł biznesowych
• Web Services przy pomocy CXF jak i modułu JSR-181
• Transformacje XSLT oraz XQuery (w oparciu o Saxona)
• File Drop to odczyt i zapis do plików dostępnych lokalnie jak i zdalnie (FTP)
• Obsługa protokołu XMPP pozwala na łatwą integrację z komunikatorami zbudowanymi w oparciu o Jabbera.
• Dostęp do poczty przy pomocy modułu servicemix-mail
• Komponenty programowe:
• Dają możliwość dopisania własnych "endpointów", czyli implementacji docelowych usług bądź pośredników.
• Dodatkowe funkcjonalności (cache, rss, walidacja)
• Języki skryptowe (min Groovy)

ESB – dlaczego Open Source

Wybór Service Mix-a nie był podyktowany przypadkiem. Jest to bowiem najpopularniejsze tego typu rozwiązanie z otwartym kodem źródłowym. Co więcej, nie jest to projekt rozwijany przez osoby bez doświadczenia, pozostawiony bez wsparcia.
Otwarty kod ułatwia przede wszystkim adaptację tego rozwiązania do potrzeb organizacji a nie odwrotnie – organizacji do potrzeb magistrali. W razie potrzeb jesteśmy w stanie dopisać własne komponenty, obsługę mniej standardowych protokołów na bazie dostarczonych interfejsów czy to w Service Mix czy to w Camelu.
Przyjęte standardy gwarantują ciągłość rozwoju oraz ułatwiają integrację (JMX umożliwia łatwe podpięcie konsoli administracyjnej), podczas gdy J2EE Connector Architecture definiuje kontrakty (zarządzanie połączeniami, transakcjami, bezpieczeństwem).
Nie bez znaczenia jest również koszt, jaki organizacja ponosi w przypadku zdecydowania się na otwarte rozwiązanie. Rozpoczęcie prac z Service Mix-em kosztuje 0 PLN. Każdy, bez rejestracji, podawania jakichkolwiek danych może pobrać źródła albo gotowe dystrybucje i uruchomić je na swoim komputerze. W chwili gdy istnieje takie zapotrzebowanie, organizacja posiada kompetencje i skromny budżet to taka konfiguracja początkowo jest optymalna. Z biegiem czasu gdy zaistnieje konieczność wsparcia czy szkoleń to są one oferowane przez firmę IONA, która jest zaangażowana w rozwój Service Mix-a.

Service Mix a bezpieczeństwo

Większość, jeśli nie wszystkie rozwiązania w Javie, które wiążą się z kryptografią są oparte na JCA – Java Cryptography Architecture. Jest to zestaw interfejsów oraz ich implementacji zawierający implementację najpopularniejszych algorytmów kryptograficznych jak i API umożliwiające tworzenie własnych rozszerzeń (JCE).
Standard autoryzacji i uwierzytelniania w Javie to JAAS (Java Authentication and Authorization Service). W oparciu o niego jest budowanych większość rozwiązań związanych z bezpieczeństwem. Nawet największe alternatywy takie jak Acegi Security (obecnie Spring Security posiadają adaptery integrujące je ze standardem). Przy użyciu dostępnych interfejsów możliwe jest dostarczenie własnej implementacji usługi obsługującej autoryzację bądź uwierzytelnianie użytkowników/systemów.
Bezpieczeństwo usług sieciowych jest zależne od wybranego komponentu Service Mix. Pełne wsparcie dla WS-Security oferują komponenty zbudowane w oparciu o Apache CXF (szyfrowanie, podpisywanie komunikatów). Z innych standardów CXF wspiera także WS-Policy, WS-Addressing.
Szyfrowane połączenia są łatwe do uzyskania przy pomocy komponentu servicemi-http.
Dostępne zabezpieczenia na poziomie wirtualnej maszyny Javy to certyfikowanie (podpisywanie) kodu modułów oraz konfiguracja Security Managera (umożliwia wyłączenie dostępu do pakietów/klas/metod).

RewriteBase /z-tego-adresu/
RewriteCond %{REQUEST_URI} !^.*\.(css|png|gif|jpe?g|php|js)$
RewriteRule ^.*$ /z-tego-adresu/index.php?%{REQUEST_URI} [QSA,L]
Oczywiście wymaga dotarcia i obsługi w kodzie, ale GET jest bez zmian.. i to najważniejsze :)