Hi Vivian, and thanks for the detailed reply. That's definitely given me a good overview of the architecture you are aiming for, and I'll make sure I keep up to date with your blog posts as they come out.
I've included some thoughts on the architecture, and my own view on the initial discussion topics you raised, below. But before I get to that it's probably worth talking about the practicalities of this for my immediate requirements. Although this approach should provide everything I need, it seems like things are at a very early stage, so I won't be able to wait for the release of 4.0 for this project. Is is feasible for me to start developing a proof-of-concept implementation of the WS layer, which would meet my immediate needs but could then be carried forward for the actual implementation? If not, or there is little chance of this having reuse value, then I might just go for a simple XML-RPC approach for the time being, in the knowledge that I will have to bin this for the proper WS stack once that is completed - at least then I can minimize the wasted effort :-) Architecture thoughts: The concept seems very strong, and I really like the idea of totally separating the front- and back-end layers. This would allow much more flexibility in the 2 development streams, and would promote more feature-completeness and better documentation of the back-end WS layer. My thoughts on the discussion topics you raised: > * most important: webservice decomposition; which functionality is exposed > as a webservice, how coarse-grained or fine-grained should the interfaces & > methods be. E.g. we could expose the hierarchy manager as a webservice and > that's all we need, even though not convenient at all. My feeling is that the WS layer should, as far as possible, expose 'logical tasks' to client developers. So rather than being a wrapper around the existing APIs and paradigms used in the current back-end, this is a great opportunity to provide a cleaner, easier to understand interface layer. As a client developer I don't want to know about hierarchy managers and the JCR :-), I want atomic tasks that I can call to achieve a business logic function, e.g.: - get content - get node value - create page - create user > * can (or shall) we create an architecture in that every module can > collaborate in exposing its part of the Magnolia's model as webservice? Or > is this all handled by one single module? This is very tricky, as you don't want to raise the level of complexity in developing modules if you want an active community of 3rd-party developers, but at the same time there will be business logic functions related to some modules that cannot be provided by the core services. However, if the core services are broad enough then another developer could work round this if they needed to, so my feeling would be to not make a WS layer a requirement for module development. That said, if we are to decouple the front- and back-ends of modules as well as the core, some modules will require a WS interface to their own business logic (e.g. Forum module > add post ), but then we could just allow them (or anyone else) to develop an optional 'WS module' for each module. > * do we have to take additional steps to make the Magnolia infrastructure > (security, context, etc.) work with webservices? Easiest would be (indeed > without any modification) to have the Magnolia filter chain as is handling > the request before passing it to a servlet that handles the webservice > request. Thus having the full context available in the webservice. Security will be important, but keep it simple - if the existing filter chain will do everything we need then just go with that. I hope those comments add some value to the discussion. Regards, Simon 2008/7/17 Vivian Steller <[email protected]>: > Hello Simon, > thanks for publishing your request on the dev list again. > > As Greg noted, Magnolia is willing to build the new Magnolia 4.0 GUI > (code-named "GenUIne") on top of a complete webservice stack (using JAX-WS > 2.x [1] compliant webservices opposed to XML-RPC) to access the backend. At > least this is the current result of the technological discussion about > GenUIne. Before we also discussed a JSF based approach, however, for the > time being ruled it out since the WS approach offers more possibilities and > flexibility for the future, see [2] for details. > > The ultimate goal is to decouple the Admin Central from the core of > Magnolia: this way the Admin Central could have its own development > life-cycle and could be developed much more independently. Furthermore, we > would exactly met your requirements by letting other applications access > Magnolia in a standardized and interoperable manner. One could even think > about different GUI implementations, e.g. as plain - again - JSP/JSF based > frontends, rich web clients (à la Adobe Flex) or statically delivered, full > blown AJAX clients (whereas the latter one is the approach we're > investigating at the moment). > > Back to your questions. So far, the only "rough architectural notes" I can > offer you are the following three scribbles outlining the request life-cycle > in the webservice scenario [3] and the JSF scenario [4]. Figure [5] outlines > how we could even reach both targets leveraging Java 5 annotations > (especially JAX-WS annotations and JBoss Seam (?) like annotations for JSF > managed-beans). > > As I said, those are only "rough" scribbles and quick ideas of mine on how > we could simplify the GUI development. Of course, these are early stage > drafts, however, I would be glad to see any discussion about the > architecture on the list and in the Wiki [6] as well. > > Especially, I think we should discuss about the following topics: > * most important: webservice decomposition; which functionality is exposed > as a webservice, how coarse-grained or fine-grained should the interfaces & > methods be. E.g. we could expose the hierarchy manager as a webservice and > that's all we need, even though not convenient at all. > * can (or shall) we create an architecture in that every module can > collaborate in exposing its part of the Magnolia's model as webservice? Or > is this all handled by one single module? > * do we have to take additional steps to make the Magnolia infrastructure > (security, context, etc.) work with webservices? Easiest would be (indeed > without any modification) to have the Magnolia filter chain as is handling > the request before passing it to a servlet that handles the webservice > request. Thus having the full context available in the webservice. > > So far, my thoughts. I think much more questions will arise as soon as we > really start. Again, I would be very glad to see an ongoing discussion on > this topic. > > FYI: I'm currently blogging about the new Magnolia GenUIne, specifically the > next post (to be published at latest next monday/tuesday) will cover the > technical status I roughly described here. I'd like to invite you following > those blog posts under http://vivian.steller.info/blog/ > > Best Regards, > vivian > > [1] http://jcp.org/en/jsr/detail?id=224 > [2] > http://wiki.magnolia.info/display/DEV/Genuine+-+Decision+Table+-+Server-Side+Technologies > [3] > http://wiki.magnolia.info/download/attachments/7241760/Webservices+Rendering+Scenario.png?version=1 > [4] > http://wiki.magnolia.info/download/attachments/7241760/JSF+Rendering+Scenario.png?version=1 > [5] > http://wiki.magnolia.info/download/attachments/7241760/Common+Architecture.png?version=1 > [6] http://wiki.magnolia.info/display/DEV/Genuine+Technology+Discussion > > > Am 15.07.2008 um 17:36 schrieb Simon Goodchild: > >> Hi there. Greg suggested I repost this from the user list: >> >> For a while now I've been wanting to access magnolia functions and >> content via external applications, so I'm looking into what options >> are currently available and any modules or core enhancements that >> might already exist. The key requirement would be to communicate with >> the magnolia backend from another application, possibly running on a >> different server, in order to retrieve content, and to create pages >> and users within the system. A mechanism like XML-RPC would seem to be >> ideal for this purpose. >> >> Greg mentioned that this is being looked at for inclusion in 4.0, but >> sounds like that will be some time away. So my intention is to write a >> module to add an XML-RPC integration layer to magnolia. Ideally I >> would like to make this a useful base for whatever mechanism you have >> planed, as this would avoid duplicated effort and also help with >> long-term support and enhancement. So are there any rough architecture >> notes or pointers that anyone could provide on how this should ideally >> be implemented? And if anyone wants to collaborate on the work then >> let me know also. >> >> Thanks for any input, >> >> Simon >> >> ---------------------------------------------------------------- >> for list details see >> http://documentation.magnolia.info/ >> ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > for list details see > http://documentation.magnolia.info/ > ---------------------------------------------------------------- > ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/ ----------------------------------------------------------------
