Re: Business Component Reuse

[William W. Lee]

I have many comments considering this is what we do... creating reusable
business application components with EJB.

First, I have to disagree with the statement "An application is a component".
An application is NOT a component. An sh.exe is not a component.
libX11.a is not a component. libX11.a is a X11 library.

To us, a component is something that provides the user with 50% (or more) of the
funtionalities. It is not supposed to give the user exactly what he/she wants.
A component has the flexible ability to allow for extensibility, and configuration
in both development time and runtime. This definition of component is far more
difficult to realize. One may need to use patterns like "Individual Instance
Method" (M. Fowler) to provide plugable methods. Most applications developers
focus on building the application. They don't usually have the time and
resources to create reusable componets. For example, Fortune-Company-#200 stays
competitive by bringing new/custom business services to their customers/partners
as quickly as possible. Chances are these custom business services cannot be
bought as a pre-package application. Creating reusable components is difficult
and not everyone can do it especially given time constraint. Like you said,
many companies creates reusable frameworks and initiatives that ultimately were
never used.

IF THERE IS NO USE, THERE IS NO REUSE.

"Models are never right or wrong, they are more or less useful" Components are
similar. We believe that in order for components to be useful, they have
to be reuseable. Here are some key points:

- Components will need to interact with each other with a set of design patterns
to solve some generic business problems.
- Component vendors should not _FORCE_ application developers to use a
large framework. Components are NOT frameworks. Otherwise you are with a car
if you only want to buy 4 tires!
- Components must be flexible. Components can be extended or configured to work
outside of the original business domain. If a component is an application,
this statement will never be true. Extensions and configurations can be done
during modelling, design, code or runtime.

I can go on, but that's all for now...

Will

ps. To see components in action, see us at JavaOne.

-------------------------------------
William Lee, Chief Technology Officer 1.617.573.5099 (Voice)
The Theory Center 1.617.262.0703 (Fax)
28 State Street, 11th Floor [EMAIL PROTECTED]
Boston, MA 02109 http://www.theorycenter.com
-------------------------------------

At 06:09 AM 5/17/99 -0500, 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?
>
>Jim Frentress 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.
>>
>> I hope this isn't yet another fault in my crack-ridden capabilities. One has
>> only to look at the work of groups such as Rosetta.net, XML/DTD in general,
>> EDI, CrossWorlds, and ERP vendors to see that reuse is important but
>> elusive. As another poster (ok Imre) said, it turns out that there is some
>> "public" data and some "private" data in systems he's been involved with (he
>> used it in another context but the idea holds here too). I've found the same
>> to be true and apparently that's because there is no one definition (view)
>> of anything. It also turns out that the truly "public" or sharable data is a
>> small fraction of the "private" data. I usually refer to the difference as
>> fixed and variable attributes but the problem remains.
>>
>> So, what are the prospects of reusable business domain components (note that
>> an application is a component). The current rush to outsource entire
>> applications makes this reuse even more critical, but I've seen no good
>> solution to it. Every integration effort I've seen has either duplicated
>> data in disparate systems or modified the underlying systems so they were no
>> longer truly decoupled.
>>
>> ===========================================================================
>--
>Richard Monson-Haefel
>Senior Consultant
>BORN Information Services
>
>Author of Enterprise JavaBeans
>Published by O'Reilly & Associates
>(Available June 1999)
>
>===========================================================================
=========================================================================== 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".