SOAP web services?

[Jacek Furmankiewicz]

I was reading through the Lift book PDF and it mentions only REST-
style web services.

In our case, we need to look at re-implementing a set of existing SOAP
web services (is there anything like 'wsdl2scala' anywhere?).

I would appreciate any best practices and suggestions for implementing
SOAP web services in the context of a larger Lift app (and Scala in
general).

[Derek Chen-Becker]

As far as I know there aren't any Scala-specific SOAP libs, so it's probably simplest to use on of the Java ones to create the stubs and then just use those from Scala. If I'm wrong and there are some Scala SOAP libs out there, I'd love to know about them.

Derek

[Timothy Perrett]

Myself and Viktor are two committers who do a lot of SOAP work - right now,
the best route forward it to use the Java JAX-WS code and call into it with
a scala wrapper - this is exactly what I do and it works perfectly.

Because there is toll free calling of Java code, there is little point in
porting such massive projects to Scala; just make a wrapper that suits your
needs.

In my environment I have about 40+ endpoints, with hundreds of methods so I
just made a scala wrapper that lets me do:

DriverManager.whateverdriver.myMethod(params) // Box[T]

IMO, that's a damn lot easier than calling a boat load of Java (of course
its doing the under the hood, but like I said, its just a wrapper).

HTH

Cheers, Tim

[Viktor Klang]

Hello Jacek,

actually, if I were you I'd consider implementing your webservices as REST services and then just have your SOAP stubs call your rest services. (If you're not using anything voodooesque)

Then you have the benefit of using the existing plumbing as much as possible, while still maintaining your SOAP interface as well as a potential migration path to something non-WSDL.

(I am severely biased by having to work with SOAP, which has scarred me for life)

--
Viktor Klang

Rogue Scala-head

Blog: klangism.blogspot.com
Twttr: viktorklang

[Meredith Gregory]

Lifted RESTafarians,

Has anyone tried the Apache Axis 2 WSDL 2.0 support? i'm looking at this page and it claims they have a maven plugin to generate the stubs for a WSDL 2.0 REST binding. i'm going to play around with it to wrap BNF Converter in a RESTful service; but, i was wondering if anyone else had experience with it.

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[Timothy Perrett]

Hey Greg,

