Re: IBM i in the cloud (was social media)

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

On 11/21/2010 7:19 PM, Henrik RÃtzou wrote:
> Joe,
>
> so you haven't meet a system with 6000 files yet - dude ;-)
>
> The generation of REST services needed fo 6000 files will be a process
> that takes about 30 minutes in my environment.
>
> And the services will all have an "output parameter"
>
> output=json
> output=xml
> output=csv
> output=html
>
> I do agree - I have never meet a system or an application that needed acces
> to all 6000 files but either we just generates in batch or we pick up the
> nessecary files

Well, thinking back in my head, no, we don't usually have 6000 files for 
a single application.  I think JDE has about 2000 for the entire ERP 
system, and a lot of those are for EDI and report writing and the like 
(that is, internal tables which would never need a server).

Regardless of the number of files, though, as I noted before you and I 
disagree on what a service is.  You have individual "services" accessing 
every table on the server, sort of like ODBC in REST.  I don't do that.  
Instead, I define business objects and access them as integral 
entities.  For each business entity we would define an object which 
exposes those rows and columns in our database that need to be exposed 
to the client.  It's rarely all of the columns from the tables, and it 
often includes columns from other tables as needed.

This is my design philosophy in any multi-tier application, regardless 
of the languages or platforms involved: servers deal with objects, not 
individual records.  I would never, for example, have individual CRUD 
services for the order header, the order detail, the order comment and 
the order allocation files.  It would be a single CRUD for an entire order.

So as I said, roughly two servers per business object (one query, one 
CRUD).  A dozen or so business objects per application, with many of 
those objects reusable between applications.  It's a really powerful 
architecture!

Joe