Subsystems may have as many interfaces as necessary. I would certainly NOT 
recommend one per client, but it is usually possible to group clients into 
areas of common interest. For example, a subsystem might have a functional 
interface (providing the major functionality of the subsystem), a control 
interface (which sets how the subsystem should operate), and a management 
interface (for maintenance and updates), or you may find that you need 3 or 
4 functional interfaces. Probably not significantly more than that though. 
The interfaces of a component or subsystem should be owned by the 
developers of that subsystem or component, but are specified in negotiation 
with the customers or clients of that interface.

At 11:08 AM 11/20/2001 -0500, Gibbs, Dennis wrote:
>         Greetings,
>
>         A topic of discussion has come up on a project I am working on.  It
>concerns subsystem component
>         architecture, and subsystem interfaces.  In discussing this topic,
>we discovered all of us have
>         widely differing perspectives and experiences :-)
>
>         Background:  We are trying to come up with a solid architecture for
>a fairly large system.
>         The system is a web-based system implemented in J2EE.  We want to
>create a component-based
>         architecture.  The system has ten separate business areas that will
>be designed and built over the
>         next 4 years.  The ten business areas will utilize the shared
>services of several components
>         that we refer to as "common components".  The controversy involves
>the definition of the interfaces
>         to these common components.  The questions are:
>
>         1) How many interfaces (JAVA) should a shared common component have?
>
>         In UML, subsystems are usually represented with one interface class
>and one proxy class that implements the interface and then delegates
>functionality to other hidden classes within the component/subsystem. In our
>case, the clients may ask for component functionality particular to them.
>
>         2) Does this warrant a separate interface for each different client
>therefore hiding the functionality not relevant to them?
>
>         3) If so, should the interfaces all have separate proxy classes?
>
>         Another scenario is that the client asks for a particular object
>from the component, and then performs operations on it before giving it back
>to the component to store to the database.
>
>         3) Should the client be given the object, a separate interface to
>operate on that object, or not be given the object at all and always be
>working through one standard interface?
>
>         4) If the client is given the interface, should this interface also
>have a proxy class inside the component that implements it?
>
>         5) If the client is not given the object, could there be performance
>issues related to not having the object locally?
>
>         6) Who owns the interfaces - the client developers developing
>against them or the component developers implementing them?
>
>         Comments? Advice/suggestions?
>
>         Thanks for any help
>
>         Dennis
>
>
>-----------------------------------------------------------------
>To unsubscribe from OTUG, send an email to [EMAIL PROTECTED]
>with the word 'unsubscribe' in the body of the message.

************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages: http://www.rational.com/support/usergroups/rose/rose_forum.jsp
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************

Reply via email to