Re: news?

Hi *Jörg,*

**
What will be requirement running the J2EE app on the hardware side?
On the coding resource.. who do we have?
Please send me the schema if you have a rough version.
 best regards


 On 10/27/05, Jörg Delker <[email protected]> wrote:
>
> 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
>
>
>


--
best regards
Atif Ghaffar