Ice & Ajax

[franky]

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.

[matthew]

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.

[franky]

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.

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 ... :).

[xdm]

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.

[franky]

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.

[xdm]

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/do...dureCalls.html

[franky]

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/do...dureCalls.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 ...

[rdilipk]

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