Page History

...

• isn't <java.interface /> mandatory for a <service />?
  • removed the line and ran the test case and it passed
  • SL - No, if you remove the interface.java element the runtime will derive the interface by looking at the service implementation
• <tuscany:binding.rmi uri="rmi://localhost:8099/CalculatorRMIService"/>
  • what does the uri attribute mean?
  • is it the uri where the service can be found? from what i understood tuscany will also deploy the service and make it available, what if the host is not localhost?
  • SL - you can use the uri to configure the binding to create the RMI endpoint at a certain address. If you omit it Tuscany should create a default endpoint address
    • FM - what if the binding.rmi uri inside a <service> specifies a host other than localhost? First of all, i believe that host should be "tuscany aware", but does tuscany know to make this kind of distributed deployments? If this is possible, please give more details.
    • Ant - i think ideally where possible we should try to avoid using absolute uri's in any of the Tuscany samples. And we should try to keep the composites as simple as possible too, so eg unless the sample is actually demonstrating how to override the defaults then probably it shouldn't even be specifiying the uri attribute instead just using the defaults.

sample-contribution-binding-sca-calculator

...

• ran mvn jetty:run, opened _http://localhost:8080/sample-store-webapp/_^{Image Removed} and i'm getting "TypeError: Cannot call method 'get' of undefined"

...

• i can see some of the .composite configurations have moved to annotations. please confirm that the @Service and @Callback class level annotations are the equivalent of <service/> and <callback/>
• is @Remotable enabling an interface to be injected remotely to another component? Why didn't it appear in the samples? Is this used by default for services?
• just to make things clear, @Remotable and @Callback annotations at class level should be used on interfaces as they interfaces will get injected (or probably proxies to the implementation) and @Service annotation should be used on the implementation classes. Please confirm this as at first sight seemed to me odd that a @Service is not @Remotable (didn't notice the annotation on the interface). might be helpful for someone
• @Callback annotation at class level denotes that the current interface will have a callback interface too and it might help somebody confused about this.nothing more. This is confusing as the first thing that comes into your mind when seeing an interface marked with @Callback is that it is a callback interface (naming on the interfaces helped that as well as they are very similar). And then you see it is implemented by the service provider and everything becomes unclear. What does this annotation help for? The callback interface is not a part of the service interface (methods cannot be called from outside), it's just about the internals of the service. Would be the @Callback annotation at instance variable level enough for injection? Is this used to facilitate the generation of configurations like
  <interface.java interface="somepackage.MyService"
  callbackInterface="somepackage.MyServiceCallback"/>
  Is this necessary so that when a component makes a call on that service and implements the callback interface to be aware of the fact that it should send a reference of it to be injected?

itest-callback-basic-ws

• very good .composite. if updated with the 4th method might be a very good candidate to become a sample.

itest-callback-complex-type

• what is this different than itest-callback-basic or itest-callback-api?

itest-callback-multiple-wires

• what is @Scope annotation? what other values can it have?
• what is @OneWay annotation?
• explain what multiple wires refers to

general questions

• how is tuscany runtime loaded in tomcat when deploying a war for instance. to be more specific, how is tomcat made aware of tuscany nature of the project?
  • SL - If you choose the package the Tuscany runtime inside the WAR then there is a Tuscany filter that's configured in the web.xml file. There is also some deeper Tuscany integration in which case the Tomcat runtime itself is updated to understand Tuscany contributions in which case you don't need to package the Tuscany runtime inside the contribution war
• define the term tuscany contribution and other ways of "packaging" tuscany composites
• if for a callback or a service no wiring is specified how is injection done? json? does tuscany choose a default wire?

general suggestions

• the above questions have risen after trying to learn about tuscany exclusively browsing the website and the samples. meanwhile, i found the osoa website and specifications http://osoa.org/display/Main/Service+Component+Architecture+Specifications which i read after going through the samples and helped me answer many of my questions (especially the annotation ones). maybe it will be a good idea to have a special page on the tuscany website which would contain the up-to-date specifications from osoa. the documents were really helpful.
• i think one question that comes to your mind when reading about tuscany would be what overhead does for example <binding.ws/> add to an application. how much heavyweight/lightweight is each binding. what infrastructure do they use (e.g. jms). covering these aspects in the documentation would be very useful for a person reading about tuscany for the first time.