You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Vasil Vasilev <va...@abv.bg> on 2007/08/20 12:28:04 UTC
XQuery implementation scenarios
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.
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.
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.
I would like to know your opinion about these topics.
Bye, Vasil
-----------------------------------------------------------------
Познай победителя във Формула 1 и спечели награда!
http://www.clubf1.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XQuery implementation scenarios
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: XQuery implementation scenarios
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org