Archived

This forum has been archived. Please start a new discussion on GitHub.

Some question about deployment of ICE

Before spending quality time to dig into ICE's technical details, from the overview it appears to be a communiction infrastructure we may be able to use. This is an application mainly for data tranformation from Linux data store to web server frontend. Originally we planned to use web service as the data infrastructure, however after found ICE, web service performance has started to concern me, while ICE is proven to handle scalability well.

In such an sceniaro, in order to establish a communcation channel between a windows web server (client) and a linux data server (server), will there be ICE "server" type of application required to run at both side? Or only on the "server" side, the Linux server?

Comments

  • Re: Some question about deployment of ICE
    In such an sceniaro, in order to establish a communcation channel between a windows web server (client) and a linux data server (server), will there be ICE "server" type of application required to run at both side? Or only on the "server" side, the Linux server? [/B]

    No, if the clients are "pure" clients (that is, only originate remote calls, but never answer them), you need to run a server only on the server side. If the clients are hybrid client-server applications (such as if the clients offer a callback object to the server), then they are obviously servers as well. But, even in that case, you don't need to anything special. The distinction between "client" and "server" is really quite arbitrary in Ice, and the run-time support provided by Ice is identical on the client and server side (that is, the same libraries are used by clients and servers).

    Why do you ask this question? Is there some concern about incoming connections or firewalls?

    Cheers,

    Michi.
  • Thanks for your reply.

    The reason it's important to clarify whether there is a "server" ICE runtime needed on the client side, is because in our case, the client is really the web server manged by the web hosting, where we don't have the control of what server runtime can be installed other than the files (pages, binary) needed for the web pages.

    The Linux server, which serves as the data store in our architecture, is under our full control, where we can install anything we need.

    The client is an asp.net web application, mostly will only need to issue RPC calls to Linux server over the Internet for a purpose to retrieve data object, including data modification sent to the Linux server. The purpose is to hide the data and location complexity from the frontend web pages, only an object graph (OO represent of data element) is feeded. Ideally, only the ICE library runtime supplied to the web application, no server daemon (NT service) type of ICE component needs to be deployed to the web server (client). Does this sound practical?
  • Originally posted by RusselHarvey
    The client is an asp.net web application, mostly will only need to issue RPC calls to Linux server over the Internet for a purpose to retrieve data object, including data modification sent to the Linux server. The purpose is to hide the data and location complexity from the frontend web pages, only an object graph (OO represent of data element) is feeded. Ideally, only the ICE library runtime supplied to the web application, no server daemon (NT service) type of ICE component needs to be deployed to the web server (client). Does this sound practical?

    Yes, sounds practical. If you can install the Ice libraries on the web server, your web server can issue Ice requests to the back end. There is no need to run any kind of server/service on the client side.

    Another option would be to use Ice for PHP on the web server side to make the requests to the back end. This will work if PHP is available on the machine that runs the web server.

    Cheers,

    Michi.
  • Thanks Michi for the advice.

    Due to my little knowledge of ICe (only heard since yesterday), I'd like to find out if ICE can be configured to communicate not limit to any particular port.

    The reason for this is because the linux data server and web server are at different locations and connected via Internet. It may be a challenge to open a particular port on the Linux server side if it is not 80, thougth possible. This has been what drove me to consider xml web service before found ice.
  • marc
    marc Florida
    Even though I don't really understand why some firewall administrators insist on opening port 80 only (what's the added security?), we are currently redesigning Glacier (the Ice firewall) so that it can work on a single port. This port can then be port 80 or any other port of your choosing.
  • After read through ICE's basic concept and history, I become curious how would ICE compare to J2EE's distributed object architecture model, since J2EE also has a root from CORPA as like DCOM, but I could not find J2EE mentioned any where in ICE's paper.

    It'd be interesting to learn about what ICE really shine in the face of current popular distributed architecture, except already known that dotNet is short for crossplatform, what about J2EE?
  • Thanks for the comments.

    In ICE's mannual, it mentioned "ice's protocol is suitable in building highly efficient event forwarding mechanism". While in our application, more often it's a type of "content" forwarding system, that may dramatically increase the size of the data packet shipped via ice. Will ICE handle it well?
  • marc
    marc Florida
    I'm not sure what you mean with "content". In any case, the reason why Ice is so efficient for event forwarding is that it can treat requests as a blob (sequence of bytes), i.e., Ice can forward requests without interpreting the request data. Both IceStorm and Glacier make use of this.
  • Originally posted by marc
    I'm not sure what you mean with "content". In any case, the reason why Ice is so efficient for event forwarding is that it can treat requests as a blob (sequence of bytes), i.e., Ice can forward requests without interpreting the request data. Both IceStorm and Glacier make use of this.

    The content referred to large quantity of data (in neighbour of 50K to 200K byte) in any single data transmission and transaction. For example, one problem arose with the first version of MS BizTalk (although not in a close comparison to ice) is its inability to carry large data size though event type message can be transmitted effectively.

    The impression I am getting of ICE is it's designed with online gaming application in mind (I could be wrong), although I like it to be light weight, but it brought my attention as how it will performance in application which may send data larger than simple event (state change) type of message. Hope I explained well. Thanks.
  • Originally posted by RusselHarvey
    The impression I am getting of ICE is it's designed with online gaming application in mind (I could be wrong), although I like it to be light weight, but it brought my attention as how it will performance in application which may send data larger than simple event (state change) type of message.

    There is no inherent limit on message size. (The limit is configurable, with a 1MB default). Whether a message is sent as a twoway or oneway message, is sent synchronously or asynchronously, or is sent via Glacier or IceStorm -- it makes no difference. The message size limit is simply what you configure and long messages are sent just as efficiently as short messages. The real limit is simply the available bandwidth. (Obviously, long messages take longer to transmit than short ones.)

    One limitation: if you use UDP as the transport, message size is limited to the size of UDP datagrams (just under 64kB). Obviously, that limitation is inherent in the transport.

    Cheers,

    Michi.
  • why open one port

    " we are currently redesigning Glacier (the Ice firewall) so that it can work on a single port. This port can then be port 80 or any other port of your choosing."
    -- I am very glad to see that news.

    why open one port:
    Network administrator will not only stakeout virus and hack's attack but also detect the any sensitivity data blow the gaff.Much less port open
    more easer to administrate.This is a realistic scenario about most of Office network envirments.