Thanks Geert, great ideas. I guess I wasn't thinking straight. Of course Both the HTTP and XDBC servers can read from the same "Modules" DB (or filesystem). I was getting confused with the difference that App server modules get arguments via the HTTP extensions whereas XDBC modules get arguments via 'declare variable external'.
I presume a typical organization is to use a directory structure to 'group' different types of interfaces ? (modules, xquery 'main' modules, App server front end etc). I haven't quite figured out how MarkLogic global libraries are addressed, like the functx library, which is outside a given app module directory ... Is there a way to share common code across App Module DB's like ML does for built-in ones ? Probably wont need that as you say the different servers can share the same App Modules DB. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Geert Josten Sent: Tuesday, December 15, 2009 3:40 AM To: General Mark Logic Developer Discussion Subject: [MarkLogic Dev General] RE: Towards a more modular app architecture... Hi David, Personally, I like the 'Separation of Concerns' principle. You shouldn't have to have calculations directly in the middle of your HTML code. Put this 'heavy' stuff in modules with accessor functions. You can either approach each module as a kind of 'object', or just make it a function library. Let some modules take care of accessing data (and searching, updating etc), some to handle more abstract application logic, and finally have modules or main modules take care of delivering results to any type of end user. If you have properly separated concerns into separate modules, then there is no need to choose at all; it will allow supporting all methods at the same time. Why wouldn't one have a webdav server to upload documents, have a xdbc server to debug from an editor, have a small http serving html for administrators and testers, and one serving xml for soap or rest clients, all connected to one and the same documents database? The latter two could be combined, perhaps, if you like.. Note: there is not really such a thing as an 'XDBC based module'. You can always use such modules from HTTP app servers as well.. Kind regards, Geert > Drs. G.P.H. Josten Consultant http://www.daidalos.nl/ Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 http://www.daidalos.nl/ KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. > From: [email protected] > [mailto:[email protected]] On Behalf Of > Lee, David > Sent: dinsdag 15 december 2009 1:21 > To: [email protected] > Subject: [MarkLogic Dev General] Towards a more modular app > architecture ... > > I've had some good success now getting a "quick and dirty" > Demo app up and running. I'm using the HTTP App server, > > with a lot of xquery pages, as well as a "common" module. > Not the cleanest solution but was extremely quick to develop > and experiment with. But I know whats coming next ... If > I'm lucky :) > > > > The team (and I agree) that its not a good idea to mix > presentation with query logic. All my current pages generate HTML > > intermixed with xquery code. While this works in this > limited case I dont think its a good long term direction in > our environment. > > Not only is the business logic bundled with presentation (and > my presentation HTML skills are not that great), > > but the intended use cases will be heterogeneous. I'll need > to integrate the fundamental queries into existing App > servers, as well as standalone applications, as well as > (likely) keep a pure ML HTTP/HTML App server . > > > > So what are good ways of architectecting a ML based backend > to be able to serve multiple front ends, including an ML App server ? > > Here's what I'm thinking ... but not entirely sure its a good > architecture. > > > > 1) Write the core code as an XDBC based module. > > a. For external uses use XCC to run the queries > > b. for ML App server use "xdmp:invoke" to access the > core modules (can the App module "invoke" modules in XDBC world ? > > c. An advantage here is I can use a debugger (Oxygen) > to debug XDBC based modules where I cannot debug App server > (HTTP) modules > > > > 2) Put the core code in xquery modules. Make them > accessable to both App and XDBC based modules. > > a. For XDBC use an inline query that 'imports' the > module then runs the function' > > b. For ML App server use, simply import the module and > use directly > > 3) Use the App server as a kind of HTTP ("Restful") type > service for both internal and external use. > > a. for external use have it produce raw xml > > b. for internal use use "Invoke" then wrap in HTML > > c. Is this much different then #1 ? although I cant > debug with oxygen an App server based module > > > > > > Any other suggestions ? > > > > > > > > > > > > ---------------------------------------- > > David A. Lee > > Senior Principal Software Engineer > > Epocrates, Inc. > > [email protected] <mailto:[email protected]> > > 812-482-5224 > > > > > > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
