Вступление

Из-за ограниченной поддержки JAX-RPC для определенной схемы построения XML, генераторы WSDL-to-Java на базе JAX-RPC часто оставляют программиста с набором приложений Java, которые в действительности не ведут себя так, как вы ожидали. Доказательством этому может служить javax.xml.soap.SOAPElement, когда вы ожидаете получения составленного типа Java, представляющего собой тип вашей схемы. Непосредственное создание и продвижение этих приложений вместо продвижения обычных приложений Java может занять много времени и быстро привести приложение в беспорядок.

А возможно, вы используете определенную технологию привязки данных XML в вашем приложении, которое в данный момент вы хотите представить как веб-службу. В этом случае вы, возможно, не захотите переписывать приложение, чтобы привести в соответствие уже существующие приложения и новые JAX-RPC, которые могут понадобиться.

С помощью примеров мы покажем Вам, как работает новая функция привязки специальных данных WebSphere, и как она может помочь вам при использовании этих сценариев использовать собственную технологию преобразования данных для веб-служб. Эта функция была впервые представлена на базе сервера прикладных программ WebSphere и Network Deployment, версия 6.

Сериализация и десериализация в WebSphere

Еще до рассмотрения особенностей привязки специальных данных, изучение текущей среды сериализации и десериализации в WebSphere поможет Вам разобраться в том, как она может быть расширена для обычной сериализации.

Типовое преобразование данных и поэлементное преобразование данных

Среда исполнения современных веб-служб (представленная в WebSphere V5.0.2) поддерживает модель программирования JAX-RPC, которая основана на понятии системного реестра типового преобразования данных. Это означает, что каждый тип, существующий в файле WSDL или XSD, будет иметь специальное параллельно-последовательное и последовательно-параллельное преобразование, созданное для тех, кто умеет соединять эти типы. Данное понятие типового преобразования данных является ключевым моментом, который необходимо помнить при разработке вашего приложения привязки специальных данных. Оно отличается от поэлементного преобразования данных, в котором типы Java создаются на основе определения конкретного корневого элемента внутри WSDL. В типовом преобразовании данных пользовательское видение данных основано на типах, которые существуют внутри XSD, ассоциирующейся с определенным WSDL.

Преобразование данных из WSDL в Java

Рассмотрим пример. Листинг 1 показывает часть XSD, взятую из файла WSDL, с двумя элементами, которые относятся к вводу и выводу операции. Запрос принимает объект ввода типа OpType, в то время как ответ возвращает обычный String. JAX-RPC отобразит комплексный тип OpType для объекта Java, который называется OpType и включает два атрибута, c1 и c2, каждый из них является типом String (строка).

                
<xsd:element name="Op1Response" type="xsd:string" />
<xsd:element name="Op1Request" type="tns:OpType" />
<xsd:complexType name="OpType">
    <xsd:sequence>
        <xsd:element name="c1" type="xsd:string"/>
        <xsd:element name="c2" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>

Пример этого класса показан в Листинге 2. Если бы эти элементы были более сложными типами, осуществлялось бы дальнейшее построение системы

public class OpType {
	
	private String c1;
	private String c2;
	
	public String getC1() {
		return c1;
	}
	
	public void setC1(String val) {
		c1 = val;
	}
	
	public String getC2() {
		return c2;
	}
	
	public void setC2(String val) {
		c2 = val;
	}

}

В другом типичном примере используется понятие свернутой (wrapped) операции, которое стало общепринятым несмотря на то, что формального определения этой модели не существует. Данная модель определяет поэлементный/комплексный тип преобразования данных, имя которых совпадает с именем операции. Дочерние элементы комплексного типа представляют собой параметры операции.

Посмотрев на часть образца файла WSDL в Листинге 3, вы видите, что там находятся два определенных элемента, за которыми следуют две части, указывающие на эти элементы. Первый элемент - объект, который уполномочивает другой объект на изменение своего интерфейса и который принимает два аргумента (один типа xsd:int, а другой типа xsd:string). Второй является элементом ответа, который содержит в себе один элемент (типа xsd:string).

Эти элементы определяются как входная и выходная части сообщения WSDL (операционный запрос и операционный ответ).

                
<element name="operation1">
    <complexType>
        <sequence>
            <element name="arg_0_0" type="xsd:int"/>
            <element name="arg_1_0"
             nillable="true="xsd:string"/>
        </sequence>
    </complexType>
</element>
<element name="operation1Response">
    <complexType>
        <sequence>
            <element name="operation1Return"
             nillable="true" type="xsd:string"/>
        </sequence>
    </complexType>
</element>
<wsdl:message name="operation1Request">
    <wsdl:part element="impl:operation1"
     name="parameters"/>
</wsdl:message>
<wsdl:message name="operation1Response">
    <wsdl:part element="impl:operation1Response"
     name="parameters"/>
</wsdl:message>
<wsdl:portType name="MyPortType">
    <wsdl:operation name="operation1">
        <wsdl:input message="impl:operation1Request" 
                name="operation1Request"/>
        <wsdl:output message="impl:operation1Response" 
                name="operation1Response"/>
    </wsdl:operation>
</wsdl:portType>

В JAX-RPC эти параметры десериализованы в нормальные объекты Java и базисные (primitive) типы данных. При использовании инструментов WSDL2Java, предоставляемых WebSphere, созданный интерфейс JAX-RPC для WSDL будет выглядеть так же, как показано ниже в Листинге 4. Заметьте, что в этом примере среда исполнения развернула операционный объект, изменяющий интерфейс, чтобы сделать его схожим с RPC.

                
public interface MyPortType extends java.rmi.Remote {
    public java.lang.String operation1(int a, java.lang.String b)
        throws java.rmi.RemoteException;
}

При использовании флажка “noWrappedOperations” (запретить свертывание операций) на панели инструментов WSDL2Java будет считаться, что у WSDL нет возможности осуществлять свертывание, и содержимое элемента не будет развернуто, пока они не будут возвращены к программному компоненту. В этом сценарии программные компоненты будут созданы для всех комплексных типов, а вместо принятия двух индивидуальных параметров (int и String), интерфейс будет вынужден принять целостный операционный элемент. Когда конечный интерфейс (SEI) создан из типа portType, он будет выглядеть, как в Листинге 5. Этот пример становится ключевым, когда мы пытаемся преобразовать полные документы XML, которых мы коснемся позднее).

                
public interface MyPortType extends java.rmi.Remote {
    public a.b.Operation1Response 
    operation1(a.b.Operation1 parameters)
        throws java.rmi.RemoteException;
}

В начало

Как сделать вашу службу настраиваемой

Теперь, когда у вас есть высокий уровень понимания того, как преобразовываются и сериализуются типы внутри WebSphere, давайте посмотрим, что вам необходимо сделать с вашей веб-службой, чтобы эффективно использовать привязку данных. В данном разделе обсуждается то, как модель данных (ваш программный компонент Java) определенной веб-службы может быть отделен от модели инициирования работы системы (интерфейсы, которые вы активизируете).

Чтобы добиться подключения к альтернативным технологиям преобразования данных, прежде всего нам необходимо научиться работать с моделью данных, независимо от модели инициирования работы системы. Нам нужны параметры веб-службы, чтобы она была более настраиваемой и чтобы мы легко могли переходить к настроенному представлению специальных объектов. Чтобы это сделать, мы будем использовать опцию noDataBinding на панели инструментов WSDL2Java WebSphere.

Когда установлен флажок noDataBinding, WSDL2Java воздерживается от привязки любых артефактов к их обычному представлению Java. Вместо этого все преобразуется в приложение SAAJ. Приложение API используется в JAX-RPC как настраиваемая форма для моделирования типов схемы и случаев, для которых нет преобразования данных (например, xsd:choice).

Если вы взглянете на Листинг 6, то увидите разработанный интерфейс JAX-RPC для этого сценария. Этот интерфейс основан на модели WSDL из Листинга 3. Как было сказано, все типы ввода и вывода преобразовываются в приложение, содержащее текст XML.

                
public interface MyPortType extends java.rmi.Remote {
    public javax.xml.soap.SOAPElement operation1
    (javax.xml.soap.SOAPElement parameters)
        throws java.rmi.RemoteException;
}

Важно помнить, что это - специфическая функция WebSphere, и не существует спецификации или стандарта, который определяет, каким будет преобразование из WSDL в Java для этого формата без привязки данных. Однако эта схема, используемая на панели инструментов, показывает, что характерной чертой методов, разработанных в интерфейсе JAX-RPC, является содержание приложения для каждой части внутри WSDL. Другими словами, количество параметров ввода по одному методу соотносится с количеством <wsdl:part/>s within <wsdl:message>. Вспомнив наш WSDL, определенный в Листинге 3, вы увидите, что существует отдельная часть параметров для сообщения operation1Request, которое представляет собой запрос. Таким образом, мы видим только одно приложение, представляющее собой полезную нагрузку целого запроса.

Если вы используете инструмент® Rational Application Developer при создании чтобы создать приложения веб-служб, опцию отключения привязки данных на созданных интерфейсах бывает нелегко найти. Чтобы ее найти, выберите Preferences => Web Services => Code Generation => IBM WebSphere Runtime, затем выберите Disable data binding (Отключить привязку данных) и используйте приложение SOAP.

Дополнительные полезные API

Пока возможно обеспечивать исполнение веб-службы, в которой используется схема без привязки данных только с официальным SAAJ 1.2 приложением API, IBM представила некоторые дополнительные методы по обеспечению исполнения для того, чтобы поддерживать эти расширения. Они представлены на официальном интерфейсе IBM на com.ibm.websphere.webservices.soap.IBMSOAPElement.

Эти два метода на данном интерфейсе являются особенно полезными при написании приложения без привязки данных: toXMLString(boolean) и toInputSource(boolean).

• toXMLString(boolean) позволяет вам получить содержимое приложения SOAP как последовательность XML. Обратная последовательность представляет собой точное содержимое текущего приложения SOAPE и его производных. Эта последовательность может быть проанализирована любым способом, какой вы выберите, и десериализована в выбранную вами форму объекта. В некоторых случаях, содержимое основной части SOAP может зависеть от деклараций пространства имен, которые имеют место на более высоком уровне в SOAP Envelope. В этих случаях, если булевский параметр задан верно, то обратная последовательность будет включать данные приложения SOAPE вместе с декларациями пространства имен от исходных элементов.
• toInputSource(boolean) позволяет вам получить содержимое приложения SOAP как InputSource (источник ввода). Данный источник ввода может обеспечивать другие среды исполнения или анализаторы для того, чтобы десериализовать данные в типы других объектов. Что касается toXMLString, булевский параметр определяет, включены ли все декларации пространства имен от исходных.

                
package com.ibm.websphere.webservices.soap;
public interface IBMSOAPElement extends SOAPElement {
    public String toXMLString (boolean includeNSDecls);
    public InputSource toInputSource (boolean includeNSDecls) 
        throws SAXException;
 ...
}

API, описанный в листинге 7, является полезным, только когда у вас есть существующее приложение SOAP и когда вам необходимо извлечь данные простым способом. Это означает, что вы будете использовать только API, когда в вашей системе будет приложение SOAP (входящий запрос на сервер или входящий ответ пользователю). Однако существуют также API, которые были созданы для помощи при разработке новых приложений SOAP. Вы можете использовать их во входящем сценарии, в котором у вас имеется объект, содержащий некоторую форму данных XML, и из которого вы хотите создать приложение SOAP. IBM предложило оптимальное решение для этого сценария через com.ibm.websphere.webservices.soap.IBMSOAPElementFactory. Данный интерфейс позволяет создавать приложения SOAP как из InputSource так и из XML String.

                
package com.ibm.websphere.webservices.soap;
import javax.xml.soap.*;
import org.xml.sax.InputSource;
public interface IBMSOAPFactory {
    public SOAPElement createElementFromXMLString(
            String xmlString) throws SOAPException;
    public SOAPElement createElementFromInputSource(
            InputSource inputSource) throws SOAPException;
}

Возникает вопрос: зачем IBM разработала эти API, и почему я должен использовать их? Эти API рассматриваются как инструменты, которые делают работу с приложениями SOAP легче, но ни в коем случае от них не требуется обеспечение данного сценария всем необходимым. Их использование действительно упрощает систему кодирования в тех случаях, когда Вам будет необходимо управлять самими приложениями SOAPE вместо работы с объектами ваших данных.

В начало

Как работает привязка данных

Теперь, когда вы ознакомились с усовершенствованной поддержкой приложения SOAPE и понимаете принцип работы без привязки данных, у вас есть все необходимые инструменты для использования новой функции сериализации внутри WebSphere.

Что такое привязка данных?

Посмотрев на JAX-RPC, вы увидите, что преобразование данных из WSDL/XML в Java является ограниченным процессом. Для некоторых более сложных принципов JAX-RPC выбирает преобразовать их (например, xsd:anyAttribute, xsd:choice, и так далее) в приложение SOAP. Если мы посмотрим на JAX-WS 2.0, модель программирования веб-служб J2EE следующего поколения, мы заметим, что вместо определения своего собственного преобразования данных, она выбирает использование спецификации JAX-B 2.0 для привязки данных. JAX-B является более полным преобразованием данных схемы XML, чем предлагает JAX-RPC, но они имеют отличия. К сожалению, невозможно для JAX-RPC использовать JAX-B 2.0, так как это является механизмом привязки данных из-за того, что спецификация была еще неполная. Хотя во многих случаях вы захотите преобразовать данные веб-служб, используя JAX-B или другую технологию привязки данных, которая сделает ваше приложение более разумным. Или, возможно, вы уже получили набор компонентов Java, которые вы используете, и захотите сохранить текущее преобразование данных, а не иное, выбранное JAX-RPC.

Используя некоторые принципы и функции, представленные выше, возможно этим управлять, работая с несовершенными приложениями SOAP как с параметрами ввода и вывода, и осуществляя переход самостоятельно. Однако это означает, что приложение SOAP появится теперь в вашем конечном интерфейсе (или в качестве свойств внутри объекта) и любой, кому вы представите это, должен уметь работать с приложением SOAP. Привязка данных позволяет вам скрыть эту логику за рамками интерфейса и представить более адаптированный к данному приложению интерфейс API.

Как раз WebSphere позволяет осуществить это с помощью представления интерфейса привязки данных, который предоставляет преобразование данных из типа XML в тип Java (и наоборот). Механизм привязки данных содержит методы, способные управлять специфичными типами XML, преобразуя их в определенные объекты Java. Наоборот, механизм привязки данных также управляет сериализацией вашего объекта Java в его надлежащем представлением в XML.

Представим, например, что вы разработали ваш SEI из WSDL в Листинге 9, который содержит xsd:choice в одном из комплексных типов. Для наглядности этого примера, мы назовем данный интерфейс InventorySearch. Без использования привязки данных, созданный интерфейс будет выглядеть как тот, что представлен на листинге 10, с приложением SOAP как возвратным типом. Однако если мы поставим привязку данных вместо типа схемы, созданный интерфейс будет выглядеть скорее так, как вы ожидаете (как показано в Листинге 11), и будет представлять подходящие типы данных как типы ввода и вывода.

                
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://mycorp.com" 
       xmlns:impl="http://mycorp.com" 
       xmlns:intf="http://mycorp.com" 
       xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
       xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 
       xmlns:wsi="http://ws-i.org/profiles/basic/1.1/xsd" 
       xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <wsdl:types>
  <schema targetNamespace="http://mycorp.com" xmlns="
  http://www.w3.org/2001/XMLSchema">
   <element name="findItemResponse">
    <complexType>
     <sequence>
      <element name="findItemReturn" nillable="true" type="
      impl:InventoryItem"/>
     </sequence>
    </complexType>
   </element>
   <element name="findItem">
    <complexType>
     <sequence>
      <element name="arg_0_0" type="xsd:int"/>
     </sequence>
    </complexType>
   </element>
   <complexType name="InventoryItem">
    <sequence>
     <element name="productId" type="xsd:int"/>
     <element name="productName" nillable="true" type="
     xsd:string"/>
      <xsd:choice>
       <element name="reorderNeeded"
        type="xsd:boolean"/>
       <element name="stockCount"
        type="xsd:int"/>
      </xsd:choice>
    </sequence>
   </complexType>
  </schema>
 </wsdl:types>
 
    <wsdl:message name="findItemResponse">

      <wsdl:part element="impl:findItemResponse"
       name="parameters"/>

   </wsdl:message>

   <wsdl:message name="findItemRequest">

      <wsdl:part element="impl:findItem"
       name="parameters"/>

   </wsdl:message>

                
   <wsdl:portType name="InventorySearch">

      <wsdl:operation name="findItem">

         <wsdl:input message="impl:findItemRequest"
          name="findItemRequest"/>

         <wsdl:output message="impl:findItemResponse"
          name="findItemResponse"/>

      </wsdl:operation>

   </wsdl:portType>

   <wsdl:binding name="InventorySearchSoapBinding"
    type="impl:InventorySearch">

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

      <wsdl:operation name="findItem">

         <wsdlsoap:operation soapAction=""/>

         <wsdl:input name="findItemRequest">

            <wsdlsoap:body use="literal"/>

         </wsdl:input>

         <wsdl:output name="findItemResponse">

            <wsdlsoap:body use="literal"/>

         </wsdl:output>

      </wsdl:operation>

   </wsdl:binding>

   <wsdl:service name="InventorySearchService">

      <wsdl:port binding="impl:InventorySearchSoapBinding"
      name="InventorySearch">

         <wsdlsoap:address location="file:undefined_location"/>

      </wsdl:port>

   </wsdl:service>

</wsdl:definitions>

Листинги 10 и 11 показывают конечный интерфейс без привязки данных и с ней.

                
import javax.xml.soap.SOAPElement;
public interface InventorySearch extends java.rmi.Remote {
    public SOAPElement findItem(int productId) 
        throws java.rmi.RemoteException;
}

                
import com.mycorp.InventoryItem;
public interface InventorySearch extends java.rmi.Remote {
    public InventoryItem findItem(int productId)
        throws java.rmi.RemoteException;
}

Где использовать привязку данных

В среде исполнения и в управлении WebSphere привязка данных используется в период разработки, а также во время рабочего цикла. Во время периода разработки происходит поиск доступных видов привязки данных и проверка каждого из них для того, чтобы найти тип схемы и тип Java, которые они поддерживают. Эта информация используется для обновления системных реестров типового преобразования данных, а во время создания интерфейсов она предоставит код для использования корректно преобразованных типов вместо приложения SOAP или какого-нибудь другого типа.

Подобным образом среда исполнения систематизирует привязку данных и использует те виды привязки данных, которые необходимы для выполнения ее функции. Она пытается найти все случаи /META-INF/services/CustomBindingProvider.xml и использует эту информацию для настройки своих системных реестров типового преобразования данных и для подготовки каждого из видов привязки данных к сериализации и десериализации.

В среде исполнения WebSphere она осуществляет поиск пути к классам для доступных видов привязки данных. Можно задать собственные виды привязки данных на различных уровнях путей к классам, которые зависят от уровня модульности системы. Например, если вы сворачиваете привязку данных внутри вашего файла EJB или файла веб-приложения, привязка данных будет доступна только для этого конкретного модуля. Или вы можете сделать ее более доступной, создав библиотеку коллективного доступа таким образом, что любой модуль, использующий эту библиотеку, сможет увидеть ее. Также вы можете сделать ее видимой для всех WebSphere, разместив ее в директории библиотеки установки WebSphere.

Создание привязки данных и ее артефактов

Привязка данных состоит из двух артефактов, которые вам будет необходимо создать. Первый - файл XML, CustomBindingProvider.xml, который определяет всю необходимую информацию для управления и среды исполнения, чтобы разместить привязку данных. Второй является реализацией класса привязки данных, который задан в CustomBindingProvider.xml. Этот класс управляет сериализацией и десериализацией объектов с помощью особого интерфейса. Мы обсудим класс привязки данных более досконально позднее в этой статье.

Ниже вы найдете список различных элементов, которые требуются в примере CustomBindingProvider.xml. Каждый из них должен быть заполнен в вашем файле и должен иметь значение для того, чтобы привязка данных работала корректно.

• xmlQName: Именованный тип XML, из которого вы преобразовываете данные
• javaName:Имя класса Java, в который вы преобразовываете данные
• qnameScope: Область действия типа
• binder: Имя класса Java привязки данных, которая используется при встрече с этим типом

После создания CustomBindingProvider.xml обычно хранится вместе с классом (классами) привязки данных в одном файле jar, и должен быть сохранен в директории /META-INF/services/CustomBindingProvider.xml. Листинг 12 является примером CustomBindingProvider.xml, основанном на примере InventorySearch, рассмотренном выше.

                
<?xml version="1.0" encoding="UTF-8"?>
<provider xmlns="
http://www.ibm.com/webservices/customdatabinding/2004/06" 
   xmlns:mycorp="http://mycorp.com">
   <mapping>
      <xmlQName>mycorp:IventoryItem</xmlQName>
      <javaName>com.mycorp.IventoryItem</javaName>
      <qnameScope>complexType</qnameScope>
      <binder>com.mycorp.InventoryItemBinder</binder>
   </mapping>
