Re: [DAS] What's next for Tuscany DAS ?
I have attached patch for TUSCANY-961+ TUSCANY-986 combined in TUSCANY-961. One observation here - Generated code shows usage of deprecated method FactoryBase.getProperty(Type, int) and needs to be replaced by getLocalProperty(), any changes needed in xsdtojava generator in SDO? Any suggestions? Regards, Amita On 8/22/07, Luciano Resende [EMAIL PROTECTED] wrote: With the DAS beta1 release out, I'd like to look forward to things that we want to do next for DAS. I think that there are still couple things that we can improve our core DAS features, the main one would be adding support for multiple DAS implementations, and review our SDO 2.1 APIs usage. As for our history with SCA integration, we have started efforts around Data Services/Declarative DAS (implementation.das) and Data Feeds (implementation.data), and this is probably another area we would like to continue to work going forward. I also think we should continue to improve our user documentation and distribution infrastructure to make our release cut easier. Below is a summary list of items and JIRAs that are related to these possible items : - TUSCANY-986 - DAS integration with SDO 2.1 APIs - TUSCANY-961 - DAS: Using deprected SDO method causes Type lookup failure - Refactoring DAS to allow multiple implementatons As for timeframe, maybe it would be good to have a release in the next couple weeks, to support SDO 1.0 and be available to the SCA release, so we can have the integration story with SCA available. This is just of brain dump of where my thinking is at the moment, I'm sure everyone has their own thoughts about things we should tackle. It would be good to get to them all on the table :-) Thoughts ? -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem configuring and reaching RSS, Atom bindings
hi skip, Skip Schuler [EMAIL PROTECTED] wrote on 08/27/2007 02:13:57 PM: I'm trying to leverage the atom and rss bindings to expose some feeds using java sca build 0.91. More specifically I'm trying to deploy a war on my Tomcat instance. I have a class that implements org.apache.tuscany.sca.binding.feed.Feed, however I'm not having any success in reaching the atom or rss endpoints (which may be due to my understanding). Anyway, here's my configuration; .composite: service name=RSSSampleFeed promote=AtomFeeder binding.rss/ /service service name=AtomSampleFeed promote=AtomFeeder binding.atom/ /service component name=AtomFeeder implementation.java class=com.schuler.feed.FeederImpl / /component web.xml: servlet-mapping servlet-nameTuscanyServlet/servlet-name url-pattern/SCA/*/url-pattern /servlet-mapping The URL http://localhost:8080/feed-atomrss/SCA/AtomSampleFeed fails with a status code 500 (see below). it seems that your are missing something. for exposing your feeds you don't necessarily put your app manually in tomcat, tucany can do it for you. i suggest that you have a look at the following example, which should clarify some points: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/feed-aggregator/ How can I reach the rss and atom endpoints? What will the URL be, and what are correct binding configurations in the .composite? the URL depends what you specify in the binding, for example: service name=rssSample promote=RssAggregator tuscany:binding.rss uri=http://localhost:8083/rssAggregator/ /service -Florian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: throws Exception clause of service method create problem
Radim Kolarik wrote: Hi ant, when is the move to Axis 1.3 planned? Will it make it to the upcoming release? Thanks, Radim Hi Radim, The 0.99 release (which we are currently voting on) uses Axis 1.2. We're just starting to talk on tuscany-dev about cutting the 1.0 release branch around mid-September. I'd like it to use Axis 1.3 if others on the tuscany-dev list are OK with it. In the meantime, you can try to build Tuscany with Axis 1.3. Somebody else already tried and it seems to work, see [1]. [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg22310.html -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Load-balancing between service instances
Simon Laws wrote: On 8/9/07, Maciek Chociej [EMAIL PROTECTED] wrote: Hello, Recently I've been investigating the same thing. I'm trying to rebuild our in-house SOA platform with the use of Tuscany. What I am lacking is clustering, dynamic lookup and load balancing of service providers. I don't think I need that for local wiring, so I just focused on providing those over the ws binding. From what I see right now it is possible to do that rather gracefully in a number of ways. For example on the remote side, you can use your web container's clustering scheme. For example Tomcat clusters might balance request to the axis servlets responsible for the ws.binded services, the downside of this is that the balancing gets out of Tuscany's control. On the other hand, on the local side (which I find much nicer) I've tampered a little with the ws axis binding and it should be easily possible to inject a UDDI or similar ws lookup into the ReferenceBindingProvider or to build a 'lookup' version extending the axis one. I'm rather new to Tuscany so any comments appreciated. Cheers Maciek Olivier Collard wrote: Hi, I'm wondering how I could implement load-balancing with Tuscany. Basically, I would need the ability to configure component X to talk to multiple instances of another component Y. Ideally, this would be like 'wiring' a reference to multiple instances of component Y, running either locally or remotely. Would I need to write some kind of extension for this? Thanks, O. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi This is an interesting thread. The easy answer is that you are both right that we haven't addressed load balancing or clustering directly just yet. We are working on a first step at the moment which might make some of this easier. That is the ability to have an SCA domain run across multiple nodes (JVMs). We have had a very simple version of this for a while and we are bringing it up again now on top of the new wiring mechanism and new SCA binding. The basic idea here is that you have parts of the domain, i.e. component services, running on separate nodes and Tuscany is able to locate which node is running which service. So this could be considered load balancing in that it allows you to distribute your application across a number of nodes but it's not load balancing in the sense that Olivier mentioned. I.e. spreading the load on a single component/service. I think Maciek is on the right track though. I like the ideas about having a new binding that is able to provide this feature within a Tuscany domain with reference to some registry of services. It would certainly be interesting to do this with a binding based on the web services binding with, as suggested, suitable logic to look up target services and pick one from the list of returned endpoints. Running inside a clustered container should also be a possibility. A you say we would expect the clustering to be outside Tuscany's control in this case and we would have to engineer for the registry of service endpoints to have the address of the head node rather than the individual servers where Tuscany is running components in the cluster. We would also need to look out for session replication issues. Either of you interested in doing some work on this? Regards Simon So I guess there's at least two options: [a] leverage the Tomcat clustering / load-balancing capabilities (make sure that Tuscany works OK in that environment) [b] write a binding extension, or tamper with an existing one :) to add load-balancing in Tuscany If any of you are interested in doing some work on this, here are a few pointers: - a simple distributed sample, which could be used as a starting point to demonstrate some load-balancing http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-distributed/ - the Tuscany SCA default binding, which uses a simple registry shared on the network to record endpoints of services as they start, and to resolve these endpoints later the binding extension http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-sca-axis2/ the distributed registry http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed-impl/ We're just at the beginning of implementing this so it's the right time to jump in if you want to add some load-balancing :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL
Re: [DAS] Transaction support - a bigger picture question
Comments inline. [snip] Amita Vadhavkar wrote: I have not worked on the latest DAS-SCA integration so far, and am quite sure Lucinao will have good pointers in this area. But looking at the current tuscany-implementation-das, can see the following possible. Yes, I guess the idea is to: - access Data inside an SCA component declared with implementation-das - let the application developer annotate the component implementation and services with transaction policy intents to indicate what he wants in terms of transaction So take this as my attempt to understand intents/policySets and DAS-SCA integration :) DASImplementation implements org.apache.tuscany.sca.assembly.Implementationand contains org.apache.tuscany.sca.assembly.Service dasService. Using dasService, requiredIntents on the Service can be found. There are two categories of policy intents in SCA: - implementation policy intents - used to indicate requirements of the component implementation (authorization for example, i.e. you must be authorized to execute my implementation) - interaction policy intents - used to configure how a component will interact with others (confidentiality for example, i.e. messages exchanged with my component must be encrypted) I think that the same will have to apply to transactions as well, the DAS implementation will probably have to deal with intents specified on both services and the implementation itself. org.apache.tuscany.das.rdb.DAS interface can be enhanced to accept these intents. DAS internally can configure DASConfig reflecting the intents specified , so that DAS instance construction happens with correct attributes. Based on these attributes DAS transaction control will occur (if intent is TransactionControl). Intent TransactionControl can be qualified as say, 1) Container Transaction Control, 2) DAS Transaction Control. Can you describe this a bit more to help me understand what you mean by Container transaction control vs DAS transaction control? Advantage of having intent attached to a service will be, using different intents for different services of same component. Yes, different services - different interaction policies Questions: What will be the policySets here? Say, if policySet/intent Container Transaction Control mandates that the implementation should expose getConnection() so that container Runtime can use it, how this mandate can be achieved? Not sure at all yet. A PolicySet translates an Intent to the corresponding configuration of the underlying runtime, so it really depends on what the DAS + SCA runtime will expect. [snip] On 8/20/07, Mike Edwards [EMAIL PROTECTED] wrote: Folks, Sorry to cut across the discussion about Transaction support in DAS, but are folks aware of the proposal for Transaction support in SCA? which leads to the entertaining question of how the DAS transaction support relates to the SCA transaction support. The problem at the moment is that the SCA spec group only has an unpublished draft of the Transaction support spec. The intention is to publish an updated draft in the near future. However, I can say that the SCA spec mechanism is based on the use of Intents to apply transactional characteristics to SCA components. I've seen several exchanges on the list already from people interested in some support for transactions... So since the spec is not ready yet, how about starting now with something really simple like an implementation policy intent that would just say: - transaction - i.e. my implementation must run as part of a transaction - noTransaction - i.e. I don't want to run as part of a transaction It may look simplistic, but will help us understand the end to end story, work on the necessary plumbing and integration with a transaction manager etc. and we can always add more later and adjust the details of the intents and policySets when the spec is ready. Thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
