Vision: JXTA Application Server Part II - P2P Workspace

(I will look into how Spring could be used as a core framework for an Application Server - Thanks to James and Venessa )

Thank you all for your points of view regarding JXTA Application Server Vision.

To continue brain storming for Vision: JXTA Application Server Part II 
================================================================

Application Server conjurs up different things for different people. Part of this exercise is defining what a JXTA Application Server could be or should not be.  Maybe it should not even be called an Application Server and a term such as "P2P Workspace" would be more appropriate.

In the jxta application server vision I see the application server acting like a "workspace", a means for controlling P2P applications, both from a service and GUI perspective.

Going back to the analogy of Web Containers such as the J2EE Servlet Engine, mechanisms can be written into the API that allow for efficient management of P2P applications and their life cycles. Equally mechanisms can be created to allow for easy GUI integration.

Please note I am not saying use a Servlet Engine - it is only an analogy for the purposes of discussion.

In my opinion there are 2 kinds of p2p applications a computer device may host:

(i) Application Type 1
=======================

Applications that are hosted for the benefit of other peers on the network. The user installs them because they are altruistic and understand that they should behave as they would like others to do.  In the future this behaviour may be rewarded by a rating that gives the user access to services they might not otherwise have enjoyed (Some P2P applications already have point system for altruistic behaviour).

This type of application is rarely used by the user. The user allocates bandwidth and processing resource to the application. They also decide whether to grant certain privileges to the application such as the ability to perform IO operations.  By default IO operations will be disabled. The user relaxes the sandbox constraints if they trust the source.  

The API needs to have a mechanism for coping with disabled resources and allowing  non-technically minded end users of P2P applications to prevent any compromise of security to their computer devices.

The application may or may not have gui components.

(ii) Application Type 2
========================

Applications that are hosted for the benefit of the user and are utilised frequently.  

The jxta application server architecture may need to have an API which allows for easy GUI Interface integration.  In my opinion this is an area that is often overly complicated as a result of the process by which the technology evolved. Take the Struts, Tiles, JSP, Servlets, Custom Tags framework.  Integrating all these technologies together seems far from perfect but is a natural consequence of how these technologies evolved.  

From a p2p point of view, we could need simple GUI integration to be core to the JXTA Application Server API.


Questions that need to be asked for the GUI Integration are:
=============================================
 
(i) Should support for different programming languages be built into the GUI Jxta Application Server API for the first milestone.  This could save having to rework the architecture in future iterations.  A plugable architecture would probably be in order.

(ii)  What is the architecture of the JXTA Application Server APIs that Gui Components adhere to?  Anyone got any ideas?

(iii) Should there be a GUI API at all for a JXTA Application Server / Workspace


Most important of all
======================

(i) Above all, the JXTA Application Server vision is to make life easier for everyone and as such, "programmer usability" should be of upmost importance to its development. This was sadly missed out with earlier EJB specifications and should never be repeated for JXTA core Application Server API specifications. 

(ii) For every line of code written there should be several lines of documentation / examples written.  There should be a strong correlation between the versions of the code base and the versions of the documentation and examples.  This is easier to enforce right from the offset of a project.

(iii) If the documentation / example theme can be enforced right from the beginning the project will grow fast and stand more chance of being adopted.

(iv)  The JXTA application server should be as light-weight as possible.  Application Servers traditionally bring to mind "bloat ware".  I am however envisaging "light-ware".

I envisage JXTA Applications Servers feeling equally at home on mobile phones, PDAs, in car computers and PCs.


Way forward
==========

As many ideas as possible:

(a) Any ideas that show how JXTA GUI integration APIs could fit within the JXTA Application Server framework ?

(b) Any ideas that show how to provide simple Sandbox security and enabling of resource utilisation such as IO?

(c) Any ideas that show how to manage processing power, memory usage and bandwidth for multiple P2P applications?  Is this possible on the Java platform using Threads? How would you do it? I am quite stumped on this one.

(d) Should one JXTA Application Server have the capability to act as different roles for different applications hosted on it (Edge Peer, Relay e.t.c)  Should there be multiple JXTA Homes on a JXTA Application Server ? My personal view is I find having just one JXTA Home a bit limiting when one is considering multiple P2P applications being hosted on one machine.

(e) Any ideas for doing all this as light weight as possible without reinventing the wheel ?


Thank you all greatly for any ideas or harsh criticisms you may have to contribute in relation to, or in addition to, the above mentioned points.

Thanks

John

-------- Original-Nachricht --------
Datum: Mon, 12 Jun 2006 12:30:32 -0700
Von: James W Todd II <[email protected]>
An: [email protected]
Betreff: Re: [JXTA user]	 Vision: JXTA Application Server for configuration & deployment

> 
> I think leveraging popular IoC containers is the right path, noting that 
> there are more then one.
> 
> Spring is no doubt a popular one.
> 
> IoC patterns, in general, is a "good thing" for most common use cases.
> 
> hth,
> 
> - james
> 
> --
> 
> Vanessa Williams wrote:
> > I may have read John's original post wrong, but I thought the 
> > intention was not to deploy JXTA apps in a servlet container, but to 
> > create a container specifically for deploying JXTA services and 
> > applications?
> >
> > Also, just to muddy the waters even further, what's the relative merit 
> > in adding "JXTA support" to the Spring Framework? I've never seriously 
> > looked into that, and  it would take more exploration of Spring's 
> > architecture, but why create a container that only does JXTA 
> > (recreating the wheel on many capabilities), when you can integrate 
> > support into a container that already does everything (db support, 
> > support for declarative transaction interception and aspect-oriented 
> > programming, etc., etc.)? Just a thought. Maybe a separate project for 
> > some day.
> >
> > Cheers,
> >
> > Vanessa
> >
> > On 12-Jun-06, at 2:31 AM, tra wrote:
> >
> >> John Dickerson wrote:
> >>
> >>> (iii) JXTA application servers make JXTA P2P a more serious 
> >>> proposition to the corporate world and consequently encourage JXTA's 
> >>> popularity as a serious alternative to .NET and J2EE for certain 
> >>> application types.
> >>> I am very excited by the JXTA Application Server vision as I believe 
> >>> it can make JXTA easier to use and will also bring JXTA into the 
> >>> mainstream alongside J2EE and .NET.
> >>> Thank you all for your attention.
> >>> Any criticisms or points of agreement you have with the JXTA 
> >>> application server vision wil be much appreciated.
> >> Your comments makes a lot of sense, and there are nothing to my 
> >> knowledge in the core platform that will preclude us from building 
> >> such container abstraction. At the same time, we should not assume 
> >> the only way to deploy JXTA is through a servlet container.
> >>
> >> Hth,
> >>
> >> B.
> >>> Regards
> >>> John Dickerson
> >>
> >>
> >> ----http://weblogs.java.net/blog/tra
> >> "As Java implies platform independence, and XML implies language
> >> independence, JXTA implies network independence."
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >
> > -- 
> > Vanessa Williams
> > Oponia Networks
> > [email protected]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]

-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl