sample-contribution-binding-rmi-calculator-service

  • 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

  • what is enabling the loading of the .composite files? don't see any scaDomain...
  • SL - In some of the samples (the ones based on the calculator scenario) we've separate the contribution module from the launcher module. In normal circumstances this is reslistic as people will develop contributions and then deploy them to a runtime. In the sample case there are a number of different launchers that start the Tuscany runtime in different ways and all should be able to run all of the contributions although there are some restrictions at the moment.
    • FM - This was probably one of the things that i found hardest to find information about: the ways of starting a Tuscany runtime. The samples analyzed on the website are started using ant run or the Tuscany plugin for Eclipse with Run As -> Tuscany. Browsing the site, you can probably find mvn jetty:run. This leaves many questions: how can the runtime be started without the use of auxiliary tools like ant, maven, etc? Going through the samples, you can find out about scaDomain, NodeFactory or org.apache.tuscany.sca.host.webapp.TuscanyContextListener but you don't have any further information about them and especially about the mechanisms behind them. This list http://tuscany.apache.org/documentation-2x/getting-started.html seems very good but does not provide too much information.. Updating this list and providing a description of how these methods work would cut a lot of the time spent on understanding how the runtime can be manipulated and used, significantly decreasing the time needed to learn how to use Tuscany.

sample-contribution-binding-ws-calculator

  • what would be the differences between <binding.ws /> inside <service/> and inside <reference />
    • SL - the binding inside the service confiures the protocol over which a component service is exposed. The binding inside the reference configures the protocol over which a component access a service provided elsewhere.
  • is the one in <service> exposing the webservice and the one in <reference> specifying where the reference can be found?
    • SL - yes
  • what triggers the webservice to be deployed?
    • SL - deploying the contribution to the Tuscany runtime.

sample-contribution-implementation-java-calculator

  • what are the differences between this sample and sample-contribution-binding-sca-calculator?
    • SL - at the moment there is no difference but you have probably noticed that we have started grouping the samples in directories that describe which SCA feature the sample is specifically demonstrating. It just so happens that this contribution uses implementation.java

sample-helloworld-jaxrs-webapp

  • <listener><listener-class>org.apache.tuscany.sca.host.webapp.TuscanyContextListener</listener-class></listener>
    • is this loading the tuscany runtime?

sample-helloworld-jms-webapp

  • what is org.apache.tuscany.sca.host.webapp.TuscanyServletFilter doing?
  • how is implementation.web working?

sample-helloworld-js-webapp & sample-helloworld-jsp-webapp

  • how is the domain injected on the client side (web page)? i see the calls are made directly from the html/jsp page, how is the page aware of the services it can call? it just receives a list of the services and their metods, or what is the format? i'm referring to things like:
    • componentContext.getService("service").sayHello(document.getElementById('name').value, sayHelloResponse); in javascript
    • <sca:reference name="service" type="sample.HelloworldService" /> in JSP

sample-helloworld-spring

  • how is implementation.spring working? only the spring file is specified, what if there were multiple beans inside?
  • could there be the bean instantiation done with spring and only the wiring with tuscany?

sample-store

  • how did var catalog = new tuscany.sca.Reference("catalog"); get imported?
  • in store.composite why does implementation.widget need binding.http but a servlet or jsp hasn't binding.http specified?
  • isn't this desktop application? Running Launch.java starts a Jetty server...

sample-store-webapp

itest-callback-api

  • 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 annotations at class level should be used on interfaces as interfaces will get injected (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 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.
  • No labels