2010.03_SOA Tworzenie serwisów wspomagających proces integracji_[Aplikacje Biznesowe].pdf

Aplikacje biznesowe

SOA

Tworzenie serwisów wspomagających proces integracji

Tworzenie rozwiązań integracyjnych to nie trend, ale wymóg stawiany przed

projektantami systemów informatycznych. Coraz bardziej złożone procesy

biznesowe wymagają od nas projektowania rozwiązań dotykających coraz

to większej ilości systemów, które w przeszłości często nie były projektowane

w sposób zapewniający łatwą możliwość inetgracji.

Dowiesz się:

• Jak integrować aplikacje stworzone w JEE z

instniejącymi aplikacjami;

• Jak skon�gurować Websphere AS do pracy

z Websphere MQ;

• Czym jest tzw. triggering w MQ i jak go wy-

korzystać w procesie integracji.

Powinieneś wiedzieć:

• Podstawowa znajomość standardu JEE;

• Znajomość podstawowych pojęć związa-

nych z Websphere MQ (SDJ 10/2008);

• Znajomość zagadnień kon�guracji We-

bsphere AS do pracy z Websphere MQ (SDJ

9/2009).

część procesu obejmować będzie przygoto-

wanie wyzwalacza (ang. Trigger) po stronie

MQ odpowiedzialnego za wywołanie apli-

kacji odpowiedzialnej za przetworzenie ko-

munikatu umieszczonego w kolejce (Rysu-

nek 2).

Mając zarys procesu, przejdźmy do anali-

zy technologicznej. Do przygotowania ser-

wisu wykorzystamy JAX-WS, JMS oraz ser-

wer Websphe AS 7. Mechanizm kolejek zo-

stanie zrealizowany przez Websphere MQ

7, który wykorzysta mechanizm wyzwala-

czy w celu wywołania aplikacji Java odpo-

wiedzialnej za przetworzenie komunikatów

(Rysunek 3).

W naszej analizie przyjęliśmy dwa istot-

ne kryteria. Pierwsze to fakt, iż część zwią-

zana z przetwarzaniem komunikatów po

stronie MQ powinna być odseparowana

i niedostępna na zewnątrz , czego konse-

kwencją było drugie kryterium związane

ze stworzeniem niezależnej warstwy po-

średniej, dostępnej dla zewnętrznych apli-

kacji klienckich. Warstwa pośrednia po-

winna być uniwersalnym pośrednikiem od-

powiadającym za wywołanie pewnego zde-

finiowanego procesu biznesowego. Opiera-

Poziom

trudności

mat tego, w oparciu o jakie technologie, na

jaką platformę itp zostało przygotowane na-

sze rozwiązanie.

Od strony biznesowej chcemy przygotowac

rozwiązanie przyjmujące pewne dane, które

zostaną przekazane w miejsce, gdzie w spo-

sób właściwy zostaną przetworzone, dając

oczekiwany rezultat (Rysunek 1).

Nasz proces będzie podzielony na dwie

części (komponenty), które mogą być do-

starczone przez niezależnych dostawców.

Pierwsza część procesu związana jest z na-

pisaniem aplikacji JEE, a dokładnie serwi-

su odpowiedzialnego za przekazanie odpo-

wiednio sparsowanej wiadomości do kolej-

ki MQ (ang. Message Queue ) ,wykorzystu-

jąc JMS (ang. Java Message Service ). Druga

re ) to pewna koncepcja, rodzaj podej-

ścia w tworzeniu oprogramowania,

w której staramy się tworzyć niezależne usłu-

gi, które następnie są udostępniane w celu

wykonania określonego zadania lub łączone

w łańcuchy kolejnych wywołań, tworząc tzw.

łańcuchy procesów biznesowych.

Tak naprawdę trudno w kilku zdaniach

powiedzieć, czym jest SOA. W tym artykule

skupimy się na tworzeniu usług sieciowych,

wykorzystując JAX-WS, które wykorzystamy

jako wygodne narzędzie wspomagające pro-

ces integracji wielu systemów.

Definicja procesu,

analiza problemu

Pracę zaczniemy od zdefiniowania procesu,

na podstawie którego przeprowadzimy ana-

lizę architektoniczną. Naszym celem jest

przygotowanie pewnego procesu bizneso-

wego który udostępnimy zewnętrznym od-

biorcom. Zgodnie z modelem SOA chce-

my oprogramować pewien proces, dla które-

go udostępnimy interfejs dla zewnętrznych

odbiorców. Proces ma być hermetyczny, na-

si klienci nie potrzebują mieć wiedzy na te-

Rysunek 1. Schemat procesu biznesowego

03/2010

