Where do new developers start..?

[psaunder]

We have a product that I would like to use ICE to create an API for.
Our product is essentially a router that does wireless authentication using PPPoE protocol.

It has a PHP web based interface for administration though would like more flexibility and power with regard to interfacing to our product - hence Ice.

The product has Oracle database that includes data for:
*Staff
*Customers
*Plans
*Usage.

I want the API to allow:
*Search
* Read
* Update
* Delete
of this data.

I am relatively experienced developer (10 years+) though have not done any middleware programming as such.
To develop this API, what books, study, articles, philosophy do people here suggest to build a good, robust API using ICE?

As I need to interface to oracle using OCCI, I'll probably use C++ as language, if that makes a difference.

Thanks for reading,

Patrick.

[beagles]

Thanks for considering Ice! I think you'll find Ice an excellent choice.

While some texts on developing distributed applications may be in order, ZeroC has plenty of materials available to get you started. The Ice documentation, FAQs, forums and demos that are included in each Ice source distributions make up a sizeable body of information. Last, but definitely not least, our Connections newsletter has several articles on a variety of topics.

[beagles]

By the way, it might also interest you that the upcoming 3.2 release includes an example that interfaces with Oracle via OCCI.

Cheers

[psaunder]

Hi Beagles,
Thanks for your reply. I have read some of the FAQ, portion of the book and most of the newsletters. Are there books that you would suggest for API/component/middleware design?

I'll keep an eye out for 3.2 - I've been reading the Oracle 10g OCCI manual and it is very full featured.

thanks,

Pat.

[michi]

Unfortunately, very few books have been written on how to design good APIs. One book that I found useful is "Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects" by Schmidt et al. It's more about design techniques than APIs, but still worth reading.

Cheers,

Michi.

[eric.hill]

I've been doing extensive testing with Ice and various clients (Win32, MFC, linux, PHP...) and various servers hitting various databases (Oracle, sqlite). Here are some of my experiences.

1. Oracle's OCCI is nice, but very touchy with respect to Visual Studio versions and library formats. Go look at OTL instead. It talks directly to the OCI, and has a very low learning curve. Plus, it's rock solid stable. I haven't had a single failure due to OTL in any of the code I've written. If you code your software right, switching between Oracle, DB2, or ODBC will be very trivial.
2. As good as OTL is, it doesn't speak native sqlite or postgresql. This is where Ice REALLY comes in handy. Separate your database services from your business services. Then, swapping database layers is as simple as writing another service and changing an Ice property.
3. It takes quite a bit of learning to get up to speed on the differences between MyObject, MyObjectPtr, MyObjectPrx, and the dozen or so other interfaces that Ice provides. Take your time and familiarize yourself with these different concepts first. An understanding of these concepts will help you quite a bit with your coding.
4. Design your services to be as simple as possible and let the Ice framework do it's job. Don't bother trying to create your own thread pool for database connections. Just use the built-in thread pool that the Ice runtime already provides. Less custom code == less bugs.

[rc_hz]

Originally Posted by eric.hill

I've been doing extensive testing with Ice and various clients (Win32, MFC, linux, PHP...) and various servers hitting various databases (Oracle, sqlite). Here are some of my experiences.

1. Oracle's OCCI is nice, but very touchy with respect to Visual Studio versions and library formats. Go look at OTL instead. It talks directly to the OCI, and has a very low learning curve. Plus, it's rock solid stable. I haven't had a single failure due to OTL in any of the code I've written. If you code your software right, switching between Oracle, DB2, or ODBC will be very trivial.
2. As good as OTL is, it doesn't speak native sqlite or postgresql. This is where Ice REALLY comes in handy. Separate your database services from your business services. Then, swapping database layers is as simple as writing another service and changing an Ice property.

I have used OTL(http://otl.sourceforge.net) many years. It's really very simple and good! It's worth trying.

[psaunder]

Thanks Michi, Eri and rc for your responses.
I've started looking at OTL, and wow, it's really different.

Just so it's clear on how I'm trying to do things, see picture attachment.

What I expected to do was write the ICE API using C++, and embed the OCI/OCCI or STL statements into their to implement the functionality.
This would all be in Linux, command line environment.
I wasn't intending to do any OCCI programming from Visual studio or any other IDE/environment.
I expected the client program may be written as .net winform app using c# or something else.

For my project, it is unlikely that we would change the database as I use of PL/SQL and triggers to implement functionality - plus I am big Oracle fan.

I expected to have tight binding between my ICE and database layer.
Would I need to have seperation of this?

Thanks for reading, and happy new year!

Patrick.

[michi]

Originally Posted by psaunder

I expected to have tight binding between my ICE and database layer.
Would I need to have seperation of this?

It really depends on what your goals are. Ice is agnostic as to how you engineer your application. If you do not anticipate a need to change databases at some point in the future, and if you do not mind being tightly coupled to a particular database, there is no need for better separation.

Cheers,

Michi.