Impala - to evolve a legacy application...
Frank Misa
---------------------------------------------------------------
Original question - asked of Impala creator/developer - Phil:
Hi Phil...
* Was wondering if Impala is still actively being developed ? Seems -
not much activity since May2010.....
* Do you believe that Impala could help us run a unified (shared
session?) JSP-based UserInterface - leveraging services on middle/back
end tiers that need to run against different codebases.... for example
- from the same UI/Application:
(Page1 <-> Spring2.0.x <-> CustomORM <-> RDBMS)
(Page2 <-> Spring3 <-> Hibernate/MyBatis <-> RDBMS)
Some background...
We're currently hampered upgrading Spring and introducing more
standard ORM/Persistence layer technology because of inter-project/
module dependencies and the cross-discipline effects of introducing
new technologies....
i.e. Database design changes, Testing/QA and Deployment/Runtime
implications - necessitated by the introducing of something like:
Hibernate.... or upgrading from Spring2.0.x to Spring3...
We'd like to be able to develop new views/UI - and run against more
modern/standard libraries.... do you think Impala can help us ?
Hope to hear from you....
---------------------------------------------------------------
REPLY From Phil:
Hi Frank
Thanks for taking an interest in Impala
...
...
In response to your specific question, I'm not sure if Impala is a
solution if your intention is to run multiple versions of various
third party libraries within the same JVM. Impala does not provide any
versioning for third party libraries. Have you looked at OSGi? That
purports to offer solutions to the kinds of problems you appear to be
addressing.
Regards,
Phil
---------------------------------------------------------------
FOLLOW-UP Question:
Hi Phil,
Thanks very much for replying...
I appreciate it.
The OSGi learning curve is too steep - and many of our JARs would not
play nice in an OSGi container; we might need to OSGi-ify some of our
JARs.
We're looking for a stop-gap measure - something to give us breathing
room - to move to a new architecture without disrupting what we
already have running.
* The ability to run our existing web-application - as is; while
simultaneously allowing us to add new User-Interfaces and
functionality that are free
to use a new architecture - perhaps a newer version of Spring - and
more standard ORM layer as I outlined before.
* It's always catch-22.... We know full well the technology debt is
increasing and we're are aware of new programming models and libraries
that could help us increase productivity
and improve our user experience... (reduce tech. debt) but we're
unable to get there - without completely uprooting the existing
architecture which was not unfortunately
written as more modular/separate web-applications :( Add to this -
limited automated testing... and it becomes a daunting task...
On first read - it seems Impala might help us stage in parallel - a
new architecture... while allowing us the flexibility to continue to
run on the old
architecture - migrating over a period of time on an as needed
basis... in time everything would run on the new version of libraries
and updated programming model.
We're not so much interested in running multiple versions of the
libraries simultaneously.... OSGi is overkill for us...
Before diving in too deep - I just wanted to hear from the creator -
if the usecase/scenario I'm describing is in fact why you created
Impala in the first place ?
Or have I misunderstood...
Any thoughts - or other suggested technologies/approaches would be
very much appreciated...
Hope to hear from you...
Thanks
Phil Zoio
It is possible to use Impala for such a scenario, I think.
With Impala you have the concept of a host project, and then attached to this, you have various modules. The host
project is just a standard Spring web project, with classes in WEB-INF/classes, etc. Sitting beneath this you have the
modules, which have visibility of the all classes in the host project (ie. the existing system).
So you could introduce new modules into this environment which do the extra stuff you need without having to make any
changes to the existing part of the application.
As time goes on you could "pull down" code and features from the host project to the modules, until eventually the
entire system would in the modules.
(You would of course be restricted in your library choice - you would be add new libraries, but you would not be able to
stop libraries from your existing application from being visible to the modules, and you would not be able to "override"
the versions, as you rightly recognise.)
Regarding my own experience ... I am coming out of the other side of a similar situation, although the approach we took
was quite different - to build an entirely new system out of what could be reused from the old, but using a new domain
model, architecture, etc. We resisted building new features on the old code base, which is now pretty much frozen,
having been long since overtaken by the new system. The problem of course for this approach is that the transition in
this situation can be lengthy and commercially potentially a non-starter.
Regards,
Phil
Phil Zoio
See my comments below
Regards,
Phil
On 09/07/2011 03:59, Frank Misa wrote:
> Thanks Phil...
>
> I don't see a way I can attach an image - in the group thread - so I'll just confirm with you directly: See attached image.
>
> I really appreciate your time and thoughts.
> If I understand you correctly - I don't think I can do it ?
>
> What you're saying is - my "Modules" would be forced to run the same Spring version as the "Host" Project ? because of class visibility.
Yes at this point this is the case
> You're right - I could introduce new JARs in the Modules - perhaps leverage some new infrastructure libraries without impacting the other modules...
> BUT - everything is so tied into Spring now..... it sounds like there's no way I could have the Module run with a different version of Spring... one which eventually I'd like all the Modules to migrate to ?
>
> I couldn't "hide" Host project Spring class conflicts from the module level class loaders...
> I think - what you're saying is I could add new functionality - with new modules.... while having the time to eventually "move-down" into proper modules all the legacy infrastructure code that currently resides at the host project level.
Yes, that's exactly what I mean
>
> In effect - giving us the time to modularize the application at our own rate...
>
> Am I missing your point ?
>
> Forgive me... if I'm being thick headed...
>
> Thanks
> F