On 2/8/07, Luciano Resende <[EMAIL PROTECTED]> 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 <[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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
