How to develop a modular enterprise application using just GWT

Hi I want to design and develop a big enterprise application using just GWT in client side. I want to break this enterprise application into parts and I call each of them a module (or bundle or portlet or whatever!). These modules might have relation with each other and might call some services that exists in other modules (in both client and server side).

The problem is, These modules must be Designed , Developed, Compiled and Deployed Independently and Dynamically and they will be placed and shown together in one context on t开发者_如何学运维he client and the dependencies between modules should be manageable (in both client and server side).

What can I do? What kind of technologies I can use to build an enterprise application like this?

When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.

In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!

Of course I have searched about the way that I can solve my problem!!! I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know! And I have found that I can use Gadgets on client side.

What do you think? Are they good choices?

If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?

How GWT and OSGi can be integrated? How can they interact with each other?

Unfortunately what you want to do is not fully possible with GWT.

OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.

A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.

However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.

As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.

As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.

I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.

Verdict: Don't do it unless you really must.

In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.

The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.

Now the other pain: project explosion.

Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.

Finally, JSON interfaces.

We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.

So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.

I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.