Show how the AlertConfig component could be replaced with one that uses a DB for storage (instead of the current XML file) - perhaps the new C++ DAS could be used here?
Sure, but we might need to wait little bit till DAS C++ functionality is in better shape. -- Luciano Resende http://people.apache.org/~lresende On 2/8/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
On 2/6/07, Simon Laws <[EMAIL PROTECTED]> wrote: > On 1/26/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > Hi Simon, > > > > On 1/24/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > Hi Andy > > > > > > Understanding how we fit into the Web2.0 space has got to be a good > > thing. I > > > also like the idea of providing an example that has some useful purpose. > > So > > > the application you have outlined gets my vote. > > > > > > In terms of providing examples and samples generally... > > > > > > 1/ It strikes me that if we can start building up a library of useful > > > components then we have a better chance of producing examples more > > quickly > > > in the future. You never know, people may want to adapt some of our > > example > > > components (they are unlikely to want to adapt the calculator components > > > :-). I'm particularly attracted by your Alert Checker components which I > > can > > > imagine being more generally useful. When we think about how to build > > this > > > example can we set it up so that the components are explicitly reusable. > > I.e. > > > this could simply mean constructing each (group of ) reusable components > > in > > > a separate directory. (The composites we have in the current CPP samples > > > seem to collect all of their components into one place by composite). > > > > Agreed - I'm trying to make the components nice and modular so that we > > can show components easily being replaced by other components or > > reused in different configurations. > > > > > 2/ I would also like to be able to say what problem we are solving from > > a > > > user/business perspective. You would expect this to be all of the usual > > > things that we hold up as good things about SOAs but I think we can give > > > some life to this through examples like the one you have suggested. So > > for > > > example, If I were running an organisation that has a static web site > > > currently, I might be asking questions like How do I... > > > - make my web site more attractive to customers by making it more > > dynamic > > > - present a view of various back end systems > > > - reduce the amount of person time spent updating the web site. > > > - reduce the technology gulf (and hence isolation etc..) between my > > back > > > end developers and front end developers > > > - reuse work I have done on previous efforts more effectively > > > - consistently aggregate content from that business I have just > > acquired. > > > . etc, etc. > > > > An article, or some kind of FAQ page that answers these questions > > using SCA might be a really persuasive bit of marketing for us! > > > > > There are many many more questions that people will ask. Now, on the > > face of > > > it, none of these say anything about SCA specifically but we are > > proposing > > > that SCA, as a programming model, provides a good basis for solving > > these > > > problems. It doesn't do it alone, i.e. there is no magic bullet, but > > it's an > > > important part of the mix. So what would be interesting as we develop > > > examples like this is to document exactly what questions we think we are > > > answering. It's great if we produce an interesting Web2.0 app but much > > > better if, having done it, we can answer, in layman's terms, the > > question of > > > why it is better to do it with SCA rather than the 1000s of other ways > > it > > > can be done. I imagine that there is a finite set of compelling value > > > statements that we can focus on. I don't have a list to hand but I'm > > keen to > > > help here collecting these "success stories"/value statements. Knowing > > what > > > we are trying to show is a good input into the kind of examples we > > choose to > > > build. > > > > > > In a little more detail. > > > > > > I would put more emphasis on the a variety of protocols in the display > > > composite as it would be nice to extend this app to include an AJAX > > style > > > front end. It would be good to do the display composite in PHP. So, for > > > example, the most useful format for the alerts would be a feed in it's > > own > > > right. We already have some feed samples in PHP so we could reuse this. > > I'll > > > think a bit more about this and give some pointers. > > > > That would be cool - the Alerter Composite provides the data as a > > REST/XML service which could be consumed via AJAX calls, but exposing > > it as an RSS/Atom feed would be another good addition to the display > > composite. > > > > > What is the AlertConfig component doing. I will be useful to show in an > > > example how components (feeds) can be included/excluded. Will this be a > > > static configuration exercise in the first instance or this there > > intended > > > to be some dynamic element to it, i.e. you can imagine that having a RSS > > > feed reader, or not, would be statically configured while the specific > > feeds > > > to be read would be dynamic. > > > > The AlertConfig component holds the configuration/state details needed > > for each checker component - such as a pop server, username and > > password for the POP Checker component, and an RSS feed URL and last > > checked time for the RSS Checker. The checkers are designed to be > > reusable, so the config could hold details for n different RSS feeds, > > all of which are checked using the same component. > > > > Cheers > > > > Andy > > > > > On 1/22/07, haleh mahbod <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Andy, > > > > > > > > This is an interesting technology sample that demonstrates various > > > > capabilities that Tuscany offers. > > > > > > > > It would be good to get user feedback on this as well. > > > > > > > > Haleh > > > > > > > > On 1/19/07, Andrew Borley <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi all, > > > > > > > > > > One of the things we thought would be good to include in the next > > > > > release of Tuscany C++ was "some kind of Web 2.0 sample" that would > > > > > show the various functionality of Tuscany C++ (and perhaps Tuscany > > > > > Java and SCA/SDO for PHP too) all working together in one app. > > > > > I've had a think around this and come up with the following idea > > that > > > > > I'm throwing open for abuse/ideas/development/etc! > > > > > > > > > > Global Alerter > > > > > A feed-reader style webapp that aggregates various sources of > > changing > > > > > data into a series of "alerts" that are displayed in, and > > > > > automatically updated via AJAX calls from, a web page. Alert sources > > > > > include RSS/Atom news feeds, POP3/IMAP email, NNTP newsgroups, SOAP > > > > > services (such as stockquotes). > > > > > > > > > > See the attached png for the initial SCA diagram (I've also put it > > up > > > > > at [1] if the mail-list doesn't let png's through) for a bit more > > > > > detail. This shows some of the power that SCA and Tuscany provides: > > > > > - the 2 composites could run in separate containers or even > > different > > > > > SCA runtimes (say HTTPD/PHP with SCA_SDO for the Display Composite > > and > > > > > HTTPD/Tuscany C++ for the Alerter Composite) > > > > > - we could show extensibility by adding extra Checker components for > > > > > other data sources (such as a component that checks for changes in a > > > > > specific web page) > > > > > - we could show re-use of components by using the Web Service > > Checker > > > > > to call a stockquote service and a weather forecast service. > > > > > - we can use different languages to implement the components > > > > > > > > > > It would be nice if the web front end could also show what is > > > > > happening under the covers - perhaps by displaying the SCA diagram > > and > > > > > highlighting which pieces are being called when the user chooses to > > > > > update the alerts from a particular data source. > > > > > > > > > > So, any ideas/thoughts? > > > > > > > > > > Thanks! > > > > > Andy > > > > > > > > > > [1] http://people.apache.org/~ajborley/web2demo.png > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > Hi Andy > > Finally ready to lend a hand here. Where should I look for the details? > > Simon > Hi All, Finally got the first version checked in! (see [1]) It pretty much follows the SCA diagram at [2], with the following components implemented: POPChecker - gets emails from POP3 servers RSSChecker - gets items from RSS/Atom feeds AlertChecker - aggregates alerts and is exposed via the REST binding allowing clients to get the latest alerts and get/alter configuration AlertConfig - manages the configuration (which RSS/Atom/POP sources to be used). This currently uses an XML file to hold the config. These 4 components make up the Alerter composite. There is also a Display composite which has a single HTMLDisplay component. This calls the AlertChecker REST service, converts the results to HTML and exposes a REST service itself. This service is called using AJAX calls from an HTML page. See the web page screenshot at [3]. This sample requires the following Tuscany extensions: Python REST service (which itself requires HTTPD) REST reference (which itself requires libcurl) It also requires the Python FeedParser library for the RSS/Atom support, found at [4] Deploy/run in the normal way for HTTPD based samples and then point your browser at http://localhost:9090/ Further things that could be done: Demonstrate use of more than one language/SCA runtime. Currently all components are implemented in Python. There is a Ruby version of the POPChecker, but I hit threading issues when I tried to use this under HTTPD so I had to replace it with a Python version. Additionally,the display composite could be replaced with one written in PHP or similar, which may be more natural than using Python again. Fix other threading issues - I think there may still be threading issues with the Python extension (and possibly the kernel itself). The sample is a little unstable and can fall over when multiple AJAX requests are sent in at the same time. Show how the AlertConfig component could be replaced with one that uses a DB for storage (instead of the current XML file) - perhaps the new C++ DAS could be used here? Add further alert sources (NNTP newsgroups, Web Services, etc) Add a component to the Display composite that formats the alert data as an RSS feed. Make the web interface a bit prettier! It's Web 2.0 in that it uses AJAX and Javascript DOM handling, but it's not very curvy or well laid out like the better known Web 2.0 apps tend to be! What do people think? Cheers Andrew [1] http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/AlertAggregator/ [2] http://people.apache.org/~ajborley/web2demo.png [3] http://people.apache.org/~ajborley/AlertAggregatorScreenshot.png [4] http://feedparser.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
