Evaluating migration to ICE based infrastructure

[grembo]

Hello,

I'm considering migrating to an Ice based infrastructure. Right now, our systems are based on a mixture of CORBA C++ and Python in the backend (omniORB, btw a really fast implementation) and PHP4 for frontend applications. This leads to a number of issues:
1. Even so after +5 years of CORBA I personally have no problems using the CORBA C++ mapping at all, it is really hard to find developers who can master it - training anybody on CORBA turned out to be almost impossible (and offending to most developers as well)
2. PHP4 is not maintained anymore, so we would need to upgrade to PHP5 anyway
3. We have to expose all functionality to the PHP frontends (which use no framework at all) through webservices, which adds another layer that needs to be maintained
4. The typical CORBA issues like lack of good implementation of OMG standardizes services, problematic firewall traversal, lack of dictionary datatypes etc. that just make life a lot harder than it should be.

Coming from a CORBA background, adpoting ICE seems to be a natural way to go - assuming I'm not following Steve V's idea that any kind of RPC is bad (btw, reading all the arguments of Michi and Steve is quite entertaining - both seem extremely frustrated about the way CORBA turned out - while Steve's conclusion is the overall idea was bad Michi is trying to do it right this time)

Anyway... what I'm planning to do (and need advice on) is:
1. Keep frontends in PHP using an MVC based framework. Right now I'm it seems like we're gonna use CakePHP. The question is if anybody has experience using one of these frameworks, which are normally designed to work directly with an SQL database backend, with Ice - and how Ice would fit in there.
2. In general: How solid is the IcePHP implementation - it's extremely hard to find any information about it outside of zeroc.com - this seems to be a general issue with Ice (partly because the name is really bad to google for ). So either it's not used at all or it just works so flawlessly that nobody posts about it?!
3. It seems like IcePHP uses only one communicator per profile, so I would assume that using glacier2 for per user session management won't work/doesn't make sense.
4. We will run everything within FreeBSD jails (7.1-RELEASE). I understand that Ice is not officially supported on this platform. But it seems that there are definitely users out there - anybody willing to share experience about stability/any known issues?! Basically there will be x jails running Apache2+PHP5+IcePHP communicating with a number of C++ and Python-based services in other jails on multiple machines (this works quite well with CORBA right now - not for the PHP side of things of course).
5. Is there any solid material out there that explains concepts of designing redundant services using Ice - what I found on your website so far is very basic. And yes I understand that the topic goes beyond Ice itself, but maybe there is good material explaining how to design services with SQL-replication in the backend and how to synchronize on an Ice driven platform - since this has to be incorporated in the design phase. OmniORB made this very impractical, so I want to get it right from the very start.
6. Has anybody experience on how long it takes to get the average developer (whatever this means) started on using Ice. With a lot of CORBA background basically everything I read in the docs so far is pretty obvious (including things like default servants, object life cycle etc.). Getting somebody to use the client side should also be trivial. How hard is it to get somebody with some basic understanding of distributed computing but no CORBA/Ice-like middleware experience started on writing production code? Do you have any experience from real world projects? (I know, this is a little bit of fortune telling...)
7. Licensing issues: Right now, all of our software is used in-house, so GPL is fine at this point - even so we tried to avoid any GPL based software in the past. The real question of course is, what if we decide in two years to sell licenses of our system? Basically all the website says is "we gonna find a deal that works". It would be good to actually be able to present something to the management to show that the invest is safe in the future. Especially because our software incorporates many API's to third parties, which are subject of intellectual property/NDAs, so even if we wouldn't care about our software we won't be able to publish the full sources. If this cannot be discussed in an open forum it would be nice if somebody from sales@ could contact me on the email address I used on registration.

Would be nice if you could answer most of my questions, after reading docs for days I'm really keen to get things started - Ice looks very sexy to me

Cheers
Michael

[benoit]

Hi,

1. Keep frontends in PHP using an MVC based framework. Right now I'm it seems like we're gonna use CakePHP. The question is if anybody has experience using one of these frameworks, which are normally designed to work directly with an SQL database backend, with Ice - and how Ice would fit in there.

We don't have much experience with CakePHP, perhaps others on the forum do and will comment. In any case, I don't see any problems with using Ice from CakePHP. I would expect it to be useful at the controller/model layer of the MVC design pattern depending on what you want to do.

2. In general: How solid is the IcePHP implementation - it's extremely hard to find any information about it outside of zeroc.com - this seems to be a general issue with Ice (partly because the name is really bad to google for ). So either it's not used at all or it just works so flawlessly that nobody posts about it?!

These public forums are a good place to find this kind of information. IcePHP is used in a number of projects and yes it works fine .

3. It seems like IcePHP uses only one communicator per profile, so I would assume that using glacier2 for per user session management won't work/doesn't make sense.

Yes, using Glacier2 from an IcePHP application doesn't really make sense. Glacier2 is typically used in a deployment where external Ice clients need to connect to back-end servers behind a firewall. If you didn't already check it out, I recommend taking a look at our chat demo example here: http://www.zeroc.com/chat/index.html

It illustrates how the various Ice compoments fit in the deployment of a typical distributed application.

4. We will run everything within FreeBSD jails (7.1-RELEASE). I understand that Ice is not officially supported on this platform. But it seems that there are definitely users out there - anybody willing to share experience about stability/any known issues?! Basically there will be x jails running Apache2+PHP5+IcePHP communicating with a number of C++ and Python-based services in other jails on multiple machines (this works quite well with CORBA right now - not for the PHP side of things of course).

The best is to try it out and see if you encounter any issues with compiling it or running the tests. I wouldn't expect any major issues as it works fine on Mac OS X which is based on FreeBSD.

5. Is there any solid material out there that explains concepts of designing redundant services using Ice - what I found on your website so far is very basic. And yes I understand that the topic goes beyond Ice itself, but maybe there is good material explaining how to design services with SQL-replication in the backend and how to synchronize on an Ice driven platform - since this has to be incorporated in the design phase. OmniORB made this very impractical, so I want to get it right from the very start.

Could you perhaps detail a bit more the issues you had with OmniORB wrt replication?

We don't have any documentation on this specific topic. However, if you checkout the Ice demos from your Ice distribution, you'll find some demos on SQL database integration (in the cpp/demo/Database directory) and replication (the IceGrid demos demonstrate replica groups).

You should also find the following newsletter articles useful to better understand replication:

• Checkout the "Replication" section page 3 of issue 9
• An example of how to write a replicated application using the master/slave model in issue 23.

6. Has anybody experience on how long it takes to get the average developer (whatever this means) started on using Ice. With a lot of CORBA background basically everything I read in the docs so far is pretty obvious (including things like default servants, object life cycle etc.). Getting somebody to use the client side should also be trivial. How hard is it to get somebody with some basic understanding of distributed computing but no CORBA/Ice-like middleware experience started on writing production code? Do you have any experience from real world projects? (I know, this is a little bit of fortune telling...)

For someone with some understanding of distributed computing, I wouldn't except it to take long before being ready to write code with Ice: it's easy to write distributed applications with Ice, much easier than with CORBA or sockets .

The most difficult is to get a good understanding of the additional issues introduced with distributed computing (as you most likely read in Michi's blog post here).

7. Licensing issues: Right now, all of our software is used in-house, so GPL is fine at this point - even so we tried to avoid any GPL based software in the past. The real question of course is, what if we decide in two years to sell licenses of our system? Basically all the website says is "we gonna find a deal that works". It would be good to actually be able to present something to the management to show that the invest is safe in the future. Especially because our software incorporates many API's to third parties, which are subject of intellectual property/NDAs, so even if we wouldn't care about our software we won't be able to publish the full sources. If this cannot be discussed in an open forum it would be nice if somebody from sales@ could contact me on the email address I used on registration.

Ok, someone will contact you regarding this.

Would be nice if you could answer most of my questions, after reading docs for days I'm really keen to get things started - Ice looks very sexy to me

Thanks and let us know if you need any additional information!

Cheers,
Benoit.

[grembo]

Hi,



We don't have much experience with CakePHP, perhaps others on the forum do and will comment. In any case, I don't see any problems with using Ice from CakePHP. I would expect it to be useful at the controller/model layer of the MVC design pattern depending on what you want to do.

I figured that it will be C and M at the same time, I was just wondering if anybody has experience of doing so - and if using these frameworks still makes sense in this scenario.

Yes, using Glacier2 from an IcePHP application doesn't really make sense. Glacier2 is typically used in a deployment where external Ice clients need to connect to back-end servers behind a firewall. If you didn't already check it out, I recommend taking a look at our chat demo example here: http://www.zeroc.com/chat/index.html

It's more about securing the communication between a server running IcePHP and a different server running Ice services across a firewall (not all servers will be in the same collocation neccessarily).

Could you perhaps detail a bit more the issues you had with OmniORB wrt replication?

The only way doing this with omniORB I'm aware of is through multiple endpoints, which doesn't really help if a machine has serious problems that won't stop it from accepting calls but either never return or only with huge delays. Also if a machine gets flaky multiple endpoints don't help that much (e.g. one server is too busy to answer further requests, but might be responsive later again). Another question is of course just design decisions, because creating read caching servants doesn't really make sense if they don't have exclusive access to the database (which might also have serious performance implications) - so most of the time I will be stuck using default servants. Last but not least, assuming you cannot guarantee 100% that there will be only one master at a time (which might actually happen in a load caused situation), how do you organize locking/coordination between services. I was just wondering, if there is anything I can use out of the box or general advice (the reference material you provided IMHO only scratches the very surface of these issues). Another possibility is just to do replication and a hot standby scenario, so migration of endpoints is still under manual control. It is a really hard topic indeed

Cheers
Michael

[benoit]

Hi,

Ok, using Glacier2 from IcePHP in such a scenario could make sense. The services hosted in the other collocation facility would be accessed through Glacier2 from IcePHP. Each PHP request will establish and destroy the Glacier2 session. Another option would be to use IceSSL to secure the connections between IcePHP and the different services but then you would need to open multiple ports on the firewall of your other collocation facility if you host multiple services.

For replication, Ice also relies on proxies with multiple endpoints but also replica groups which are basically virtual object adapters whose endpoints get resolved thanks to the Ice location mechanism. IceGrid (which implements the Ice location mechanism) offers a number of load balancing policies that can help balancing the requests over multiple replicas (random, round-robin, adaptive, etc.).

There's however indeed no easy way to prevent access to a bogus/un-responsive but still running service replica. One solution could be implement a custom monitoring service that monitors the health of each service and brings down the un-responsive services. Note that you can also implement your own Ice location service if IceGrid doesn't fit your needs. So while Ice doesn't provide general purpose solutions to easily implement a replicated service (my feeling is that it's often something very specific to the application and unfortunately there can't be a general purpose solution), I believe it provides the necessary core components to allow accessing and building such replicated services.

Cheers,
Benoit.

[matthew]

To me, Ice provides infrastructural tools necessary to implement fault tolerant replicated services. IceGrid, replica groups, and so on are part of that infrastructure. Most of the stuff that you've outlined is out of scope of Ice, or is too application specific, and should really be implemented at the application level. For an example of a fault tolerant application take a look at IceStorm. It handles many of the things that you've outlined using master-slave replication (including providing absolute guarantees that there is only a single master).