S OA (ang. Service Oriented Architectu-

SOA

jąc się o model SOA, wykorzystamy do te-

go celu Webservice, który będzie interfej-

sem dostępowym dla niezależnych klien-

tów. Z punktu widzenia klienta, dostaje-

my interfejs do usługi, która odpowiada za

odebranie danych i odpowiednie ich prze-

procesowanie. Cała usługa jest hermetycz-

na, mamy interfejs odpowiedzialny za do-

stęp do procesu, który odbiera dane, parsu-

je, a następnie przesyła do kolejki, gdzie na-

stępuje przetworzenie tych danych i wyge-

nerowanie odpowiedniego rezultatu.

Rysunek 2. Schemat procesu biznesowego z podziałem na komponenty

Tworzenie usługi sieciowej

z wykorzystaniem JAX-WS

W pierwszej fazie implementacji naszego

procesu biznesowego zajmiemy się utwo-

rzeniem Webservice’u odpowiedzialne-

go za odebranie komunikatu i przekaza-

niu go do asynchronicznego przetwarzania.

Jak już wcześniej wspomniałem, wykorzy-

stamy standard JEE do utworzenia serwisu

oraz uzyskania dostępu do obiektów zwią-

zanych z JMS. Pierwszym krokiem będzie

utworzenie naszego serwisu, który poprzez

JMS prześle komunikat do kolejki. Dzię-

ki wsparciu dla Websphere MQ od strony

Websphere AS zostaną utworzone obiekty

QueueConnectionFactory oraz Queue , któ-

re dzięki odpowiedniej konfiguracji będą

naszym interfejsem dostępowym do We-

bsphere MQ. W pierwszym kroku utwo-

rzymy instancje obiektu QueueConnection-

Factory , wykorzystując Websphere MQ ja-

ko dostawcę usługi zarządzania komunika-

tami (Rysunek 4).

Po utworzeniu QueueConnectionFactory ,

ustawienia naszej fabryki powinny nawiązy-

wać do tego, co zostało zdefiniowane po stro-

nie MQ. W naszym przypadku dla fabryki

połączeń konfiguracja została przedstawiona

na Rysunku 5.

W sposób analogiczny tworzymy obiekt

Queue, który musi zostać powiązany z odpo-

wiadającą mu kolejką po stronie MQ (dokład-

ny opis konfiguracji Websphere AS do pracy

z Websphere MQ za pomocą JMS został omó-

wiony w SDJ 9/2009).

Mając zdefiniowane obiekty JMS, może-

my stworzyć nasz serwis do przekazywania

komunikatów do kolejki MQ. W tym celu

wykorzystamy standard JEE, a dokładnie

adnotację @Webservice, która pozwala nam

w bardzo prosty sposób stworzyć kod nasze-

go Webservice’u (Listing 1) oraz obiektu

wejściowego (Listing 2).

Po prawidłowej instalacji aplikacji na ser-

werze powinniśmy mieć możliwość wy-

generowania WSDL-a (Listing 3). W tym

celu należy wpisać w przeglądarce http:

//localhost:9080/sdjservice/MyServiceService-

?wsdl . Oczywiście url może wyglądać nieco

inaczej, w moim przypadku serwis został za-

Rysunek 3. Schemat procesu biznesowego z uwzględnieniem technologii

Listing 1. Webservice w JAX-WS

@WebService

public class MyService {

private static inal Logger LOGGER = Logger . getLogger ( MyService . class );

@Resource ( mappedName = "MQFactoryJNDI" )

private QueueConnectionFactory queueConnectionFactory ;

@Resource ( mappedName = "SDJQueue" )

private Queue queue ;

public Boolean sendData ( InputData input ){

LOGGER . debug ( "Invoking MyService.sendData" );

LOGGER . debug ( input );

try {

QueueConnection conn = queueConnectionFactory . createQueueConnection ();

Session session = conn . createSession ( false , Session . AUTO_ACKNOWLEDGE );

MessageProducer producer = session . createProducer ( queue );

TextMessage msg = session . createTextMessage ();

msg . setText ( input . mqMessage ());

LOGGER . debug ( "Sending message to mq" );

LOGGER . debug ( input . mqMessage ());

producer . send ( msg );

conn . close ();

return new Boolean ( true );

} catch ( JMSException ex ) {

LOGGER . error ( ex );

return new Boolean ( false );

}

www.sdjournal.org

Aplikacje biznesowe

instalowany na lokalnej maszynie z ustawio-

nym kontekstem sdjservice .

Na tym etapie dysponujemy poprawnie za-

instalowanym serwisem, który wykorzystu-

jąc odpowiednio zdefiniowane obiekty JMS

prześle komunikat do kolejki zdefiniowanej

po stronie MQ.

go za odebranie danych od klienta i prze-

kazanie ich do kolejki. Dzięki podzieleniu

naszego procesu biznesowego na dwa nie-

zależne komponenty możemy przeprowa-

dzić test i ostatecznie dostarczyć w peł-

ni funkcjonalny komponent niezależnie

od tego, czy dostawca odpowiedzialny za

utworzenie części związanej z przetwa-

rzaniem komunikatu po stronie MQ do-

starczył już swój komponent, czy nie. Ta-

kie podejście wyodrębniania niezależnych

części procesu biznesowego pozwala dość

łatwo zdywersyfikować dostawców kom-

ponentów do naszego systemu, a co za tym

idzie zmniejszyć ryzyko związane z uzależ-

nieniem projektu od jednego konkretnego

dostawcy.

W celu przeprowadzenia testu nasze-

go komponentu wykorzystamy komunikat

SOAP, którym wywołamy nasz serwis (Li-

sting 4).

Po wywołaniu naszego serwisu do MQ zo-

stał przekazany komunikat, który możemy

podejrzeć za pomocą narzędzia MQ Explo-

ler (Rysunek 6) oraz zwrócony komunikat

SOAP (Listing 5).

Test usługi sieciowej

W tej chwili możemy przeprowadzić pełny

test naszego komponentu odpowiedzialne-

Rysunek 4. Kon�guracja dostawcy zarządzania komunikatami

Tworzenie

i konfiguracja aplikacji

– konsumenta komunikatów MQ

Druga faza naszego procesu jest związana

z przetwarzaniem komunikatu umieszczo-

nego w MQ. Nasz proces biznesowy z zało-

żenia ma być częścią większego systemu,

który w oparciu o pewne kryteria wywoła

nasz proces lub nie. Załóżmy więc, że mo-

że istnieć sytuacja, w której nie będzie co

przetwarzać przez kilka lub kilkanaście go-

dzin. Jak w takiej sytuacji zapewnić wydaj-

ne oraz optymalne przetwarzanie komuni-

katów? Zastosowanie klasycznej aplikacji

wielowątkowej na pewno spełni nasze ocze-

Listing 2. De�nicja klasy InputData

@XmlAccessorType ( XmlAccessType . FIELD )

@XmlRootElement ( namespace =

"http://model.sdj" , name = "InputData" )

public class InputData {

private String code ;

private Integer num ;

@Override

public String toString () {

StringBuilder sb =

new StringBuilder ();

sb . append ( "InputData \n" );

sb . append ( "code=" + code + ";" );

sb . append ( "num=" + num + ";" );

return sb . toString ();

}

public String mqMessage (){

StringBuilder sb =

new StringBuilder ();

sb . append ( "code=" + code + ";" );

sb . append ( "num=" + num + ";" );

return sb . toString ();

}

Rysunek 5. Kon�guracja QueueConnectionFactory

03/2010

SOA

kiwania w zekresie funkcjonalnym, ale czy

będzie rozwiązaniem optymalnym i wydaj-

nym na płaszczyźnie naszego problemu?

Czy stworzenie wątku głównego, który sta-

le będzie musiał w krótkich odstępach cza-

su odpytywać MQ o to, czy istnieją jakieś

komunikaty, jest rozwiązaniem oczekiwa-

nym ? Bardzo możliwe, że w pewnych wa-

runkach tak, natomiast w naszych na pew-

no nie. Zakładamy, że nasz proces jest czę-

ścią większego systemu, który może w pew-

nych warunkach poprosić nas o asynchro-

niczne przetworzenie pewnych informa-

cji we względnie krótkim czasie, ale zara-

zem może nas o to nie prosić przez dłuż-

szy okres. W takiej sytuacji oczekiwanym

rozwiązaniem byłby mechanizm, który po-

zwalałby konsumować komunikaty tylko

wtedy, kiedy będą w kolejce, unikając sytu-

acji, w której komunikat czeka w kolejce na

przetworzenie.

MQ dostarcza nam taki mechanizm, tzw.

triggering, który pozwala zdefiniować po stro-

nie MQ proces odpowiedzialny za wywołanie

aplikacji – konsumenta w chwili nadejścia

nowego komunikatu do kolejki.

Od strony programisty naszego kompo-

nentu kod nie ulega dużym modyfikacjom.

Tworzymy aplikację odpowiedzialną za na-

wiązanie połączenia z managerem kolej-

ki, pobraniem komunikatu i wykonaniem

dedykowanej logiki biznesowej w oparciu

o informacje zawarte w komunikacie (Li-

sting 6).

Tak przygotowany kod wraz z odpowied-

nim plikiem MANIFEST.MF (Listing 7) na-

leży zapakować w plik jar i wraz z zależnymi

bibliotekami umiejscowić gdzieś na dysku.

Jest to o tyle istotne, ponieważ MQ pozwa-

la wywoływać za pomocą triggera pliki wy-

konywalne, zatem chcąc wywołać naszą apli-

kację JAVA, będziemy wykonywać polecenie

„ java -jar D:\lib\mqclient.jar ”.

W ostatnim etapie dokonamy niezbęd-

nej konfiguracji po stronie MQ. W pierw-

szym kroku należy stworzyć kolejkę (INI-

TQ) wykorzystywaną przez monitor wyzwa-

lacza ( ang. Trigger Monitor ) . Od strony czy-

sto technicznej proces wyzwalania aplikacji

przez MQ przebiega w czterech podstawo-

wych krokach:

Listing 3. WSDL serwisu MyService

<?xml version="1.0" encoding="UTF-8"?>

<deinitions name= "MyServiceService" targetNamespace= "http://service.sdj/"

xmlns= "http://schemas.xmlsoap.org/wsdl/" xmlns:xsd= "http://www.w3.org/2001/

XMLSchema"

xmlns:tns= "http://service.sdj/" xmlns:soap= "http://schemas.xmlsoap.org/wsdl/soap/" >

<types>

<xsd:schema>

<xsd:import namespace= "http://service.sdj/" schemaLocation= "MyServiceService

_schema1.xsd" />

</xsd:schema>

<xsd:schema>

<xsd:import namespace= "http://model.sdj" schemaLocation= "MyServiceService_

schema2.xsd" />

</xsd:schema>

</types>

</part>

</message>

</part>

</message>

</input>

</output>

</operation>

</portType>

<soap:binding style= "document" transport= "http://schemas.xmlsoap.org/soap/

http" />

<soap:operation soapAction= "" />

<input>

<soap:body use= "literal" />

</input>

<soap:body use= "literal" />

</output>

</operation>

</binding>

<soap:address location= "http://ewadl00gb1c74j.ams.com:9080/sdjservice/

MyServiceService" />

• wstawienie wiadomości do kolejki

QUEUE _ SDJ ;

• wygenerowanie wiadomości – wyzwa-

lacza ( ang. Trigger control message) i wsta-

wienie jej do kolejki INITQ (proces ten

przebiega automatycznie);

• odebranie zgłoszenia przez monitor z ko-

lejki INITQ;

• wyzwolenie (uruchomienie) naszej apli-

kacji JAVA poprzez wykonanie polece-

nia „ java -jar D:\lib\mqclient.jar ”.

</port>

</service>

</deinitions>

W Sieci

• http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.amqtac.doc/

wq11350_.htm ;

• http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp ;

• http://java.sun.com/javaee/5/docs/tutorial/doc/ .

www.sdjournal.org

Aplikacje biznesowe

Drugim krokiem będzie odpowiednia kon-

iguracja kolejki głównej (QUEUE_SDJ) do

wykorzystywania mechanizmu wyzwala-

nia (Rysunek 7). Do najważniejszych usta-

wień można zaliczyć:

Rysunek 6. Przeglądarka komunikatów

• kontrola wyzwalacza – ustawia możli-

wość wykorzystywania mechanizmu

wyzwalaczy dla kolejki, musi być włą-

czona;

• wyzwalacz uruchamiany zapełnieniem

– ilość komunikatów, która spowoduje

uruchomienie naszej aplikacji;

• kolejka inicjująca – kolejka skojarzona

z monitorem, ustawiamy na INITQ;

• nazwa procesu – nazwa procesu, z któ-

rym zostanie skojarzona nasza aplikacja

– konsument.

Trzecim i zarazem ostatnim krokiem będzie

zdeiniowanie procesu powiązanego z na-

szą kolejką QUEUE _ SDJ . W tym celu należy

rozwinąć QM_SDJ->Zaawansowane i utwo-

rzyć nowy proces o nazwie SDJ _ PROCESS

i wybrać Dalej . W kolejnym oknie w polu ID

aplikacji należy wpisać java -jar D:\lib\

mqclient.jar (Rysunek 8).

Listing 4. Komunikat SOAP do wywołania

serwisu MyService

<soapenv:Envelope xmlns:soapenv=

"http://schemas.xmlsoap.org/soap/

envelope/" xmlns:ser= "http:/

/service.sdj/" >

Rysunek 7. Kon�guracja QUEUE_SDJ

<soapenv:Header/>

<soapenv:Body>

<ser:sendData>

<arg0>

</arg0>

</ser:sendData>

</soapenv:Body>

</soapenv:Envelope>

Listing 5. Komunikat SOAP z odpowiedzią

z MyService

<soapenv:Envelope xmlns:soapenv=

"http://schemas.xmlsoap.org/soap/

envelope/" >

<soapenv:Body>

<dlwmin:sendDataResponse xmlns:

dlwmin= "http://service.sdj/" >

<return xmlns:ns2=

"http://model.sdj" >

true </return>

</dlwmin:sendDataResponse>

</soapenv:Body>

</soapenv:Envelope>

Rysunek 8. Kon�guracja procesu

03/2010

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: