XML based Web Services (in Bulgarian)

XML-базирани уеб услуги въведение Петьо Димитров 27.09.2013

2/50 Съдържание Същност и характеристики История SOAP протокол и WSDL интерфейс Java имплементация: SAAJ и JAX-WS Разширения към уеб услугите © 2013, Musala Soft JSC. All rights reserved

3/50 Какво са уеб услуги? © 2013, Musala Soft JSC. All rights reserved

4/50 Характеристики на уеб услугите • XML-базирани • отворени за широк кръг участници • ясно дефиниран интерфейс • ориентирани към обмен на съобщения • асинхронни и синхронни извиквания • едрозърнести © 2013, Musala Soft JSC. All rights reserved

5/50 Страни в комуникацията • Service Broker (registry) – спомага за откриване на уеб услугата • Service Provider – предоставя за използване услугата • Service Requester (consumer) – използва услугата © 2013, Musala Soft JSC. All rights reserved

6/50 История на уеб услугите • 2000г., Майкрософт разработва SOAP (a.k.a. Simple Object Access Protocol) за трансфер на данни, като алтернатива на съществуващи RPC решения (надделява над XML-RPC) • бързо се включват други компании и в следващата година се появяват WSDL и UDDI • това е първото поколение от стандарти за уеб услуги © 2013, Musala Soft JSC. All rights reserved

7/50 История (продължение) • SOAP еволюира към пренос на съобщения вместо отдалечени извиквания и абревиатурата отпада (не е особено прост и не дава достъп до обекти???) • UDDI “bites the dust” • под натиска на бизнеса започва разширяване и допълване на спецификациите © 2013, Musala Soft JSC. All rights reserved

8/50 © 2013, Musala Soft JSC. All rights reserved

9/50 © 2013, Musala Soft JSC. All rights reserved

10/50 HTTP(S) has counted to infinity… twice • основен транспортен протокол в Интернет • добре познат • надежден • подържан от съвременните инфраструктури • появява се 1996г. • една от опциите за уеб услуги © 2013, Musala Soft JSC. All rights reserved

11/50 XML they drew first blood, not me (Rambo) • EXTENSIBLE MARKUP LANGUAGE • extensible – няма предефинирани тагове • markup – текстов формат използващ тагове • language – самоописателен (XMLSchema описва XML) • фокус върху структура и данни (vs. HTML) • GMLSGMLHTMLXML © 2013, Musala Soft JSC. All rights reserved

12/50 SOAP I’ll be back (Terminator) • дефинира стандартен формат за съобщения • прост, но лесно разширяем • езиково и платформено независим • базиран на XML © 2013, Musala Soft JSC. All rights reserved

13/50 Структура <?xml version=”1.0”?> <soap:Envelope xmlns:soap=”http://www.w3.org/2001/12/soap-envelope”> soap:Header … </soap:Header> soap:Body … soap:Fault … </soap:Fault> </soap:Body> body to Arnold Shwarzenegger fault </soap:Envelope> © 2013, Musala Soft JSC. All rights reserved

14/50 SOAP хедъри • съдържат мета информация, която може да е необходима за съобщението: ▫ инструкции за обработка или рутиране на съобщението ▫ условия за сигурност ▫ информация за корелиране на съобщения • правят съобщението независимо • имат незадължителен характер • стоят в основата на много от WS-* спецификациите © 2013, Musala Soft JSC. All rights reserved

15/50 SOAP + Java = SAAJ • SOAP WITH ATTACHMENTS API FOR JAVA • API от по-ниско ниво позволяващо работа със SOAP съобщения • стои в основата на JAX-RPC и JAX-WS • поддържа SOAP и SwA спецификациите © 2013, Musala Soft JSC. All rights reserved

