WCOP'98

Motivation

WCOP'98 follows the highly successful WCOP'96 and WCOP'97 events, which took place in conjunction with ECOOP'96 and ECOOP'97, respectively. COP has been described as the natural extension of object-oriented programming to the realm of independently extensible systems. Several important approaches have emerged over the recent years, including CORBA, COM (COM+, DCOM, ActiveX, DirectX, ...), JavaBeans (including Enterprise JavaBeans).

After WCOP'96, focusing on the fundamental terminology of COP, and WCOP'97, expanding into the many related facets of component software, WCOP'98 shall concentrate on those software architecture aspects of component-software that directly affect the actual design and implementation, ie, programming of component-based solutions. In particular, a focus on component frameworks, as introduced below, is suggested.

COP aims at producing software components for a component market and for late composition. Composers are third parties, possibly the end user, who are not able or willing to change components. This requires standards to allow independently created components to interoperate, and specifications that put the composer into the position to decide what can be composed under which conditions. On these grounds, WCOP'96 led to the following definition:

• A component is a unit of composition with contractually specified interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties.

A problem discussed at length at WCOP'97 are non-functional requirements. Another key problem that results from the dual nature of components between technology and markets are the non-technical aspects of components, including marketing, distribution, selection, licensing, and so on. While it is already hard to establish functional properties under free composition of components, non-functional and non-technical aspects seem quickly beyond controlability.

One promising key approach to establishing composition-wide properties of functional and non-functional nature is the use of component frameworks. A component framework is a framework that itself is not modified by components, but that accepts component instances as "plug-ins". A component framework is thus a deliverable on its own that can enforce (sub)system-wide properties of a component system. As such, a component framework is sharply distinct from application frameworks that are subject to (partial) whitebox reuse and that do not retain an identify of their own in deployed systems.

Topics

• design methods for component frameworks
• interoperation among component frameworks
• properties, function, non-functional, or even non-technical that can or that cannot be established by a component system architecture based on (tiered) component frameworks
• use of selected component frameworks to reduce the set of possible components in a market setting
• impact of component frameworks on independent evolotion of components and component-oriented systems
• domain-specific standards for component interoperability and their impact on component frameworks and component framework design
• dynamic changes in the configuration (set of components in a system): how can components be added, replaced and removed and how can other components reconfigure themselves to cope with this
• adaptation of components and composition of frameworks
• programming language support for COP and component frameworks in particular
• performance/efficiency of component-oriented implementations and effects of component frameworks introducing a level of indirection
• impact of businesses on components and vice versa, packaging and distribution of components and component frameworks
• criticism of the suggested component framework approach

Submissions and Participation

Important Dates:

• Paper submissions: 8 May 1998
• Notification of acceptance: 29 May 1998
• Workshop handouts ready: 30 June 1998

Workshop Co-Organizers: