Home Comments

Ice & Ajax

frankyfranky Member
I think AJAX and WebApps will be a nice way in the future to
develope software.

But what I am currently missing in AJAX is a nice way for
invoking functionality on the backend server side.

All the new stuff like JSON-RPC, WSDL/SOAP, XML-RPC is missing
the point, much too complex and not feasable for real distributed
applications. And at most they are just re-inventing the wheel
with all the pitfalls in distributed programming: No type safety,
missing language mappings, no well defined runtimes etc.

I am very familiar with CORBA and so I know it is not an option
here, too (firewalls, NAT-Traversal, Security etc., you name it).

But I think ICE would fit nice into this new paradigm (or may
be not so new paradigm) as a solution for remote procedure
calling.

But some parts seem to be missing.

To use ICE from a browser with JavaScript, one would need
an http transport, so you can use the XmlHttpRequest-Object
for the transport on the browser side.

Did anybody try to develope such a beast?

On the other hand a language mapping for JavaScript would
be needed and of course a corresponding SLICE-Compiler.

And last but not least an ICE-Runtime in JavaScript is needed
that could use the XmlHttpRequest-Object.

My Idea here is to develope something like Glacier but
with an http-Server on the client-side. It would just transport
the ICE-Serialized Data in the bodies of the Http-Request and
-Responses and forward them as normal TCP streams to the
backend servers (like glacier does as far as I understood the
concept of its architecture).

For the server callbacks the JavaScript client would invoke
a special Http-Request which just polls (ie. waits) for server
callbacks which are marshalled in the body of the response
to the polling http-request.

What do you think about this idea? Is it just too stupid? Or is it
an interesting option to do RPC in AJAX? Or is it too hard to go
that way?

Thanx in advance for any opinions or hints on the subject.

P.S.: Forgive me my spelling erros. English is not my native
language.