</provider>

В вышеупомянутом примере вы можете увидеть, что мы детально представили привязку данных, которая преобразовывает комплексный тип mycorp:IventoryItem, определенный в схеме, в тип Java com.mycorp.InventoryItem.

Класс привязки данных, определенный элементом <binder/>, является классом Java, который обеспечивает работу интерфейса com.ibm.wsspi.webservices.binding.CustomBinder, необходимого для привязки данных. Эти методы предоставляют информацию для среды исполнения также как для типов QNames и/или Java, в которые преобразовываются данные, вместе с методами сериализации и десериализации. Эти два метода: сериализовать(Object, SOAPElement, CustomBindingContext) и десериализовать(SOAPElement, CustomBindingContext). Когда привязка данных распознается средой исполнения, она соединяется со средой исполнения через приложение SOAP следующими способами:

• Метод сериализации привязки данных осуществляется средой исполнения и принимает объект Java и приложение SOAP. Объект Java представляет собой данные, которые должны быть сериализованы, а приложение SOAP является контекстным элементом для сериализации. Данное приложение SOAP показывает место в SOAP Envelope, куда будут помещены ваши данные таким образом, что вам остается их туда только подтолкнуть.
• В отличие от обычной сериализации, когда выполняется контрольное считывание необработанных данных, привязка данных представляет промежуточную форму сообщения SOAP как приложение SOAP. Среда исполнения сама переписывает приложение SOAP в необработанные данные. Очевидно, что легче создать приложение SOAP, чем необработанный текст, потому что SAAJ API доступны для помощи. Когда приложение SOAP заполнено необходимыми данными, оно должно быть возвращено пользователю.
• Подобным образом во время десериализации среда исполнения создает подходящий пример javax.xml.soap.SOAPElement и передает его для привязки данных, которая затем десериализует его в объект Java. Здесь передается именно ответственность привязки данных создавать и заполнять данными корректный объект Java, на основе SOAP.

Листинг 13 показывает интерфейс CustomBinder.

                
public interface CustomBinder 	 {
    // the QName this binder targets
    public QName getQName():
    // QName scope for this binder
    public String getQNameScope();
    // the Java type name for unmarshalling
    public String getJavaName();	
    // serialize the Java object to SOAPElement
    public javax.xml.soap.SOAPElement serialize 
    (Object bean,
            SOAPElement rootNode, 
            CustomBindingContext context) 
        throws SOAPException;
    // deserialize the SOAPElement to Java object
    public Object deserialize 
    (javax.xml.soap.SOAPElement source, 
            CustomBindingContext context)  
        throws SOAPException;
}

Листинг 14 содержит каркас того, как должен выглядеть класс привязки данных в нашем примере InventorySearch.

                
import com.ibm.wsspi.webservices.binding.CustomBinder;
import com.ibm.wsspi.webservices.binding.CustomBindingContext;

public class InventoryItemBinder implements CustomBinder {
    public QName getQName() {
        return new QName("http://mycorp.com", "InventoryItem");
    }

    public String getQNameScope() {
        return CustomBinder.QNAME_SCOPE_COMPLEXTYPE;
    }

    public String getJavaName() {
        return com.mycorp.InventoryItem.getClass().getName();
    }

    public javax.xml.soap.SOAPElement serialize (Object bean,
            SOAPElement rootNode, CustomBindingContext context)
        throws SOAPException; {
        // populate the SOAPElement based on the contents of the
        // object that was passed in.
        return rootNode;
    }

    public Object deserialize (javax.xml.soap.SOAPElement source, 
            CustomBindingContext context)  
        throws SOAPException {
        // create an instance of the appropriate Java object based on
        // the SOAPElement that was passed in.
        return inventoryItem; 
   }
}

Подведение итогов

В настоящее время не существует инструментов для создания CustomBindingProvider.xml или обычного класса привязки данных автоматически, поэтому вам будет нужно создавать их вручную. Используя вышерассмотренные примеры, вы должны суметь собрать вместе оба этих артефакта при помощи Rational Application Developer или текстового редактора.

