Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] SOAPVerse - the kernel of an idea for an interoperability test/de mo

Expand Messages
  • Paul Kulchenko
    Hi, Glen! I was excited about the speed of decisions and the level of understanding yesterday and now I m observing the number of political issues around it
    Message 1 of 4 , Mar 20, 2001
    • 0 Attachment
      Hi, Glen!

      I was excited about the speed of decisions and the level of
      understanding yesterday and now I'm observing the number of political
      issues around it today and it makes me ...hm, kind of sick, so I'll
      talk ONLY about technological aspects and I would be the first to
      implement it as soon as we agree on it (and maybe even befor :)).

      --- Glen Daniels <gdaniels@...> wrote:
      > 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
      I hope it's not and I agree with goals.
      > help design/implement, is it cool?
      I think it is and here is my view on that.

      Map (A x B rooms)
      Every room is server implementation (server)
      Several crawlers are available to go throuh map (client and server)

      Procedure for participants:
      GET list of crawlers from Map
      choose one
      START with this crawler ([x,y]) and get back information where you
      are (crawler will MOVE_IN into specified room)
      you may GET_LIST of other crawlers in this room, WRITE_NOTE for
      other crawlers, READ_NOTEs posted by others
      now you may MOVE your crawler somewhere (direction) and crawler
      will tell current room MOVE_OUT and new room MOVE_IN. MOVE_OUT
      shouldn't fail (otherwise you're locked in :)), because you already
      succesfully moved in, but MOVE_IN may fail, so you'll be in the same
      room.

      Why do we need crawlers and do not tell directly where we want to go
      (MOVE_OUT to one room/server and MOVE_IN to another one)? First, if
      we really want to test interop both sides should be under some
      control (not political :)) to log in errors and be sure that both
      sides are doing it right. Second, it will let us to test
      interoperability on two levels: from user to crawler and between
      crawlers and servers. It'll let user switch crawler and keep moving,
      so after some time we will have map how crawlers are moving (and
      where) and problem spots on our map. Providing different interfaces
      to crawler (it could be web, GUI or something else) you can drive it
      thru the map, so it becomes accessible to (almost) everybody. Yet
      you're able to call servers directly, but that's your responsibility
      to handle and deal with errors, interfaces, etc.

      Map interface
      add_field(endpoint, details) -- register server to participate
      add_crawler(endpoint, details) -- register crawler
      get_list_of_crawlers
      draw_the_map -- :)

      Room interface
      move_in
      move_out
      write_note
      read_notes
      get_list_of_crawlers_here

      Crawler interface
      start([x,y])
      move(direction) -- does move_out from one and move_in into another
      one
      write_note -- "I was here"
      read_notes
      get_list_of_crawlers_in_this_room
      get_room_information

      In my understanding central point IS required, just because both
      server and crawler implementation should be REALLY simple and DOES
      NOT require any back-end, like persistent storage, databases, etc.,
      not because it difficult or will take time, but just because we'll
      cut implementations that otherwise could participate, like Kafka
      (XSLT) or I don't know, maybe SOAP.py. In my understanding (since we
      have both client and server in crawler) crawler should try to go
      inside the room (different implementation) and then report to server
      result (no one else will be able to do it, current room doesn't care
      about it and new room may not know about it, because message wasn't
      parsed). That's another reason why I think it shouldn't be just
      client to talk to server, but specific crawler that will have little
      bit logic inside. Another important piece is that all reauired
      information going back and forth and is not stored somewhere except
      client's computer (or maybe yet central point for stat) and it'll let
      switch crawler and keep going farther.

      So, the picture is:

      [any client: client, could be browser, applet, application, whatever]

      /----- game borders ----------------------------
      |
      | [crawler: implements both client and server]
      |
      | [room: server only]
      |
      | [map: central point, control the game, server only]
      |
      \----------------------------------------------

      In this picture Map should be MOST interoperable implementation at
      this time, because anyhow crawler and any other client should be able
      to talk to it. Then everybody can write server (interface is simple)
      and see how it goes. More efforts required to write crawler, but it's
      more interesting also, and could be done independently. Anyway, we'll
      be able to check interop between users and crawlers and register
      (hopefully) all issues and problems in interoperability between
      crawlers and rooms.

      Having central point will slightly modify the interface, so let me
      know if you think it IS or ISN'T required. Any thoughs will be
      greatly appreciated.

      Best wishes, Paul.

      >
      > The SOAPVerse : A long-term SOAP interoperability demo
      > ------------------------------------------------------
      >
      > [1.0 Introduction - the view from outside]
      >
      > 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:
      >
      > --------------
      > SOAP Tower
      >
      > 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.
      >
      > There is a briefcase sitting here.
      >
      > (this room lives at foo.ibm.com, and is powered by
      > Tomcat/Apache-SOAP 2.1!)
      > --------------
      >
      > 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:
      >
      > --------------
      > [a strange feeling overcomes you for a moment as you pass through
      > the door]
      >
      > Campus West
      >
      > You stand on the Microsoft campus, near building 33. You may
      > ENTER, or
      > travel WEST or SOUTH down the main road.
      >
      > Others in this room : KeithB
      >
      > There is a rubber ducky sitting here.
      >
      > (this room lives at bar.microsoft.com, and is powered by
      > IIS/ASP.NET!)
      > ---------------
      >
      > 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.
      >
      > 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.
      >
      > [2.0 Digging a little deeper]
      >
      > 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.
      >
      > 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.
      >
      > 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.
      >
      > 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.
      >
      > [3.0 Musings]
      >
      > 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.
      >
      > 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.
      >
      > 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.
      >
      > 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.
      >
      > What do you think?
      >
      > --Glen
      >
      > ------------------------ Yahoo! Groups Sponsor
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Get email at your own domain with Yahoo! Mail.
      http://personal.mail.yahoo.com/
    • Steve Graham
      Curious, I was pretty sure foo.ibm.com was powered by WebSphere! I guess I was wrong? ++++++++ Steve Graham sggraham@us.ibm.com (919)254-0615 (T/L 444) Web
      Message 2 of 4 , Mar 20, 2001
      • 0 Attachment
        Curious, I was pretty sure foo.ibm.com was powered by WebSphere! I guess I
        was wrong?

        ++++++++
        Steve Graham
        sggraham@...
        (919)254-0615 (T/L 444)
        Web Services Architect
        Emerging Internet Technologies
        ++++++++


        Glen Daniels <gdaniels@...> on 03/20/2001 11:35:40 AM

        Please respond to soapbuilders@yahoogroups.com

        To: interopathon@yahoogroups.com, Soapbuilders
        <soapbuilders@yahoogroups.com>, "'SOAP@...'"
        <SOAP@...>
        cc:
        Subject: [soapbuilders] SOAPVerse - the kernel of an idea for an
        interoperability test/de mo



        Hi folks!

        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?

        The SOAPVerse : A long-term SOAP interoperability demo
        ------------------------------------------------------

        [1.0 Introduction - the view from outside]

        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:

        --------------
        SOAP Tower

        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.

        There is a briefcase sitting here.

        (this room lives at foo.ibm.com, and is powered by Tomcat/Apache-SOAP 2.1!)
        --------------

        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:

        --------------
        [a strange feeling overcomes you for a moment as you pass through the door]

        Campus West

        You stand on the Microsoft campus, near building 33. You may ENTER, or
        travel WEST or SOUTH down the main road.

        Others in this room : KeithB

        There is a rubber ducky sitting here.

        (this room lives at bar.microsoft.com, and is powered by IIS/ASP.NET!)
        ---------------

        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.

        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.

        [2.0 Digging a little deeper]

        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.

        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.

        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.

        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.

        [3.0 Musings]

        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.

        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.

        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.

        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.

        What do you think?

        --Glen


        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.