Openwings Context Specification Request

Openwings Specification Request (OSR)

Title:

Openwings Context Services (OSR_004)

Summary:

The Context Expert Team focuses on providing a secure, available context for system formation and service discovery.

Section 1. Identification

Submitting Member and Specification Lead:

	Submitting Member	Specification Lead
Name of Contact	Guy Bieber	Guy Bieber
Telephone Number	1-480-441-7692	1-480-441-7692
Fax Number	1-480-441-2304	1-480-441-2304

Expert Nominee Qualifications:

Candidate for this expert team should have the following qualifications:

Experience with the Java2 platform (mandatory requirement).
Understanding of network formation technology (Dynamic Host Configuration Protocol - DHCP, Domain Name Service - DNS, MobileIP, ZeroConf, related IETF RFCs).
Understanding of installation technology (Webstart, Open Service Gateway Initiative - OSGI).
Understanding of gateway technologies (OSGI, Microsoft Net).
Understanding of network security and container security (firewalls, code security).
Understanding of management.
Understanding of discovery technology (Jini, Upnp, Chai, Ninja).
Understanding of Naming and Search Technology (Web Search Engines, Lightweight Directory Access Protocol - LDAP).

Section 2: Request

2.1 Please describe the proposed Specification:

The Context Expert Team focuses on providing a secure, available context for system formation and service discovery. It is the job of the context to provide the core services required for self-forming and self-healing systems. The context service provides the environmental information for components to execute. The static part of this is delivered at installation time. Other information is delivered at runtime through the context service. The context service keeps the core services necessary for system formation running, through use of the container services. These include network services, discovery services, security services, management, network formation, and install services. The install services provide for zero interaction installation, dependency resolution, and policy resolution. In addition the install service can act as an application server to deliver services software to the network.

The Context Expert team will be responsible for developing the following:

Context Services Specification.
Context Services Reference Implementation
Context Services Compatibility Test Suite.
Install Service Specification.
Install Service Reference Implementation
Install Service Compatibility Test Suite.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

J2SE is largely targeted towards desktop and webtop applications on the front end. J2EE is largely targeted towards E-Commerce and back end servers. J2ME is targeted towards the device market. This specification has a system focus on networked components, which includes the front end, back end, and devices; hence this specification targets all three Java platforms. The J2ME configurations to be considered should go down to the CDLC configuration.

2.3 What need of the Openwings community will be addressed by the proposed specification?

A specification that implements context pattern for Service-Oriented Programming (SOP) does not exist.

2.4 Why isn't this need met by existing specifications?

No other specification covers context services in Openwings.

2.5 Please give a short description of the underlying technology or technologies:

The context services configure and run many of the other openwings services. These include containers, install, discovery, network, security, and management services. The install services use the JVM and policies. The network services use DHCP, DNS, VPN, and Network Address Translation.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The proposed package for this specification is net.openwings.context.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current Openwings security model?

No.

2.9 Are there any internationalization or localization issues?

This OSR is targeted towards systems that may be internationally deployed and hence use the internationalization features of Java. It is anticipated that the existing internationalization infrastructure will be sufficient for this OSR.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.

2.11 Please describe the anticipated schedule for the development of this specification.

Currently a draft specification exists as a contribution and starting point. The following schedule applies:

Milestone	Date
Openwings Specification Request Approved	04/06/2000
Form Expert Group	05/11/2001
Participant Draft	TBD
Participant Review	TBD – 2Q 2001
Public Review	TBD – 2Q 2001
Beta Release	TBD – 3Q 2001
Maintenance	TBD

Once the expert team is formed the finalized schedule will be made available.

Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology.

The Motorola IISG (now General Dynamics C4 Systems)/Sun Openwings team, has previously generated work that is being contributed as a basis for this OSR. In particular the following contributions available at http://www.openwings.org/download.cfm#specs are relevant.

Openwings White Paper
Openwings Naming Specification (Alpha version 0.7)
Openwings Architecture Specification (Alpha version 0.7)
Openwings Interface Specification (Alpha version 0.7)
Openwings Availability Specification (Alpha version 0.7)
Openwings Security Specification (Alpha version 0.7)
Openwings Component Services Specification (Alpha version 0.7)
Openwings Management Specification (Alpha version 0.7)
Openwings Policy Specification (Alpha version 0.7)

In addition to these draft specifications an alpha reference implementation of connector services, component services, management services, and polices are being contributed.

3.2 Explanation of how these items might be used as a starting point for the work.

The existing specifications will serve as the starting draft for the specifications produced under this effort. The space specification provides an initial outline and content for the specification.

Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the OSR.

None.