Когда вы создали эти два предмета, следующим шагом будет их сворачивание в файл jar привязки данных таким образом, что вы сможете использовать его, чтобы разрабатывать и размещать приложение ваших веб-служб. Лучший способ - это создать новый файл jar (либо вручную, либо используя Rational Application Developer – RAD) и включить его в класс привязки данных вместе с CustomBindingProvider.xml. Помните, что файл XML должен быть сохранен в директории /META-INF/services/CustomBindingProvider.xml.

Теперь, с настроенной привязкой данных, все готово для разработки оставшейся части вашего приложения. Если вы используете панель управления командной строки веб-служб WebSphere (Java2WSDL и WSDL2Java), для разработки вашего приложения, выберите следующую команду:

WSDL2Java.sh [your normal options] -classpath /temp/mybinder.jar [wsdl file name]

Как видите, единственное изменение, которое необходимо сделать с вашим обычным использованием WSDL2Java, это включить директорию в созданный вами файл jar. Когда вы это сделаете, инструмент WSDL2Java будет осуществлять поиск директории для доступного CustomBindingProvider.xml и изменит свои установки подходящим образом. Классы и дескрипторы установки, которые создаются, должны это отражать и должны теперь содержать ваш особый тип данных вместо приложений SOAP, которые были раньше.

Если вы используете Rational Application Developer, все, что Вам необходимо сделать, это удостовериться в том, что файл jar привязки данных был добавлен во внешний файл jar. Rational Application Developer добавляет все эти файлы jar в прежнюю директорию панели инструментов WSDL2Java и Java2WSDL.

В начало

Вывод

Используя нашу информацию, теперь вы должны уметь создавать приложения веб-служб, основанные на WebSphere, которые могут преобразовывать некоторые более сложные типы, неподдерживаемые JAX-RPC. Созданные интерфейсы должны выглядеть так, как этого ожидают те, кто пытается использовать ваше приложение, а от пользователей не требуется глубокого понимания SAAJ и структуры ожидаемого приложения SOAP.

Как было отмечено ранее, целью этой статьи было предложить обзор механизма привязки данных и то, как она может улучшить ваше приложение. Следующая статья этой серии предложит детальный анализ класса привязки данных, которой мы пользуемся для сериализации и десериализации типов данных, основанных на преобразовании данных пользовательского типа (другими словами, без использования специальной технологии привязки данных). Мы также дадим некоторые полезные советы для разработки пользовательской привязки данных.

В будущих публикациях этой серии мы рассмотрим особые примеры интеграции различных технологий привязки данных, включая JAX-B 2.0, EMF/SDO и XML Beans.

В начало

Загрузка

Описание	Имя	Размер	Метод загрузки
code samples in zip format	sample_files.zip	17KB	FTP|HTTP

Информация о методах загрузки

Ресурсы

Научиться

• Оригинал статьи: "Web Services Custom Data Binding, Part 1: How to choose a custom mapping technology for Web services."
  
  
• Какой стиль WSDL мне следует использовать? (developerWorks, 2005 г.) представляет четыре схемы, с которыми согласуется и из которых извлекает пользу файл WSDL.
  
  
• Используйте Учебник по работе со схемами XML, чтобы лучше ознакомиться с некоторыми аспектами XML-схем.
  
  
• Другая статья описывает, как использовать SAAJ API.
  
  
• Прочтите спецификацию Java API для XML-Based RPC (JAX-RPC) для дополнительной информации об ограничениях типового преобразования данных.
  
  
• Узнайте больше о спецификации SAAJ и приложении SOAP.
  
  
• Посетите раздел веб-служб developerWorks, чтобы расширить ваши веб-службы и умения в технологии SOA.
  
  
• Посетите раздел веб-служб developerWorks WebSphere, чтобы узнать новое о WebSphere и веб-службах.
  
  
• Откройте ряд других полезных и интересных статей и учебников в Технической Библиотеке WebSphere.
  
  

Получить продукты и технологии

• Создайте ваш следующий проект разработки при помощи пробных программ IBM, доступных для скачивания от разработчиков.
  
  

Обсудить

• Примите участие в обсуждении материала на форуме.
  
  
• Примите участие в блогах разработчиков и вступите в их сообщество.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Вступление
• Сериализация и десериализация в WebSphere
• Как сделать вашу службу настраиваемой
• Как работает привязка данных
• Вывод
• Загрузка
• Ресурсы
• Об авторах
• Комментарии