Re: Business Component Reuse

[Chris Ferris - Enterprise Architect - EMA]

One of the major reasons why business object reuse hasn't
caught on is that well defined interfaces to these components
haven't been developed. EJB defines an interface to application
server functionality without exposing the implementation details
(much;-) allowing application server vendors to compete on the
merits of their implementation w/r/t performance, scalability, etc.
while leaving component providers free from having to "port"
their components to each vendor specific (can you say
pro-pri-et-ary? I knew you could...) implementation API.

Note that this actually increases each application server vendor's
potential market because they are no longer excluded from
competing for business where a previous vendor laid claim because
it precludes the requirement for a complete rewrite of the
application.

Note that it is the common _interface_ which enables this. If
component providers were to agree to standard interfaces for
their business components then, and only then, will business
component/object reuse become a possibility, enabling application
assemblers the freedom to select the best implementation of
a given component interface and opening up potential markets
for component providers.

One last point is that only recently, in my experience, have
traditional application vendors caught on to the fact that
while they may be able to sell the business customer on the
flashy functionality they provide, they must also sell the
IT department on their flashy EAI features which enable the
integration of the application into the hairball of legacy add-on
systems which have grown out of, into and around the application
which is to be replaced. Thus, business component providers should
(IMHO) build similar EAI capabilities into their implementation.
This will help open doors to the potential for business component
reuse.

The one with the best implementation wins.

Chris

Steve Demuth wrote:
>
> With a very few exceptions, this parallels my experience.  Business
> components don't get re-used in my experience for two reasons:
>
>   1) My clients are trying to distinguish themselves from their competitors
> by being better, or at least different.  This leads inevitably to
> specializations which the general purpose business component creator
> usually didn't anticipate.
>
>   2) Clients won't change the way they have historically done things, even
> if a general purpose component might help.  People get attached to special
> purpose functionality, and will veto a lot of good ideas which might cost
> them small bits of customization from the past.  This leads frequently to
> requirements that new systems be backward compatible in detail with older
> systems, at great cost to the idea of basing them on re-usable general
> purpose components.
>
> In theory, of course, a good business component should be able to cope with
> these problems by being extendable.  Unfortunately, many "custom" business
> rules rely on relationships which don't exist in general-purpose models, or
> other features which are not easily added.
>
> All of which is discouraging, but sure keeps the application programmer's
> of the world employed.
>
> At 06:49 PM 5/16/99 -0700, you wrote:
> >What is the experience out there regarding the reuse of Business Components,
> >particularly distributed components? My experience has been that systems
> >level stuff can be componentized and reused (an example is EJB). However,
> >when it comes to domain objects, reuse has largely eluded me. I have yet to
> >completely or even largely reuse a Customer, Partner, Address, Phone, or
> >other business object. When I refer to reuse, I really mean reuse outside of
> >a business domain. No points will be awarded to solutions demonstrating
> >reuse within a tight domain.
> >
>
> Steve Demuth
>
> Artemis Alliance, Inc.          An Inprise Premier Partner
> 289 East Fifth St, Suite 211
> St. Paul, MN 55101              [EMAIL PROTECTED]
> 651-227-7172 or 319-382-0593
>
> ===========================================================================
> 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".

--
    _/_/_/_/ _/    _/ _/    _/ Chris Ferris - Enterprise Architect - EMA
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: [EMAIL PROTECTED]
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

===========================================================================
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".