Hi All, @Amita: I am including you also in the discussion, because I saw some effort from your side on the topic of XQuery DAS: https://issues.apache.org/jira/browse/TUSCANY-1431
I will enumerate my comments for clarity: 1. About the database access for XQuery components. When I am thinking of it the following comes into my mind: a. As you, Jean, supposed - JDBC connection information could be provided in the component definition. And this could be achieved in a standard way, by using XQJ connection API and providing the parameters that are needed for establishing the XQJ connection. In this case the developer of the XQuery component should specify in some way what implementation of XQuery he will use (by supplying the XQDataSource class name for example). Then he should supply the connection information (if any) to the data source. It should be noted that not all XQuery engines support database access (like Saxon). One question that occurs here is where exactly is the best place to provide the connection information. This place could be under the specific reference (or associated to the reference) by using some kind of binding for example. Or we can define the connection with the parameters of the implementation.xquery tag - in this case the component will be able to talk to only one database (which I think is normal for XQuery which is executed on the database directly) b. The XQuery component can use an XQuery DAS (which is currently under development) and the XQuery DAS will be responsible for executing the query over the data source and return the result like SDO data object. Again the connection information and the XQuery engine information should be supplied in some way. @Amita: Could you elaborate on this topic? Can you explain your scenarios for the XQuery DAS. How could they relate with the XQuery component which is currently under development (you can see details at: http://issues.apache.org/jira/browse/TUSCANY-1536) c. The XQuery component could talk to another component, which provides the database access (it could be done event now). This variant is the poorest, I think, because it won't work for large volumes of data Generally what should be kept in mind is that whatever solution is selected for the database integration purposes of XQuery, the execution of the script should be done as close to the data base as possible. We should also verify that we could work with volumes of information, which are higher then the volume of the JVM memory. d. It is possible that we will need to have two types of XQuery components: one for data integration purposes and another for mediation purposes. Or have just one type of component and have a property which differentiates between the two modes. Does anybody have other thoughts about this topic? 2. About extensibility of the used XQuery processor a. Yes, there is a standard API, which is independent of the XQuery implementation - it is the XQJ API: http://jcp.org/en/jsr/detail?id=225. However still there are settings, which are specific for a given XQuery processor. b. The idea for using policy-intents seems very interesting. But how will be the exact XQuery engine identified? In the PolicySet section? In fact the exact implementation class of the XQDataSource should be provided. How can we state that some Saxon implementation satisfies a given intent - should the user provide a policy set for given vendor if it is used? 3. About mediation a. I found that IBM have some experience in this area in the WebSphere process server. There SCA components are used for data mediation, which are implemented with XSLT transformations. However I am not very sure how the interface mediation is done. b. You are right - there are no interfaces in XQuery, but I defined them by using namespace declarations. If you take a look at the example XQuery scripts, you will see that I have defined all implemented services (i.e. their interfaces) by an namespace URI starting with "scaservice:java/", followed by the fully qualified class name of the interface. The XQuery implementation will implement as many interfaces as there are namespaces declarations. Similarly I define the reference interfaces using the prefix "scareference:java/" and the properties with "scaproperty:java/". c. @Jean: Can you explain the idea for "bunch of transforms" in a given component a little bit more? I am still continuing to think of possible evolution of the XQuery type within SCA and I will appreciate any suggestions and propositions. Bye, Vasil >-------- Оригинално писмо -------- >От: Jean-Sebastien Delfino <[EMAIL PROTECTED]> >Относно: Re: XQuery implementation scenarios >До: [email protected], tuscany user <[EMAIL PROTECTED]> >Изпратено на: Четвъртък, 2007, Август 23 03:53:56 EEST >---------------------------------- > >Hi, interesting topic :) so I've copied the tuscany-user list as well in >case some of our users are interested too. > > >Vasil Vasilev wrote: >> Hi all, >> >> I would like to start a discussion about how we see the usage and the >> future of XQuery within the boundaries of SCA. >> >> What inspired me when I started my work on the XQuery implementation type >> for SCA was the capabilities it provides in the area of data integration. >> You can take a look for example on the BEA AquaLogic platform. You can see >> how they create the data integration layer of a SOA application on the >> basis of XQuery. >> >> Currently the SCA specification supports integration with EJB and Spring, >> but I think XQuery provides many capabilities for working directly with XML >> data sources - like Web Services and DataBases. It should be noted that the >> main database vendors support XQuery. >> > >Yes, I agree with you that it's missing from SCA right now, and people >who use XML based programming models, XML schema for their data, WSDL >for their interfaces, or BPEL for their processes, and want to work >directly with the XML data will want to use XQuery to transform, filter, >mediate their XML messages, and query data from all kinds of XML-enabled >backends. > >I think that with your code contribution we have a good starting point >that we can now further develop and refine, use to develop scenarios, >samples, demos that illustrate its usage. I'm hoping that this work and >the discussions here will help put together a proposal to bring to the >spec group. > >With respect to database access, a number of folks in Tuscany are >working on DAS (Data Access Service) and I believe they have started to >look at XQuery as well, so I'm not sure if or how these two subjects are >related, but I'd be curious to hear from the DAS people on the XQuery >subject as well. > >Another interesting question may be: If the XQuery program talks to a >database, will we want to configure the database information on the >XQuery component itself? or is the XQuery component going to be more >independent of the database itself and we'll represent the accessed >database as a separate service? > >> So having in mind what was said above one step for enhancing the XQuery >> implementation type is to decouple it from Saxon. The user should be able >> to plug-in his preferred XQuery processor. For example if he uses Oracle, >> he could delegate the execution of the XQuery script to the Oracle parser. >> Or he could prefer to use DataDirect's implementation, which is very >> optimized for accessing databases. In order to do it we could think of some >> kind of extension points, which define what is needed by the >> implementation, i.e. to introspect the XQuery file, to call a single >> function in it, to set external parameters and functions and etc. >> > >That sounds good to me. Is there a standard XQuery processor API that we >could use here? or should we define that extensibility mechanism >ourselves as a specific Tuscany API? > >How about using SCA "policy intents" to configure which XQuery processor >is going to be used. Have you looked at SCA policies at all? I'm just >brainstorming here, but maybe we could define a few policy intents that >the application developer could put on a component to say "I want an >XQuery processor that works well with this XML databinding" or "I want >the XQuery processor that works well with my database"... > >> Another direction where the XQuery implementation type seems useful is in >> the area of mapping one service interface to another and in this way adapt >> both interfaces. He could even do it with a mapping tool, which generates >> XQuery code out of it. This could be very useful for BPEL implementation >> type services for example. Of course here also XSLT could be used, but I >> selected XQuery, because it is more similar to a programming language and >> it could easier fit in the concept of interfaces and operations of the >> services. >> In this area JBI inherently provide a solution (you can see Open ESB for >> example), while in SCA this concept is somehow missing. That's why I thing >> an XQuery implementation type would be a good step forward. >> > >Right! XQuery can definitely be very useful to implement "mediation" >components. I can see two different patterns here: > >- Data mediation - I have data type X and need to transform it to Y, I >could write a XQuery component named TransformX2Y for example and then >reuse it in various places in my SCA composite application, from Java >components that don't want to write this transformation in Java, from >BPEL components between BPEL assigns, etc. This kind of component could >have a fixed operation like "any transform(any) for example, or a more >specific operation signature indicating its input/output types. We could >have one transform per component or choose to bundle a bunch of related >transforms in the same component... There's a lot to explore here I >think :) > >- Interface mediation - I have two WSDL interfaces that don't exactly >match, the operation names are different, the parameters need to be >shuffled around, etc. To cover that scenario, we'll need to map XQuery >to operations, and understand how the operation and its parameters are >exposed to the XQuery program. I'm just starting to look at XQuery and >I've seen functions but no interfaces :) Could you tell us a little bit >more about what you've done in your current code and the Quote sample to >expose service interfaces and operations to XQuery? > >Thanks! > >> I would like to know your opinion about these topics. >> >> Bye, Vasil >> >> ----------------------------------------------------------------- >> Познай победителя във Формула 1 и спечели награда! >> http://www.clubf1.net/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >-- >Jean-Sebastien > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > ----------------------------------------------------------------- ЕЛА и направи свой сайт, намери нови приятели! http://www.zoom.bg/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
