Re: Vision: JXTA Application Server Part II - P2P Workspace
James W Todd II <[email protected]> Wed, 14 Jun 2006 10:29:43 -0700
| Newsgroups | gmane.comp.java.jxta.user |
|---|---|
| Message-ID | <[email protected]> |
Hey John - >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. Sounds cool. When I first started hacking w/ ext:config/profile, which to me "can be thought of" as a servlet web.xml equivalent, i toyed w/ the idea of creating PAR files, in the same spirit as WAR files. Now, on a more practical front, w/in MyJXTA some pieces of this have come into being ... but by bringing this up I want to point out that the current implementations are more application specific vs library ready per se. That said, alot my JXTA Commons contribs, and in fact a large part of ext:config, is refactored from MyJXTA as well. MyJXTA has a loopback listening socket that is used for a number of things, one being to handle second and subsequent application startups that point to the same JXTA_HOME. You can see the socket port id in the ~/.myjxta/myjxta.sid file. The listener process is pretty simply to which I have plans to replace it w/ the JXTA Commons HTTP server (/net/jxta/ext/service/JavaServer. A practical use case is for when the second (or subsequent) MyJXTA JNLP link is activiated (eg http://blogs.sun.com/gonzo -> Chat About It). At MyJXTA startup, data (eg group info) is conveyed to "daemon" application process after which the newly started and duplicate process exits. I see this as a pretty core "commons" type application feature, thus the JXTA Commons refactoring work, to bullet proof the work a bit more, flesh out the protocol, etc. Now, MyJXTA also supports (or supported) the ability to share (http://cms.jxta.org) files that appear in the MyJXTA "data|share" directory outside of the scope of the running process ... by starting a thread that watches that dir(s) for changes, file adds, file removes, etc. A use case is that a user could specify a "share folder" at the OS level to which MyJXTA could manage accordingly. Now, to spin back up, I like the thread and have mulled over pieces of this space over time. As such, I'd like to see this theme fleshed out a bit further, to define terms, etc. and then see if we can proto out some of the ideas. Perhaps as a Wiki topic, initially. That and the "commons" project should prove flexible for starting to build upon these ideas. - james 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] >> > >