DRAFT PROPOSAL - Pattern Oriented Framework

[David S]

DRAFT PROPOSAL
Pattern Oriented Framework for the rapid implementation of Java applications
                               
1. Summary
----------
This proposal describes a Pattern oriented Framework for the rapid implementation
of Java applications. This integrated framework is based on a messaging architecture
which provides strong encapsulation and loose coupling; framework components can be 
easily and interchangeably plugged into complex framework applications using a “lego" approach. 
This framework is envisioned to provide capabilities for the implementation of applications 
based on design patterns. The framework itself is conceived, from the ground up, 
based on design patterns. 
The main goal of this project is to provide a complete reference implementation of
the proposed framework.

2. Goals
--------
The framework should address the following goals:

A) The pattern oriented framework should implement and/or facilitate the implementation of 
well-known design patterns like GoF design patterns and  J2EE Design patterns. The framework 
itself  should be conceived and implemented based on design patterns (from the ground up). 
The framework should also facilitate and accelerate the implementation of applications 
based on design patterns.
B) The framework architecture should be based on a messaging design pattern: framework objects 
should be able to interchange information and perform computations by sending, receiving and 
processing messages. A messaging API provides strong encapsulation and loose coupling; 
framework components can be easily and interchangeably plugged into complex framework applications 
using a “lego/messaging” architecture. The framework should take full advantage of the power 
and simplicity of the messaging design pattern.
C) The framework lego/messaging architecture should provide transparent access to remote components: 
remote framework objects should be treated as local objects. Design patterns implemented by the 
framework (adapters, remote proxies and facades) should make this possible by hiding the complexities 
associated with remote APIs. 
D) The framework should provide transparent integration with other technologies via framework 
adapters, proxies and the implementation of related design patterns. These technologies include BPM,  
DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services.  
E) The framework should be designed to be lightweight and fast in terms of performance 
(very low overhead).
F) The framework messaging/lego architecture should improve and simplify design/development efforts. 
There should be a tight correspondence between UML design diagrams and the framework messaging based 
applications and components needed for the implementation. Ideally, the framework should provide 
wizards and automated capabilities for generating framework applications. Framework components 
should be easily added to BPM process diagrams. In future versions of the framework, it should 
be possible for applications to be generated directly from the UML design diagrams.  
G) The framework  messaging architecture should facilitate testing and debugging efforts. 
The framework should provide capabilities for testing components independently (each component as a unit) 
by sending messages and verifying the reply (output) messages.
 
H) In order to provide additional productivity, the framework should be integrated 
with open source IDEs.

3. Previous work
----------------
Most of these requirements are met by the current version of the reference implementation of the framework. 
This reference implementation needs to be completed. A fair amount of work needs to be done 
in terms of automated framework Wizards and BPM integration.  
A JSR is being worked on. The JSR and the progress achived so far has been documented via the project web site.

4. Approach
-----------
The project will be delivered using the Agile methodology. 3 or 4 iterations are envisioned.
Each iteration should produce working software: a new revision of the reference
implementation. The specific list of features for each iteration will depend
on several factors including project membership.
 


5. Deliverables
---------------
The projects delivables are as follows:

1) Complete source code for the reference implementation of the framework (feature complete). 
2) Complete documentation. This includes javadoc documentation.


6. Sun Involvement/Participation
--------------------------------
No Sun involvement/participation is required.

7. Team Membership
-------------------

TBD


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools..search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/challenge-discuss/attachments/20080226/21e6f5eb/attachment.html