You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by te...@apache.org on 2003/09/10 13:01:07 UTC
cvs commit: ws-site/targets/axis/docs SOAPVerse.html
tetsuya 2003/09/10 04:01:07
Modified: targets/axis/docs SOAPVerse.html
Log:
Deleted unnecessary LF chars
Revision Changes Path
1.2 +22 -22 ws-site/targets/axis/docs/SOAPVerse.html
Index: SOAPVerse.html
===================================================================
RCS file: /home/cvs/ws-site/targets/axis/docs/SOAPVerse.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SOAPVerse.html 28 Jan 2003 13:28:14 -0000 1.1
+++ SOAPVerse.html 10 Sep 2003 11:01:07 -0000 1.2
@@ -2,29 +2,29 @@
Hi folks!
<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
+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
+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>
The SOAPVerse : A long-term SOAP interoperability demo<br>
------------------------------------------------------<br>
<p>
-[1.0� Introduction - the view from outside]
+[1.0 Introduction - the view from outside]
<p>
-I'll start explaining the idea by giving a brief scenario.� You connect a
+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,
+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
+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>
--------------<br>
SOAP Tower<br>
<p>
-You stand in the SOAP tower.� The floor's a bit slippery here, but you
+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>
@@ -41,7 +41,7 @@
<p>
Campus West
<p>
-You stand on the Microsoft campus, near building 33.� You may ENTER, or
+You stand on the Microsoft campus, near building 33. You may ENTER, or
travel WEST or SOUTH down the main road.
<p>
Others in this room : KeithB
@@ -52,7 +52,7 @@
---------------<br>
<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
+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>
@@ -60,27 +60,27 @@
the whole graph of rooms currently connected to the SOAPVerse, color-coded
by host/server technology.
<p>
-[2.0� Digging a little deeper]
+[2.0 Digging a little deeper]
<p>
That's the basic idea - a totally distributed text adventure game that
-demonstrates SOAP interoperability at a number of levels.� The actual APIs
+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>
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
+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)
+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>
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
+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
+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
@@ -93,20 +93,20 @@
there's
enough community interest in this project.
<p>
-[3.0� Musings]
+[3.0 Musings]
<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
+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>
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,
+fail in the face of problems. It's meant as an interoperability demo,
not a full-scale game.
<p>
-None of this is at all carved in stone, we just liked the basic idea.� It
+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>