В този пример, нашата реализация на услугата ще се състои от самостоятелен Java клас включващ едновременно кода на услугата и на ресурсите. По принцип е препоръчително да се разделя реализацията поне на два класа: един за услугата и един за ресурсите. Подхода който ще използваме да обединим всичко в един клас е подходящ за по прости примери какъвто е и нашия.
Писането на кода на услугата е всъщност доста механично. Единственото не тривиално в кода е методът който ще отговаря за инициализирането на ресурсите на услугата. Опорните точки на класа са следните:
package org.globus.examples.services.core.first.impl;
import java.rmi.RemoteException;
import org.globus.wsrf.Resource;
import org.globus.wsrf.ResourceProperties;
import org.globus.wsrf.ResourceProperty;
import org.globus.wsrf.ResourcePropertySet;
import org.globus.wsrf.impl.ReflectionResourceProperty;
import org.globus.wsrf.impl.SimpleResourcePropertySet;
import org.globus.examples.stubs.MathService_instance.AddResponse;
import org.globus.examples.stubs.MathService_instance.SubtractResponse;
import org.globus.examples.stubs.MathService_instance.GetValueRP;
public class MathService implements Resource1, ResourceProperties2 {
}
-
1 След като нашият Java клас ще имплементира едновременно услугата и ресурсите, ще е необходимо да се имплементира интерфейс за ресурсите. Този интерфейс не се нуждае от каквито и да е методи.
-
2 Имплементирайки интерфейса ResourceProperties показваме, че класът ни има набор от ресурси, които искаме да са на разположение. Този интерфейс се нуждае от следната добавка в нашия клас:
private ResourcePropertySet propSet;
public ResourcePropertySet getResourcePropertySet() {
return this.propSet;
}
Трябва да не забравяме, че нашите ресурси се състоят от две променливи: Value от тип xsd:int и LastOp от тип xsd:string. Необходимо е да добавим атрибут за всяка променлива посредством get/set метод.
/* Resource properties */
private int value;
private String lastOp;
/* Get/Setters for the RPs */
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
public String getLastOp() {
return lastOp;
}
public void setLastOp(String lastOp) {
this.lastOp = lastOp;
}
4.3. Дефиниране на параметрите и настройване.
До този момент сме написали двете най важни части от нашата уеб услуга: интерфейсът и имплементацията на услугата. Независимо от това все още нещо ни липсва. Как на практика ще дадем на разположение услугата на клиенти? В този следващ етап ще обединим всичко което сме направили до момента и ще го направим достъпно посредством контейнера с уеб услуги. Тази стъпка се нарича внедряване на уеб услугата с помощта на инструментите предоставяни от експерименталната ГРИД среда.
4.3.1. Описание на услугата.
Описанието на услугата се прави посредством описател на услугата /deployment descriptor/. В описателя се включват следните елементи:
-
Име на услугата – то определя местоположението, където може да бъде намерена услугата. Ако комбинираме това с базовия адрес на контейнера ще получим пълния път до нашата услуга.
-
Име на клас – този параметър се отнася към класа, който имплементира интерфейса на услугата.
-
Файлът WSDL – Този файл /Math_service.wsdl/ ще се генерира автоматично от Глобус Тулкит 4 когато компилираме услугата.
-
Зареждане при стартиране – този параметър ни позволява да контролираме дали услугата да се зарежда заедно със зареждането на контейнера. Най добре е услугите да се зареждат заедно със зареждането на контейнера.
-
Параметри
Това са три параметъра, които могат да се видят във всяка уеб услуга и по добре да бъдат оставени непроменени.
4.3.2. Файл за стартиране в ГРИД средата.
Файлът за стартиране /JNDI deployment file/ се използва за да бъде внедрена нашата услуга в ГРИД средата. Файлът изглежда по следния начин:
factory
org.globus.wsrf.jndi.BeanFactory
4.4. Създаване на архив.
На този етап имаме интерфейс, реализация на услугата, описател и стартиращ файл. Всички тези файлове са безполезни ако не са заедно, но как точно трябва да ги поставим в контейнер с уеб услуги? Отговора на този въпрос ще стане ясен в този четвърти етап. Използвайки файловете които написахме ще генерираме Грид архив /Grid Archive/ или така наречения ГАР файл /GAR file/. Този ГАР файл представлява един единствен файл, който съдържа всички файлове и информация нужни на контейнера за да бъде внедрена и представена нашата услуга на външния свят. Създаването на ГАР файл е доста сложна задача включваща следното:
-
Обработка на WSDL файла
-
Създаване на допълнителни класове
-
Компилиране на допълнителните класове
-
Компилиране на имплементацията на услугата
-
Организиране на всички файлове в много специфична директорийна структура
Всички тези стъпки са сложни и изискват много внимание, но благодарение на инструмента Ant всички тези процедури се свеждат до една стъпка.
Фиг. № 7 Създаване на архив.
Както се вижда на фигура № 7 , Ант генерира ГАР директно от трите групи файлове. Вътрешно Ант се грижи да изпълни всяка една от горепосочените стъпки, спестявайки ни много работа.
Използвайки предоставения билд файл и съответния скрипт можем да преминем към създаването на нашия архив. За целта е необходимо да направим следното:
./globus-build-service.sh -d <базова директория на услугата> -s
Базовата директория на услугата представлява директорията където сме поставили файла deploy-server.wsdd и там където се намират Java файловете. За да изградим нашия пример е необходимо да направим следното:
./globus-build-service.sh \
-d org/globus/examples/services/core/first/ \
-s schema/examples/MathService_instance/Math.wsdl
След като сме направили това можем да преминем към създаването на архива. Това става по следния начин:
./globus-build-service.sh first
Ако всичко е както трябва, ГАР файлът ще бъде създаден и поставен в съответната директория. За да бъдем точни генерираният файл е следния:
$EXAMPLES_DIR/org_globus_examples_services_core_first.gar
Сподели с приятели: |