> In addition to Rickard's response to this point, remember that Bean
> Provider and Application Assembler are two distinct J2EE roles: just
> because a one provider gives me a Customer bean and another an Order
> bean doesn't mean I don't assemble them into one jar.
Ahh, this is the one that I didn't think about (maybe because we
currently have both these roles in our organization :-)
> Generally a developer (Bean Provider) would go through modify-test-debug
> cycles in a test environment where they'd deploy the one bean they're
> working on. From there it would move to an integration test environment
> where it would be packaged into the full application jar (actually it
> really ought to be an ejbjar in a .war file). The roll into integration
> test is probably an automated weekly build.
>
> Organizations that have been building large systems with large teams for
> any length of time will have automated the build and roll into
> integratioin test long ago: EJB just adds a few wrinkles (well, a lot of
> wrinkles, since some vendors haven't implemented command line deployment
> tools, which makes a scripted deploy a wee bit difficult)
>
True. Although I'v seen large organizations building large applications
totally manually without any automation (or even without version
control)
but that's their problem.
This discussion has been very helpful for me - I'm currently working
for a company that has quite large java-based process-industry
applications
which are built on custom multi-tier jdbc-based framework. What I'm
trying to
do is to push development and deployment to EJB models (which I hope
will happen
some day in near future). However, sometimes the existing work model
makes it difficult to see obvious things.
Ari S.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
