Roots,
'I'm only looking at _a_ W-D-P, too far behind the pack on the _j_ front, I did some yonks back but it's long forgotten.'
hindsight is a funny thing and it may be a blessing in disguise that you are too far behind the pack on the _j_ front and therefore focusing on the _a_ front
the interesting thing I have been observing with the latest versions (jeez aren't we lucky to be at a customer who is always going for the new stuff) is,
the trend became to move everything to wdp J, but then it was noticed that customers were just wacking all the wdp J applications on the core component app servers and not scaling accordingly or adding more app servers only for the wdp J and therefore performance was going down
the only choice the customers had was a redesign and move the wdp J stuff onto separate federated wdp J servers, but how many want to do this or understand it or have the $$$
so.... then the next version came, and suddenly wdp J functionality started moving on the backend old skooool systems in the form of wdp A
to conclude my old skooool friend, wdp A might become your renaissence, just when folks were thinking it was going to be game over for the old backend developers whoc didn't know J, so the mother ship from WALLd has taken the decision to move all this onto the backend as wdp A
I guess this is because the backends are more easily scalable and also, instead of chucking everything into the wdp J cooking pot on the J app servers, by moving to wdp A, they actually keep the functionality separated by business area and therefore easier to size and scope and in the companies get money for.
to conclude, get into wdp A I think it will be big and pay good bucks
Milan.
'I'm only looking at _a_ W-D-P, too far behind the pack on the _j_ front, I did some yonks back but it's long forgotten.'
hindsight is a funny thing and it may be a blessing in disguise that you are too far behind the pack on the _j_ front and therefore focusing on the _a_ front
the interesting thing I have been observing with the latest versions (jeez aren't we lucky to be at a customer who is always going for the new stuff) is,
the trend became to move everything to wdp J, but then it was noticed that customers were just wacking all the wdp J applications on the core component app servers and not scaling accordingly or adding more app servers only for the wdp J and therefore performance was going down
the only choice the customers had was a redesign and move the wdp J stuff onto separate federated wdp J servers, but how many want to do this or understand it or have the $$$
so.... then the next version came, and suddenly wdp J functionality started moving on the backend old skooool systems in the form of wdp A
to conclude my old skooool friend, wdp A might become your renaissence, just when folks were thinking it was going to be game over for the old backend developers whoc didn't know J, so the mother ship from WALLd has taken the decision to move all this onto the backend as wdp A
I guess this is because the backends are more easily scalable and also, instead of chucking everything into the wdp J cooking pot on the J app servers, by moving to wdp A, they actually keep the functionality separated by business area and therefore easier to size and scope and in the companies get money for.
to conclude, get into wdp A I think it will be big and pay good bucks
Milan.
systems. I doubt any of them will be moving that way in the forseeable future but who knows. As far as I can see it's vendor attempts to flog more s/w that the clients don't need and defo would be advised to steer clear of. 
I've no problems with itabs, even deep ones. It's just a question of being able to visualise the data structures. But judging by the number of questions on .netDN, I think you're not the only one who finds it confusing.
Comment