That's a good list Sebastien!
On 11/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote: > Andrew Borley wrote: >> On 11/9/06, Simon Laws <[EMAIL PROTECTED]> wrote: >>> On 11/8/06, Andrew Borley <[EMAIL PROTECTED]> wrote: >>> > >>> > Hi everyone, >>> > >>> > Now M2 is finally available, we should start thinking about what we'd >>> > like to do next in Tuscany C++. There were quite a few items that >>> were >>> > suggested for M2 that we ended up leaving out for time reasons and it >>> > would be good to progress the function we have in M2. >>> > >>> > Things I would like to do/see: >>> > - Add initial support for SDO handling in the Python extension (as an >>> > XML serialization) >>> > - Remove requirement for componentType side-files for Python >>> components >>> > - Get the PHP extension up to the level of the Ruby/Python extensions >>> > - perhaps by using the SCA for PHP stuff >>> > (http://www.osoa.org/display/PHP/SCA+with+PHP ) >>> > - Improve the samples for the scripting languages (nebulous! does >>> > anyone have any good ideas?) >>> > - A sample showing the different languages working together. >>> > - A standalone REST binding - we can do a limited REST via the >>> > support in Axis2C, but I think it would be cool to have a real >>> > binding.rest that we can host in HTTPD. >>> > >>> > Please join in with your own thoughts/plans! >>> > >>> > Cheers >>> > >>> > Andy >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > Hi Andy >>> >>> I like the idea of extending the PHP extension and it would be pretty >>> interesting to see if we can make the PHP extension use the SCA for >>> PHP work >>> we have in the PECL SCA_PHP project (see the homepage at >>> http://www.osoa.org/display/PHP/SOA+PHP+Homepage). I do of course >>> have a >>> vested interest here ;-) In PHP SCA we don't use component type files >>> instead we rely on annotations and we also have SDO integration. The >>> thing >>> about this is that we have a set of APIs that are, to some extent, an >>> interpretation of SCA and SDO as we thought they should be presented >>> in a >>> scripting language. Now it may very well be that our interpretation >>> needs >>> adjusting so this exercise of looking at PHP, Python, Ruby >>> extensions to C++ >>> SCA together will be really useful. >>> >>> Of particular interest is how we push down the model from the scripting >>> language into the C++ model. So I imagine a set of APIs that allow >>> us to >>> extend/complete the SCA C++ model by adding components type, >>> components, >>> services, references, wires etc. as a result of parsing the >>> information in a >>> supplied script. There is an interesting crossover point when it >>> comes to >>> bindings, i.e. we have the oppotunity to leverage scripted or native >>> bindings. >> >> +1 it would be good to re-jig the tuscany::sca::model::ModelLoader >> class so that the loading/initialisation/wiring of composites can be >> done either via files (as it is now) or programmatically. This would >> allow extensions to define their composites via annotations, etc. >> >>> From a samples point of view, the likes of PHP and Ruby get used a >>> lot to >>> implement web applications and particulary now as the service >>> providers for >>> AJAX applications. In particuar we now have JSON-RPC/SMD support in >>> PHP SCA >>> (just about to be checked into PECL). So we could do something there >>> showing >>> how SCA describes integration through multiple application tiers. >>> >>> The big question for me is how langauge specific do the sample have >>> to be. >>> It's useful to have a single sample that shows how you do SCA stuff >>> in all >>> of the different extensions. Calculator? But I think it would also >>> be useful >>> to show the extensions operating in some more systematic sample. I'm a >>> little sceptical about just using the extensions arbitrarily in >>> samples like >>> big bank but would rather use them where they are appropriate. So >>> using a >>> PHP or Ruby component to provide the GUI experience for Big Bank makes >>> perfect sense. Just implementing the account service in Ruby or PHP >>> is less >>> compelling. >>> >>> I don't have that much experience of Python. The one time I have >>> come across >>> it we were using it for infrastructure scripting I.e. we were using >>> it in >>> place of a shell script so it would be interesting to have some SCA >>> components that play this role. In my particular case we we were >>> providing a >>> job execution service so we had a number of scripts, e.g. assess job, >>> provision servers, provision data, run jobs, retrieve results etc. >>> >>> We could pick any process where scritps are often use, e,g, ETL/data >>> processing pipelines or batch control. Perhaps we could invent some >>> data/document processing pipeline that has various scripted >>> components that >>> can be wired in in different ways to change the end effect, for >>> example, you >>> can imagine todays application developers being familir with >>> scripting in >>> data integration scenarios where they have to build service which go >>> and >>> pull answers from lots of web sites and data resources. A script being >>> required to handle the peculiarities of each web site's particluar API. >>> Typically a problems in the "tell me all the houses for sale in my >>> area" >>> type of question. SCA script components would be good here because >>> you can >>> use the environment most appropriate for the peculiaries of the >>> particular >>> data source in question and then use SCA to stitch it together. >>> Anyhow just >>> some thoughts. >> >> This sounds like a good idea. These mash-up type applications would >> fit pretty well with SCA I'd say (should actually make them easier). >> >>> In doing all this scripting stuff we need to think about how SCA is >>> hosted. >>> Currently we have Axis and local hosting IIRC. We need to think >>> about more >>> direct HTTPD hosting. This is not the same as, but fits alongside, >>> the REST >>> binding thoughts. >> >> Don't quite understand this - we can be hosted in Axis on HTTPD, and >> create a REST binding to be hosted on HTTPD. Does direct HTTPD hosting >> mean that SCA components can return HTML (or some other browser-usable >> data) that is returned by the HTTP call? Kind of a less-formal REST? >> Invoked via a call to >> http://server/sca/compositeName/componentName/methodName or something >> like that? >> >> >>> Are we maintaining the tasks link ( >>> http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks)? >> >> Not yet! Feel free to update it! >> >> Thanks >> >> Andy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > Hi, I'm catching up on this thread after some conference travel and > other work distractions. > > This all sounds like a pretty good plan! I'd like to add a few more > things... > > Runtime: > - Improvements to our exception handling (I ran into this when > preparing Tuscany demos for conferences, and could have used better > error reporting...) > - Utility classes to handle data conversions (instead of repeating > similar code in several extensions). > - Validation of an SCA composite with meaningful error messages. > - A single working Windows build with VC++ express 2005.
YES!!!! I've had enough of trying to maintain multiple ide projects. We can document the steps needed if someone wishes to import the code to a VS IDE.
> Hosting / deployment: > - Make the integration with Apache Httpd (behind mod_axis2) our > default hosting story, make sure it's easy to configure and deploy, > test it, document it, etc. > - RPM packages for our distributions to help installation on Linux > systems. > > Bindings: > - A Qpid binding. > - A real REST binding (using Httpd on the server and Curl or Serf on > the client), with support for cookies, Http headers etc. > > Samples: > - A sample showing how to turn existing C and/or C++ code into an SCA > component. > - Real world samples talking to Google search, Amazon, Yahoo, Ebay, > Amazon... > - A more distributed BigBank sample, with separate composites for > Account, AccountData, the mediation component in front of the > StockQuoteService, and a client UI. > - Complete the implementation of the WS-I SupplyChain scenario. > Forgot one more thing... build all the above on Mac OS-X.
I just ordered up a new iMac today ;-) --
Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Pete
