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

Hi John


I took a look to JCA. It seams it haven't had much activity lately.
Also, the specification is very complex, just the opposity we are
looking for.

In the meantime, I took another look at SP2A
(http://sp2a.sourceforge.net/), a project wich is developing a web
services oriented platfor based on Jxta. The project's page has little
details, but some additinal information can be found here
(http://middleware05.objectweb.org/WSProceedings/MGC05/a9-amoretti.pdf)

I have not personaly tested the platform, but I know one of the guys who
lead this project, called Michelle Amoretti. He also worked at the
JXTA-SOAP project (http://soap.jxta.org/).

>From the project's description, it looks as a good starting point. They
already solved the Jxta-web services integration, have an enhanced
peer-group management and also a framework for resource managing. 

I think we could talk with him and see to what extend his platform is
suitable to our needs. For instance, how they manage the deployment of
services and the application interfaces.

Pablo


On Wed, 2006-06-14 at 14:23 +0200, John Dickerson wrote:
> Hi Pablo,
> 
> Thanks for your comments - I have briefly looked at www.mono-project.com and will look at JCA when I have some time.
> 
> As a starting point we could list some features we would like a jxta app server to have and then experiment with those individual features.
> 
> For example I would like to drop a jxta archive file under a certain deploy directory and then have the App Server automatically initialise the PeerGroup. 
> 
> This feature requirement would then necessitate the definition of the package structure of the archive file and the XSD schema file definitions for the deployment descriptors.
> 
> This is an area that can be useful both to a JXTA App Server project and JXTA applications in general.  These libraries could be initially placed in the jxta/commons module in CVS.  If they proove to be very useful they could be migrated into the platform module at a later stage.
> 
> At the same time we could create a general framework for a jxta application server - Do you know of a good place we could publish and collate thoughts online.  The act of publishing these thoughts could proove a good starting point for the project.
> 
> I have ideas about adding services to the Application Server in a similar fashion to the way JBoss uses MBeans.  One mbean style service I would like to see is some libraries using "JXTA Search" libraries. Do you know if the "JXTA Search" project is compatible with the head of JXTA ? 
> 
> There seems to have been very little activity recently with JXTA Search - do you know why?
> 
> Thanks
> 
> Regards
> 
> John
> 
> p.s. 
> 
> 
> 
> 
> -------- Original-Nachricht --------
> Datum: Wed, 14 Jun 2006 10:43:43 +0200
> Von: Pablo Chacin <[email protected]>
> An: [email protected]
> Betreff: Re: [JXTA user] 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
> > ========================================================================
> > 
> > ---------------------------------------------------------------------
> > 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
========================================================================