Detta ska bli ett riktigt blogginlägg, alltså ett inlägg där bloggaren i fråga hittar något fånigt att klaga på och gör det utan substans i sina argument. Here we go!
Här om veckan fick jag äran att konsumera en web service! Party utan like.
Web services är ju så 90-tal, men det verkar vara det bästa vi har för interoperabilitet, så det vara bara att hugga in. Axis kändes också 90-tal, men det var vad jag kände till, så valet föll naturligt. Jag skulle anropa tre olika metoder, varav en var av karaktären “Hello World”, en krävde korrekt stöd för komplexa datatyper, medan den tredje erfordrade hantering av attachments.
Som vanligt, med open source, gick det alldeles utmärkt att göra anrop ett och två. Sedan vart det väggen! Jag kunde absolut inte få Axis 1.4 att klara attachements. Testade 1.5 utan framgång, och det enda man fick var konstiga odokumenterade fel, som inte vill låta sig googlas särskilt väl. Det fina med det hela var frihetsgraderna. Axis kan generera klinetstubbar på inte mindre än tre olika sätt, plus att man kan gå direkt via egna SOAP-meddelanden (typ).
Nu är det som så att jag är säker på att attachements kan klaras av både Axis 1 och 2, och poängen med inlägget är inte att skryta med hur dålig jag är på Axis. Poängen är att berätta om något annat, nämligen att man ska vara försiktig med att skriva att man kan XML i sitt CV.
Ett tag försökta jag förkasta Axis helt och försökte mig på JAX-WS. Det gick nästan, men jag fick namnkonflikter mellan komplexa typer och element – en situation tydligen ganska vanlig om man arbetar med .Net-genererade web services. Googling gav att man skulle använda en “binding file” för att suffixera elementen och därmed lösa namnkonflikten. Jag hittade inga direkt bra exempel och började surfa XML. Under tiden hittade jag följande godbitar:
<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" jxb:extensionBindingPrefixes="xjc"> <jxb:bindings schemaLocation="po4.xsd" node="/xs:schema"> <jxb:globalBindings> <xjc:superClass name="com.syh.Shape"/> <xjc:serializable uid="12343"/> </jxb:globalBindings> <jxb:bindings node="//xs:element[@name='Widgets']//xs:complexType//xs:choice"> <jxb:property name="Shapes"/> </jxb:bindings> </jxb:bindings> </jxb:bindings>
Eller den här:
...
<package name="services.datastaging">
<jxb:javadoc>
<![CDATA[<body>Package level documentation for generated package services.datastaging.</body>]]>
</jxb:javadoc>
</package>
...
Jag brukar sällan skryta med okunnighet, men första blocket ovan är ren rappakalja och det andra visar att någonting som borde vara enkelt kan göras svårt. Det var den här typen av googlande som lärde mig följande läxor:
1. Jag kan inte XML
2. Jag VILL inte kunna XML
3. Jag vill träffa dem som kom på det här
4. Det bästa vi har för att skicka små textmeddelanden mellan datorer hanteras av en, för en normal person, obegriplig gegga.
Man lär så länge man lever.
#1 by Erik Hansen on August 23, 2010 - 18:47
Det är inte särskilt proffsigt att sträva efter okunnighet enligt punkt 2? Jag tycker nog att XML som sådant är lika enkelt som det är genialt men tillämpningarna är inte alltid så glasklara som man skulle önskat. Som du beskriver här t.ex när man vill kommunicera mellan Java och .Net, men det har blivit mycket bättre och idag är det mesta “klickbart” i programmeringsmiljön.