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
On Tue, Aug 11, 2009 at 9:27 AM, marius d. <marius.dan...@gmail.com> wrote:
>
>
>
> 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
> > > 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)
> >
> > > > > On Thu, Aug 6, 2009 at 5:26 PM, Jacek Furmankiewicz <
> jace...@gmail.com
> > > >wrote:
> >
> > > > >> 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).
> >
> > > > > --
> > > > > Viktor Klang
> >
> > > > > Rogue Scala-head
> >
> > > > > Blog: klangism.blogspot.com
> > > > > Twttr: viktorklang
> >
> > > > --
> > > > L.G. Meredith
> > > > Managing Partner
> > > > Biosimilarity LLC
> > > > 1219 NW 83rd St
> > > > Seattle, WA 98117
> >
> > > > +1 206.650.3740
> >
> > > >http://biosimilarity.blogspot.com
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 1219 NW 83rd St
> > Seattle, WA 98117
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
> >
>
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
