You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Andrew Borley <aj...@gmail.com> on 2007/02/08 10:37:14 UTC
[C++] Alert Aggregator Sample - was: Web 2.0 sample
On 2/6/07, Simon Laws <si...@googlemail.com> wrote:
> On 1/26/07, Andrew Borley <aj...@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On 1/24/07, Simon Laws <si...@googlemail.com> 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 <hm...@gmail.com> 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 <aj...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> > 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: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [C++] Alert Aggregator Sample - was: Web 2.0 sample
Posted by Simon Laws <si...@googlemail.com>.
On 2/8/07, Andrew Borley <aj...@gmail.com> wrote:
>
> On 2/8/07, Luciano Resende <lu...@gmail.com> wrote:
> > >>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
>
> :-) Absolutely - there's no rush - these aren't all short-term goals!
> I just spotted a place that would be a good fit for C++ DAS!
>
> Andy
>
> > On 2/8/07, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > On 2/6/07, Simon Laws <si...@googlemail.com> wrote:
> > > > On 1/26/07, Andrew Borley <aj...@gmail.com> wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On 1/24/07, Simon Laws <si...@googlemail.com> 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 <hm...@gmail.com> 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 <aj...@gmail.com> 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:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > > For additional commands, e-mail:
> tuscany-dev-help@ws.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > > >
> > > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> Andy
Noice work. I go the demo up and working. Looks pretty well rounded for a
first pass! I've had it running on my PC for a for a little while and have
watched the feeds being updated today. I had a bit of a struggle getting it
going due to the number of dependencies we have now and the environment
variable based approach we use. Not a reflection on the demo we just need to
tighten up the project setup.
It set me thinking that it would be useful to provide template scripts to
demonstrate to people what environment variables can be set and what they do
as a backup for the info found in the getting started docs. Here is what I'm
using to run the AlertAggregator. Not all of these are actually required for
the sample, e.g. the PHP ones are not required, but this is what I have set.
Windows
=======
set AXIS2C_HOME=c:\axis2c-bin-0.96-win32
set LIBXML2_HOME=c:\libxml2-2.6.26.ein32
set ICONV_HOME=c:\iconv-1.9.2.win32
set ZLIB_HOME=c:\zlib-1.2.3.win32
set HTTPD_HOME=c:\apache2.0.55\Apache2
set LIBCURL_HOME=c:\libcurl-7.15.4-nossl
set PHP_HOME=c:\php-5.2.0
set PHP_SCA_SDO_HOME=c:\pecl\sdo
set PYTHON_HOME=c:\python25
set PYTHONPATH=c:\sca\deploy\extensions\python\bin
set TUSCANY_SCACPP=c:\sca\deploy
set TUSCANY_SCACPP_LOGGING=9
set TUSCANY_SDOCPP=c:\sdo\deploy
set TUSCANY_SDOCPP_LOGGING=0
would also be useful to explain what the following are for
set TUSCANY_SCACPP_ROOT=%~d0%~p0\..\
set TUSCANY_SCACPP_COMPONENT=sample.calculator.CalculatorComponent
set TUSCANY_SCACPP_BASE_URI=http://localhost:9090/axis2/services/
Linux
=====
I'm guessing a little here as I haven't tried the sample on linux but it
would be something like
export AXIS2C_HOME=/home/slaws/apps/axis2c-bin-0.96-linux
export LIBXML2_LIB=/usr/lib
export LIBXML2_INCLUDE=/usr/include/libxml2
export PHP_LIB=/usr/local/lib
export PHP_INCLUDE=/usr/local/include/php
export PHP_SCA_SDO_INCLUDE=/home/slaws/phpbuild-5-2/pecl/SDO
export PHP_SCA_SDO_LIB=$PHP_LIB/php/extensions/no-debug-zts-20060613/
export TUSCANY_SDOCPP=/sdo/deploy
export TUSCANY_SDOCPP_LOGGING=0
export TUSCANY_SCACPP=/usr/local/tuscany/cpp/sca/deploy
export TUSCANY_SCACPP_LOGGIN=9
etc.
Unless there is a way to automatically discover this info I could drop some
scripts into the sca root dir to give people an idea about what they
can/need to set.
On this note we could pull this all together with a page about dependencies.
I've started this on the cwiki with a view to translating it into a doc page
when we are happy with it. [
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+CPP+Dependencies]
Also the samples expect certain things to appear on the PATH, e.g. Python,
Ruby, PHP bins. We could update our samples scripts to force this to be the
case. My windows installer installed the Python package without adding it to
my path for some reason and it causes the samples to fail.
I got stuck on an error message caused because I had failed to upgrade to
the latest version of axis which in turn causes the ws extension to fail to
load. The result was a rather mysterious error message. I'll investigate and
propose an alternative.
I think doing an alternative of the display in PHP would be a good test (or
even just using PHP to provide an RSS version). The alerter composite can
stay the same and we just switch out the display part for a PHP
implementation. We don't have a REST binding just yet, it's being worked
on:-), so I may have to switch to a web services binding.
The other thing is that we could have a PHP server and to the demo
completely stand alone for the case where we don't have network
connectivity.
Simon
Re: [C++] Alert Aggregator Sample - was: Web 2.0 sample
Posted by Andrew Borley <aj...@gmail.com>.
On 2/8/07, Luciano Resende <lu...@gmail.com> wrote:
> >>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
:-) Absolutely - there's no rush - these aren't all short-term goals!
I just spotted a place that would be a good fit for C++ DAS!
Andy
> On 2/8/07, Andrew Borley <aj...@gmail.com> wrote:
> >
> > On 2/6/07, Simon Laws <si...@googlemail.com> wrote:
> > > On 1/26/07, Andrew Borley <aj...@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On 1/24/07, Simon Laws <si...@googlemail.com> 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 <hm...@gmail.com> 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 <aj...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > > >
> > > > 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: tuscany-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: [C++] Alert Aggregator Sample - was: Web 2.0 sample
Posted by Luciano Resende <lu...@gmail.com>.
>>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 <aj...@gmail.com> wrote:
>
> On 2/6/07, Simon Laws <si...@googlemail.com> wrote:
> > On 1/26/07, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On 1/24/07, Simon Laws <si...@googlemail.com> 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 <hm...@gmail.com> 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 <aj...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-user-help@ws.apache.org
> > >
> > > 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: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>
Re: [Native] Threading issues with Ruby on Windows, was: Alert Aggregator Sample - was: Web 2.0 sample
Posted by Simon Laws <si...@googlemail.com>.
On 2/12/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> [snip]
> Andrew Borley wrote:
> > 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.
>
> The Ruby 1.8.5 interpreter is not thread safe. To work around this
> limitation on Windows (where HTTPD runs multithreaded) we can use CGI
> (or FastCGI like many Ruby on Rails users do).
>
> Note that this is not really a problem on Linux where most people run
> multiple HTTPD processes instead of threads.
>
> I have started a CGI variation of the server side REST binding support.
> This can be an interim solution on Windows until the Ruby interpreter
> becomes thread safe, as well as a super easy way to test REST based
> applications outside of the server, just from the command line...
>
> BTW your Web 2.0 sample app is really cool!!
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
> For PHP we have set ourselves up to modify the Tuscany Native SCA PHP
extension to allow PHP to act as the hosting environment, i.e. we rely on
PHP's existing integation with HTTPD to do the work for us. The advantage to
us is
1/ To the PHP developer their deployment story is that same as for any other
PHP application. I.e. they drop PHP scripts into the document root.
2/ They do need extra infrastructure and don't need to mess with the HTTPD
configuration, i.e. PHP would load a PECL extension which in turn would load
the Tuscany Native librarys. This solution still has problems in the LAMP
hosted environment but it is at least familiar to the PHP developer.
3/ Close integration between PHP SCA/Tuscany Native SCA without recourse to
remote bindings. Don;t have a specific use case but many PHP extensions are
wrapped libraries so this provides an alternative high performance (?)
mechanism for introducing native application level components to a PHP
application.
We haven't actually made this run but we have constructed the PHP extension
to allow us to do this fairly easily. Anyhow just thought I would share this
thought as it seems to fit in with what Jean-Sebastien is suggesting as a
stop gap for Ruby.
Regards
Simon
[Native] Threading issues with Ruby on Windows, was: Alert Aggregator
Sample - was: Web 2.0 sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Andrew Borley wrote:
> 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.
The Ruby 1.8.5 interpreter is not thread safe. To work around this
limitation on Windows (where HTTPD runs multithreaded) we can use CGI
(or FastCGI like many Ruby on Rails users do).
Note that this is not really a problem on Linux where most people run
multiple HTTPD processes instead of threads.
I have started a CGI variation of the server side REST binding support.
This can be an interim solution on Windows until the Ruby interpreter
becomes thread safe, as well as a super easy way to test REST based
applications outside of the server, just from the command line...
BTW your Web 2.0 sample app is really cool!!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org