Index Changes
This is version 3. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Cross Product Features

This information is 
Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know
Copyright 2006 Sun Microsystems

1. Introduction
   1.1. Project/Component Working Name:

	Cross Product Features for JBI Binding Components

   1.2. Name of Document Author/Supplier:

	Alexander Fung: afung@dev.java.net

   1.3. Date of This Document:

	28th March 2007

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:
		// This should match the spelling used in PLCtool, as this will be
		// used to cross-reference the information
	1.4.2. The ARC(s) you expect to review your project:
		// Leave blank if you don't have any preference
		// This item is advisory only
	1.4.3. The Director/VP who is "Sponsoring" this project:
		// John.Doe@Sun.Com
	1.4.4. The name of your business unit:
		// SSG, Software, ...

   1.5. Email Aliases:
    	1.5.1. Responsible Manager: 
    	1.5.2. Responsible Engineer: afung@dev.java.net
    	1.5.3. Marketing Manager:
	1.5.4. Interest List:

2. Project Summary
   2.1. Project Description:

	This project intends to provide a set of cross product features for JBI
	Binding Components.  JBI Binding Components often face a similar set of
	problems regarding security, integration with third-party components,
	and general systemic qualities.  This project seeks to capture these
	problems and formulate a common solution for use by all JBI Binding
	Components.

   2.2. Risks and Assumptions:

	The success of this product relies somewhat on the adoption of these
	techniques by other Binding Components.  We will need to work well
	with developers of other Binding Components so that they can
	incorporate these ideas into their code.

3. Business Summary
   3.1. Problem Area:

	There are several key problems we want to address through this project.
	They include (but are not limited) to the following:
	
	1. Security Context propagation.  We must define how we handle security
	contexts that are passed from one JBI Component to another.  There must
	be some semantic understanding of what to do with security contexts.

	2. Integration with software and hardware products.  We need to solve
	how JBI Binding Components might leverage third-party software and
	hardware products.  Some examples of this is the Sun Access Manager and
	the Cascade Service Gateway.

	3. Systemic qualities.  Each Binding Component has to deal with a core
	set of qualities such as performance, reliability, and administration.
	This project will seek to provide guidelines on measuring these qualities.

   3.2. Market/Requester:

	Two core requesters have pushed for this project.  SUN Product Management
	has requested the integration and interoperability solutions.  Internal
	architects have requested solutions to the systemic qualities.

   3.3. Business Justification:
	// Why is it important or valuable to do this project?
	// Include monetary estimate and precision.

   3.4. Competitive Analysis:
	// Who are the current and anticipated players in this market?
	// How/why will we succeed when competing with them?

   3.5. Opportunity Window/Exposure:
	// Time-to-market window, if any, and precision.

   3.6. How will you know when you are done?:
   	// What will you measure to determine that the project is complete?
	//
	// This section is for explicit measurable customer CTQs that apply
	// to this specific feature proposal, not to the product as a whole.
	//
	// We *expect* every development team to meet their Feature,
	// Performance and Security and Testing goals, as well as getting
	// all required ARC and PAC review approvals, so don't put that
	// sort of metric here.




#ifndef HALF_PAGER	// A Half Pager stops at this point

4. Technical Description:
    4.1. Details:
	// To the extent known, how is this going to be done?
	// If the source of implementation technology is external to Sun,
	// identify them here, too.
	// This information is used by the CPT's to get a feel for the
	// complexity and risk involved, and by the ARC's to help understand
	// the architectural constraints that this project is working
	// under.  Try to present alternatives and show relationships to
	// existing or proposed projects/standards.

    4.2. Bug/RFE Number(s):
	// List any bug/rfe's which will be addressed by this proposed
	// change.
    
    4.3. In Scope:
	// Aspects that are in scope of this proposal if not obvious from
	// the above.

    4.4. Out of Scope:
	// Related aspects that are out of scope for this proposal if not
	// obvious from the above.
    
    4.5. Interfaces:
	// What interfaces are introduced, modified or deleted by this
	// proposal?  What interfaces does it import and export?  What are
	// the new exported interface's stability levels?
	// See http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp
	// (Think of Files/directories, Ports, DTD/Schema, admin tools and
	// config files, APIs, CLIs, etc, as well as incompatible or
	// unexpected changes that may affect consumers and/or customers)
    
    4.6. Doc Impact:
	// List any Documentation (man pages, manuals, service guides...)
	// that will be impacted by this proposal.
    
    4.7. Admin/Config Impact:
	// How will this change impact the administration of the product?
	// Identify changes to GUIs, CLI, agents, plugins...
    
    4.8. HA Impact:
	// What new requirements does this proposal place on the High
	// Availability or Clustering aspects of the component?
    
    4.9. I18N/L10N Impact:
	// Does this proposal impact internationalization or
	// localization?
    
    4.10. Packaging & Delivery:
	// What packages, clusters or metaclusters does this proposal
	// impact?  What is its impact on install/upgrade?
    
    4.11. Security Impact:
	// How does this proposal interact with security-related APIs
	// or interfaces?  Does it rely on any Java policy or platform
	// user/permissions implication?  If the feature exposes any
	// new ports, listeners, or any similar communication points
	// which may have security implications, note these here.
    
    4.12. Dependencies:
	// List all dependencies that this proposal has on other
	// proposals, components or products.  Include interface
	// specifics above in the interfaces section; list component
	// version requirements here.

5. Reference Documents:
	// List of related documents, if any (BugID's, RFP's, papers).
	// Explain how/where to obtain the documents, and what each
	// contains, not just their titles.  Identify any related projects
	// (by ID or case number, if possible).

6. Resources and Schedule:
   6.1. Projected Availability:
	// Dates in appropriate precision (quarters, years)

   6.2. Cost of Effort:
	// Order of magnitude people and time for the *whole* project, not
	// just the development engineering part.
	// You may wish to split the estimate between feature
	// implementation, implementing adminsitrative Interfaces, unit
	// tests, documentation, support training material, i18n, etc.
	

   6.3. Cost of Capital Resources:
	// Order of magnitude.

   6.4. Product Approval Committee requested information:
   	6.4.1. Consolidation or Component Name:
	6.4.3. Type of CPT Review and Approval expected:
		// Pick one of
		//   Standard
		//   FastTrack
		//   BugFix or RFE
        6.4.4. Project Boundary Conditions:
		// Give the document's URL  http://....
	6.4.5. Is this a necessary project for OEM agreements:
		// if Yes, give references
	6.4.6. Notes:
		// See dependencies section above.
	6.4.7. Target RTI Date/Release:
		// List target release & build and/or date.
		// RTI = Request to Integrate - when does *this* project
		// expect to be ready to integrate its changes back into
		// the master source tree?  We are not asking when the
		// component wants to ship, but instead, when the
		// gatekeeper/PM needs to expect your changes to show up.
	        // examples: S8u7_1, S9_45, Aug 2002...
	6.4.8. Target Code Design Review Date:
	6.4.9. Update approval addition:
		// Did this project have prior Solaris PAC approval for a
	        // Marketing Release and now your requesting to go into an
	        // Update Release or Early Access CD?

   6.5. ARC review type:
   		// Pick one of
		//   Standard
		//   FastTrack
		//   SelfReview

7. Prototype Availability:
   7.1. Prototype Availability:
	// Functional subset expected to be needed to leave "prototype"
	// stage.

   7.2. Prototype Cost:
	// Subset of Cost of Effort to leave "prototype" stage.

#endif

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This particular version was published on 28-Mar-07 16:10 PM, -0700 by Alexander.Fung