There are probably a few things involved to support the "any" interface:
1) We already have the interface/operation to be flagged as "dynamic" in the model. The compatibility check between interfaces allows a "dynamic" interface or operation match any other interfaces/operations. 2) Allow new implementation types to produce component types that have references or services typed by the "dynamic" interface. 3) Allow binding/implementation providers to recognize the "any" interface and deal with dispatching or invocation. (Something like the Invoker spi). Thanks, Raymond ________________________________________________________________ Raymond Feng [email protected] Apache Tuscany PMC member and committer: tuscany.apache.org Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com Personal Web Site: www.enjoyjava.com ________________________________________________________________ On Jun 28, 2010, at 3:00 AM, Simon Laws wrote: > On Mon, Jun 28, 2010 at 5:57 AM, Jean-Sebastien Delfino > <[email protected]> wrote: >> I'm trying to implement a generic Java 'relay' component that relays >> requests from one binding to another. I may need to inspect and transform >> the request before relaying it. >> >> Is there a way for a component to implement a generic invocation interface, >> get the invoked operation and input and relay it to a reference? >> >> Thanks >> -- >> Jean-Sebastien >> > > Hi Jean-Sebastien > > The only place we've done this kind of thing to date is with the JMS > binding which dictates that a component must be able to implement an > onMessage(JMSMessage) style interface. > > This is supported under the covers using Operation Selection (and > somewhat orthogonally Wire Format) handlers that can be specified as > part of the binding in the composite file. This is described on a > binding by binding basis. The Assembly spec describes wire format and > operation selection generally. > > You can see some examples in the JMS itests [1]. However these tests > don't explicitly show the user configuration of an operation selector > being installed to enable the onMessage pattern. There is an operation > selector [2] but it's installed automatically to follow some, rather > complicated, default rules described in the JMS spec. > > An option is to write your own operation selection handler and have it > always select a generic operation on a component if such a generic > interface is available. You are then in control and can pass anything > you like into that operation including the name of the target > operation and the message contents. A word of warning though. Not all > of our bindings support operation selection or wire formats just yet. > I believe that JMS, WS and HTTP do. > > Simon > > [1] http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/itest/jms/ > [2] > http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/operationselector/jmsdefault/runtime/OperationSelectorJMSDefaultServiceInterceptor.java > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com
