Openwings Community Change Proposal #001

Proposal for Openwings Architecture Update

PDF version

Submitting Member: Guy Bieber, General Dynamics C4 Systems

Date: 3/28/01

Overview:

This document provides an overview of proposed architectural changes for evaluation by the Openwings Community and approval by the Openwings Process Management Organization (PMO).The PMO will receive feedback (through the Openwings mailing list) from the community for one week prior to voting on this issue. The changes are summarized below:

ITEM 1: Restructuring of Space Services
ITEM 2: Restructuring of Platform Services
ITEM 3: Movement of Data Service from Openwings core to Openwings Facilities.
ITEM 4: Update of top-level architecture diagram to reflect items 1 thru 3.
ITEM 5: Update of the supporting documents to reflect changes in items 1 thru 4.
ITEM 6: Re-issuing the OSRs for the following unformed expert teams: Context, Container, Data, and Management

Proposed Changes:

The proposed community changes are outlined below:

ITEM 1: Restructuring of Space Services

Description of Change:

The name “Space” has consistently been confused with “JavaSpace”. They are actually two entirely different things. The Openwings “Space” is related to the Service Oriented Programming (SOP) “Context” pattern. Hence, we propose renaming Openwings Space Services to Context Services. In addition the scope of the spaces specification was previously very large, covering discovery plug-ins (for discovery beyond the workgroup), network formation, software installation, and context configuration. We are proposing that this work be divided as follows:

Discovery service plug-ins should be moved to Component Services. The encapsulation of discovery is also one of the main jobs of Component Services, so plug-ins for service discovery naturally fit in there. The Component API actually provides a natural abstraction for service discovery plug-ins (such as .NET discovery, Bluetooth discovery, or web based discovery).
Installation of components should move into Install Services. This provides a more concise specification topic.
The remaining elements of network formation and context configuration fall into the Context specification. This specification describes the establishment of contexts for component deployment and how contexts can form relationships to share services. Again this provides a more concise specification topic.

Justification for Change:

The name “Space” is confused with “JavaSpace”.
The existing “Space” topics were too broad for a single specification.

ITEM 2: Restructuring of Platform Services

Description of Change:

The core service provided by a platform is a processing capability. This was previously represented by the Platform – Processing Services. To more closely map to the SOP model the name is being changed to Container. Functionally it does the same thing. The other Platform Services are being de-scoped for the following reasons:

Platform - Storage Service – There are industry efforts underway in the Storage Area Network markets to standardize and optimize access to network based storage. This effort would be redundant in light of the existing effort.
Platform – Printer Service – The current Java Printer API is sufficient to publish printing services. Hence this would be a duplicate effort.
Platform – Display Service – The sharing of displays can be handled through existing collaboration technology, hence this would be a redundant effort.

Justification of Change:

De-scope Platform Storage, Printer, and Display services due to existing efforts in these areas.Rename the Processing Service to map to the Openwings SOP model (container).

ITEM 3: Movement of Data Services out of the Openwings Core, into Openwings Facilities.

Description of Change:

This change moves Data Services from the Openwings core to Openwings Facilities.Openwings facilities provide an optional part of the framework that vendors need not implement to be compliant. It is expected that other useful services defined by the community may be added into the Openwings Facilities. This does not affect the implementation or scope of the data services effort.

Justification of Change:

The core service-oriented programming model does not depend on data services.In fact data services is built entirely on top of the core framework. Hence, moving it from the core to facilities makes sense.

ITEM 4:Update of Top Level Architecture Diagram to reflect changes from items 1-3.

Description of Change:

The following is the proposed new top-level architecture diagram:

Justification of Change:

This change is being made to reflect changes in items one thru three of this document. The new diagram more closely matches the SOP model proposed by Openwings.

ITEM 5: Update of supporting documents to reflect changes from items 1-4

Description of Change:

The following document updates are driven by items 1-4.

Openwings White Paper – Update this document to reflect the changes in this document and the latest thought on the Openwings project.
Introdution to Service Oriented Programming – Update the top-level Openwings drawing and discussion.
Architecture Overview – Update top-level architecture and service descriptions to reflect the changes in this document.
Community Overview – Modify the name of the Spaces team and rewrite the team description. Modify the Platform Services name and rewrite the team description. Update Component Services to reflect the re-allocation of Spaces discovery plug-in functionality.
Openwings Technical Overview – Update with architecture changes and latest design work.
Openwings Executive Overview – Update to reflect architecture changes described in this document.

Justification of Change:

This also provides an opportunity to provide the latest technical content.

ITEM 6: Re-issuing the OSRs for the following unformed expert teams: Context, Container, Data, and Management

Description of Change:

This will open the call for experts for context services (formerly spaces), data services, container services (formerly platform processing services), and management services.

Justification of Change:

These expert teams have not been formed yet or require scope changes as a result of this document.

To comment on this proposal, please send email to owings1@gdc4s.com.