What would be ideal is a light weight, non-distributed EJB server/container
that runs In The Client JVM!
Since we don't have this today, and since the integrated environments are
immature ( I have heard this from our customers too...), you might consider
some design patterns that eliminate EJB'ness during development. In the
GemStone/J Developer's Guide, the domain objects are not-EJB's. EJB's wrap
them for deployment. So one could develop, test and debug prior to wrapping
as beans and deploying to EJB.
There is also a design pattern for this approach on java.success.com. It is
admittedly incomplete, but it's not a bad start.
-Chris.
> -----Original Message-----
> From: Humphrey Sheil [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, July 11, 2000 12:57 PM
> To: [EMAIL PROTECTED]
> Subject: MI2: Strategies to reduce EJB development time?
>
> I've been trying to improve this for a while and I've come to the
> conclusion
> that beyond doing what I've listed below, there isn't anything else
> possible
> to reduce the net amount of development time required in the EJB world at
> present.
>
> So the problem is that our code->build->deploy->test cycle is taking too
> long, especially for impatient developers who are new to the distributed
> component model. We've been using javabeans / Servlets and jsps on
> e-commerce apps. prior to adopting a fully-fledged J2EE architecture and
> as
> you can all imagine, although it's not as powerful, it's a hell of a lot
> faster to develop in.
>
> Here are some of the things I've been looking into to mitigate the
> problem.
>
> 1. Hot deploy of EJBs when supported by app. servers. Instead of having
> to
> bounce the server, instead redeploy your EJBs.
>
> 2. Invest in an IDE with a dynamic class loader to reload changed classes
> (e.g. Visual Age).
>
> The problem with both approaches above is that any changes to either the
> home or remote interfaces (method names, params, throws clause etc.) or
> referenced support classes (usually value objects) means that you still
> need
> to stop, rebuild and restart. In my experience, this accounts for a large
> part of the time when I want to hot deploy anyway!
>
> Even given that I've met the restrictions above, if I want to be sure that
> an exception I'm getting is my fault and not the hot deploy feature or
> funky
> IDE classloader, I'll bypass them and bounce the server anyhow (do you
> have
> 100% faith in your hot deploy feature or IDE?)
>
> I'm not worried about having to hot deploy gracefully to a production
> system
> (that's a whole other problem in itself), my only concern is speeding up
> the
> development cycle.
>
>
> 3. Use jikes to reduce the build cycle time - I haven't seen any great
> reduction in time here.
>
> Are there any design patterns, rules of thumb, howtos etc. that I'm
> missing
> which are applicable here? I had thought of building business logic first
> as a regular Java class and then moving over to an EJB approach when the
> class does what I want, but I feel this will lead to headaches later on
> down
> the line as you have to add in the EJB plumbing (JNDI lookup, etc. etc.)
> Plus, divorcing what I want (business logic) from how I get it (the EJB
> model) doesn't make that much sense (at least not in our world at
> present).
>
> On the subject of IDEs, I've evaluated most if not all of the IDEs
> promising
> tight integration with various app. servers and I find them all unstable
> enough that when something goes funny in development (especially if I'm
> building on more than a couple of EJBs), the first thing I do is close
> down
> the IDE, bounce the app. server and start from basics myself so I don't
> think they're good enough to address this problem yet.
>
> I'm interested in hearing about other folks best practices on this
> subject.
>
> Humphrey
>
>
> PS If anybody else wants to get into the steel building market for
> peanuts
> let me know, I think we can beat the guy down if we go for a bulk
> purchasing
> strategy.
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
