For the Generico case, the name "blueprints" was derived from the J2EE
"Petstore" blueprints. The Middleware Company had worked extensively
with the petstore, frequently performing productivity studies for
vendors. I guess you can say the usage of blueprint in the petstore
case was to provide a sample application that best illustrated the use
of J2EE (i.e. exercising all the features). I would suspect we want to
define it with more scope for this TC.
On 11/21/05, Ken Laskey <> wrote:
> I have not been following the email carefully enough, so forgive me if this
> has already been established but
>
> 1. Exactly what is a blueprint?
> 2. What purpose does it serve?
> 3. Why should I think one will be generally applicable?
> 4. Why do I care?
>
> Do we expect that a blueprint will be a sort of turnkey formula? How do we
> determine the limits of applicability for a given blueprint? Are there
> underlying assumptions that all blueprints have in common, or is each
> blueprint fundamentally different (a very possible construction), or are
> there fundamental groupings with multiple non-redundant examples in each
> group?
>
> I think agreeing on a clear strawman definition of blueprint is essential.
> It can be modified as we learn more but we need a clear starting point.
>
> Ken
>
>
> On Nov 21, 2005, at 9:12 PM, <>
> <> wrote:
>
>
> One question to pose to the group is maybe the case study actually becomes a
> type of primer for the blueprints once the blueprints are defined.
>
> Thoughts?
>
> Dan
>
>
>
>
>
> ---
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-983-7934
> 7515 Colshire Drive fax: 703-983-1379
> McLean VA 22102-7508
>
>
>
>