16/50 SAAJ: създаване на съобщение SOAPMessage msg = MessageFactory.newInstance().createMessa ge(); SOAPPart part = msg.getSOAPPart(); SOAPEnvelope env = part.getEnvelope(); SOAPBody body = env.getBody(); QName title = new QName(“http://opa/main”, “title”); body.addBodyElement(title) .setValue(“Avengers”); © 2013, Musala Soft JSC. All rights reserved

17/50 SAAJ: подготовка за изпращане String ns = “http://opa/main”; URL wsdl = new URL(“http://opa/Cinema?wsdl”); QName serviceName = new QName(ns, “Cinema”); Service service = Service.create(wsdl, serviceName); String portName = new QName(ns, “CinemaPort”); Dispatch<SOAPMessage> dispatch = service.createDispatch(portName, SOAPMessage.class, Service.Mode.Message); © 2013, Musala Soft JSC. All rights reserved

18/50 SAAJ: заявка и отговор msg.writeTo(System.out); SOAPMessage response = dispatch.invoke(msg); response.writeTo(System.out); <?xml version=”1.0”?> <soap:Envelope xmlns:soap=”…”> soap:Header/soap:Body <length xmlns=”http://opa/main” <title xmlns=”http://opa/main” >> 143 Avengers </length> </title> </soap:Body> </soap:Envelope> © 2013, Musala Soft JSC. All rights reserved

19/50 SOAP и бинарни данни • SOAP съобщенията са текст, но честo пренасят бинарни данни (картинки, документи) • base64 ▫ конвертира бинарните данни до ASCII текст ▫ увеличава размера ~30% ▫ пример: <image imageType=”jpg” xsi:type=”base64binary”>4f3Е9b0…</image> © 2013, Musala Soft JSC. All rights reserved

20/50 SOAP и бинарни данни • SwA (SOAP with Attachments) и DIME ▫ използват href за да свържат съдържание извън XML съобщението ▫ същата идея като при e-mail-ите ▫ прикачените данни не се считат за част от съобщението ▫ пример: <image href=”cid:image@test.com”/> … —MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: image@test.com …binary JPG image… —MIME_boundary— © 2013, Musala Soft JSC. All rights reserved

21/50 SOAP и бинарни данни • MTOM (Message Transmission Optimization Mechanism) ▫ прехвърляните данни са същите като при SwA ▫ прикачените данни са част от съобщението (SOAP infoset) ▫ пример: <image xop-mime:content-type=’image/jpeg’> <xop:Include href=”cid:image@test.com”/> </image> … —MIME_boundary … © 2013, Musala Soft JSC. All rights reserved

22/50 MTOM и Java @WebService @MTOM public class Opa implements IOpa { public int test(int number) { … } } IOpa opa = (IOpa) service.getPort(IOpa.class); BindingProvider bp = (BindingProvider) opa; SOAPBinding binding = (SOAPBinding) bp.getBinding(); binding.setMTOMEnabled(true); © 2013, Musala Soft JSC. All rights reserved

23/50 SOAP 1.2 • позволява използването на други транспортни протоколи освен HTTP • нов content type application/soap+xml • нов namespace http://www.w3.org/2003/05/soap-envelope © 2013, Musala Soft JSC. All rights reserved

24/50 WSDL Yippee ki-yay, motherfucker (Die Hard) • позволявана услугите да са независими (loosely coupled) • всяка услуга има описание • за уеб услугата това е договор, който изпълнява • за клиента това е наръчник как да комуникира с услугата • базиран на XML © 2013, Musala Soft JSC. All rights reserved

25/50 Структура на WSDL документа • абстрактна част – описва интерфейса на уеб услугата без инфо за използваната технология • конкретна част – съдържа имплементационни детайли за уеб услугата • допълва се от XSD дефиниции и policy-та © 2013, Musala Soft JSC. All rights reserved

26/50 Структура - definitions • корен на всяка дефиниция на уеб услуга • важни са дефинираните namespace-и <definitions name=”Employee” targetNamespace=”http://opa/wsdl/” xmlns=”http://schemas.xmlsoap.org/wsdl/” xmlns:act=”http://opa/schema/accounting/” xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” xmlns:tns=”http://opa/wsdl/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”> … </definitions> © 2013, Musala Soft JSC. All rights reserved

27/50 Структура - types • незадължителен елемент (може да се ползва messages) • xsd дефиниции и/или import-и на xsd документи <types> <schema xmlns=”http://www.w3.org/2001/XMLSchema” targetNamespace= “http://opa/schema/”> <complexType name=”ReturnCodeType”> <sequence> <element name=”Code” type=”xsd:integer”/> <element name=”Message” type=”xsd:string”/> </sequence> </complexType> </schema> </types> © 2013, Musala Soft JSC. All rights reserved

28/50 Структура - messages • message се създава за всяко обменяно съобщение • всяко съобщение има един или няколко part елемента • всеки part елемент има type или element атрибут <message name=”getEmployeeHoursRequestMessage”> <part name=”RequestParameter” element=”act:EmployeeHoursRequestType”/> </message> <message name=”getEmployeeHoursResponseMessage”> <part name=”ResponseParameter” element=”act:EmployeeHoursResponseType”/> </message> © 2013, Musala Soft JSC. All rights reserved

29/50 Структура - portType • интерфейса на уеб услугата дефиниращ операции • позицията на input и output определят MEP <portType name=”EmployeeInterface”> <operation name=”GetHoursLimit”> <input message=”tns:getHoursRequestMessage”/> <output message=”tns:getHoursResponseMessage”/> </operation> </portType> © 2013, Musala Soft JSC. All rights reserved

30/50 Структура - binding • имплементационна информация • задава транспортния протокол и структурата на SOAP съобщенията <binding name=”EmployeeBinding” type=”tns:EmployeeInterface”> <soap:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http”/> <operation name=”GetWeeklyHoursLimit”> <soap:operation soapAction=”…”/> <input> <soap:body use=”literal”/> </input> <output> <soap:body use=”literal”/> </output> </operation> </binding> © 2013, Musala Soft JSC. All rights reserved

31/50 Структура - service • оказва endpoint-а на услугате, тоест адреса където е достъпна • други елементи: import, documentation <service name=”EmployeeService”> <port binding=”tns:EmployeeBinding” name=”EmployeePort”> <soap:address location=”http://opa/employee/”/> </port> </service> © 2013, Musala Soft JSC. All rights reserved

32/50 MEP = Message Exchange Pattern (single-destination, multi-cast, broadcast) © 2013, Musala Soft JSC. All rights reserved

33/50 MEP = Message Exchange Pattern © 2013, Musala Soft JSC. All rights reserved

34/50 MEP и WSDL • определят се от реда на input и output елементите в WSDL-a © 2013, Musala Soft JSC. All rights reserved

35/50 Document, literal, RPC, encoded • style бива: ▫ rpc (remote procedure call) ▫ document (message centric) • use бива: ▫ encoded (xsd в SOAP съобщенията) ▫ literal • комбинации: rpc/encoded, document/literal, rpc/literal (рядко), document/encoded (няма) + 1 © 2013, Musala Soft JSC. All rights reserved

36/50 RPC/encoded: WSDL <message name=”myMethodRequest”> <part name=”x” type=”xsd:int”/> <part name=”y” type=”xsd:float”/> </message> <message name=”empty”/> <portType name=”PT”> <operation name=”myMethod”> <input message=”myMethodRequest”/> <output message=”empty”/> </operation> </portType> © 2013, Musala Soft JSC. All rights reserved

37/50 RPC/encoded: SOAP soap:envelopesoap:body <myMethod> <x xsi:type=”xsd:int”>5</x> <y xsi:type=”xsd:float”>5.0</y> </myMethod> </soap:body> </soap:envelope> © 2013, Musala Soft JSC. All rights reserved

38/50 RPC/encoded особености + прост WSDL + името на операцията присъства в съобщението - не отговаря на изискванията на WSI-I профила за съвместимост - типовата информация в SOAP увеличава размера на съобщението (и е често ненужна) - трудно за валидация понеже само x и y елементите имат XSD © 2013, Musala Soft JSC. All rights reserved

39/50 Document/literal: WSDL <types> <schema> <element name=”xElement” type=”xsd:int”/> <element name=”yElement” type=”xsd:float”/> </schema> </types> <message name=”myMethodRequest”> <part name=”x” element=”xElement”/> <part name=”y” element=”yElement”/> </message> <message name=”empty”/> <portType name=”PT”> <operation name=”myMethod”> <input message=”myMethodRequest”/> <output message=”empty”/> </operation> </portType> © 2013, Musala Soft JSC. All rights reserved

40/50 Document/literal: SOAP soap:envelopesoap:body <xElement>5</xElement> <yElement>5.0</yElement> </soap:body> </soap:envelope> • няма име на операция • няма типова информация © 2013, Musala Soft JSC. All rights reserved

41/50 Document/literal особености + няма типова информация + цялото съдържание на body-то може да се валидира с xsd + донякъде съвместим е с WS-I - WSDL-а е по-сложен - липсва името на операцията, което затруднява разпределянето на съобщенията - WS-I изисква да има само един елемент в тялото на съобщението (тук са 2) © 2013, Musala Soft JSC. All rights reserved

42/50 Document/literal wrapped: WSDL <types> <schema> <element name=”myMethod”> <complexType> <sequence> <element name=”x” type=”xsd:int”/> <element name=”y” type=”xsd:float”/> </sequence> <portType name=”PT”> </complexType> <operation name=”myMethod”> </element> <input message=“methodRequest”/> <element name=”myMethodResponse”> <output message=“methodResponse”/> <complexType/> </operation> </element> </portType> </schema> </types> <message name=“methodRequest”> <part name=”parameters” element=”myMethod”/> </message> <message name=“methodResponse”> <part name=”parameters” element=”myMethodResponse”/> </message> © 2013, Musala Soft JSC. All rights reserved

43/50 Document/literal wrapped: SOAP soap:envelopesoap:body <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope> • съобщението има само един part, който е елемент • елемента има същото име като операцията и няма атрибути © 2013, Musala Soft JSC. All rights reserved

44/50 Document/literal wrapped особености + няма типова информация + цялото съобщение може да се валидира + името на операцията присъства в съобщението • съвместим е с WS-I профила (само един елемент в SOAP body-то) - WSDL-а е много по-сложен - има ли други проблеми? © 2013, Musala Soft JSC. All rights reserved

45/50 WSDL + Java = JAX-WS • JAVA API FOR XML WEB SERVICES • анотации обогатяват класа с инфо за уеб услугата • проектиране върху договор (WSDL) или код • команда wsimport – за генерация на JAX-WS артефакти (SEI и SIB) и JAXB класове wsimport -keep -verbose http://localhost:9999/ws?wsdl • команда wsgen – за генерация на JAXB класове и WSDL и XSD дефиниции © 2013, Musala Soft JSC. All rights reserved

46/50 Пример с Java (SEI и SIB) @WebService @SOAPBinding(style = Style.DOCUMENT, use=Use.LITERAL) public interface ICinema { @WebMethod String getMovieInfo(String title); } @WebService(endpointInterface=”test.ICinema”) public class Cinema implements ICinema { public String getMovieInfo(String title) { return “Info for ” + title; } } © 2013, Musala Soft JSC. All rights reserved

47/50 Пример с Java (publisher) • позволява тестване на JAX-WS уеб услугата локално без сървър • автоматично генерира WSDL и XSD дефиниции public class CinemaPublisher { public static void main(String[] a) { Endpoint.publish(“http://localhost:9999/cinema”, new Cinema()); } } © 2013, Musala Soft JSC. All rights reserved

48/50 WSDL 2.0 • • • • definitions  description portType  interface port  endpoint messages е премахнат заради ограничената си RPC употреба (part е предназначен за параметри) , за document винаги се ползва XSD • interface има extends атрибут (от ООП) • operation има pattern атрибут (in-out, out-only) и wsdlx:safe атрибут за идемпотентни операции • fault се дефинира на ниво операция © 2013, Musala Soft JSC. All rights reserved

49/50 Инструмент за работа с уеб услуги © 2013, Musala Soft JSC. All rights reserved

50/50 Демонстрация © 2013, Musala Soft JSC. All rights reserved

51/50 UDDI Are you man enough to fight with me? (Street Fighter) • UNIVERSAL DESCRIPTION, DISCOVERY, AND INTEGRATION • UBR = UDDI Business Registry = публични “жълти страници” за уеб услуги • позволяващ регистриране и автоматично търсене на уеб услуги © 2013, Musala Soft JSC. All rights reserved

52/50 UBR: Dead man walking • 2006 г. IBM, SAP и Microsoft прекратяват поддръжката на публичните си UDDI регистри • причини за провала: ▫ сложен модел на данните (различни бизнеси) ▫ ограничено търсене ▫ сигурност ▫ липса на поддръжка на регистрите © 2013, Musala Soft JSC. All rights reserved

53/50 Наследство • JAX-R: JAVA API FOR XML REGISTRIES • ръчна настройка (http://www.xmethods.net) • специфични решения (база данни, LDAP) • вътрешни регистри (Apache jUDDI, WSRR) © 2013, Musala Soft JSC. All rights reserved

54/50 WS-Addressing I cannot be defeated! (Rocky IV) • WS-Addressing – позволява информацията за изпращане да е част от съобщението © 2013, Musala Soft JSC. All rights reserved

55/50 WS-Addressing информация • откъде идва съобщението • за къде е съобщението • на кого трябва да се отговори • кой трябва да го получи • къде да иде при проблем с доставянето © 2013, Musala Soft JSC. All rights reserved

56/50 WS-Addressing концепции • endpoint reference – адрес позволяващ да се идентифицира конкретна инстанция на уеб услуга и нейни метаданни: ▫ URL до уеб услугата ▫ reference properties – за идентификация на инстанция ▫ reference parameters – за обменяна на прости данни с услугата ▫ port type – мястото на описанието на услугата на извикващата страна, полезна при отговора ▫ policy – мета информация за обмена © 2013, Musala Soft JSC. All rights reserved

57/50 Сапунена имплементация: EndpointReference wsa:EndpointReferencewsa:Addresshttp://opa</wsa:Address> wsa:ReferencePropertiesapp:idunn:AFJK323llws</app:id> </wsa:ReferenceProperties> wsa:ReferenceParametersapp:sesno12345</app:sesno> </wsa:ReferenceParameters> </wsa:EndpointReference> • други: PortType, ServiceType, ServiceName, Policy © 2013, Musala Soft JSC. All rights reserved

58/50 WS-Addressing концепции • message information headers – хедърите добавяни към едно съобщение: ▫ ▫ ▫ ▫ ▫ ▫ ▫ дестинация (url) източник (endpoint reference) адрес за отговор (endpoint reference) адрес за грешка (endpoint reference) идентификатор на съобщението (id) корелация между заявка и отговор (id) action – показва целта на съобщението (url) © 2013, Musala Soft JSC. All rights reserved

59/50 Сапунена имплементация: хедъри

60/50 WS-Addressing и Java @WebService @Addressing(enabled=true, required=true) public class Opa implements IOpa { @Action(input=”http://opa/input”, output=”http://opa/output”) public int test(int number1, int number2) { … } } IOpa opa = (IOpa) service.getPort(IOpa.class, new AddressingFeature()); opa.test(1, 2); © 2013, Musala Soft JSC. All rights reserved

61/50 WS-I Basic Profile спецификация • профил за съвместимост между уеб услуги (версия 2.0 e публикувана на ноември 2010) • WSDL 1.1 • SOAP 1.2 • МТОМ • WS-Addressing • UDDI 3.0 • други изисквания: HTTP протокол (POST), rpc/literal или document/literal (wrapped), само request/response и one-way © 2013, Musala Soft JSC. All rights reserved

62/50 Въпроси © 2013, Musala Soft JSC. All rights reserved

63/50 Благодаря за вниманието © 2013, Musala Soft JSC. All rights reserved