Eclipse SOA Tools Project support for SCA/Java dev with Tuscany
Hi all, Over at Eclipse STP we've made some progress on supporting SCA/Java service development using Tuscany [0]. In the flash movie at [1] (14MB) you will see how to develop and SCA Java service and client using the RMI binding. This is a call for feedback on this initial tool support to help us deliver something that is useful for SCA developers in the Eclipse Europa release, due end of June. We would appreciate your thoughts and comments sent to stp- [EMAIL PROTECTED] best regards Oisin Hurley, STP PMC Lead [0] http://wiki.eclipse.org/index.php/SCA_Java_support_in_STP [1] http://www.eclipse.org/stp/sc/demos/sca_rmi_movie.swf
Re: Eclipse SOA Tools Project support for SCA/Java dev with Tuscany
Any plans to do anything to support SDO 2 in eclipse. I wrote a simple plugin for generating SDOs from XSDs, wondering where best to donate it to ? I was planning on doing a couple more, but no-one took up my previous comments on this matter at Tuscany, so can only assume they are not of interest to tuscany (I hope I'm wrong btw) I might be a good plan to get in touch with Ed Merks at the Eclipse Modeling project, where they host things like EMF, SDO and many other pieces of code. They have a series of mailing lists and newsgroups [1] and Ed is very responsive to newsgroup postings. best regards --oh [0] http://www.eclipse.org/modeling/emf/?project=sdo [1] http://www.eclipse.org/modeling/emf/newsgroup-mailing-list.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tuscany C++ sub-project name
On 23 Jan 2007, at 10:55, Pete Robbins wrote: I was wondering whether we should package a Tuscany C++ kernel, which is the core runtime and cpp language extension, and have a separate package for scripting extensions ?? +1 --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tuscany C++ sub-project name
My +1 is for Tuscany Native I wonder what all the Tuscany natives in Italy would think ;) [] keep the old name (Tuscany C++) This would get my vote. --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki or website for doc?
I think the wiki is the best place for development of this type of documentation. It is so easy to update that I hope it will invite others to participate. I also like Venkat's idea to snapshot content developed on the wiki to include in a milestone distribution. Just a point on this one - wiki is a good place to do stuff, easy to update, etc, but it's important to remember that it does not lend itself naturally to the provision of docs that follow the 'usual' table-of-contents style approach we see in tech docs -- instead it is more bazaar than cathedral. So - if you have a vision of producing 'natural' PDF docs for offline use, then one needs must layer some behaviour on the wiki editing, like keeping a toc up to date etc. cheers --oh +353 1 637 2639 http://blogs.iona.com/ohurley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transcript of IRC chat on C++ M2 release
Hi guys, Sorry I couldn't make the IRC - had to run off to a night class. 18:36:06ajborleywhat about MacOSX? there was a patch for that, but I don't know what the status is 18:36:17ajborleyI also don't have access to any mac machines 18:36:19robbinspgI'll do Mac OSX 18:36:32robbinspgso long as someone buys me a new PowerBook 18:36:47jsdelfinofor MacOSX the first question is: is Axis2C shipping bins on MacOSX? I can get a MacOSX build done for 0.94, but as you can see at [0], the priority on the patch is low. Looking at the current set of Jirae that are going in there it seems they have more pressing concerns. This brings up a question from me wot is ignorant of Apache devoirs in term of infrastructure support. Since I'm mostly doing Eclipse work, I'm used to having heaps of donated build machines that will do nightlys etc. I guess that this is not the case at Apache and that binary builds are done by project committers - or the most excellent release person :) I will update the Axis patch to work with the current pre-0.94 base and see will they take it (it's not a new feature imho). If they don't, would it be a horrible gaffe to post an 'independent' set of binaries and headers as a supplemental download on the Tuscany site? I hope asking that question wasn't of itself a horrible gaffe :) 18:36:50ajborley:) do we want RC1 on OSX? Could anyone volunteer? 18:37:12ajborleyGood point - I doubt it 18:37:22robbinspglet's get RC1 out and see if the resulting src release can be built on Mac 18:37:36jsdelfinowe should ask oisin what he wants to do, since he contributed that patch and tested it Consider me volunteered for build and test - I would consider that there is more important work to be done for RC1, so I'm not going to be insistent on it's inclusion. cheers --oh [0] https://issues.apache.org/jira/browse/AXIS2C-287 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transcript of IRC chat on C++ M2 release
That would be good - we decided near the end of the IRC chat to have a dependency on Axis2C 0.93 as we weren't sure exactly when 0.94 would be out and we'd like our first RC by the end of this week. Saying that, Sebastien put in a tiny code change which made Tuscany work with the latest Axis2C trunk, so the 0.94 release will hopefully work with Tuscany M2. Ok, well I notice their code freeze was lifted there today, so I'll go see what I have to do to get a build together on 0.94. The 0.93 build did have some unit test failures on MacOS, it will be interesting to see if any of the current spate of updates has fixed these. I have no idea - I'm not sure if the Tuscany site is the best place to host an Axis2C MacOSX binary, but we could certainly point to one on another (perhaps independent?) site. Another option is to point to/provide the patches to enable OSXers to build Axis2C and then Tuscany. If I get a build and test clean, I will do some volunteering to do the builds and tests for the Axis2C guys in the interim so maybe they will host the bin build. Cheers Oisin, that's great - I guess we won't have the time to get it into RC1, but we may be able to sort it out for a later RC. Quick clarification Andy - will you be shifting axis version before Milestone? Or saving it for after? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transcript of IRC chat on C++ M2 release
Quick clarification Andy - will you be shifting axis version before Milestone? Or saving it for after? It depends when 0.94 comes out I guess - if it's soon then shifting is probably a good idea (especially with some of the fixes that are planned for 0.94), but I don't think we should delay M2 specifically for 0.94. Does that sound OK? Sounds fair enough to me, thanks! cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2][ANN]Apache Axis2/c 0.94 Released.
I guess this answers some of our questions about which level of Axis2C to use :) We should probably build our release with Axis2c 0.94 now, I tested with their trunk 2 days ago and it worked with a minor change in our code, will test again today with the official release on Linux. They are not publishing a Mac OS-X binary distro so I guess if we want a Mac OS X story we're going to have to document the steps to build from source with Oisin's patches. Building Axis now on the shiny mac - it looks like at least *some* of my patch is in there already :) Will let you know how it works out. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for Project Ideas for M.Sc Students
You know that you've been looking at waaay too much C code when you read: I have a .pdf document that describes the web services course at Oxford and think to yourself: 'r' isn't a hexadecimal number :) --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mobile
On 18 Sep 2006, at 21:19, Hamdi, Louenas wrote:
Hello,
My name is louenas Hamdi and I work for SAP Research. My interest is
mainly in the mobile platforms. while I was reading the Tuscany white
paper I thought that this could be good for Mobile clients as well.
Do you think that Tuscany specification could suite the mobile
environment for building small services running on a cell-phone or a
PDA? right now the best platform I know for doing that is OSGi but
it is
still very Java oriented.
Hi Louenas,
For local-hosted services then I think that there is certainly
a potential, especially with the OSGi effort going on. As Jeremy
adds, though, there is an issue with Java5 annotations.
For services that are to be access remotely, i.e. the phone-to-phone
peer networking kind of thing that Nokia is currently pushing, then
we will need to look at providing a transport ('binding' in SCA terms)
that has built-in support for occasional connection - so, durable
storage, reliability etc etc.
For *clients* to tuscany runtimes then of course there is lots
of scope pretty much immediately - one doesn't even need to have
java 5 annotations depending on the binding that you choose :)
regards
Oisin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-681) Port of Tuscany C++ to Mac OS X, powerpc arch
[ http://issues.apache.org/jira/browse/TUSCANY-681?page=all ] Oisin Hurley updated TUSCANY-681: - Attachment: macos-patch Patch for MacOS X 10.4.7 port of C++ SDO and SCA SDO tests are all clear. Some minor wrinkles in the makedist which I believe are across the board, not specific to this platform. Port of Tuscany C++ to Mac OS X, powerpc arch - Key: TUSCANY-681 URL: http://issues.apache.org/jira/browse/TUSCANY-681 Project: Tuscany Issue Type: New Feature Components: C++ Build, C++ SCA, C++ SDO Environment: MacOS X 10.4.7 PowerPC Reporter: Oisin Hurley Priority: Minor Attachments: macos-patch Plain old porting job - prerequisite is a port of Axis2C for axiom bits and hosting. -- 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: Mac OS X port, was [C++] Build instructions on Web site
On 7 Sep 2006, at 04:48, Jean-Sebastien Delfino wrote: Did you get a chance to look into the MacOS X port? I have an iBook with 10.4.7 ppc Mac OS X here and was wondering if you had a patch to the Makefiles that I could try. Patch is up: http://issues.apache.org/jira/browse/TUSCANY-681 Apply in cpp directory. Let me know of blunders :) cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mac OS X port, was [C++] Build instructions on Web site
Did you get a chance to look into the MacOS X port? I have an iBook with 10.4.7 ppc Mac OS X here and was wondering if you had a patch to the Makefiles that I could try. Quick update on this, I have the Axis2C mostly built, SDO part of the port was straightforward, currently working thru some link issues with sca, I've stuck a comment on the jira: https://issues.apache.org/jira/browse/TUSCANY-681 Biggest speedbump so far has been re-learning Autoconf :D cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-681) Port of Tuscany C++ to Mac OS X, powerpc arch
[
http://issues.apache.org/jira/browse/TUSCANY-681?page=comments#action_12433503
]
Oisin Hurley commented on TUSCANY-681:
--
Just an update:
-- necessary libraries from axis2c ported
-- sdo part ported
-- sca part suffering from some multiple symbols at link time
Looking into the link issues at the moment and constructing a patch
for submission to Axis2 C.
Ye errormsg:
-
g++ -dynamiclib -single_module ${wl}-flat_namespace ${wl}-undefined
${wl}suppress -o .libs/libtuscany_sca_cpp.0.0.0.dylib .libs/CPPExtension.o
.libs/CPPImplementationExtension.o .libs/CPPImplementation.o
.libs/CPPInterfaceExtension.o .libs/CPPInterface.o .libs/CPPServiceProxy.o
.libs/CPPReferenceBinding.o .libs/CPPServiceWrapper.o .libs/CPPServiceBinding.o
-L/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sdo/deploy/lib
/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sdo/deploy/lib/libtuscany_sdo.dylib
-L/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sca/runtime/core/src
/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sca/runtime/core/src/.libs/libtuscany_sca.dylib
-install_name
/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sca/deploy/extensions/cpp/libtuscany_sca_cpp.0.dylib
-Wl,-compatibility_version -Wl,1 -Wl,-current_version -Wl,1.0
ld: multiple definitions of symbol
__ZN7tuscany3sca3cpp17CPPImplementation19initializeComponentEPNS0_5model9ComponentE
.libs/CPPImplementation.o definition of
__ZN7tuscany3sca3cpp17CPPImplementation19initializeComponentEPNS0_5model9ComponentE
in section (__TEXT,__text)
/Users/oisin/Projects/SCA/Tuscany/tuscany/cpp/sca/runtime/core/src/.libs/libtuscany_sca.dylib(single
module) definition of
__ZN7tuscany3sca3cpp17CPPImplementation19initializeComponentEPNS0_5model9ComponentE
ld: multiple definitions of symbol
__ZN7tuscany3sca3cpp17CPPImplementation19initializeComponentEPNS0_5model9ComponentE.eh
Port of Tuscany C++ to Mac OS X, powerpc arch
-
Key: TUSCANY-681
URL: http://issues.apache.org/jira/browse/TUSCANY-681
Project: Tuscany
Issue Type: New Feature
Components: C++ Build, C++ SCA, C++ SDO
Environment: MacOS X 10.4.7 PowerPC
Reporter: Oisin Hurley
Priority: Minor
Plain old porting job - prerequisite is a port of Axis2C for axiom bits and
hosting.
--
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++] Build instructions on Web site
Great! I don't think that anybody has tried MacOS X yet. It will be really great if you can port the Linux build... and then we can all get iBooks :) I've to get axis2c ported first :) Would it be good practice to put a JIRA in for this so that it's visible? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-681) Port of Tuscany C++ to Mac OS X, powerpc arch
Port of Tuscany C++ to Mac OS X, powerpc arch - Key: TUSCANY-681 URL: http://issues.apache.org/jira/browse/TUSCANY-681 Project: Tuscany Issue Type: New Feature Components: C++ Build, C++ SCA, C++ SDO Environment: MacOS X 10.4.7 PowerPC Reporter: Oisin Hurley Priority: Minor Plain old porting job - prerequisite is a port of Axis2C for axiom bits and hosting. -- 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: REST bindings for Tuscany SCA runtime
I am not sure I understand the issue with create/delete (except if PUT and DEL are disabled). Posting/putting to a URL that doesn't exist yet to create that resource can be troubling. Is that the issue? Are you looking for some kind of factory service pattern to create resources? Or am I completely mis-understanding the issue you're describing here? :) Apologies for not making the context clearer - however, you've got the point: there needs to be either a resource factory, or a generic resource holder to process create/delete of resources. I think I was attempting to say that a first cut would be ok to support just the GET/POST (as the most pressing scenarios) and then the PUT/DEL and factory approach could follow as a feature improvement. I will put up a wiki summary on this thread. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
Simon - apologies I've been away from this for the last week... [deletia] ...and this is why :) There are number of responsibilities of an extension - which you accurately describe - and there are a number of responsibilities of a plugin, related to configuration and lifecycle and I think it would be a Good Thing to keep them as separate development efforts. What do you think? Do you mean that a plugin may have responsibilities that are a sub- set or super-set of those of a particular extension? Actually I see that the plugins responsibilities are a disjoint set - meaning that the plugins are unconscious of the value of their content and are used only as a way to bang a bunch of libraries together in a predictable manner and correctly initialize/deinitialize them. We could probably have the same conversation re. deploying components and composites into the C++ SCA infrastructure as opposed to deploying parts of the C++ SCA infrastructure. +1 Maybe we need to be a bit more explicit about what we anticipate being in a plugin. For examle, 0..n Component type container implementations 0..n Binding implementations 0..n Host adapters [0..n Components 0..n Composite(s) should these be included as well? Seems unlikely that you want to deply at the same time but you will want to deploy at some time.] So there's two roads - one where one must be explicit about the content of the plugin in terms of architectural artifacts, this is the manifest style approach, and the other, where the plugin initialization code does the necessary registrations of architectural artifacts. These are not necessarily incompatible approaches either. Can we use exsiting technology for some of this, for example, there has been much discussion of OSGi on the java list, is OSGi wider that just Java now? AFAIK OSGi is still Java only and a Google search didn't turn up much that was useful. In terms of existing technology, I'm not familiar with any technologies along this line that are open. That being said, a C++ version of OSGi would be a beautiful thing :) My gut feeling is that plugin/extension should be decoupled, but the only strong point I can see for it in the current architecture is the fact that databindings are not explicit as an extension - there is scope for say an interface.mumble that has databindings of say XMLBeans or JiBX. If the databinding can be an extension in its own right, then maybe the simplifying assumption of plugin == extension may be the way to go. From the point of view of deployment, there may be a greater need for a non-extension plugin to package application code to be 'deployed'. Maybe we should have that conversation about deployment now? cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Build instructions on Web site
On 28 Aug 2006, at 22:56, Jean-Sebastien Delfino wrote: Would it make sense to publish this: http://www.mail-archive.com/ tuscany-dev%40ws.apache.org/msg05276.html and this: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ msg05379.html on a How to build page on the Tuscany C++ Web site? Thoughts? Please do :) BTW - has anyone done a port to MacOS X 10.4.7 ppc? If not I will get a start on it - not vital for the roadmap, but it is my machine of choice and I'll get nothing done if it doesn't work there ;) cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
What do you think about the following approach: a) If you put no annotations in your code then you have to stick to the fixed pattern with fixed method names, and you write the side SCDL file that turns your code into a component and publishes the REST endpoint. b) If you want more flexibility to map state changes to nicer method names then you use annotations as your were proposing earlier in this thread. The annotations also allow you to completely avoid writing SCDL and specify the details of the binding like the base URI for the resources... Thoughts? These sound like good approaches to me - the one thing that I'm scratching my head about a bit is the create-resource and delete-resource support. The read-resource and update-resource ops are fine, because we have a resource (i.e. the thing that has just been coded). What's implicit here, though, is that there is always a fixed set of resources - the ones that you have just 'deployed'. So the create/delete ops can never be used because things are just set up that way. BTW, this is probably ok and it does match nicely with the accepted admin practice of disabling PUT and DEL in real webservers (as observed previously in this thread). I would be happy enough to leave off the create/delete support for the immediate future :) You have .put and .get in the client example, maybe the .post should be something like customers.post(uri, state-diff) Ah! interesting, I never thought about that before, looks like there could be a pretty good fit with SDO with the following: customers.post(uri, state-diff-in-an-SDO-change-summary-graph) ... This would be an interesting usage of SDO change summaries IMO, obviously just as an option as you should be able to format your state diff in any format you want as long as it's understood by your application. What do you think? This sounds like a nifty fit for sure. But now I have to go and read that SDO spec in more detail, because I know too little about it :) I like the general approach of going down the diff route because if you do it right then you can undo/redo changes to the data, which is neat feature, provided you are willing to store all of the diffs in a timeline. I'll go off and read that spec again. I just love reading specs ;) Are we close enough to condense a summary on the topic of REST and SCA? This would be good white paper material BTW. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
[deletia]
js-d says:
I've been thinking about this and wondering what the architecture
of the runtime will be with many different plugins? Are you guys
envisioning one big process with different (maybe incompatible?)
libraries loaded in it? or a more distributed architecture with
multiple processes?
I must admit I've been toying with the idea of having multiple
processes handling the various component implementation types and
binding types, then it would be quite easy to bring them up/down...
What do you think?
[deletia]
pr says:
Not sure what the definition of incompatible is here. Is it, for
instance,
having two separate extension plugins that both provide a
binding.ws? I
think this is an interesting case and one we should try to support. Of
course there would need to be some config outside of the Assembly
specification to determine which one gets used. I see the jave folk
discussing this very issue.
It's probably the case that we can't define what 'incompatible' means
upfront
except to say that bitter experience will provide :) +1 on being
able to
resolve a choice from a number of binding providers what all can
support 'ws',
I think this is necessary right now, but I'm still a bit
uncomfortable with
binding.ws as being too general (not trying to start a new thread
here -
others are looking into this issue :)
[deletia]
9. Plugins have versions, and dependencies on other plugins too.
We may want to get there at some point, but I was not sure that we
really needed this to start with... Would it make sense to stage
this and start with a simple solution with no versions and no
dependencies, and get into the whole versioning / dependency /
coexistence of multiple versions etc. later?
Simple solution, followed by dependencies, followed by versioning
would work for me. We can learn from what OSGi does in terms of
its management of these things and maybe emulate it to some extent.
So: +1
Having tried to retro-fit versioning into many software products
over my
many years I would say this is one to think about up front even if
you don't
implement it. It is very easy to make it virtually impossible to
this later
without majot restructure!
I'm comfortable with starting off using something like a {namespace,
name,
version} triple as a unique identifier for a plugin - or even a {name,
version} pair with the proviso that the name is structure ala java
package
names, eclipse plugin names etc.
We can start off with the basic resolution approaches of exact-match and
latest-match on the version part and then later on develop at-least-
match
and range-match if they are really necessary.
I've seen lots of +1s on this thread, which is nice, and I've just found
out that I can edit the Tuscany wiki, so I'll summarize to there -- the
page will be http://wiki.apache.org/ws/Tuscany/TuscanyCpp/
PluggableCppRuntime
it'll be later today before I get to it.
cheers
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
Hi Simon, Had a long weekend so just picking up this thread. Looks like a really useful discussion and I too like the requirement driven approach. I have a few to add/comment on. It seems that a plugin resolves to a component type or binding, i.e. what the assembly model refers to as extensions, so that is what I have in my mind. IMHO you can package an extension as a plugin, but you can also package an extension as 1 plugin, or you could package a number of extensions in just 1 plugin. So I think there should be a level of decoupling there... 6. There will need to be some kind of manager thingie to keep track of plugins and their state at runtime. Extensions should be able to constribute information to the in memory model, for example, via annotations. [deletia] ...and this is why :) There are number of responsibilities of an extension - which you accurately describe - and there are a number of responsibilities of a plugin, related to configuration and lifecycle and I think it would be a Good Thing to keep them as separate development efforts. What do you think? [deletia] +1 for a simple lifecycle interface. What kind of parameters do you have in mind? Will also need some hosting abstraction to tie in with these lifetime interfaces, for example, it might be useful for an extension to know when it can observe caching semantics. Also has an impact on the (re) deployment story, for example, we may want to deploy extensions without stopping the server so we need to be able to do this and have the extension come up cleany. These don't need to be at the top of the list. +1 [deletia] I would extend the extra requirement added by JSD to include all runtime error, logging and audit requirements. +1. On the subject of audit, to do successful auditing we need to have access to the concept of an identity :) Has there been any discussion about this already? Oisin, good idea to put all this up on the wiki. I'll check there when you have added you first tranche and add comments in. Will email the list when it's in place. cheers --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
REST is a very generic term, and I think it's more like a resource/ service naming pattern (URL/URI). When we say REST bindings, what are we expecting as the REST Service ? The resource part is really important, but the small interface part is important too, as are the expected behaviours of the interface: i.e., GET is idempotent, PUT will replace a resource, POST will perform a partial update of the state of a resource. IMHO the first place we could go is an XML over HTTP binding and some kind of 'generic' processing method in the service (see [0] for an example of what's RESTful with JAX-WS, which might prompt some ideas). cheers --oh [0] http://java.sun.com/developer/technicalArticles/WebServices/restful/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
I think anything that is sent to/from a SCA REST binding needs to either be Plain Old XML or JSON and not SOAP. SOAP is generally what makes most RESTifarians shudder :) It's the encoding of the method in the XML body that is the anathema :) --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Apologies for addressing the emails in this thread out of order :)
I was on a similar track, thinking about implementing a REST
binding for Tuscany C++. I agree with you that the REST pattern is
about resources, so we need to go further than just sending XML
service requests over HTTP, and understand what it means to work
with resources in an SCA application.
I was thinking about starting with something very simple like this:
In an SCDL component reference:
reference name=customers
interface.resource type=http://my.business.objects/#Customer/
/reference
and later in a composite reference:
reference name=customers
binding.rest/
/reference
QName http://my.business.objects/#Customer; specifies an XSD
complex type describing my Customer business object.
binding.rest loads my new REST binding extension that knows how
to send Customer resource requests over HTTP.
interface.resource indicates a fixed interface pattern with the
resource management / HTTP verbs.
In the client:
customers.get(http://my.customer.database.com/customers/1234;);
returns an instance of the Customer XSD complex type
customers.put(http://my.customer.database.com/customers/1234;,
customerDataObject) updates customer 1234 with a Customer instance.
customers.get(http://my.customer.database.com/customers/;) returns
a list of URIs to the customers.
On the server, the CustomerResource component implements the
Customer resource management verbs:
class CustomerResource {
DataObject get(string uri);
void post(string uri, DataObject customer);
void put(string uri, DataObject customer);
void delete(string uri);
liststring list(string uris);
}
Yes I do like it, but I still have a fond attachment to the annotation
driven state-change - method mapping :)
You have .put and .get in the client example, maybe the .post should be
something like
customers.post(uri, state-diff)
where state-diff is a state format dependent serialization.
Also, I was thinking that somehow our REST work should tie in with
the DAS work that we're doing in Tuscany.
+1 - I know little about the DAS stuff as yet, but the REST/CRUD/BREAD
approach has a strong affinity for data sources. IMHO this would be
a great first step!
--oh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
Pete Robbins wrote:
Hi Oisin,
Here's the dumb question: What do you mean by Plugin? Is it a
composite or
group of composites?
Or just a set of extensions packaged in a library that you plug
into the runtime?
'Plugin' means a piece of software that adds some functionality in the
form of a core extension or an application element. So yes I think it
would work to have a composite bundled as a plugin - it also would be
a nice idea to have say binding.ws bundled as a plugin too. Lots of
scope - just the plugin mechanisms need to be clear, an SPI type of
thing needs to be in place and of course (the interesting piece ;) a
collection of shlib loaders for all the target platforms.
At this point I declare my allegiance to Darwin/powerpc :)
I'll add a few more requirements here :)
The extension programming model should be easy to understand by
people who have read the SCA spec. Using consistent terminology
(e.g. an implementation plugin/extension contributes the support
for a particular component implementation type) will help.
+1
Also the model used by the developer of an extension should be
consistent enough with the model described in the SCA spec. The in-
memory model describing SCA assemblies can be optimized for use by
the runtime, but it should be easy to grasp by the guy who just
read the SCA spec and just understood what a composite, component,
service or reference are.
For 'consistent enough' it would be good to say 'as consistent as
possible',
make it a bit stronger, otherwise +1
3. Plugins can be loaded on-demand, from dynamic libraries,
and many plugins can be put into a library.
Do you really mean multiple plugins in a library? or one plugin per
library contributing multiple extensions? I guess this depends on
what we mean by plugin :)
Multiple plugins in a library is the goal to be aimed for in the
long term, IMHO, the reason being it makes it really easy for an
extension provider to package everything up into one lib - so if
you have (for example) interface.idl, implementation.cxx.poa
and binding.iiop then you can just deliver them all as libcorba.so
and all will resolve gracefully.
4. Plugins can be statically linked with an application.
Could you describe the use case you have in mind? Does that apply
to just plugins? or the whole runtime?
I'll 'fess up and say that I have no particular use case in
mind right now. When I was writing that line, I was thinking
of 'embedded' applications - not in the sense of 'embedded
systems', although that might be an option for router hardware -
but in the sense of an SI constructing and provisioning a
system that uses Tuscany buried deep in folded layers of fat
application code. The Tuscany runtime is meant to stay buried,
and having a statically linked binary is an effective way to
do that -- it bakes the version in so that if a newer version
of Tuscany gets installed with shlibs, the old version won't
pick anything up by accident. Not a very strong case :)
5. Plugins should be evictable too, provided that this feature
is supported on the target platform.
6. There will need to be some kind of manager thingie to keep
track of plugins and their state at runtime.
I've been thinking about this and wondering what the architecture
of the runtime will be with many different plugins? Are you guys
envisioning one big process with different (maybe incompatible?)
libraries loaded in it? or a more distributed architecture with
multiple processes?
I must admit I've been toying with the idea of having multiple
processes handling the various component implementation types and
binding types, then it would be quite easy to bring them up/down...
What do you think?
It's late here and my brain is a mite melted, but I think I
can see advantage to both :) In the first case, I think that
having incompatible libraries cohabiting a process should be
ruled out of order, but it should be possible for example for
an application to be able to take advantage of multiple binding
extensions in the same process - this seems like a reasonable
expectation if you are writing something that is going to work
as a bridge, for example.
If I understand the second case correctly, you're thinking of
having separate processes for a {binding, implementation} pair
or something like that, rather than using IPC between binding
and implementations? If thats the case, that seems ok to me :)
7. Plugins need to support an interface for initialization
and shutdown at the least. There will need to be some kind
of simple lifecycle put together. Request for lifecycle
transitions will need to support parameters
+1 for a simple lifecycle interface. What kind of parameters do you
have in mind?
I'd go for a simple context-stylee thing with named properties
and simple typing. A bit of a step up from const void* const *
and pleasantly debuggable :)
9. Plugins have versions, and dependencies on other plugins too.
We may want to
Re: REST bindings for Tuscany SCA runtime
Hi Bert,
I am still at the point where I am trying to get my head really
wrapped around how Tuscany works
I will be travelling the same road soon ;)
Have you put much thought towards the subject of a REST binding? Are
there things about which you believe we should be aware?
Well, the thing that comes to mind first is the mismatch between
the basic REST approach of using a fixed set of 'verbs' richly flexible
data and the Interfaces approach, which uses an open-ended set of
'verbs' (read: operations) and constrained strongly-typed data.
[small REST primer - skip if you know all this stuff]
The short document at [0] below characterises some of the issues of
developing a (Web) service using REST principles and is useful and
the wikipedia link at [1] has a good example (generic, not Tuscany
specific) :
Say you have a service that has methods
getUser()
addUser()
removeUser()
updateUser()
then you might use code like:
exampleAppObject = new ExampleApp(example.com:1234)
exampleAppObject.getUser()
to get details of a user. This is the interface or unconstrained
verbs approach.
Now, let's flip over to a REST means of getting the same
information. In this case, you are limited to small set of
well-defined operations, which map very well to the CRUD [3]
operators that a persistence system must provide. Because
of this stricture, you need to ramp up the diversity of
nouns (or resources, or maybe objects, but really the concept
of a resource may not equal an object in programming terms,
many resources could be 'supported' by a single object).
These resources (which is the accepted term) are represented,
uniquely, and immutably, by URIs. So taking the example
above and REST-ing it you get resources:
http://example.com/users/
http://example.com/users/{user} (one for each user)
and then you might use code like:
userResource = new Resource(http://example.com/users/001;)
userResource.get()
and you get the same information as the Interface-y example
previously.
REST is liked by many, for many reasons, but one good on is
that it's scalable (the web is an
example, although there is an extra factor that makes the
web scalable and that is the 404) in the sense that everyone
supports the same 'interface' and the semantics of the interface
are simple and clear.
In practical terms, this means that you can just join the
web, as a resource, and you will immediately fit in. No adapters
required :)
[end of small REST primer]
My interest in responding to your initial mail was that I am
currently attempting to use RESTian principles in another
project and I am finding myself making lots of interesting
decisions that I would not have made using the Interface
approach that I have used for more years than I care to
remember. Using the REST principles has deeply impacted they
way I've approached the development of the development of
the project -- in a good way :)
I'm sure you've noticed the example I gave earlier on the
programming model is client-specific and so impacts on only
part of a prospective RESTian addition to Tuscany. There is an
impact on the server too, and that's a direct consequence of
the 'few verbs' approach - talking from a programming language
perspective, every 'servant' (or resource implementation may
be a better way to put it) will have a tiny interface.
My point is that if Tuscany wants to support REST style -
a goal which I think is good, right and true - it's a job
that will involve constructing a binding extension,
re-working the Basic Client Model (see 1.3 in Java CI spec)
and adding some new annotations to the Java interface (or
maybe adding a new interface type). Note that the same will
apply to other language mappings too since REST is language
neutral (it's also protocol neutral too as an architectural
style, but assuming HTTP as the #1 priority would be safe
enough :)
On the annotations I mentioned, consider something like:
package services.hello;
import org.osoa.sca.annotations.*;
@Remotable
public interface HelloService {
@RESTMethod(RestMethods.RETRIEVE)
@RESTBaseURIContext(/foo/bar/sossages)
String hello();
}
Here I've decorated the ubiquitous HW example from JCI 1.2.1.1
with some spanky new annotations. This example indicates to the
runtime that the hello() method should be called on this interface
should the 'RETRIEVE' REST method (for HTTP this is 'GET') appear
on the dispatch, directed to a URI that starts with the string
specified in with the RESTBaseURIContext (now - this is probably
the wrong way to do it, but I just trying to illustrate the
broad outlines of an approach, i.e. I am making it up).
Note that the concept of XML/HTTP interchange may be RESTful,
but indeed may not. However, it is the basis for an implementation
of a RESTful approach (given HTTP as the transport) and is
useful in an of itself (especially for so-called Web 2.0 apps).
Methinks I've said enough for now, thank you for reading this
far if indeed you have ;)
Re: REST bindings for Tuscany SCA runtime
Oisin may have been referring to how REST would impact the programming model rather than the implementation of bindings. For example, how would cache information in the request be handled by the binding and/or exposed to the application code? What is the mapping between REST resources and SCA services? Caching, which is only made possible by the fact the RESTful retrieves are idempotent, might be difficult to do effectively since it's not really possible to control what the programmer does from within a mapped retrieve method in the implementation short of giving them a new execution environment to be bad in :) IMO we can tackle this in to stages. First one is to get the basic transports working (like JSON-RPC, XML over messaging, HTML over HTTP etc.); that would at least allow SCA applications to provide/ access REST resources. The second stage would be to support more of the semantics of RESTful interactions. +1 --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[C++] Requirements for a pluggable C++ Tuscany implementation
Hi guys, I thought I might kick off a thread on pluggability in the C++ implementation to get some ideas rolling around, so while these are not 'requirements' at all, they might eventually lead to some ;) 1. Language independence is not an issue here, so all plugins are described and implemented in C++. 2. It should be reasonably straightforward to make a plugin with minimum code, so things like base plugin classes as part of the core are a good thing. 3. Plugins can be loaded on-demand, from dynamic libraries, and many plugins can be put into a library. 4. Plugins can be statically linked with an application. 5. Plugins should be evictable too, provided that this feature is supported on the target platform. 6. There will need to be some kind of manager thingie to keep track of plugins and their state at runtime. 7. Plugins need to support an interface for initialization and shutdown at the least. There will need to be some kind of simple lifecycle put together. Request for lifecycle transitions will need to support parameters 8. Plugins have names. Easy. 9. Plugins have versions, and dependencies on other plugins too. 10. Plugins describe and can validate their own configuration. 11. Plugins need to be signable, or equivalent. Comments? --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST bindings for Tuscany SCA runtime
Hi Bert, Sreelatha, Have you any thoughts on how a REST binding will need to influence the SCA programming model? rgds --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for callbacks
Yes I was counting on the binding (e.g. Celtix, Axis) to provide RM capabilities. However, we also need to manage stateful callbacks... We will need to spec the RM requirements with a magical policy or have some kind of constraint to validate the presence of the feature (spec issue I guess there). Quick clarification on what you call a stateful callback: Is a callback said to be stateful if the target of the callback needs to maintain state that will be influenced by the arrival of the callback? Or is a callback stateful if the source of the callback needs to deliver state to the target during the callback? Or both, I guess :) and I was thinking of persisting that state using a scope container that implements a mechanism similar to what is found in messaging systems like ActiveMQ (some type of identity-based store on the file system). What do you think? Sounds like a reasonable approach and fairly straightforward :) Is there a possibility of ordering constraints on the callbacks? This could put a crimp in the runtime if a failing callback was holding other things up. Reliable ordered delivery is going to be an interesting one :-) Does Celtix support or plan to support this? Well Celtix and similar projects implement WS-RM [0], but that only speaks to ordering and delivery of the wire messages really. Theres a thing called the Callback RM-Reply Pattern in the spec, it seems to just spec out how what the MEP looks like and the vocabulary of SOAP Headers to do the bookkeeping. It's probably better to state up front that ordering criteria MUST not be associated with callbacks. (Except of course that the callback must come after the call :D ). rgds --oh [0] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Icon
The cypress on the hill motif is pretty cool and it doesn't need to be too busy - take a look at http://www.tuscanystyle.it/index.html for an example of how it can be stylized. --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re-post of link to Mike Rowley's blog article on JBI
At the ApacheCon Tuscany BOF, there was some questions about JBI and SCA and what the story is there. Jim mentioned a blog entry by Mike that had an explanation of what JBI isn't - here's that link to remind everyone :) http://dev2dev.bea.com/blog/mrowley/archive/2005/08/jbi_doesnt_host.html --oh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More useful links mentioned @ ApacheCon Tuscany BOF
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]
Re: XML Comparison
Hi Simon, However this test compares everything and I am hitting the problem which is touched on in http://issues.apache.org/jira/browse/TUSCANY-427, i.e. my input xml files have comments and my output XML files don't so the current equalXML... function always returns false. What might be useful here is some XML Canonicalization (c14n) code that will munge both XML sources to a canonical form and then compare those forms. This does things like elide extraneous whitespace in the elements, reorder attributes using a particular algorithm, optionally remove comments and that kind of thing. The Canonical XML spec is at [0], but you might be more interested in the example implementation which you can find in the Xerces samples at [1]. A candidate for that testutils jar that Dan was talking about, perhaps. regards Oisin [0] http://www.w3.org/TR/xml-c14n [1] http://svn.apache.org/viewvc/xerces/java/trunk/samples/sax/ Writer.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Eclipse SOA Tools Project (was: Re: SDO tooling for Apache Tuscany)
You should be aware of the Eclipse SOA Tools Project (http://www.eclipse.org/stp/) since there is a potential overlap with them... And there's my cue... :) I'll introduce myself: my name's Oisin Hurley and I'm on the STP PMC. Some of you on this list might know me already, from the SCA process, since I get to do some of that too :) Right now in STP land [0] we are collecting scenarios to drive our planning process [1] for integrating the elements we have (specifically around the SCA model core and deployment areas). Needless to say, we would be keen to have a very diverse set of scenarios to wrangle over -- if you have something in mind, feel free to put it on the STP wiki (go to [2] for a bugzilla login to get the write access). Ok, that's the pitch over :) - on the subject in hand, while an EMF- based implementation of SDO for eclipse is available at [3], there are no efforts in progress in STP to create a SDO-generator wizard and AFAIK same goes for the other top-level projects. So you won't be stepping on any code :) On a general note, we're real open to any suggestions, code, questions or other feedback that you may have. There's usually a couple of people hanging out on #eclipseSTP at irc.freenode.net:6667 if you want to get in touch that way, or send a mail to [EMAIL PROTECTED] cheers Oisin [0] http://www.eclipse.org/stp [1] http://wiki.eclipse.org/index.php/STP_Call_for_Scenarios [2] https://wiki.eclipse.org/index.php? title=Special:Userloginreturnto=STP [3] http://www.eclipse.org/emf/sdo.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