Im not sure about WSDL2.0, but my understanding was that WADL
( https://wadl.dev.java.net/ ) was making the most ground in the REST
service description arena.

Cheers, Tim

On Aug 10, 10:58 pm, Meredith Gregory <lgreg.mered...@gmail.com>
wrote:

> Lifted RESTafarians,
>
> Has anyone tried the Apache Axis 2 WSDL 2.0 support? i'm looking at this

> page<http://ws.apache.org/axis2/tools/1_2/maven-plugins/maven-wsdl2code-pl...>and

> it claims they have a maven plugin to generate the stubs for a WSDL
> 2.0
> REST binding. i'm going to play around with it to wrap BNF Converter in a
> RESTful service; but, i was wondering if anyone else had experience with it.
>
> Best wishes,
>
> --greg
>

> On Fri, Aug 7, 2009 at 12:31 AM, Viktor Klang <viktor.kl...@gmail.com>wrote:
>
>
>
>
>
> > Hello Jacek,
>
> > actually, if I were you I'd consider implementing your webservices as REST
> > services and then just have your SOAP stubs call your rest services. (If
> > you're not using anything voodooesque)
>
> > Then you have the benefit of using the existing plumbing as much as
> > possible, while still maintaining your SOAP interface as well as a potential
> > migration path to something non-WSDL.
>
> > (I am severely biased by having to work with SOAP, which has scarred me for
> > life)
>

[Meredith Gregory]

Tim,

i was under the same impression, but then read a couple of IBM comparison articles and a WSO2 blog and it seemed that the WSDL 2.0 was gaining ground. Further, the tooling for WSDL, with integration into all the major IDE's, has been significantly more developed than the WADL tooling. However, yesterday i tried a simple example with a schema-valid WSDL 2.0 xml document for a simple service with 1 operation and the Apache Axis2 tool barfed on the fact that the schema pointed to in the document was for WSDL 2.0 and not WSDL 1.1 -- despite the fact that they claim on their home page to support WSDL 2.0.

For the record, WSDL -- as much as i hate it -- was not meant to be tied to a transport. As a matter of fact, neither was SOAP. You should be able to effect these over any transport, HTTP included, and presumably in more than one way. WADL is tied to HTTP. This means its scope is considerably more limited.

Best wishes,

--greg

[marius d.]

On Aug 11, 7:09 pm, Meredith Gregory <lgreg.mered...@gmail.com> wrote:
> Tim,
>
> i was under the same impression, but then read a couple of IBM comparison
> articles and a WSO2 blog and it seemed that the WSDL 2.0 was gaining ground.
> Further, the tooling for WSDL, with integration into all the major IDE's,
> has been significantly more developed than the WADL tooling. However,
> yesterday i tried a simple example with a schema-valid WSDL 2.0 xml document
> for a simple service with 1 operation and the Apache Axis2 tool barfed on
> the fact that the schema pointed to in the document was for WSDL 2.0 and not
> WSDL 1.1 -- despite the fact that they claim on their home page to support
> WSDL 2.0.
>
> For the record, WSDL -- as much as i hate it -- was not meant to be tied to
> a transport. As a matter of fact, neither was SOAP. You should be able to
> effect these over any transport, HTTP included, and presumably in more than
> one way. WADL is tied to HTTP. This means its scope is considerably more
> limited.

Very true. But then again in reality how often are we seeing WSDL/SOAP
bound to something else then HTTP? ... in some respects this seems a
false selling point of SOAP.

Assuming an enterprise application where let's say we can escape HTTP
realm, probably RMI/IIOP, JINI, JXTA etc. even proprietary on the wire
representation etc.becomes valid choices.

>
> Best wishes,
>
> --greg
>
> On Tue, Aug 11, 2009 at 12:55 AM, Timothy Perrett

> <timo...@getintheloop.eu>wrote:

>
>
>
>
>
> > Hey Greg,
>
> > Im not sure about WSDL2.0, but my understanding was that WADL

> > (https://wadl.dev.java.net/) was making the most ground in the REST

[Timothy Perrett]

Id say you are correct Marius - you simply don't see it; I think that's
partly because of marketing (wind back to 2004... SOA == SOAP, and SOAP ==
XML + HTTP), and partly because of companies such as Microsoft implementing
SOAP in their tooling such as they did (and still do).

To that end, perhaps WSDL/SOAP has too much of a stigma attached to it now
to become successful in the wider service description arena? I also think
that same stigma gave rise to efforts like WADL...

But as usual, we digress!

Cheers, Tim

[Viktor Klang]

On Tue, Aug 11, 2009 at 6:09 PM, Meredith Gregory <lgreg.m...@gmail.com> wrote:

Tim,

i was under the same impression, but then read a couple of IBM comparison articles and a WSO2 blog and it seemed that the WSDL 2.0 was gaining ground. Further, the tooling for WSDL, with integration into all the major IDE's, has been significantly more developed than the WADL tooling. However, yesterday i tried a simple example with a schema-valid WSDL 2.0 xml document for a simple service with 1 operation and the Apache Axis2 tool barfed on the fact that the schema pointed to in the document was for WSDL 2.0 and not WSDL 1.1 -- despite the fact that they claim on their home page to support WSDL 2.0.

For the record, WSDL -- as much as i hate it -- was not meant to be tied to a transport. As a matter of fact, neither was SOAP. You should be able to effect these over any transport, HTTP included, and presumably in more than one way. WADL is tied to HTTP. This means its scope is considerably more limited.

That's not really the truth. You could send an HTTP-request as the body of an SMTP message. SOAP is just another envelope format, and if you need a non-commodity parser anyway, why not build upon existing infrastructure?

I must honestly say that I've never felt good about using SOAP. Comparing its merits and flaws it comes in heavy on the flaws and light on the merits.

But I'm just a weird guy with weird opinions...
 

[Alex Cruise]

Disclaimer: I worked at http://www.layer7tech.com/ for six years so I
have a fair bit of déformation professionelle.

<rant target="urn:noOneInParticular">

While I wholeheartedly agree that SOAP, WSDL, WS-* and the whole
mainstream SOA stack, as it's currently broadly defined and implemented,
is ugly and verbose and redundant and regrettable, I'll posit that it is
currently the *only* game in town that **meets all of the requirements**
that drove its creation:

* Vendor- and platform-neutral
* Standards-based
* Business semantics decoupled from transport
* Supports message-level security (allowing decoupling from transport
and business semantics)
* Declarative service publishing and discovery, and automatic
RPC/OO-style stub generation
* ... and many more requirements that you, personally, may not ever feel
the need for.

But a lot of companies actually do need a significant subset of these
requirements on a significant subset of their projects, and there is
certainly a great deal of value in having a global, IT-industry-wide
consensus (even among bitter competitors, which was never the case
previously) on a set of technologies, standards and practices that
actually do meet those requirements.

</rant> :)

-0xe1a

[Timothy Perrett]

> But I'm just a weird guy with weird opinions...

We hadn't noticed Viktor ;-)

Cheers, Tim

[Viktor Klang]

So basically it's very good for very few.
In all other cases I'll opt for something more suiting :)
 

-0xe1a

[Alex Cruise]

Viktor Klang wrote:
> So basically it's very good for very few.

And for everyone else, it's at least useful at the outset, due to the
maturity of tools, and will also interoperate well with emergent
requirements that tend to pile up over the years the system is in
production. :) It's also very fair to point out that most of the
mainstream SOA stack is totally overkill for non-enterprise applications.

> In all other cases I'll opt for something more suiting :)

The title of my moribund presentation on this subject is "SOA is Not For
You" (a reference to http://www.penny-arcade.com/comic/2004/3/24/ :)

-0xe1a

[Viktor Klang]

SOA and SOAP are as RAPE is to GRAPE
 

-0xe1a

[Meredith Gregory]

Marius,

The original design goals of WSDL were very straightforward:

• a Port Type is a set of Message Types governing all the messages arriving on the Port
  
• A Message Type is given precisely by an XML Schema (e.g. an XSD)
• A Port is instanced by binding a Port Type to an Endpoint (URL) supporting a transport protocol

In symbols, WSDL was intended to be able to make statements of the form

• URL+Transport : { XMLSchema1, ..., XMLSchemaN }
• Notice the close correlation between this and the statement you see on the Scala REPL all the time:
  
• ScalaExpr <ret>
• res1 : ScalaType

URL is the location of the resource/instance in the same way that res1 provides a location that the Scala REPL can use to look up the instance. PortType is very much like a ScalaType. In the case of typing at the Scala REPL from a command shell there is no question of transport and any encoding/decoding necessary. However, if one had a more remote network access to the Scala REPL that did involve some issues around transport and encoding/decoding, then these two cases would be isomorphic.

BTW, this lines up nearly perfectly with the idea of sorts and sorting in Milner's π-calculus.

Because message exchange usually involves parameter-passing & because of confusion about the role of "Object Technology" in all this, WSDL was extended with the notion of Operation. This could have been done more cleanly, but was not. Not everyone involved in WSDL's design had the same picture in their minds of what they were attempting to accomplish.

As for what happens today, i could easily imaging WSDL and/or WSDL+SOAP over RabbitMQ, for example. i think something like this is considerably better than JSON over transport. The basic reason for this is straightforward. XMLSchema are a form of typing discipline. So, you get a typing discipline for messaging-style applications that fits well with the typing discipline of a language like Scala.

This could, for example, play out very nicely in an actor framework. An actor's mailbox is a good thing to locate at an URL. Then you have statements of the form

• URL + Transport/Actor : { MessageType1, ..., MessageTypeN }

Today, Scala actors do not even support statements of this basic form, though they would greatly enhance the actor package.

Beyond this, you can imagine putting constraints on the order of messages. Here's a general scheme

• Actor : ( { MsgType1 -> Type1, ..., MsgTypeN -> TypeN }, RegularExpressionOver(MsgType1,...,MsgTypeN) )
• The first element in the pair just maps message type names to Scala types (or the types of some host language) and the second element in the pair says the order you expect to see messages in the mailbox.
• Here's an example: ( { Init -> OpenSession( id, pwd ), Read -> ReadDb( ... ), Update -> UpdateDB( ... ), Finish -> CloseSession( ... ) }, Init.(Read+Update)*.Finish )
• It says that the only legal sequences of messages in the mbox are of the form Init :: Read-or-Update :: ... :: Read-or-Update :: FInish.
  

Best wishes,

--greg

[Meredith Gregory]

All,

As a follow up, i was able to get the Apache Axis2 maven plugin to accept WSDL 2.0. Below is what i had to add to my pom.xml. Attached is an example that will get you an Http binding that should work "RESTfully".

Best wishes,

--greg

<pluginRepositories>
...
   <pluginRepository>
      <id>plugin.axis2.apache.org</id>
      <name>Apache Axis2 Repository</name>
      <url>http://apache.sunsite.ualberta.ca/ws/axis2/tools/1_4_1</url>
    </pluginRepository>
</pluginRepositories>



<plugins>
...
<plugin>
    <groupId>org.apache.axis2</groupId>
    <artifactId>axis2-wsdl2code-maven-plugin</artifactId>
    <version>1.4.1</version>
    <executions>
      <execution>
        <goals>
          <goal>wsdl2code</goal>
        </goals>
      </execution>     
    </executions>
    <configuration>
      <packageName>${groupId}.${artifactId}.model</packageName>
      <wsdlVersion>2.0</wsdlVersion>
      <generateAllClasses>true</generateAllClasses>
      <generateServerSide>true</generateServerSide>
      <generateServerSideInterface>true</generateServerSideInterface>
      <generateServicesXml>true</generateServicesXml>
      <generateTestCase>true</generateTestCase>
    </configuration>
      </plugin>
</plugins>

2009/8/11 Meredith Gregory <lgreg.m...@gmail.com>

[Meredith Gregory]

Tim,

How do you compose JAX-WS generated services with lift or do you? i'm trying to enumerate the ways to do this.

Best wishes,

--greg