Hi,
On Thu, Mar 4, 2010 at 10:24 PM, Raymond Feng <[email protected]> wrote:
> Hi,
>
> Are you looking for mediation abilities that handle message level
> processing agnostic to the business logic?
>
Yes, kinda, this is for porting an exsiting body of Groovy code that is used
to return canned and or parametrized XML responses for 3rd party webservices
during dev/testing. It's wy of being a proper webservice stack, it 'just
enough' for early phases :)
>
> Let's assume that we have the following scenario:
>
> 1) There are multiple clients, such as ClientA and ClientB, that makes Web
> Service calls.
> 2) A broker component (Broker) will receive all the SOAP messages and
> perform mediations
> 3) The broker needs to dispatch to a Groovy class that provide the real
> service implementation
>
> Does ClientA and ClientB use the same WSDL interfaces?
>
Not always. there are multiple WSDL's being presented. A call to any SOAP
operation goes thru an existing central mediator/broker (a Servlet, actually
a Groovlet) that uses the URI and operation to route to a groovy script.
There is 1 script for each operation in a WSDL. Each WSDL stub has what
could be termed a (non-OSGi) 'bundle' of: groovy scripts, a wsdl file and
XML test data for responses.
Do you want to implement the Broker in Java?
>
That is what I was thinking would need to be done. The ideal would to not
have to modify the numerous Groovy scripts that handle the SOAP
request/responses.
We already have a broker written in Groovy but was thinking that for this to
work in Tuscany I need to re-implement the Groovy Servlet dispatcher it in
Java.
Do you intend to wrap Groovy as SCA components?
>
Yes, and new development will probably fit in better with how Tuscany's
script implenetation behaves. We will also be using it in anger on
production deployable code; this is my 1st foray into SCA and we would like
to port what we have with only minor impact on the operation test stubs.
However, the exiting code as-is does not fit well with what the SCA script
implementation expects, all the current SOAP operation stubs are implement
as separate groovy files.
Another benefit of the existing broker is that it performs some pre&post
processing on the XML (text) passed in/returned to make handling more
Groovy-like with-in the operation script, ie. it passes in a XMLParser
object and not text.
>From my limited experience with SCA scripting with Groovy I have to call
utilities in every operation in the Tuscany compatible Groovy script to
perform conversion to and from Groovy/Axiom, e.g.:
// Convert Axis2 AXIOM to Groovy XMLParser
def getXmlParser(request) {
new XmlParser().parseText(request.toStringWithConsume())
}
def getAxiomDoc(request) {
def parser = XMLInputFactory.newInstance().createXMLStreamReader(new
StringReader(request))
def builder = new StAXOMBuilder(parser)
return builder.getDocumentElement()
}
I would like to be able to perform the above in my potentially new 'SCA
Broker'; or is there a better way to work with Axiom in a Groovy way?
The existing dispatcher also passes a contextual filepath to the base
location of testdata related to the current' WSDL 'bundle'.
I also would like to pass in the filepath location for the test data,
although I can see it will be better in the future to move away from such
direct file access pass this as a reference set-up in the .composite to an
over the wire/VFS/SOA registry of sorts.
Further to my previous example with what I have talked about about, the new
SCA Java to Groovy broker would perform:
class MyCustomRouter {
public Document handler(ExchangeInfo ex, Document request) {
String operationName = ex.getOperation();
// convert Axiom request to a GRoovy XMLParser
// calculate where the testdatapath is
// calculate where the groovy script is (using some base path and the
operation)
// response = call groovy script (testdataPath, request)
// convert response to Axiom Document
return doc;
}
}
All the best,
Wayne
> I'm trying to better understand the usage requirements before we start to
> explore some potential solutions.
>
> Thanks,
> Raymond
>
> *From:* Wayne Keenan <[email protected]>
> *Sent:* Thursday, March 04, 2010 12:11 PM
> *To:* [email protected]
> *Subject:* Composite promotion of custom dispatch class
>
> Hi,
>
> In a few messaging stacks (e.g. XFire, Apache CXF, Apache Camel) it is
> possible to route invocations on a SOAP endpoint to a generic handler if the
> implementation class behind the interface contains a method with a signature
> such as this fictional example:
>
> class MyCustomRouter {
>
> public Document handler(ExchangeInfo ex, Document request) {
>
> String operationName = ex.getOperation();
> // do some custome dispatch and build a SOAP response
> return doc;
> }
>
> }
>
> Is such a implementation.java promotion possible for Tuscany SCA
> composites?
> As I wish to route all SOAP requests to a common Java component that does
> some common setup and then dispatches to a Groovy class - in a way very
> different to 'implementation.script language="groovy"' provides.
>
> Regards
> Wayne
>
