This is a funny discussion and the sort that randomizes otherwise
hardworking people. Reuse is an ongoing evolution (for all of us, as a
group)- the simpler, more generally well understood "commodity" objects are
easier to reuse, while the complex, "branded" niche objects are difficult to
reuse. Does anything really more need to be said?
Actually, more always does need to be said. Especially with regards to the
reuse of design patterns versus the reuse of instantiated classes. Perhaps
once we've solved that former problem, we should start worrying about object
reuse .. (or is it the other way around? ;)
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, May 18, 1999 12:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Business Component Reuse
>
> I'd like to try to clear up what I believe are a couple of misconceptions
> regarding
> 1) IBM SanFrancisco and 2) business component reuse:
>
> SanFrancisco is layered to allow application developers to use its
> infrastructure
> and common business objects separately from its domain-specific financial
> and
> logistics frameworks. The Common Business Objects (CBO) layer of
> SanFrancisco
> has
> captured numerous cross-domain business objects representing currencies
> and
> exchange
> rate conversions, company structures, various calendars (both natural and
> period-based),
> number series generation, and payment calculation (including installments
> and
> discounts),
> among others. A user guide documenting these business objects can be
> downloaded
> from http://www.software.ibm.com/ad/sanfrancisco/library.html.
>
> Applications using SanFrancisco have been successful in achieving business
> object
> reuse outside of a specific domain. For example, Front Ends Incorporated
> (http://www.frontends.com) has successfully built a health care
> application on
> top of
> SanFrancisco using common business objects such as NaturalCalendar,
> Currency,
> Address,
> and Company among others, even though these business objects were
> developed from
> initial
> requirements extracted from the financial and logistics domains. These
> business
> objects
> have the right attributes and behaviors to make them reusable because they
> were
> developed
> within the context of use cases defined by experienced application
> developers.
> That said,
> we took pains during development to properly isolate the common
> characteristics
> of a
> business object from its domain-specific characteristics. For example, the
> SupplementaryCharge
> business object introduces the capability to define charge types with
> various
> calculation
> mechanisms (e.g., fixed fee, charge based on weight or value). This
> business
> object can
> be used wherever a need to represent free-form charges occurs within an
> application. The
> SanFrancisco logistics framework extends this business object to
> incorporate it
> into
> various order types such as a sales order.
>
> Business component reuse is possible, and applications built on top of
> SanFrancisco are
> living proof of this.
>
> Richard Monson-Haefel wrote:
>
> > I agree with Jim completely. Business component reuse seems to be more
> myth
> > than reality. I can not imagine, given my project experience in several
> > different domains, how an off the self business component could be
> reused
> across
> > industries or even business within the same industry. Domain models from
> one
> > business to the next are very different, not to mention persistence
> > requirements. The only exception, of course, is if the component is
> part of
> > larger framework. IBM San Francisco is an example where there is reuse,
> but
> in
> > this case you have to purchase the whole thing including the vertical
> tower
> > specific to your domain.
> >
> > How successful has MTS been in this area?
>
> Regards,
>
> Brent Carlson
> Chief Architect
> San Francisco Project -- Application Business Components
>
> ==========================================================================
> =
> 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".
