Put Raymond's DataMediation into sandbox? - WAS:RE: TypeHelper WAS: RE: Status of databinding module in sandbox and DataMediation
Hi Jeremy, Thanks for the explanation. I am more convinced now that we should use a data transformation service in binding extension to deal with various data bindings instead of having the data binding knowledge directly embedded in binding (e.g., use SDO TypeHelper directly). To move things forward quickly, I wonder, if most people can agree this is the direction to go, or at least there is no objections to add a data meditation service, can someone has committer right kindly put Raymond's code into sandbox please? Once this code is in svn, we can play with it and help out to resolve the TODO list mentioned by Raymond as well as issues like sdo typeHelper. Thanks, Jervis Liu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Boynes Sent: Thursday, June 29, 2006 9:25 PM To: tuscany-dev@ws.apache.org Subject: Re: TypeHelper WAS: RE: Status of databinding module in sandbox and DataMediation On 6/29/06, Liu, Jervis [EMAIL PROTECTED] wrote: Hi Jeremy, So what is the issue with TypeHelper, and when can this be resolved? SDOXMLHelper.java will need to use typeHelper. Previously in M1, Binding extension can get TypeHelper from LoaderContext, so how can I get it now using the new SPI code? From DeploymentContext? (see sandbox\jboynes\sca\bindings\binding.celtix\src\main\java\org\apache\tuscany\binding\celtix\WebServiceBindingLoader.java). Thanks. The big issue is how does type scoping work in a recursive runtime? This isn't something the spec covers so we need to come up with something. In M1 we had import.sdo to import types for use in a module which worked well at one level. When we add recursion it brings up the question of which types if any get propogated between the outer and inner composites. My first thought is that component types should be able to declare the types that they depend on. This could be done in the sidefile (using import.sdo) or by annotation of the implementation. This is a more general form of what we had in M1 that can be done now that a composite is an extension of a component type. It would then be the responsibility of the thing that used an implementation to make sure that type dependencies in its component type definition were resolved. This is most likely to be in a composite and could be done with a version of import.sdo that referred to type definition information (e.g. an annotated schema instance). I took the typeHelper out of the LoaderContext for a couple of reasons. The first was that I did not want to have the SPI be dependent on SDO classes (thinking that SDO would be a plugin module rather than fundamental). I was also thinking we would need to support multiple type hierarchies (e.g. both SDO and JAXB) and so would need to have an extensibility point for that. Finally, it should be possible to install type heirarchies on their own and one way to do that would be to have type helper instances become system components. To implement this I was thinking we'd have a system service in the SDO databinding plugin that would be a register for type helpers. The databinding would also contibute annotation processors and XML element handlers that would be used by component builders to handle SDO artifacts (like injecting a helper or creating DataObjects during an invocation). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More useful links mentioned @ ApacheCon Tuscany BOF
Here's a recent blog entry from Sun JBI spec lead http://blogs.sun.com/roller/page/rtenhove?entry=what_s_wrong_with_sca On 6/29/06, Oisin Hurley [EMAIL PROTECTED] wrote: More top link suggestions from Jim at the ApacheCon Tuscany BOF: http://www.davidchappell.com/blog/2006/04/why-service-component- architecture-is http://www.davidchappell.com/HTML_email/Opinari_No15_12_05.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On Jun 29, 2006, at 1:47 PM, Ignacio Silva-Lepe wrote: - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, June 29, 2006 12:18 PM Subject: Re: Support for callbacks On Jun 28, 2006, at 7:13 AM, Ignacio Silva-Lepe wrote: I'd like to start working on providing support for callbacks, assuming the sandbox is a good place to do this. Great. In case you haven't seen it, we have some architecture slides in the sandbox under jboynes/sca/doc in tuscany.architecture.v4. In there is information on scopes and wires, among other things. Currently, I am focusing on local, stateless callbacks to begin with. Later, and assuming that conversational support is in place (which I am also keen on contributing to) I can work on stateful and remote callbacks. The first basic issue I see is how to incorporate callbacks as defined in the CI spec in particular, and bi-directional interfaces in general, into the Tuscany architecture. Depending on how closely a RuntimeWire is supposed to correspond to an SCA wire, it seems like one way to incorporate a callback is to extend InboundWire to include an OutboundInvocationChain, and OutboundWire to include an InboundInvocationChain. That is, a wire would include a 'reverse' pair of invocation chain ends to account for a callback.With that in place, it seems feasible to re-use WireInvocationHandler and TargetInvoker in a similar fashion to actually perform the callback invocation. Are there any subtle (or not so subtle) gotchas in this that I am overlooking? I was thinking there would be a couple of things: a system transport service and a conversational scope container. The system transport service would listen for callbacks. That service would dispatch and invoke a component, which in turn would ask its scope container for the component implementation instance to dispatch to. Not sure if I follow. Is the system transport service intended as an alternative for a reverse invocation chain pair? Yes. The system service would be a transport listener which would pick up the callback invocation off of a wire. The callback invocation would be sent from the proxy injected into the target as described below. Do you think it would help if we outlined several of scenarios, e.g. a stateless callback done in the same composite, a stateless callback done across remote boundaries, a stateful callback done in the same composite, and a stateful callback done across remote boundaries? I was thinking we could sketch out what happens and then map it down to the core. The conversational scope container could have a pluggable persistent store API (we could have a simple implementation which serialized to disk and eventually used a journaling mechanism such as HOWL http:// howl.objectweb.org/). Two other basic pieces are: (1) callback injection, and (2) implementation of ServiceReference. Callback injection may be simple enough and similar to reference injection for stateless callbacks, but it'll get more interesting for stateful callbacks (or stateful scopes), as it is not clear that a callback field or method will remain valid for the duration of the component instance, and may need to be re-injected. Couldn't we use a proxy for this to avoid reinjection? In terms of flow, it could possibly work as follows: 1. Client invokes, invocation is passed through a wire 2. Target is invoked. When the target is created (it could be at this point or before), a callback proxy is injected. During the invocation, a threadlocal context is set up which allows the proxy to dispatch back. 3. Target calls the callback and an invocation is dispatched back 4. The listener on the client end receives the calback and dispatches to the callback using a normal component invocation. ServiceReference requires support for RequestContext and includes support for sessions. Since neither of these seem to be implemented, I could take a stab at implementing enough of RequestContext to support ServiceReference, and I could stub out support for sessions for now. On the other hand, ServiceReference is not as critical as, say, the RuntimeWire issue, so I could do without it at a very first try. Thoughts? If it is ok with everyone, I'll create a JIRA to start with stateless callbacks and can someone assign it to me? I'll create the JIRA and get it over to you. Perhaps we could start with outlining a couple of scenarios with progressive difficulty? In order to get this all to work we will probably need to refactor some of things such as the scope extensibility mechanisms. If we have some scenarios, I can help with the refactoring. Let me know if this works fr you and when you have more questions. Jim - To unsubscribe, e-mail:
[jira] Commented: (TUSCANY-465) SDO calls without error handling
[ http://issues.apache.org/jira/browse/TUSCANY-465?page=comments#action_12418614 ] Andrew Borley commented on TUSCANY-465: --- The patch fixes TUSCANY-485 SDO calls without error handling Key: TUSCANY-465 URL: http://issues.apache.org/jira/browse/TUSCANY-465 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Ed Slattery Fix For: Cpp-current Attachments: TUSCANY-465.patch The SCA code uses xpath expressions to get data objects when parsing files (E.g XSD/... in reading the config file.) These need to be wrapped with a SDORuntimeException handling, otherwise the call just terminates without warning when there are no entries defined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-485) Missing xsd element in Tuscany-model.config file causes failure.
[ http://issues.apache.org/jira/browse/TUSCANY-485?page=comments#action_12418615 ] Andrew Borley commented on TUSCANY-485: --- Fixed by patch on TUSCANY-465 Missing xsd element in Tuscany-model.config file causes failure. -- Key: TUSCANY-485 URL: http://issues.apache.org/jira/browse/TUSCANY-485 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Priority: Minor If the xsd element is missed out of the Tuscany-model.config file an exception is thrown in ModelLoader::loadModuleFile with message: Invalid path:xsd/file. There may be no xsd files needed by the component, so we should probably be able to cope with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C++ M1 test distro
There a number of problems with the windows zips... missing folders etc. I will be fixing these ASAP. -- Pete
Re: Type definitions in composites, was: [PATCH] Porting SDO DataBinding to the new SPI in Jeremy's sandbox
On 6/8/06, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Jeremy. Here's the patch with correct SVN property settings. Please try again. Thanks, Raymond I'm having problems applying this. I will merge the changes in by hand - please bear with me. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Samples
Robbie, Thanks very much for the sample. Let me just clarify my understanding if I may. I guess that for the 3 packages you mention above there would be two styles of coding; the two packages that pick up code snippets and samples from the spec would be broad coverage of the API, attempting to succinctly cover as much as ground as possible, targeting primarily the reader who is reasonably experienced in either the SDO spec or SDO coding or both. This might be seen as a kind of reference source. The third package, drawing on papers would be more educational, moving from novice to advanced features, and using the API in a more natural sense, suggesting best practice for given scenarios. Is that reasonable? I'm not sure I have a full perspective on what resources we have to draw upon in the latter category, although I know that there's some work in the pipeline in this respect. I'd be keen in all cases that there's no implicit context; e.g. if a set of examples reflects code in the spec it should say so, up front in an opening comment, with a link to the spec. If these code examples get sent around and moved out of context of their distribution it would be good if there is a link back to that source of info. With regards to your attached example, which is from the set of examples in the spec, I think we need to deviate from the spec here. The reason I say this is that it's not following the mainstream 2.0.1 concepts in that it talks about DataGraph but then creates a DataObject for which the Type is one which models a data graph. I believe that for the 2.0.1 spec we should be creating real instances of commonj.sdo.DataGraph. We can make use of the SDOUtil class's loadDataGraph method, which has been provided as a Tuscany extension particularly for the purpose of assisting the programmer to achieve this kind of wrapping (which more naturally fits into the responsibility of a DAS writer). There's quite a bit of thought going into the 2.1 and 3 specs about the relationship between DataObject and DataGraph, and use of this method to abstract the detail of how the data graph gets wrapped in an instance of DataGraph should help smooth the way to adopting new aspects of forthcoming spec revisions. Frank queried the use of the shouldUseDataGraph() method, and I have concerns about this too. For my part I'd like to see as little control code around the samples as possible. Perhaps this could be hived off to somewhere less visible just as you have done with the constants, or maybe have a command line argument processing module similarly tucked away. An alternative which I rather like would be to include comments in the code which invite the reader to edit the code to observe the alternative behaviours. In think there's some missing code in this example, in that logging needs to be turned on to get the serialization to include a populated change summary. I also wonder what is gained here by having the two paths of choosing whether or not to wrap the root DataObject in a DataGraph. If there's not much gain I guess I'd prefer to take the wrapped route only, but I'd be happy to be proved wrong here. Cheers, Kelvin. On 6/29/06, Frank Budinsky [EMAIL PROTECTED] wrote: Robbie, Looks pretty good to me. I wonder if someone from the SCA team can comment on consistency of approach with other Tuscany and Apache samples. What do others think about using things like SdoSampleConstants. What about the shouldUseDataGraph() call to query the user to choose from two ways to run it? For this: // TODO: do you need to do this ? employees.add(newEmployee); The answer is no. You would only need to add the newEmployee if you created it by calling DataFactory.create(). Since you created it by calling create() on the parent object, it's already attached, so this call to add will be a NOOP. Frank. Robbie J Minshall [EMAIL PROTECTED] wrote on 06/29/2006 02:48:15 PM: I am working on some samples for the SDO specification. Any thoughts or comments on the following would be appreciated. The first point of contact with SDO may or may not be the specification or an introductory paper, regardless it of the first point of contact I would hope that the samples are complete and usable enough that they can be used in close conjunction with the spec, sdo papers, or on their own. With this in mind it is very very important that the documentation generated ( I think the the project site is a good candidate here ) include a very consumable tutorial as well as a good outline of the sample packaging and usage so that the user can either use the samples on their own or in reference to the paper or specification in their hand. Currently the draft samples have a package that includes the code snipets throughout the specification so that the user can read each section and run or modify the very simple code snipet as it appears in the 2. 0 specification (these are essentially
[jira] Closed: (TUSCANY-465) SDO calls without error handling
[ http://issues.apache.org/jira/browse/TUSCANY-465?page=all ] Pete Robbins closed TUSCANY-465: Resolution: Fixed Fixed by patch supplied SDO calls without error handling Key: TUSCANY-465 URL: http://issues.apache.org/jira/browse/TUSCANY-465 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Ed Slattery Fix For: Cpp-current Attachments: TUSCANY-465.patch The SCA code uses xpath expressions to get data objects when parsing files (E.g XSD/... in reading the config file.) These need to be wrapped with a SDORuntimeException handling, otherwise the call just terminates without warning when there are no entries defined. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-485) Missing xsd element in Tuscany-model.config file causes failure.
[ http://issues.apache.org/jira/browse/TUSCANY-485?page=all ] Pete Robbins closed TUSCANY-485: Fix Version: Cpp-current Resolution: Fixed duplicate of TUSCANY-465. now fixed Missing xsd element in Tuscany-model.config file causes failure. -- Key: TUSCANY-485 URL: http://issues.apache.org/jira/browse/TUSCANY-485 Project: Tuscany Type: Bug Components: C++ SCA Versions: Cpp-current Reporter: Andrew Borley Priority: Minor Fix For: Cpp-current If the xsd element is missed out of the Tuscany-model.config file an exception is thrown in ModelLoader::loadModuleFile with message: Invalid path:xsd/file. There may be no xsd files needed by the component, so we should probably be able to cope with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Type definitions in composites, was: [PATCH] Porting SDO DataBinding to the new SPI in Jeremy's sandbox
On 6/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote: I'm having problems applying this. I will merge the changes in by hand - please bear with me. It's now applied. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SDO Samples
From below: choosing whether or not to wrap the root DataObject in a DataGraph. If there's not much gain I guess I'd prefer to take the wrapped route only, +1 Thanks, Frank. [EMAIL PROTECTED] wrote on 06/30/2006 08:48:23 AM: Robbie, Thanks very much for the sample. Let me just clarify my understanding if I may. I guess that for the 3 packages you mention above there would be two styles of coding; the two packages that pick up code snippets and samples from the spec would be broad coverage of the API, attempting to succinctly cover as much as ground as possible, targeting primarily the reader who is reasonably experienced in either the SDO spec or SDO coding or both. This might be seen as a kind of reference source. The third package, drawing on papers would be more educational, moving from novice to advanced features, and using the API in a more natural sense, suggesting best practice for given scenarios. Is that reasonable? I'm not sure I have a full perspective on what resources we have to draw upon in the latter category, although I know that there's some work in the pipeline in this respect. I'd be keen in all cases that there's no implicit context; e.g. if a set of examples reflects code in the spec it should say so, up front in an opening comment, with a link to the spec. If these code examples get sent around and moved out of context of their distribution it would be good if there is a link back to that source of info. With regards to your attached example, which is from the set of examples in the spec, I think we need to deviate from the spec here. The reason I say this is that it's not following the mainstream 2.0.1 concepts in that it talks about DataGraph but then creates a DataObject for which the Type is one which models a data graph. I believe that for the 2.0.1 spec we should be creating real instances of commonj.sdo.DataGraph. We can make use of the SDOUtil class's loadDataGraph method, which has been provided as a Tuscany extension particularly for the purpose of assisting the programmer to achieve this kind of wrapping (which more naturally fits into the responsibility of a DAS writer). There's quite a bit of thought going into the 2.1 and 3 specs about the relationship between DataObject and DataGraph, and use of this method to abstract the detail of how the data graph gets wrapped in an instance of DataGraph should help smooth the way to adopting new aspects of forthcoming spec revisions. Frank queried the use of the shouldUseDataGraph() method, and I have concerns about this too. For my part I'd like to see as little control code around the samples as possible. Perhaps this could be hived off to somewhere less visible just as you have done with the constants, or maybe have a command line argument processing module similarly tucked away. An alternative which I rather like would be to include comments in the code which invite the reader to edit the code to observe the alternative behaviours. In think there's some missing code in this example, in that logging needs to be turned on to get the serialization to include a populated change summary. I also wonder what is gained here by having the two paths of choosing whether or not to wrap the root DataObject in a DataGraph. If there's not much gain I guess I'd prefer to take the wrapped route only, but I'd be happy to be proved wrong here. Cheers, Kelvin. On 6/29/06, Frank Budinsky [EMAIL PROTECTED] wrote: Robbie, Looks pretty good to me. I wonder if someone from the SCA team can comment on consistency of approach with other Tuscany and Apache samples. What do others think about using things like SdoSampleConstants. What about the shouldUseDataGraph() call to query the user to choose from two ways to run it? For this: // TODO: do you need to do this ? employees.add(newEmployee); The answer is no. You would only need to add the newEmployee if you created it by calling DataFactory.create(). Since you created it by calling create() on the parent object, it's already attached, so this call to add will be a NOOP. Frank. Robbie J Minshall [EMAIL PROTECTED] wrote on 06/29/2006 02:48:15 PM: I am working on some samples for the SDO specification. Any thoughts or comments on the following would be appreciated. The first point of contact with SDO may or may not be the specification or an introductory paper, regardless it of the first point of contact I would hope that the samples are complete and usable enough that they can be used in close conjunction with the spec, sdo papers, or on their own. With this in mind it is very very important that the documentation generated ( I think the the project site is a good candidate here ) include a very consumable tutorial as well as a good outline of the sample packaging and usage
[jira] Created: (TUSCANY-512) Add ability to explicity set the root object of a data graph
Add ability to explicity set the root object of a data graph Key: TUSCANY-512 URL: http://issues.apache.org/jira/browse/TUSCANY-512 Project: Tuscany Type: New Feature Components: Java SDO Implementation Versions: Java-M1 Reporter: Ronald L. Gavlin Add utility method SDOUtil.setRootObject(DataGraph dataGraph, DataObject rootObject) to set the root object of a data graph. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
Jim, Perhaps we could discuss this via a more immediate medium. How about IRC or phone? I am online today until 5pm EDT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-504) Ability to find out if a property is required or not
[ http://issues.apache.org/jira/browse/TUSCANY-504?page=all ] Frank Budinsky resolved TUSCANY-504: Resolution: Fixed Fixed in revision 418323. Added SDOUtil.isResolved(Property). Ability to find out if a property is required or not Key: TUSCANY-504 URL: http://issues.apache.org/jira/browse/TUSCANY-504 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1 Reporter: Suraksha Vidyarthi Ability to get required fields from an SDO definition. Currently there is no mechanism to find out from the SDO instance if a given property is mandatory/required or not. The implementation should be able to use the minOccurs and maxOccurs values from XSD to detect if a field is required or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-504) Ability to find out if a property is required or not
[ http://issues.apache.org/jira/browse/TUSCANY-504?page=comments#action_12418676 ] Frank Budinsky commented on TUSCANY-504: I meant SDOUtil.isRequired not isResolved. Ability to find out if a property is required or not Key: TUSCANY-504 URL: http://issues.apache.org/jira/browse/TUSCANY-504 Project: Tuscany Type: Bug Components: Java SDO Implementation Versions: Java-M1 Reporter: Suraksha Vidyarthi Ability to get required fields from an SDO definition. Currently there is no mechanism to find out from the SDO instance if a given property is mandatory/required or not. The implementation should be able to use the minOccurs and maxOccurs values from XSD to detect if a field is required or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Proposed approach for M2
I have used the last two weeks studying our current code streams (M1 and sandbox) and the evolving SCA specification. During this exercise, I have realized that we have a LOT to do in order to reach the level of function that supports the spec, as well as implement additional interesting ideas that have been discussed on the mailing list. This can only be achieved if we have our community engaged actively. I would like to propose the following approach to help us achieve that. 1. Use scenarios to drive the M2 work Start a community discussion on the end to end scenarios that we want to support in M2. I'm thinking about concrete end to end scenarios that define the end user experience and the overall story going from development, build, package, deploy to runtime and administration of an SCA application. This exercise should help us realize the following: - better understand what it means to build an application using the new SCA recursive composition model - better understand the requirements, put them in perspective and stage the introduction of the relevant function in the runtime - use these top level scenarios as a starting point to drill down into more detailed scenarios and the design of the runtime - give the whole group common goals for M2, we build a runtime that supports the scenarios - demonstrate the value of SCA to our users Here are a few ideas of scenarios to initiate the discussion: - a scenario building your average web app with SCA - a scenario showing how to aggregate multiple services into new ones - mediation and routing/exchange scenarios - an application using publish/subscribe - building a whole system of services on a network - integration with an AJAX UI - what else? any thoughts? 2. Stage the assembly of our M2 runtime. I propose that we start a fresh stream for M2 and build the runtime through baby steps, in parallel with the scenario work. This will get our community members involved in building the runtime together and will lead to a wider knowledge base that makes it possible to quickly implement new functionality in the future. It will also build a community knowledge base that is ready to help new community members come on board quickly. Here's a proposal for how to do this: - design and develop M2 by bringing into this fresh stream the best pieces from the sandbox and M1, as well as new ideas emerging from community discussions - stage the introduction of functional chunks required to support our scenarios - at each step, focus on simplicity and approachability of the runtime that we produce (to allow more people to approach it and get involved). Here are some themes that we could consider to initiate this effort (not an exhaustive list, and needs help): - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - A simpler metadata model (the recursive model is much simpler than the 0.9 spec, this is a great opportunity for us to simplify our implementation) - Better continuity and consistency between our metadata model and the runtime model - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.) - Better continuity between the SCA component programming model and the Tuscany interceptor programming model - The need for a special system component implementation type, or the ability to extend Tuscany with just regular components. This is just an initial list, I'm sure we're going to come up with many more themes and areas of improvement :) I am looking forward to constructive discussions, and hoping that this community effort will allow us to come up with a nice runtime platform to attack the work ahead of us. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
On 6/30/06, Ignacio Silva-Lepe [EMAIL PROTECTED] wrote: Jim, Perhaps we could discuss this via a more immediate medium. How about IRC or phone? I am online today until 5pm EDT. Ignacio, I've been following this thread with interest but won't be able to get on IRC any time soon. Please could you continue this on the list so that everyone in the community can follow along. Thanks -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed approach for M2
Sebastien, This sounds great to me. You may have intended this but, I think that the scenarios should be implemented as we go resulting in new unit tests, samples or sample apps by the time we are ready to release M2. Also, I propose a scenario that involves data access and the transfer of a data graph between modules. A source module would get the graph using the DAS and pass it to a worker module. The graph would be modified by the worker and sent back to the source module with change history intact to be synchronized with the database. An inter-op scenario would be nice too. Thanks, --Kevin Jean-Sebastien Delfino wrote: I have used the last two weeks studying our current code streams (M1 and sandbox) and the evolving SCA specification. During this exercise, I have realized that we have a LOT to do in order to reach the level of function that supports the spec, as well as implement additional interesting ideas that have been discussed on the mailing list. This can only be achieved if we have our community engaged actively. I would like to propose the following approach to help us achieve that. 1. Use scenarios to drive the M2 work Start a community discussion on the end to end scenarios that we want to support in M2. I'm thinking about concrete end to end scenarios that define the end user experience and the overall story going from development, build, package, deploy to runtime and administration of an SCA application. This exercise should help us realize the following: - better understand what it means to build an application using the new SCA recursive composition model - better understand the requirements, put them in perspective and stage the introduction of the relevant function in the runtime - use these top level scenarios as a starting point to drill down into more detailed scenarios and the design of the runtime - give the whole group common goals for M2, we build a runtime that supports the scenarios - demonstrate the value of SCA to our users Here are a few ideas of scenarios to initiate the discussion: - a scenario building your average web app with SCA - a scenario showing how to aggregate multiple services into new ones - mediation and routing/exchange scenarios - an application using publish/subscribe - building a whole system of services on a network - integration with an AJAX UI - what else? any thoughts? 2. Stage the assembly of our M2 runtime. I propose that we start a fresh stream for M2 and build the runtime through baby steps, in parallel with the scenario work. This will get our community members involved in building the runtime together and will lead to a wider knowledge base that makes it possible to quickly implement new functionality in the future. It will also build a community knowledge base that is ready to help new community members come on board quickly. Here's a proposal for how to do this: - design and develop M2 by bringing into this fresh stream the best pieces from the sandbox and M1, as well as new ideas emerging from community discussions - stage the introduction of functional chunks required to support our scenarios - at each step, focus on simplicity and approachability of the runtime that we produce (to allow more people to approach it and get involved). Here are some themes that we could consider to initiate this effort (not an exhaustive list, and needs help): - Modularity, building our runtime in a more modular way, with more but simpler modules, clean SPI modules with only interfaces, and decoupling the core and the Java component implementation type / container. - A simpler metadata model (the recursive model is much simpler than the 0.9 spec, this is a great opportunity for us to simplify our implementation) - Better continuity and consistency between our metadata model and the runtime model - Simpler SPIs, covering all aspects of the cycle (development, build, deployment + install, runtime, admin etc.) - Better continuity between the SCA component programming model and the Tuscany interceptor programming model - The need for a special system component implementation type, or the ability to extend Tuscany with just regular components. This is just an initial list, I'm sure we're going to come up with many more themes and areas of improvement :) I am looking forward to constructive discussions, and hoping that this community effort will allow us to come up with a nice runtime platform to attack the work ahead of us. Any thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Brainstorm not to expose INTERNAL Properties
Current SDO impl bases on EMF, EMF may produce INTERNAL Properties besides user designation. It may be nice for SDO not to expose the INTERNAL Properties. Here lists some thoughts JUST as a START, it's much more important if YOU brainstorm please. Frank has provided options such as 1. SDOXSDEcoreBuilder builds user Properties at the beginning of getEStructuralFeatures() List and INTERNAL properties at the end of getEStructuralFeatures(). SDO can simply hide high-index INTERNAL Properties without too much performance sacrifice. 2. SDO maintains a seperated List from getEStructuralFeatures() I agree with either of the two options and feel like it may be another option to extend getEAllStructuralFeatures() to change the property List in effect. Really hope to see your comment on any of the options even more options from you. No matter what option, an interesting thing to consider is the order of INTERNAL Properties from SUPER typeS and user Properties from subtype. Really hope to see good solution to that concern so that List decoration (index translation) can be evitable. Thanks in advance. -- Yang ZHONG
Re: Support for callbacks
Apologies Jeremy, didn't mean to exclude people, just trying to expedite the discussion. The first basic issue I see is how to incorporate callbacks as defined in the CI spec in particular, and bi-directional interfaces in general, into the Tuscany architecture. Depending on how closely a RuntimeWire is supposed to correspond to an SCA wire, it seems like one way to incorporate a callback is to extend InboundWire to include an OutboundInvocationChain, and OutboundWire to include an InboundInvocationChain. That is, a wire would include a 'reverse' pair of invocation chain ends to account for a callback.With that in place, it seems feasible to re-use WireInvocationHandler and TargetInvoker in a similar fashion to actually perform the callback invocation. Are there any subtle (or not so subtle) gotchas in this that I am overlooking? I was thinking there would be a couple of things: a system transport service and a conversational scope container. The system transport service would listen for callbacks. That service would dispatch and invoke a component, which in turn would ask its scope container for the component implementation instance to dispatch to. Not sure if I follow. Is the system transport service intended as an alternative for a reverse invocation chain pair? Yes. The system service would be a transport listener which would pick up the callback invocation off of a wire. The callback invocation would be sent from the proxy injected into the target as described below. Do you think it would help if we outlined several of scenarios, e.g. a stateless callback done in the same composite, a stateless callback done across remote boundaries, a stateful callback done in the same composite, and a stateful callback done across remote boundaries? I was thinking we could sketch out what happens and then map it down to the core. If I understand correctly, would a system service transport use a low level communication mechanism, like a socket for instance? This does not seem like an appropriate approach for a local scenario, but I am really guessing about how such a listener would pick up a callback invocation if it is not via the architected RuntimeWire/InvocationChain mechanism. On the other hand, you do say the listener would pick up the callback invocation off of a wire, which I'm not sure I follow either. Admittedly, using a 'reverse' pair of invocation chains does not seem like a very orthodox approach, but given that the SCA architecture does not define separate reference and service elements for a callback (i.e., these seem to be bundled into the forward reference and service only in reverse), it looks like it is up to the Tuscany architecture to supply a sensible design. As an alternative, a separate RuntimeWire instance could be introduced for a callback, with corresponding outbound and inbound ends, but this would not correspond that closely to its SCA counterpart. My question about gotchas had more to do with trying to use a WireInvocationHandler (e.g., JDKOutboundInvocationHandler) as the object called by the callback proxy injected into the target. At first glance, this seems feasible, even if we are performing an outbound invocation on an InboundWire and the corresponding inbound invocation of the client happens from an OutboundWire. Is this reversal the reason why a transport listener is a better approach in your mind Jim? One concern I have (if I understand the transport listener idea) is that it seems like a departure from the current architecture. That is, there is no such listener used in a forward invocation. The conversational scope container could have a pluggable persistent store API (we could have a simple implementation which serialized to disk and eventually used a journaling mechanism such as HOWL http:// howl.objectweb.org/). Two other basic pieces are: (1) callback injection, and (2) implementation of ServiceReference. Callback injection may be simple enough and similar to reference injection for stateless callbacks, but it'll get more interesting for stateful callbacks (or stateful scopes), as it is not clear that a callback field or method will remain valid for the duration of the component instance, and may need to be re-injected. Couldn't we use a proxy for this to avoid reinjection? In terms of flow, it could possibly work as follows: 1. Client invokes, invocation is passed through a wire 2. Target is invoked. When the target is created (it could be at this point or before), a callback proxy is injected. During the invocation, a threadlocal context is set up which allows the proxy to dispatch back. 3. Target calls the callback and an invocation is dispatched back 4. The listener on the client end receives the calback and dispatches to the callback using a normal component invocation. - To
Brainstorm for who to load schema
Tuscany InterOp / JIRA 505 (http://issues.apache.org/jira/browse/TUSCANY-505) brings us an interesting topic: there're code or users interested in loading XML, then who is responsible to load schema? Here lists some thoughts JUST as a START, it's much more important if YOU brainstorm please. I can think of 3 options so far: 3-1. code or users who to load XML, loads schema themselves 3-2. SCA loads component interfaces (WSDL) related schema automatically 3-3. SDO LOCATES and loads schema automatically 3-1 may not be very friendly/efficient since the schema loading burden is pushed to users who may need to track loaded or not to avoid unnecessary multiple loading if SDO impl hasn't made such effort. 3-1 may not need to change (SDO) spec. 3-2 might waste effort if component impl isn't SDO based or shcema is not used on some execution paths. 3-2 may need to change SCA spec. 3-3 may be ambiguous if user deploys conflicting schemas although which may not be seen often. My previous comercial product automatically LOCATES, loads and REFRESHES schema on demand. 3-3 may need to change SDO spec. Really hope to see your comment on any of the options even more options from you. Thanks in advance. -- Yang ZHONG
[C++] Issues with sdotest.cpp?
Tried building FC3 I386 got the following make[5]: Entering directory `/home/rineholt/testing/tuscany_sdo_cpp-0.1.incubating-M1-src/runtime/core/test' if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../runtime/core/test -I../../../runtime/core/src -g -O2 -MT sdotest.o -MD -MP -MF .deps/sdotest.Tpo -c -o sdotest.o sdotest.cpp; \ then mv -f .deps/sdotest.Tpo .deps/sdotest.Po; else rm -f .deps/sdotest.Tpo; exit 1; fi sdotest.cpp:1135: error: integer constant is too large for ‘long’ type sdotest.cpp:2569: error: integer constant is too large for ‘long’ type sdotest.cpp:2575: error: integer constant is too large for ‘long’ type make[5]: *** [sdotest.o] Error 1 make[5]: Leaving directory `/home/rineholt/testing/tuscany_sdo_cpp-0.1.incubating-M1-src/runtime/core/test' looking at 1135 dor-setLong(long, 0x); 12 Fs 48 bits ? Is integer machine size 32 bits ? Are you compiling on 64 bit architecture? Also this file has as header : /* * * Copyright 2005 International Business Machines Corporation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brainstorm for who to load schema
On 6/30/06, Yang ZHONG [EMAIL PROTECTED] wrote: Tuscany InterOp / JIRA 505 (http://issues.apache.org/jira/browse/TUSCANY-505) brings us an interesting topic: there're code or users interested in loading XML, then who is responsible to load schema? Here lists some thoughts JUST as a START, it's much more important if YOU brainstorm please. Comments inline ... I can think of 3 options so far: 3-1. code or users who to load XML, loads schema themselves I think this always need to be available as an option - sometimes it's the application that knows what to do rather than the infrastructure. There are APIs for this in the SDO; we provide the @SDOHelper annotation in SCA that allow them to be injected (to avoid the .INSTANCE anti-pattern). I think we could also enhance the introspector to detect properties whose values are SDO helpers and could eliminate the need for the annotation. This would be one of the introspections contributed by the SDO databinding. 3-2. SCA loads component interfaces (WSDL) related schema automatically and not just from WSDL... I alos mentioned on the TypeHelper thread that we should provide a mechanism that allowed components to import SDO definitions in their component-type definition. 3-3. SDO LOCATES and loads schema automatically I don't think SDO should do this. Specifically, I mean the basic SDO implementation should not do this - it may be a feature of some framework that is using SDO (like Tuscany't SCA framework). snip/ -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
