Re: Vision: JXTA Application Server Part II - P2P Workspace

Hi John

Maybe because my expertise is more related to middleware development
than application development, I have a service centric vision of the
Jxta App Server, instead of an application centric vision, as you are
proposing. I beleive both are valid and should be considered when
designing the server.

For example, consider a distributed content storage and retrieval that could be used as a "folder) (see iFolder from Novell as
an example) or a service to altruistically execute cpu intensive applications (for example, SETI@home, or the World Community Grid)

Using the same  analogy of web applications, there is a fundamental difference between a service container 
(such as a servlet or even better an EJB) and a user interface container (such as an applet). 
Actually, a Servlet is not, strictly speaking a service container. It is more a user
interaction controller. Then we have three tiers here: service, user interaction and user
presentation. I'm not sure how to map the user interaction layer to the concept of Jxta application server, 
but the other two are clear: the Jxta AppServer should support the services and user can use diverse 
aaplications and interfaces to access them, like the traditional rich clients that characterize most P2P 
applications for content sharing or collaborations nowdays.

The interesting thing about P2P architectures is that both, the service and user interaction containers are hosted by the 
user. There is not need for a separate hosting machines (but they can still be used)

The service container should only adhere to some generic service interfaces such as JCA.
I will done a brief research of available service interfaces we could use. This way, we can separate the GUI issues from 
the service support issues, which have very, very different design concerns.

>From the GUI point of view,  I don't beleive it is a good approach to propose yet nother gui interface or technology, 
because each application  will have dirrent requirement and it dificult to satisfy them all. It would be interesting to see
how this is being addressed in other projects leveraging technologies such as AJAX. The main question from the architectural 
point of view is how to integrate the service and application containers?

Regarding you other questions about how to limit resource usage and do the sand boxing. 
I'll take a look at some research projects that address  these issues and let you know .
 
Finally, even when the Jxta community has been mainly Java oriented (in the practice, at least) I would also
consider other development plaforms such as mono (www.mono-project.com). It is very active, offers platform
portability. Supports different development languages (C#, Java, VB) and offers some interesting features for supporting
both services and end-user applications. 


Pablo


On Tue, 2006-06-13 at 00:07 +0200, John Dickerson wrote:
> (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]
> 
-- 
========================================================================
 0 0 0  Pablo Chacin               | Dept. d'Arquitectura de Computadors
 0 0 0  e-mail: [email protected] | UPC-Campus Nord. Modul C6, 002
 0 0 0  phone: +34 +93 401 1055    | Jordi Girona, 1-3            
 U P C  fax:   +34 +93 401 7055    | 08034 Barcelona - SPAIN     
        www:   http://personals.ac.upc.es/pchacin
========================================================================