<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd">
<document> 
  <header> 
    <title>WebServices - Axis</title> 
  </header> 
  <body> 
    <section>
      <title>WebServices - Axis - SOAPVerse</title>
<p>
Hi folks!
</p>
<p>
This is a quick writeup of an idea that a bunch of folks had last week while
discussing interoperability demos and tests. It's a pretty simple system
which we thought was a) fun, b) technically interesting, and c) quite a
compelling demo. I'd like to know what people think of the idea - is this
too ambitious, is it something you'd be psyched to help design/implement,
is it cool?
</p>
<p>
The SOAPVerse : A long-term SOAP interoperability demo<br/>
------------------------------------------------------<br/>
</p>
<p>
[1.0 Introduction - the view from outside]
</p>
<p>
I'll start explaining the idea by giving a brief scenario. You connect a
browser to SOAPVerse.org, which gives you three choices - 1) enter the
SOAPVerse, 2) look at the map, and 3) learn about joining. You choose #1,
and are offered a list of available clients and "entry portals" (i.e.
clients (no, not "IE clients", necessarily...)) on the web. You choose a
local entry portal, and a Java applet appears, primarily composed of a text
window:
</p>
<p>
--------------<br/>
SOAP Tower<br/>
</p>
<p>
You stand in the SOAP tower. The floor's a bit slippery here, but you
suspect you could make it to the exits to the NORTH or EAST if you walked
slowly.
</p>
<p>
There is a briefcase sitting here.
</p>
<p>
(this room lives at foo.ibm.com, and is powered by Tomcat/Apache-SOAP 2.1!)
--------------<br/>
</p>
<p>
It's a text adventure, much like Zork or Colossal Cave, but a lot simpler.
The interesting part happens when you move to the East:
</p>
<p>
--------------<br/>
[a strange feeling overcomes you for a moment as you pass through the door]
</p>
<p>
Campus West
</p>
<p>
You stand on the Microsoft campus, near building 33. You may ENTER, or
travel WEST or SOUTH down the main road.
</p>
<p>
Others in this room : KeithB
</p>
<p>
There is a rubber ducky sitting here.
</p>
<p>
(this room lives at bar.microsoft.com, and is powered by IIS/ASP.NET!)<br/>
---------------<br/>
</p>
<p>
What just happened is that you smoothly and transparently moved from one
SOAP-based server to another. The servers had to interoperate to "pass you
off", and anyone who wants to go check out the website can see the deeper
technical explanation of what's going on.
</p>
<p>
If you'd selected the "map" option, you'd see a cool graphical depiction of
the whole graph of rooms currently connected to the SOAPVerse, color-coded
by host/server technology.
</p>
<p>
[2.0 Digging a little deeper]
</p>
<p>
That's the basic idea - a totally distributed text adventure game that
demonstrates SOAP interoperability at a number of levels. The actual APIs
are pretty simple, and should be implementable in few days at the most.
</p>
<p>
So if you go to the "join us" section of the site, you end up with several
things. First, a description of the structure of the application, in
enough
detail that you could implement it on your own site. This can (and should)
be in as many forms as possible - english text, WSDL, SDL, IDL, etc....
So you build the server to the spec, in any language/environment/platform
you happen to have handy.
</p>
<p>
Next, you find a form which allows you to test your server once you've got
it up. This causes the SOAPVerse server to run a series of tests against
your endpoint, to see if you can interoperate with it. Assuming that
works,
you can click "hook me up!" and the SOAPVerse server randomly picks a place
on the graph to add your area, and matchmakes a connection between your
server and whoever you're connecting to. The tests should get run again
between you and this new guy, to make sure you two interoperate (you don't
want to just prove interoperation between the "main" server and your impl),
and then if everything looks good, you're now a part of the world, and your
rooms appear on the master map.
</p>
<p>
There's some more detail about which kinds of things we're testing with a
system like this (data serialization, headers, intermediaries?), actual
APIs,
etc. but I'll convey my thoughts about that in a design discussion if
there's
enough community interest in this project.
</p>
<p>
[3.0 Musings]
</p>
<p>
This kind of thing serves at least two purposes. First, it can stay up in
perpetuity, demonstrating SOAP interoperability in a fun way. This should
be something you can always find, and hook new servers into. Second, it's
a
good demo for tradeshow-type events.
</p>
<p>
Obviously there's a lot of opportunity for errors to happen here, so the
system shouldn't assume too much about robustness, and should gracefully
fail in the face of problems. It's meant as an interoperability demo,
not a full-scale game.
</p>
<p>
None of this is at all carved in stone, we just liked the basic idea. It
shouldn't get too complicated, and it shouldn't rely on any particular
implementation.
</p>
<p>
If this could get done by late next month, this could be the actual
technolgy
for the "interopathon" demo which has been discussed for NetWorld/Interop
in May.
</p>
<p>
What do you think?
</p>
<p>
--Glen
</p>
    </section>
  </body>
</document>