Re: news?

Atif Ghaffar wrote:

> Hi Joerg,


Hi Atif,

obviously, your kids keep you quite busy... ;))

> On 10/25/05, *Joerg Delker* <[email protected] <mailto:[email protected]>> 
> wrote:
>
>     I'm planing on having four major blocks with the next generation
>     of ISPMan:
>     1) an encapsulated backend
>        * contains all business logic
>        * does no provisioning at all (totally enclosed!)
>        * runs on RDBMS
>        * feed to LDAP
>        * complete webservice (SOAP) interface for interaction
>        * single instance
>        * probably a J2EE application (under evaluation, due to much better
>          WS handling)
>
>
> I am ok on all points. Is it neccessary to  bring in J2EE. Nothing 
> against it but will make more difficult to modify for non-programmers.
> The app is used mostly by system administrators and they can usually 
> hack on perl/php etc more easily.
> PS: What is WS handling?

That's (W)eb(S)ervice.
IMHO, the opposite is the case.
When I started evaluating this, I actually had more experience with Perl 
than J2EE. Despite of that it was much easier to create proper (!) 
webservices, than this was possible with perl so far.
For a nice and clean web service it needs more than just a RPC call, 
such as a robust WSDL interface and proper API documentation.
All that will be provided by the J2EE framework practically "by default".
But there is more:
J2EE provides us with a common, solid framework, taking the burden of 
security (SSL, ...) and database handling from us (persistent objects). 
So we can actually focus on the business logic and not all the stuff 
around it.
This makes development much easier (and faster).
Besides that, I don't expect a system administrator to just "hack" in 
the backend code. That stuff (hopefully) should become basic, rock solid 
logic, that needs very few tweaking. People, who want to make changes 
here, are (from my experience) much more in favor of java, than perl.

When coming to the frontend stuff, I totally agree.
For the agent, there is probably nothing more appropriate than perl.
For the UI, I leave it to everyones personal favorite programming 
language. Would be nice to eventually get some coding competition on 
this one, to see (possibly many) evolving interfaces.

So for my part, using J2EE for the backend is still under evaluation, 
but looks very promising from a programmers point of view.

> Moving LDAP out and feeding it via RDBMS is ok too. We are also doing 
> something similar here at my employer but mainly due to the reason 
> that they were running RDBMS already and we brought in LDAP to take 
> away some load from the DB.


Using LDAP for typical RDBMS tasks is basically possible (as ISPMan <2 
shows), but is a real pain, because of the schema adjustments and the 
overall handling.
On the other hand, we can't drop LDAP, because it's just to important 
for ISP business.
Therefor, I think this is a feasibly way to go.

Joerg