Re: Configuring and loading Composites and/or components at runtime?
On 10/19/07, Jason Clark [EMAIL PROTECTED] wrote: More questions :-) See below. -Jason -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 9:42 AM To: tuscany-user@ws.apache.org Subject: Re: Configuring and loading Composites and/or components at runtime? Hi Jason, Welcome to Tuscany! Comments below... Would be great to have your input on how some of these features should work . So keep asking the questions:-) Regards Simon On 10/18/07, Jason Clark [EMAIL PROTECTED] wrote: Another question. Is there a way to load composites and components at runtime? I'm looking at issues of distributed application survivability and in the event that a given service is no longer functional (hardware crash, or other problems), I want to be able to relaunch a portion of the domain after the component crashed. Is that possible? There is an api for loading composites. It you look at most of our samples you see that they use a domain api to read a composite file which has the effect or loading the application. We are doing some work on the node and domain apis now so they have moved on a little from the 1.0 release. The idea with the distributed domain is that you can have mulitple nodes in a domain. A node is something that will run SCA applications, i.e. read and run an SCA contribution. The nodes register with the domain and when the nodes expose services they register those with the domain also. With this information you can build SCA applications without having to explicitly specify endpoints as long as you are connecting components within the domain. Does this mean you can only restart composites and not components within a composite? If 1 component crashed, I would have to shutdown and restart the entire composite? Currently the level of granularity of the API is start/stopping composites but under the covers this deals with individual components so that could be opened up relatively easily. This is actually one of the areas we have been debating, i.e. what level of control should be provided. Can you say a little more about what it means for you when a component crashes. What is the sign that a component has crashed? Is an exception reported? What are the implications for restarting a component? Are you restarting some other system that the component is wrapping? If a node crashes you can just restart is again and it will re-register. There is a bit of code commented out in the invoker for the default binding that does retries and looks up the endpoint again in the case that the endpoint can't be reached, i.e. the target node has failed. There was some issue with it so that needs looking at but if we fix that then basic restarts should be ok. The best example I could find in the samples in the calculator-distrubuted example in the 1.0-incubating release, but the readme file lists a few resource directories that are not in the project (resource/domain, resource/management). Is the readme incorrect or are the files really missing? Yeah, that looks like a mistake in the documentation. Can you raise a JIRA for that and I'll fix it. The connection between the domains and the nodes within it is actually implemented as an SCA application. That's what the domain and management directories had in them. These have been moved now and are currently node-impl/src/main/resources/node.composite and domain-impl/src/main/resources/domain.composite which seemed to make more sense. I can't seem to locate these two directories. I feel like I'm looking in the wrong place though. I'm guessing it's not in the sample project? Second, do I even need to see them? Are they general composites used to construct nodes, or are they specific to the calculator sample? You are right, you don't really need to see them. Was just giving you a bit of background. There are system composites that are used by the node and domain implementations to communicate with one another. They aren't specific to the calculator-distributed sample which is why they were moved. They can be found in trunk here http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/domain-impl/src/main/resources/ http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/node-impl/src/main/resources/ You may have noticed already the way that the SCA code is layed out. All of the modules that provide SCA runtime features appear under the modules directory. You can only see the modules in a source distribution.. Some of these modules are loaded statically and some are loaded dynamically (primarily optional bindings, databindings and extensions). Then you see there are samples and demos that show various features being used. Also in trunk, but not in the distributions, you see there is an integration test (itest) directory. Thanks.
RE: Handling authentication for non-web services?
-Jason # This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. # -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Friday, October 19, 2007 2:21 AM To: tuscany-user@ws.apache.org Subject: Re: Handling authentication for non-web services? On 10/19/07, Jason Clark [EMAIL PROTECTED] wrote: That's a lot of text to scroll through, so I'll just add my comments at the top. In regards to how the service is selected, this is based on information within the message. Authentication simply determines if the message is allowed to pass on. In regards to the protocol between tomcat and the service, once authentication is accepted, the message is simply forwarded to the service. The service itself handles the entire message parsing. There seem to be some alternatives here then. Convert the current services to SCA Components and maintain the servlet routing component. This would be my first suggestion to get you up and running and give you a feel for what Tuscany can do. The servlet of course needs to talk to the services. This can be done either locally or remotely using a binding of your choice. So the servlet would need to be modified to hold references to services in the SCA domain. You can see examples of Tuscany running in a web app, for example, calculator-webapp. These webapp samples don't run as part of the distributed domain yet but I'm looking at that at the moment. I don't want to give the impression that I think everything must live inside of SCA but just thinking aloud about some other things that could be done... Based on what you have said already I'm assuming that you can't change your clients and that they currently provide the XML message as part of an HTTP POST. Construct a gateway component (in place of the servlet) that accepts the XML over an HTTP binding. The function of the component would be to route the message to wired components based on the contents of the XML. To make this work we'd have to fix up binding.http to accept POSTed data. On the OSOA page, there is a section on bindings that covers ws and jms, but I have been unable to find documentation on the http, rss, and atom bindings. Is there any documentation that outlines the schema for the various bindings available? I've seen discussions recently about hosting web applications in SCA as well as the other way round. So in the future the solution maybe that you just take the servlet you have and deploy that as a component. There's no support yet though. Construct a set of policies to handle the LDAP based authentication activity for binding.http . I've seen the WS policies sample, but I'm still trying to figure the policies system out. If it's not a bother, can you give me a quick example on how I would deal with LDAP based authentication for the http binding given that user name and pw have been passed in the message? If you can change your clients then there are of bindings that could be used while keeping the same XML message structure. The service interface extends our own general MessageService interface which has methods for receiving text messages it will have to parse as well as a more specific service interface for places where services can make method calls directly. I don't understand the last bit about more specific service interface for places where services can make method calls directly. Should it read ...where clients can make method calls directly? In this case, I meant the service interface for a reference given to a service. This isn't that important given that all the service interfaces can be modified at the moment. We're actually moving into phase II of the project where phase I was just prototyping. So it can all be modified at the start of the new phase. This was more or less an initial attempt at a roll-our-own service component architecture if you will, before I even knew how to goggle those 3 words together. I didn't even know SCA existed until last week. HA! I don't want to keep writing code for something that already exists. Glad you found us! By TCP, I meant socket, to keep a persistent connection with our application due to some real-time processing requirements, i.e. someone posts some information, we want it pushed as quickly as possible out to the clients. As We don't support TCP sockets directly. All of our bindings are currently at a higher level but of course
Re: Why there is no tuscany-binding-jms-1.0-incubating.jar in release apache-tuscany-sca-1.0-incubating.zip
The following JIRA [1] has some more info on the JMS Binding and it's current status. [1] https://issues.apache.org/jira/browse/TUSCANY-1789 On 10/19/07, JunJie Nan [EMAIL PROTECTED] wrote: $ ls modules/*-binding-* modules/tuscany-binding-dwr-1.0-incubating.jar modules/tuscany-binding-ejb-1.0-incubating.jar modules/tuscany-binding-feed-1.0-incubating.jar modules/tuscany-binding-http-1.0-incubating.jar modules/tuscany-binding-jsonrpc-1.0-incubating.jar modules/tuscany-binding-notification-1.0-incubating.jar modules/tuscany-binding-rmi-1.0-incubating.jar modules/tuscany-binding-sca-1.0-incubating.jar modules/tuscany-binding-sca-axis2-1.0-incubating.jar modules/tuscany-binding-sca-xml-1.0-incubating.jar modules/tuscany-binding-ws-1.0-incubating.jar modules/tuscany-binding-ws-axis2-1.0-incubating.jar modules/tuscany-binding-ws-xml-1.0-incubating.jar I can not find it on maven2 repository too. Any story? Thanks! -- Cheers Jun Jie Nan ∧ ∧�� ミ^ō^ミ灬)～ -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Why there is no tuscany-binding-jms-1.0-incubating.jar in release apache-tuscany-sca-1.0-incubating.zip
$ ls modules/*-binding-* modules/tuscany-binding-dwr-1.0-incubating.jar modules/tuscany-binding-ejb-1.0-incubating.jar modules/tuscany-binding-feed-1.0-incubating.jar modules/tuscany-binding-http-1.0-incubating.jar modules/tuscany-binding-jsonrpc-1.0-incubating.jar modules/tuscany-binding-notification-1.0-incubating.jar modules/tuscany-binding-rmi-1.0-incubating.jar modules/tuscany-binding-sca-1.0-incubating.jar modules/tuscany-binding-sca-axis2-1.0-incubating.jar modules/tuscany-binding-sca-xml-1.0-incubating.jar modules/tuscany-binding-ws-1.0-incubating.jar modules/tuscany-binding-ws-axis2-1.0-incubating.jar modules/tuscany-binding-ws-xml-1.0-incubating.jar I can not find it on maven2 repository too. Any story? Thanks! -- Cheers Jun Jie Nan ∧ ∧�� ミ^ō^ミ灬)～
Re: [DISCUSS] Tuscany SCA Roadmap and next releases
Simon Laws wrote: On 10/17/07, Raymond Feng [EMAIL PROTECTED] wrote: I collected all the input we have so far at the following WIKI page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion Thanks for doing that! Coincidentally there's a recent news article related to the worthwhileness of these types of lists over on INFOQ: http://www.infoq.com/news/2007/10/product-backlogs-wasteful We did try having the wishlist jira version but it never really ended up being used very much. ...ant [snip] Thanks for the ref ant. Very interesting. In our case the list we have generated is very much a list of features desired but not yet implemented.I wasn't suggesting we take the next step and analyse them all in detail though, just that we don't loose these thoughts in case someone decides that they would like to do the analysis in the future. I think this thread is equating the act of creating a Roadmap with identifying the ideas that the currently active community agree will add real value to Tuscany SCA and it's users. I'm keen though that we don't create an immutable plan/roadmap and that we have plenty of ideas hanging around that may encourage those not currently contributing to do so. I see the danger of a stated roadmap is that it gives the impression that that is what is going to happen, that all the items are being worked on and encourages people to sit back and wait for features to arrive. Re. the wish JIRA type. maybe now is the time. The wiki page is a long list already. Wish list items don't require much management, they may hang around for a long time but they provide inspiration to newcomers and to the active community when we inevitably repeat this exercise. Regards Simon How about trying to understand the use cases for that Wiki page and/or JIRA list? Here are a few: A) I just found out about SCA and Tuscany. I want to know what it does now and what it'll do in the future. B) I'm using Tuscany. I want to know what features will be provided, short, middle and long term. C) I'd like to contribute to Tuscany. Who's working on what and are there any interesting areas that I could jump into? more thoughts? Here are some roadmaps that I found worthwhile and useful as a lurker, user, and potential contributor. There are some good organization + format ideas in these roadmaps: [1] http://harmony.apache.org/roadmap.html [2] http://cwiki.apache.org/GMOxDEV/roadmap-for-21.html [3] http://cwiki.apache.org/GMOxPMGT/geronimo-what-folks-are-working-on.html [4] http://wiki.apache.org/ws/FrontPage/Axis2/post-1%2e3-plans [5] http://ode.apache.org/roadmap.html [6] http://subversion.tigris.org/roadmap.html Going back to the use cases: IMO a roadmap like [3] answers question (C), and questions (A) and (B) too... as seeing people names and the releases that they target shows that the listed features are not just wishes or vaporware. Hope this helps. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Configuring and loading Composites and/or components at runtime?
-Jason # This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by another person is strictly prohibited. # -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 9:42 PM To: tuscany-user@ws.apache.org Subject: Re: Configuring and loading Composites and/or components at runtime? On 10/19/07, Jason Clark [EMAIL PROTECTED] wrote: More questions :-) See below. -Jason -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 9:42 AM To: tuscany-user@ws.apache.org Subject: Re: Configuring and loading Composites and/or components at runtime? Hi Jason, Welcome to Tuscany! Comments below... Would be great to have your input on how some of these features should work . So keep asking the questions:-) Regards Simon On 10/18/07, Jason Clark [EMAIL PROTECTED] wrote: Another question. Is there a way to load composites and components at runtime? I'm looking at issues of distributed application survivability and in the event that a given service is no longer functional (hardware crash, or other problems), I want to be able to relaunch a portion of the domain after the component crashed. Is that possible? There is an api for loading composites. It you look at most of our samples you see that they use a domain api to read a composite file which has the effect or loading the application. We are doing some work on the node and domain apis now so they have moved on a little from the 1.0 release. The idea with the distributed domain is that you can have mulitple nodes in a domain. A node is something that will run SCA applications, i.e. read and run an SCA contribution. The nodes register with the domain and when the nodes expose services they register those with the domain also. With this information you can build SCA applications without having to explicitly specify endpoints as long as you are connecting components within the domain. Does this mean you can only restart composites and not components within a composite? If 1 component crashed, I would have to shutdown and restart the entire composite? Currently the level of granularity of the API is start/stopping composites but under the covers this deals with individual components so that could be opened up relatively easily. This is actually one of the areas we have been debating, i.e. what level of control should be provided. Can you say a little more about what it means for you when a component crashes. What is the sign that a component has crashed? Is an exception reported? What are the implications for restarting a component? Are you restarting some other system that the component is wrapping? One of my biggest concerns is application survivability. My work is in the realm of Disaster Management, so one of my requirements is to have an application that more or less self heals. If part of it fails, it needs to recognize that and fix the problem. I guess if a component reports a problem, the entire composite can be restarted, but it might be nice to create a composite, part of which contains a health monitoring component that contains a reference to every other component. Should one fail, it could be restarted? To be honest, I don't know the solution to my problem and I don't know best practices for dealing with this sort of situation, so I'm more or less grasping at straws trying to figure out how to solve my dilemma. For a component to crash would be that the hardware failed, or the component threw an exception. In the latter case, most likely that would be a programming error for a rare case we didn't consider. The component might go up and down for as long as it takes for us to patch the app. For the former, I'm still trying to understand if it's even possible to restart a component on a different machine. If I understand everything correctly, this would be possible to do at the composite level. Can components of a composite even run on separate machines? I mean, not a reference but the actual instance? All domains get launched with a composite, of which another composite can reference as a component correct? Kind of? Or am I way off? If a node crashes you can just restart is again and it will re-register. There is a bit of code commented out in the invoker for the default binding that does retries and looks up the endpoint again in
Re: Testing my service
On 10/19/07, Ana Belén Antón Gironés [EMAIL PROTECTED] wrote:
Hi!
I have a problem with the test of my application. The tearDown() test
fails,
and I don't know what is happening. When I run my JUnit test I get this
message:
java.lang.NullPointerException
at eu.services.information.tests.ISTestCase.tearDown(ISTestCase.java:25)
at junit.framework.TestCase.runBare(TestCase.java:136)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java
:35
)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
(JUnit4TestRef
erence.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java
:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner
.java:196)
My test is:
==
package eu.services.information.tests;
import junit.framework.TestCase;
import org.apache.tuscany.sca.host.embedded.SCADomain;
import eu.services.information.is.InformationService;
/**
* This shows how to test the IGS component.
*/
public class ISTestCase extends TestCase {
private InformationService is;
private SCADomain scaDomain;
@Override
protected void setUp() throws Exception {
SCADomain scaDomain = SCADomain.newInstance(Information.composite);
is = scaDomain.getService(InformationService.class,
InformationServiceComponent);
}
@Override
protected void tearDown() throws Exception {
scaDomain.close();
}
public void testIS() throws Exception {
assertEquals(is.getInformationObject(myInformationObject).getText(),
myTest);
assertEquals(is.getInformationObject
(myInformationObject).getId(),
myId);
}
}
===
Have you got any idea about what is wrong? Thanks in advance!!
Ana Belen.
Hi Ana Belen
I quite often see this when there is some exception in the setUp phase that
isn't caught and printed out. The result is that scaDomain remains null and
hence JUnit calls tearDown() and calling scaDomain.close() causes a null
pointer exception. Try putting a try/catch around the code in setUp and
print out any exceptions that are thrown.
Hope that helps
Simon
Testing my service
Hi!
I have a problem with the test of my application. The tearDown() test fails,
and I don't know what is happening. When I run my JUnit test I get this
message:
java.lang.NullPointerException
at eu.services.information.tests.ISTestCase.tearDown(ISTestCase.java:25)
at junit.framework.TestCase.runBare(TestCase.java:136)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35
)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestRef
erence.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)
My test is:
==
package eu.services.information.tests;
import junit.framework.TestCase;
import org.apache.tuscany.sca.host.embedded.SCADomain;
import eu.services.information.is.InformationService;
/**
* This shows how to test the IGS component.
*/
public class ISTestCase extends TestCase {
private InformationService is;
private SCADomain scaDomain;
@Override
protected void setUp() throws Exception {
SCADomain scaDomain = SCADomain.newInstance(Information.composite);
is = scaDomain.getService(InformationService.class,
InformationServiceComponent);
}
@Override
protected void tearDown() throws Exception {
scaDomain.close();
}
public void testIS() throws Exception {
assertEquals(is.getInformationObject(myInformationObject).getText(),
myTest);
assertEquals(is.getInformationObject(myInformationObject).getId(),
myId);
}
}
===
Have you got any idea about what is wrong? Thanks in advance!!
Ana Belen.
Re: Handling authentication for non-web services?
On 10/19/07, Jason Clark [EMAIL PROTECTED] wrote: That's a lot of text to scroll through, so I'll just add my comments at the top. In regards to how the service is selected, this is based on information within the message. Authentication simply determines if the message is allowed to pass on. In regards to the protocol between tomcat and the service, once authentication is accepted, the message is simply forwarded to the service. The service itself handles the entire message parsing. There seem to be some alternatives here then. Convert the current services to SCA Components and maintain the servlet routing component. This would be my first suggestion to get you up and running and give you a feel for what Tuscany can do. The servlet of course needs to talk to the services. This can be done either locally or remotely using a binding of your choice. So the servlet would need to be modified to hold references to services in the SCA domain. You can see examples of Tuscany running in a web app, for example, calculator-webapp. These webapp samples don't run as part of the distributed domain yet but I'm looking at that at the moment. I don't want to give the impression that I think everything must live inside of SCA but just thinking aloud about some other things that could be done... Based on what you have said already I'm assuming that you can't change your clients and that they currently provide the XML message as part of an HTTP POST. Construct a gateway component (in place of the servlet) that accepts the XML over an HTTP binding. The function of the component would be to route the message to wired components based on the contents of the XML. To make this work we'd have to fix up binding.http to accept POSTed data. I've seen discussions recently about hosting web applications in SCA as well as the other way round. So in the future the solution maybe that you just take the servlet you have and deploy that as a component. There's no support yet though. Construct a set of policies to handle the LDAP based authentication activity for binding.http . If you can change your clients then there are of bindings that could be used while keeping the same XML message structure. The service interface extends our own general MessageService interface which has methods for receiving text messages it will have to parse as well as a more specific service interface for places where services can make method calls directly. I don't understand the last bit about more specific service interface for places where services can make method calls directly. Should it read ...where clients can make method calls directly? This was more or less an initial attempt at a roll-our-own service component architecture if you will, before I even knew how to goggle those 3 words together. I didn't even know SCA existed until last week. HA! I don't want to keep writing code for something that already exists. Glad you found us! By TCP, I meant socket, to keep a persistent connection with our application due to some real-time processing requirements, i.e. someone posts some information, we want it pushed as quickly as possible out to the clients. As We don't support TCP sockets directly. All of our bindings are currently at a higher level but of course ultimately built on TCP. Is it important that it is TCP or just that the client is listening waiting for a message? far as I can tell, this isn't possible with web clients. (We have both a web front end and a thick client app to the program). It depends how your web client has been written. For example, we have a level of support for this kind of thing in binding.dwr which allows a fake reference to be construct from services back to a web client. Under the covers it is using some HTTP tricks to make it happen. The SCA programming model more generally has some concepts that might help. The implication of having an open socket between the client and a service is that the service holds state about this connection.Typically we try to think of services as being stateless but it is often that some state must be maintained in some circumstances. It might be worth thinking about how to formalize this relationship with callback and/or a conversational semantics. -Jason -Original Message- From: Simon Laws [mailto:[EMAIL PROTECTED] Sent: Thursday, October 18, 2007 12:10 PM To: tuscany-user@ws.apache.org Subject: Re: Handling authentication for non-web services? Hi Jason I expect others in the project who are closer to some of the non web services bindings will have their own views on this. Am setting the ball rolling by asking some questions. See below. As a general rule I would try and start simple so I wouldn't necessarily dive into thinking about new bindings, policies etc. in the first instance. Have a go with your front end and an SCA service behind it and then expand from there. Even with this you might be facing
[SDO JAVA] JIRA priorities for the next release
I'm looking through the mounting number of JIRAs in SDO Java and hope to knock a few down. It would be good to get another release in plan. What do people want in it? I'm going to be doing a full pass through the open JIRAs in the near term and flag up my own priorities. Regards, Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
