For a number of reasons, some time ago we added some new hardware to our operations environment, including F5 hardware load balancing. This enabled us to implement some new HTTP processing functions, as well as centralizing some of our existing HTTP processing, all in the F5 layer. As a part of this, the F5 hardware layer took over the URL rewriting duties previously carried out by squid. Squid is still a part of our stack, but for the most part it's operating only as a caching layer.
Cheers ian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > John Craft > Sent: Friday, May 30, 2008 6:20 AM > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] Exposing content via Web services > > What does MarkMail use now for URL rewriting and what were > the reasons for switching from squid? > > John Craft > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ian Small > Sent: Sunday, May 25, 2008 6:17 PM > To: General Mark Logic Developer Discussion > Subject: RE: [MarkLogic Dev General] Exposing content via Web services > > Travis - > > A few quick responses while I have a couple of minutes on the weekend. > > Doing (1) with the MarkLogic Server 3.2 requires having > something in front of MLS do URL rewriting into form (2). > MarkMail does this using squid, for instance (well, we did, > now we do it differently, but you get the drift). > > Form (2) is supported using the AppServer built-ins > (http://developer.marklogic.com/pubs/3.2/apidocs/AppServerBuil > tins.html) > . So for instance, xdmp:get-request-field() and > xdmp:get-request-field-names() are your friends here. > > Form (3) is more work, and while the server itself does not > directly support it, it can probably be done (although I > haven't tried it > myself). One starting point might be the SOAP Router contributed by > the community and found a ways down the page here: > http://developer.marklogic.com/code/ > > Cheers > ian > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > Of Travis > > Spencer > > Sent: Sunday, May 25, 2008 3:16 PM > > To: [email protected] > > Subject: [MarkLogic Dev General] Exposing content via Web services > > > > Good Afternoon All, > > > > I am trying to figure out the particulars of how one would > create XML > > Web services to expose the content within MLS. I would think that > > this is a very common use case, but I can't find enough > information to > > actually solve it. If anyone can point me to documentation, URLs, > > Webcasts, etc., I would really appreciate it. Alternatively, can > > someone help me fill in the blanks by answering the questions below? > > > > As I see it, there are three types of interfaces that such services > > could have, but I'm stumped on various details with all of > them. I've > > enumerated these three options below: > > > > 1. Expose the content using a RESTful Web service API > > > > To do this, the URLs would have to be unique per resource. > > This would mean, for example, that a fictitious user > management system > > might expose users with URLs like this one: > > > > http://travisspencer.com/user/tspencer > > > > To do this, the HTTP app server defined in MLS would have > to map this > > URL to some XQuery script, e.g., /user.xqy, and pass it the > user name, > > tspencer, from the URL. I don't see any way to do this in > MLS. Once > > this mapping was done, assuming it can be, I'd have to > determine the > > HTTP verb (GET, PUT, > > etc.) within the script to know what action to perform. Is there a > > custom XQuery function supported by MLS to allow me to > determine the > > HTTP verb of a request? > > > > 2. Expose the content using a query API > > > > To do this, the action and/or parameters would be passed to > my XQuery > > scripts on the query string like this, for example: > > > > http://travisspencer.com/user.xqy?action=delete&name=tspencer > > > > I'm sure that MLS provides a way to pluck out the > parameters and their > > values from the query string, but I'm not sure how. > > Any idea? > > > > 3. Expose the content using a SOAP-based API > > > > With SOAP, I'm not even sure where to start. For instance, > how would > > the WSDL describing the service's interface be created? > Would I have > > to do it by hand? If so, what about the non-abstract > portion of the > > contract -- the biding, port, and service which are specific to the > > host environment? > > Would I have to hand role this too? What if the port or > machine name > > change? It seems that even these volatile datum would have to be > > modified unless MLS is some how able to automatically generate the > > WSDL for me. > > > > If the WSDL is automatically generated, how do I specify which > > operations are included, and how do I map those to the > proper XQuery > > scripts that should be called upon to handle SOAP messages > for those > > respective operations? Can I indicate that all the functions in a > > module, for example, are to be exposed as one SOAP service > and MLS is > > able to do the WSDL generation and dispatching of messages? > Or would > > I have to role the WSDL myself and interrogate the SOAP messages, > > determine the operation, and pass it to the appropriate XQuery > > script/function? > > > > What about when a fault occurs? Do I have to create the entire XML > > document that represents the SOAP fault myself or does MLS support > > some helper XQuery method that I can use in my catch blocks > to create > > the fault XML? > > > > Can I only hope for my SOAP Web services to comply with > WS-I BP or is > > there some way to also support the more advanced protocols > like WS-AT, > > WS-RM, etc.? Would I have to build this support myself? > > > > As you can see, I have many questions about how all this is > done. If > > I can figure this out though, I'll be ready to do some really cool > > stuff w/ MLS. Any help getting to that point would be much > > appreciated. > > > > -- > > > > Regards, > > > > Travis Spencer > > _______________________________________________ > > General mailing list > > [email protected] > > http://xqzone.com/mailman/listinfo/general > > > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ > General mailing list > [email protected] > http://xqzone.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