Comments

  • matthewmatthew NL, CanadaMember Matthew NewhookOrganization: ZeroC, Inc.Project: Internet Communications Engine ✭✭✭
    Glacier2 is a connection concentrator and firewall traversal application. It, however, talks the native Ice protocol, so it would be different than the web server plug-in you are discussing above.

    Unfortunately, I don't know enough about javascript to know whether you could implement an Ice client side mapping & runtime engine in javascript.

    PS: Can you please fill in your signature details as described in the link in my signature.
  • frankyfranky Member
    Ice & Ajax + Glacier2
    matthew wrote:
    Glacier2 is a connection concentrator and firewall traversal application. It, however, talks the native Ice protocol, so it would be different than the web server plug-in you are discussing above.

    I would try to transport the native Ice protocol in the http-requests. So the
    'web server plugin' would need only to strip these headers and could continue
    with the raw Ice protocol data (The web server plugin needs some session
    tracking and request multiplexing).

    So the one side of the plugin to the Ice servers should look like the
    corresponding Glacier2 part.

    The client side of course would need some changes.
    matthew wrote:
    Unfortunately, I don't know enough about javascript to know whether you could implement an Ice client side mapping & runtime engine in javascript.

    I would start low. The basic types and the collections are mappable.
    Modules & Interfaces could be simulated by the JavaScript ,object'.
    Structs could be simulated by objects, too. And for classes one could
    use JavaScript prototypes.

    Binary protocol data can be created an manipulated in JavaScript.

    As a concept for such an architecture one could look at 'JSON-RPC-Java'
    (http://oss.metaparadigm.com/jsonrpc/).

    I am just wondering whether such an approach would be feasible.

    On the other hand one could try to add an http transport with
    corresponding endpoints to Ice. But this way all runtimes would
    be affected. Therefore I thought, using a bridge, one would reach
    a broader set of different Ice server runtimes with less compatibility
    problems and could support older server implementations without
    recompiling or adapting them. There would be no need to extend
    all Slice compilers to create the correct output or to extend all
    runtimes in all languages, respectively.

    My interest in Ice: We are going to develope a big web application
    with Ajax. And now I am looking for some kind of RPC we can use in
    JavaScript.

    WSDL/SOAP and XML-RPC are supported but I don't think they fit
    remoting very well. Corba on the server side is ok, but it would be
    hard to support it over http.

    So Ice seems to be very interesting to me. Especially since I can
    forward requests without unmarshalling them (this could not be done
    with Corba, a real pain when writing load balancers and bridges ... :).
  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    hi using AJAX with Ice is posible without reivent nothing

    DOJO toolkit and other packages provides map form java to ajax, you can generated your ajax stuf from your Java interfaces. and like Ice suports java nothing extra is needed.
  • frankyfranky Member
    xdm wrote:
    hi using AJAX with Ice is posible without reivent nothing

    DOJO toolkit and other packages provides map form java to ajax, you can generated your ajax stuf from your Java interfaces. and like Ice suports java nothing extra is needed.

    Could you please provide some links to corresponding web pages or
    online documentation.

    I surfed the dojo pages but didn't find anything close to your description.

    The only thing I found was the not very well documented idea of
    an interface specification via '.jsdl'.

    But I didn't find anything to map java interface definitions automatically
    too any JavaScript libraries or functions.

    Any help would be really appreciated. Thanks in advance.
  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Sorry franky i say you DOJO but i talking about DWR

    take a look to this http://getahead.ltd.uk/dwr/overview/dwr

    and take a look to the new google ajax tookit it has support for RPC
    http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.html
  • frankyfranky Member
    Ice & Ajax + Glacier2
    xdm wrote:
    Sorry franky i say you DOJO but i talking about DWR

    take a look to this http://getahead.ltd.uk/dwr/overview/dwr

    and take a look to the new google ajax tookit it has support for RPC
    http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.html

    These projects are all very interesting but they are far away from something
    like Corba or Ice.

    They don't provide composite data types cleanly in JavaScript. They don't
    have precise portable type mappings for Collections or Structs/Beans. They
    don't support modules and nested interfaces and not to mention polymorphism.
    The Google GWT approach is not portable and can only be used when
    your backend is Java-centric (not a problem for me but may be for others).
    The support for complex compound data types , like 'hashmap of Employee',
    is clumsy (Java collection genericity problem).

    For example. You want to invoke a remote function, that uses a hashmap
    of employees. Where is your Constructor for the 'employee' object in
    JavaScript? How do you check, that 'employee' is constructed with the
    right members with the right types? What about the base class 'Person'
    in the class 'Employee'. When you are lucky, you will get a most an
    unmarshal exception at the 'server side'.

    All the mentioned aproaches put the burdon of creating these
    type implementations on you, instead to create fitting JavaScript stubs
    through generation.

    It all starts with the problem that these aproaches don't use a clean
    type description and mapping scheme. And this is the real hard stuff.

    Just exporting some method names for remote invocation is not a clean
    implementation of an RPC middleware. Especially when you have to
    marshal the arguments for these calls by hand (and in most cases you
    even don't get the signature of a remote method not to mention the
    description of the compound types it contains).

    So what I need is something, that creates JavaScript modules that
    contain all these types with their corresponding inheritance relationships
    and the stub proxies of the defined interfaces for remote invocation.

    And to my knowledge there is currently no project or ajax toolkit to
    tackle these problems 'the right way to do' ... :)

    Just my 2 cents ...
  • rdilipkrdilipk Member Dilip RanganathanOrganization: 3MProject: None ✭✭
    So what I need is something, that creates JavaScript modules that
    contain all these types with their corresponding inheritance relationships
    and the stub proxies of the defined interfaces for remote invocation.

    And to my knowledge there is currently no project or ajax toolkit to
    tackle these problems 'the right way to do' ...
    I came across something in the .NET-land called Script# just generates JavaScript modules from equivalent C# code. Not sure if this is what you are after -- for that matter you might not even want .NET but just FYI:
    http://www.nikhilk.net/ScriptSharpIntro.aspx
Sign In or Register to comment.