Related
I have just been asked by my company to rewrite a largish (50,000 single lines of code) Java application (a web app using JSP and servlets) in Clojure. Has anyone else got tips as to what I should watch out for?
Please bear in mind that I know both Java AND Clojure quite well.
Update
I did the rewrite and it went into production. It's quite strange as the rewrite ended up going so fast that it was done in about 6 weeks. Because a lot of functionality wasn't needed still it ended up more like 3000 lines of Clojure.
I hear they are happy with the system and its doing exactly what they wanted. The only downside is that the guy maintaining the system had to learn Clojure from scratch, and he was dragged into it kicking and screaming. I did get a call from him the other day saying he loved Lisp now though.. funny :)
Also, I should give a good mention to Vaadin. Using Vaadin probably accounted for as much of the time saved and shortness of the code as Clojure did.. Vaadin is still the top web framework I have ever used, although now I'm learning ClojureScript in anger! (Note that both Vaadin and ClojureScript use Google's GUI frameworks underneath the hood.)
The biggest "translational issue" will probably be going from a Java / OOP methodology to a Clojure / functional programming paradigm.
In particular, instead of having mutable state within objects, the "Clojure way" is to clearly separate out mutable state and develop pure (side-effect free) functions. You probably know all this already :-)
Anyway, this philosophy tends to lead towards something of a "bottom up" development style where you focus the initial efforts on building the right set of tools to solve your problem, then finally plug them together at the end. This might look something like this
Identify key data structures and transform them to immutable Clojure map or record definitions. Don't be afraid to nest lots of immutable maps - they are very efficient thanks to Clojure's persistent data structures. Worth watching this video to learn more.
Develop small libraries of pure, business logic oriented functions that operate on these immutable structures (e.g. "add an item to shopping cart"). You don't need to do all of these at once since it is easy to add more later, but it helps to do a few early on to facilitate testing and prove that your data structures are working..... either way at this point you can actually start writing useful stuff interactively at the REPL
Separately develop data access routines that can persist these structures to/from the database or network or legacy Java code as needed. The reason to keep this very separate is that you don't want persistence logic tied up with your "business logic" functions. You might want to look at ClojureQL for this, though it's also pretty easy to wrap any Java persistence code that you like.
Write unit tests (e.g. with clojure.test) that cover all the above. This is especially important in a dynamic language like Clojure since a) you don't have as much of a safety net from static type checking and b) it helps to be sure that your lower level constructs are working well before you build too much on top of them
Decide how you want to use Clojure's reference types (vars, refs, agents and atoms) to manage each part mutable application-level state. They all work in a similar way but have different transactional/concurrency semantics depending on what you are trying to do. Refs are probably going to be your default choice - they allow you to implement "normal" STM transactional behaviour by wrapping any code in a (dosync ...) block.
Select the right overall web framework - Clojure has quite a few already but I'd strongly recommend Ring - see this excellent video "One Ring To Bind Them" plus either Fleet or Enlive or Hiccup depending on your templating philosophy. Then use this to write your presentation layer (with functions like "translate this shopping cart into an appropriate HTML fragment")
Finally, write your application using the above tools. If you've done the above steps properly, then this will actually be the easy bit because you will be able to build the entire application by appropriate composition of the various components with very little boilerplate.
This is roughly the sequence that I would attack the problem since it broadly represents the order of dependencies in your code, and hence is suitable for a "bottom up" development effort. Though of course in good agile / iterative style you'd probably find yourself pushing forward early to a demonstrable end product and then jumping back to earlier steps quite frequently to extend functionality or refactor as needed.
p.s. If you do follow the above approach, I'd be fascinated to hear how many lines of Clojure it takes to match the functionality of 50,000 lines of Java
Update: Since this post was originally written a couple of extra tools/libraries have emerged that are in the "must check out" category:
Noir - web framework that builds on top of Ring.
Korma - a very nice DSL for accessing SQL databases.
What aspects of Java does your current project include? Logging, Database transactions, Declarative transactions/EJB, web layer (you mentioned JSP, servlets) etc. I have noticed the Clojure eco-system has various micro-frameworks and libraries with a goal to do one task, and do it well. I'd suggest evaluate libraries based on your need (and whether it would scale in large projects) and make an informed decision. (Disclaimer: I am the author of bitumenframework) Another thing to note is the build process - if you need a complex setup (dev, testing, staging, prod) you may have to split the project into modules and have the build process scripted for ease.
I found the most difficult part was thinking about the database. Do some tests to find the right tools you want to use there.
Hey,
i've a simple question.
Task:
Program a backup system which can be used by server-, or desktop-systems. The backup system should include a graphical configuration and status view. The programming language should be Java.
Question:
Would you use a web interface, which will solve these jobs or would you create a GUI in Swing?
My thoughts:
- The web interface has the advantage that is is accessible from everywhere (server - configuration made easy without any additional software on the client side).
- The GUI has the advantage that it is more responsive than a web interface and will maybe look more professional on a desktop-system than, the web interface version.
Which solution whould you choose?
Thanks!
The desktop vs. web app discussion usually depends on who would use the application, and from where. If it's always going to be used by the person sitting at their desk (or at the desk of the server), a desktop application is a good choice. If the user may be remote a web application is the way to go.
Another consideration is deployment. Is this going to be deployed on one or two machines, or does it need to be installed / available to 10's, 100's or 1000's of users? Deployment and updates across hundreds of machines can be onerous for desktop applications, but a non-issue with web-based apps.
Generally speaking, you can give a much richer experience with a desktop app. In this case, however, "rich" isn't really a requirement. You're going to have a few buttons, perhaps a window showing a log of some sort, and that's about it. So from a usability perspective you can probably create a compelling UI using either method.
If deployment and a rich UI don't really factor in, pick the one that either a) you know well, so you can do a good job, or b) want to learn assuming you have the time.
Since the actual question you asked was "which would you choose", personally I'd choose a desktop GUI based on the little information provided in your question.
Yeah Bryan is totally right. Choose the solution you prefer, since you are the developer :)
I'd prefer the web solution, because I love to play around with these nice Web 2.0 AJAX/JS things. Also there are at the moment a few new Browser Developments, which will make it possible to use an webapp as desktop app.
Basically, it's really no matter which variation you choose.
I did serious Swing work in the past but I see less and less the incentive to use "fat client" technologies with today's web based UI (Ajax, JQuery, HTML5 and efforts like html5boilerplate.com to make them work on older browsers). The browser is the present and future of rich UI, specially as more software makes the move to the cloud.
I would like to start up a project from scratch. I am a java developer for years. I did even write my own mvc framework some time ago for fun. Now I am working in a company using in-house framework - which i think is a total loss of time and money. I respect the idea of teaming up with different skilled people for a large scale project. The separation of the project is very important; Graphics guys, front end developers, software architectures, software developers, database experts, etc. I cannot risk to use a scripting language like php.
Lately, I am researching java technologies for a large scale project in every aspects. What I mean by that, for the front layer I come across with very famous technologies.
Spring
MyFaces
Tapestry
Google Web Toolkit
Cocoon
Velocity
Every one of them states that it is the simplest, the fastest, the latest technology and whatsoever. Of course only one them can hold the truth. I need a front end technology for fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb. It should also have IDE support, community support, rich documentation and online tutorials. Still I have no experience of those frameworks which to choose from. Maybe there is even better one? And most importantly, I cannot risk to start up on a technology which has development limitations. Is there any suggestions for this layer?
For the business layer, I am sure of EJB and JPA. I do even considering a web service for facade of this layer for interoperability purposes for future extensions. However, I have no idea about securing that layer (it could be applied on its web service level) which is still a problem for me. For the application server I am considering GlassFish.
And for the last question is what IDE should be picked for development. Regarding all the technologies, which are going to be used, an IDE should help me in every step, either doing the configuration for me or helping me configuring with its ready wizards. I suppose the IDE will have proper plugins for to be used technologies.
I know that I want too much, however I have a hope for a combination of technologies which will help me saving time and money in my future plans.
I ll be really glad to hear your responses, experiences for a bigger picture.
edited: There is no ultimate answer, I know that. I am just taking advice. Any answer is appreciated.
Well, I'm going to go out on a limb and give concrete recommendations, since I think the question can be answered.
I'll simply recommend my stack.
My stack is Stripes for the front end, and Glassfish/Java EE 5 on the back end.
Stripes is a simple Action (or MVC, whatever floats your boat), that has a small, but robust and vocal community. It has tight integration with JPA (through a plug in), a very good, and current, printer book on the topic as well as excellent reference documentation. It's main rendering tech is JSP with JSP Tags and EL.
It is not a component framework like JSF/MyFaces, so it's implementation is simpler, and it's lifecycle is simpler. It works very well with Ajax.
The key factor around Stripes, since it's based on the HTTP request cycle is that it does most of the grunge work for you, yet is very lightweight. It's easy to pick up and understand. Creating a basic Stripes app is a couple lines in the web.xml and two jars (one of which is log4j). If you can think in HTTP, then Stripes is a good fit for you.
On the back end I would simply stick with EJB and GlassFish. Java EE 6 and GFv3 are out have been out for sometime. It offers a lot of new features over Java EE 5, and GlassFish offers most any web service tech you would like to use. Java EE 6 and Spring are pretty much equal on a bullet point by bullet point basis, and since you were looking at GF, you may as well use EJB since it's there and integrated in the box. If you were using Tomcat, then Spring might be a good choice.
And, that's it. That's all you need (I dunno what you wanted Velocity for, you can add that trivially if you like, but I wouldn't use it for pages, personally, modern JSP is much better IMHO).
Glassfish will secure your web services, you can use Java EE security with your web apps, you can share logic between the back end EJBs and your web app and web services. It all works out of the box with 15 minutes of configuration to get Stripes running.
I use NetBeans, but all of the other IDEs work as well. NetBeans is nice because it come integrated with Glassfish. One less thing to configure. Download it, fire it up, and it works.
There's a Stripes plugin for NetBeans, that I don't use. I don't see a need. Once you add your few lines to your web.xml that you cut and paste from the web site, you never see Stripes again. From there, it's all simple annotations.
Unless you have a crushing need for all of the complexity and learning curve of a component framework, it doesn't get any better than Stripes, and GF w/Java EE 6 has everything you need in the box.
So, in summary: Stripes distro from www.stripesframework.org, NetBeans download from netbeans.org, and stripersist from stripes-stuff.sourceforge.net. It's a rock solid foundation that will go wherever you want to take it.
Come on by to the Stripes IRC on freenode at #stripes, and we'll answer any question you have (or hit the mailing list).
Well, first of all, your question is not good. Every technology has it's bright sides and dark sides. To choose some specific technology - you need experience in all of them to estimate which problems can emerge with your project. Given your definition: fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb - 90% of frameworks support all of it either directly or using some plugins.
Moreover, various technologies are better optimized for various needs. You can't have a all-in-one-super-framework that is flawless and does everything the best way possible. Given that the framework is highly scalable and fast (example: Spring and/or Portlets) will make it hard to configure for some small tasks.
So the only thing I can recommend is to google "Java Web Framework Comparison" and hope for the best.
As about IDE, I can see only 2 choices: IntelliJ Idea and Eclipse. Again, there is no clear winner so yet again google is the only source of information you can get.
Added:
Talking about frameworks again, complex projects use several of them at once taking the best parts of each to aid with the specific project needs. But to do that effectively - you need to be a guru in all of the mixed technologies.
There is almost no way that someone can actually answer this question for you. In terms of frontend technology, one of the frameworks will work for you and others won't. It all depends on which one makes sense to you. My suggestion would be to try them all out and pick the ones that you feel the most comfortable with.
With that being said, I do have a few suggestions. First, don't limit yourself to using Java. If it were me, I would use Ruby on Rails running on jRuby as the frontend as it is the fastest framework for developing web applications that I have used. By running it on jRuby, it allows you to hook into Java and let java and its libraries do all the heavy lifting on the back end. I would stay away from web services and implement things using ReST.
In terms of an IDE, definitely go with IntelliJ IDEA. It may take a little bit to get used to, but it is definitely the fastest IDE on the market. However, both Eclipse and Netbeans are also very good for Java and a tad cheaper.
Once again, the answer is, "it depends".
All of the above projects started off with simple ideas. As they gained traction, they have all added neighboring features which are useful to some but not necessarily all. In other words, you will have to do deep analysis to pick the perfect framework.
You are not going to find a perfect match unless you just happen to be of like mind as the dozens of people working on the particular framework, assuming that all those minds were ever in perfect agreement. The only "perfect" fit is the one you write yourself, and even then you find it's not perfect as you are limited in time and effort on developing the framework; after all, you DO have a program to write, and the framework development time competes with the program development time.
As far as IDEs go, there's differences in taste and style. I tend to gravitate between the old standbys of Netbeans and Eclipse, and my next IDE to play with will be IntelliJ Idea. The thing to remember is that most people commit to one IDE and then defame the rest, so you really can't get a good comparison. IDEs take too much time to really learn for a person to give a honest unbiased opinion. A good candidate IDE "X" will be the worst in some eyes and be the best in others.
Given how the other answers look, I would say the biggest remaining factor is the learning curve for you and your team. Given your description of the separation of roles, your primary concern should be picking an overarching framework, such as Spring. From there, your database guys can pick whatever they want for data persistence (hibernate, jdbc, whatever) and your gui guys can pick whatever they want for their front-end (tapestry, jsf, etc.).
The primary concern I would have with such a distinct separation of roles would be the communication on the team. Make sure that their is a high degree of open communication, especially when discussing interface design, as those will be integral in the success or failure of your project (especially if you pick Spring).
As far as IDEs go, it's personal preference. The two mentioned in the other posts (Eclipse and IntelliJ) are the two I hear the most about, with Eclipse being my standard IDE for the last 4 or 5 years. I'm not familiar with IntelliJ, but I know that Eclipse has plug-ins to support Spring, Hibernate, and a host of other frameworks and ORM solutions. It also has plug-ins to support other languages as well, such as Ruby and PHP.
"I did even write my own mvc framework some time ago for fun" - at the end of the day it may happen that you will regret that you did not stay with it. In fact the technology that is better than currently "famous" most probably is the one that will be famous a little bit later, not now. Half of your list is already "famous" as obsolete.
We are looking at reworking a java business management web service that has been in use for over 4 years now. The software's internal architecture has been all custom built and with a bad separation of of the presentation layer and business logic. As well the overall model layer has proven it can't effectively keep up with changing business logic and needs refactored. As I am planning out this task I have been looking at available frameworks that I could leverage to make the application more friendly to new developers hired on and changing business logic. I have never used struts or JSF before but read up on them in a somewhat brief and overview method and at first glance am not overly impressed by either, however I find JSF more intriguing.
First Both Frameworks seem to focus on the Controller and View portions of the MVC pattern. Leaving you to do whatever on the model/business layer. (am I correct?)
With the rework we want to be able to employ outside contractors to help expedite the rework so finding a unified development methodology is important to insure quality of code and decrease inconsistencies and ramp-up times.
So what recommendation would you have on frameworks, practices, etc that might help this effort. I really don't want to reinvent the wheel with a custom framework and find us in a similar situation later.
There are a couple of things you should think about when undertaking this approach:
Your specific needs vs. the focus
of a particular framework
Availability of coders who know the
framework (in-house and on the
market)
Learning curve for the
framework, and the level of its acceptance & support in the broader community of developers.
Many people speak highly of Spring MVC, though if IOC is new to you (or you don't buy the concept) this may be a bit more than you want to bite off "all at once."
Another well established option is Struts (though I'd strongly suggest Struts 2 for new development).
One thing to be wary of is the size & scope of a "framework transplant" operation. If your app is in dire need of serious structural reorganization, it's quite likely you could end up basically starting from scratch and hanging chunks of your existing business logic off of a skeleton built upon framework. The time/money/resources (and opportunity cost!) should not be underestimated, and you should be certain management really buys off so you don't get the plug pulled on you halfway through. It's really really important to "measure thrice and cut once" here, and make sure you're biting off a chunk of work you can chew -- going from "legacy app" to "brand new state of the art app using all new technologies" is frankly best done in stages, rather than all at once.
It would be helpful to understand the size & relative complexity of the application as well as it's basic nature (is it a very web-UI intensive app, or a back office system which does lots of jobs?) in order to make better suggestions about particular frameworks: though you could certainly build most webapps on any given framework, some are slanted more heavily in one direction than another (e.g., Struts and Wicket have a pretty different focus)
Additionally, there's nothing wrong with trying a couple candidate platforms alongside your existing application. Though I know nothing about your current app's technology backplane, unless you've done something really strange it's likely quite possible to install one or more frameworks and experiment with them alongside your existing app (e.g., write new features against them, or rewrite portions of existing code using them, then hook that code into the backend). This will let you experiment and "try before you buy". I'd suggest having your team give this a whirl on one or more "short list" framework candidates to get the feel for how it'll work in practice. This is, incidentally, not a terrible way to approach refactoring: gradually replace old functionality with your new framework.
Final (I think) piece of advice: look long & hard at your datamodel and the interfaces thereto. That's typically going to be where the real gremlins are, and regardless of framework you want to get that right. I'd strongly consider making that your #1 refactoring target, rather than the adoption of a particular framework. A strong datamodel is going to make implementing ANY framework (and handling upgrades) much easier...and should your management change directions on you and end up delaying the framework upgrade for whatever reason, time spent refactoring the data model will pay off.
EDIT:
Given your comments about the shape of the product, I'd double-down on the "be very, very careful" advice. The spot you're in now is very common (and notorious) and has eaten many teams (and careers) alive. You need strong understanding & support from stakeholders up the chain and on the business side as this is going to be a hugh undertaking which will, by nature, take longer & cost more than you imagine. The technical team's ability to be clear-eyed and realistic about the cost + scope of the changes here is CRUCIAL to success -- if you underestimate significantly you're jeopardizing budget, careers, and potentially the business itself. If you overestimate, you may never get to start :)
One approach, once you have strong buy-in and support from management, is to really treat this as a whole new product -- put the old stuff on maintenance, roll up your sleeves, and start designing the replacement system with all the knowledge you've gained in the previous implementation. In that case, I'd work out the component and data interactions sans-framework, then look at how a given set of candidate frameworks would support that implementation. Starting with the framework may lead you to unnatural places, and could land you back in a similar spot down the road.
Some well-known popular frameworks to check out:
Struts2 - MVC /w AJAX support
Wicket - AJAX heavy
Struts1 - Granddaddy of pretty much all Java frameworks; worth a look
Spring MVC - Spring's IOC webframework
If you liked JSF and want to use it, I would recommend the use of JBoss Seam. You can also use Spring, but I think that using JBoss Seam makes the use of JSF much easier. I am using it for almost 1 year now with good results. And if you want to modelate your process as a business process you can try JBPM (along with Seam).
If you want to know more about agile methodologies so you can improve both your methodologies and practices, take a look first on the agile manifesto http://agilemanifesto.org/ . And then start trying established methodologies like XP or Scrum.
But take your time, start trying one change than another not to confuse yourself
JSF allows you to focus on components, while JSP based solutions don't as well, or as much. You'll still find yourself coding a lot of jsp'ized html stuff, while with JSF solutions, you really don't need to.
Look at RichFaces or IceFaces as libs. RichFaces makes it trivially easy to do AJAX type stuff. Just add the tag <a4j:support event="onkeyup" reRender="output"/> to your standard JSF control. In the example above, on the keyup event for the control, it will rerender an area <a4j:region, or another JSF, Richfaces tag. Nothing simpler.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I joined a new company about a month ago. The company is rather small in size and has pretty strong "start-up" feel to it. I'm working as a Java developer on a team of 3 others. The company primarily sells a service to for businesses/business-type people to use in communicating with each other.
One of the main things I have been, and will be working on, is the main website for the company - from which the service is sold, existing users login to check their service and pay their bills, new users can sign up for a trial, etc. Currently this is a JSP application deployed on Tomcat, with access to a database done thru a persistence layer written by the company itself.
A repeated and growing frustration I am having here (and I'm pretty happy with the job overall, so this isn't an "oh no I don't like my job"-type post) is the lack of any larger design or architecture for this web application. The app is made up of several dozen JSP pages, with almost no logic existing in Servlets or Beans or any other sort of framework. Many of the JSP pages are thousands of lines of code, they jsp:include other JSP pages, business logic is mixed in with the HTML, frequently used snippets of code (such as obtaining a web service connection) is cut and paste rather than reused, etc. In other words, the application is a mess.
There have been some rumblings within the company of trying to re-architect this site so that it fits MVC better; I think that the developers and higher-ups are beginning to realize that this current pattern of spaghetti code isn't sustainable or very easily scalable to add more features for the users. The higher-ups and developers are wary of completely re-writing the thing (with good reason, since this would mean several weeks or months of work re-writing existing functionality), but we've had some discussions of (slowly) re-writing certain areas of the site into a new framework.
What are some of the best strategies to enable moving the application and codebase into this direction? How can I as a developer really help move this along, and quickly, without seeming like the jerk-y new guy who comes into a job and tells everyone that what they've written is crap? Are there any proven strategies or experiences that you've used in your own job experience when you've encountered this sort of thing?
Your best bet is probably to refactor it slowly as you go along. Few us of have the resources that would be required to completely start from scratch with something that has so many business rules buried in it. Management really hates it when you spend months on developing an app that has more bugs than the one you replaced.
If you have the opportunity to build any separate apps from scratch, use all of the best practices there and use it to demonstrate how effective they are. When you can, incorporate those ideas gradually into the old application.
First pick up a copy of Michael Feather's Working Effectively with Legacy Code. Then identify how best to test the existing code. The worst case is that you are stuck with just some high level regression tests (or nothing at all) and If you are lucky there will be unit tests. Then it is a case of slow steady refactoring hopefully while adding new business functionality at the same time.
In my experience, the "elegance" of an app typically has more to do with the database design than anything. If you have a great database design, including a well-defined stored procedure interface, good application code tends to follow no matter what platform you use. If you have poor database design, no matter what platform you use you'll have a very difficult time building elegant application code, as you'll be constantly compensating for the database.
Of course, there's plenty of room between great and poor, but my point is that if you want good application code, start by making sure your database is up to snuff.
This is harder to do in applications that are only in maintenance mode because it is hard to convince management that rewriting something that is already 'working' is worth doing. I would start by applying the principles of MVC to any new code that you are able to work on (ie. move business logic to something akin to a model, put all your layout/view code in one place)
As you gain experience with new code in MVC you can start seeing opportunities to change the existing code subtly so that it also falls in line. It can be a very slow process, but if you can show the benefits of this way of doing it then you will be able to convince others and get the entire team on board.
I would agree with the slow refactoring approach; for example, take that copy-and-pasted code and extract it into whatever the appropriate Java paradigm is (a class, perhaps? or better yet, use an existing library?). When your code is really clean and terse, yet still lacking in overall architectural strategy, then you'll be able to make things fit into an overall architecture much more easily.
Iteratively refactor. Also look for new features that can be done completely in the new framework as a way to show the value of the new framework.
My suggestion would be to find the rare pages that do not require an import of other JSPs, or have very few imports. Treat each JSP imported as a black box, and refactor these pages around them (iteratively, testing each change and making sure it works before continuing). Once these are cleaned up, you can continue finding pages with more and more imports, until finally you have refactored the imports.
When refactoring, note the parts that try to access resources not given to the page and try to take this out to a controller. For instance, anything that accesses the database should be inside a controller, let the JSP handle the display of the information the controller gives to it via a forward. In this way you will develop several servlets, or things like servlets, for each page. I would suggest using a front-controller based framework for this refactoring (from personal experience I recommend Spring and its Controller interface), so that each controller isn't a separate Servlet but is rather delegated to from a single servlet that is mapped appropriately.
For the controller, it is better to do database hits all at once rather than attempt them piecemeal. Users can and generally do tolerate a page load, but the page output will be much faster if all the database data is given to the rendering code rather than the rendering code hanging and not giving data to the client while it is trying to read yet another piece of data from the database.
I feel your pain and wish you luck in this endeavor. Now, when you have to maintain an application that abuses Spring Webflow, that's another story :)
The best way is to print out the code, crumple it up, and throw it out. Don't even recycle the paper.
You've got an application that is written in 1,000+ line long JSPs. It probably has a god-awful Domain Model (if it even has one at all) and doesn't just MIX presentation with business logic, it BLENDS it and sits there and keeps stirring for hours. There is no way to take out the code that is crappy and move into an MVC Controller class and still be doing the right thing, you'll just end up with a MVC app with an anemic domain model or one that has stuff like Database calls in Controller code, you're still failing.
You could try a new app that does the right thing and then have the two apps talk to each other, but that's new complexity in itself. Also you're likely going to be doing the same amount of work that you were going to do if you just started from scratch, but you might have an easier time trying to convince your bosses that this is a better approach.