I understand that XMPP is used in chat services, but it seems to be more generally useful than that. Can someone list some scenarios and examples where you would consider using XMPP, and the pros and cons of it versus other approaches?
I know that Dropbox uses it for its filesharing system in Android (possibly it does in other platforms too).
Cons: much more verbose than binary (more bandwidth).
Pros: a wide variety of already implemented client and servers. A wide range of already implemented reliability, scalability, security, presence, rpc, federation, custom components, mail, VoIP mechanisms... the list is very very long. Even if you need something different, and you know where to touch, you could extend it to your needs, inheriting all the already implemented features.
We had a project on collecting information eg. wind direction, temperature, stock and forex, etc. Every sensor is a Jabber 'user'.
This allows us to detect if a sensor
is online, offline or problematic.
Sensors also publish information to
a pubsub node to be distributed to
collectors.
Human users can also
interact with a particular sensor by
querying with the sensor. The sensor
returns human friendly formatted
data.
We use it for chatrooms, and for distributing sports results to users watching live events.
Google Buzz and Facebook talk is built on it.
Related
my app has passed the first review (yay) - but has now been passed to Allion for 'hardware review'.
The issue is that I am not providing hardware, i've provided voice interactions for an open source HA system, which in turn can support 00s of device types.
The Amazon review process was happy for me to provide them credentials to my service, which had access to a subset of device types, to then QA the interactions.
Is this normal for the review process?
Thus far many of the supported services have been direct hardware partners who own their own hardware and cloud. If your integration is done in a slightly different way it may require special instructions to your reviewer that may be different from normal.
I have had further comment from Google. Unless I can provide 1 of every type of physical device that the underlying HA system supports, they will not review, or certify my app. What this tells me is that either Google aren't committed to small SaaS providers & HA enthusiasts, or that this comment is not true. I note that there are several equivalent services listed on Smart home app list, which do exactly the same thing as mine. I rather doubt they provided one of every manufacturers zwave switch/light etc etc. Very disappointing, Amazon have a more welcoming approach –
I was reading a paper titled "An Optimized Web Feed Aggregation Approach for Generic Feed Types" and googles PubSubHubbub protocol was discussed and the paper stated its drawback something like
Furthermore, there are patch systems such as pubsubhubbub (Google 2010) which can be seen as a mod-erator between feed readers and servers. All of these solutions only work if both, client and server support the extensions, which is rarely the case. Pubsubhubbub, for example,is only supported by 2 % of the feeds in our dataset.
I have never really interacted with this protocol , does it require clients (subscribers) to have some sort of a software on their system like feed listeners are required on the client side(subscribers) for obtaining feeds (is that what the above means) ?
I am not sure where they pulled that 2% number from, but it is probably not right.
For example, all the major blogging platforms support PubSubHubbub. A lot of news outlets (HuffPo, Gawker, Foxnews, ABCLocal...) support the protocol too.
Many other services, like Craigslist, Getglue, (even StackOverflow) . A lot of other services, like Github or Instagram do support PubSubHubbub-like APIs for JSON resources, even though this is outside of the current (0.3) spec.
The list goes on and on and on.
Now as far as complexity, it really isn't that difficult for a huge benefit. The "clients" (technically these are web servers) need to visible, accessible outside the firewall.
For publishers, it is even easier as they just need to ping (a simple HTTP POST request) the hub that they've chosen previously.
I am really curious to know how Google Buzz and Facebook implement their comment feature which is being updated instantly. is it similar to Google wave technology? are there any resources to learn that technology and implement it to our website?
Thanks !!
I work on the Google Buzz team, so hopefully I can give you a good answer for our side of the equation. I obviously won't go into any of the confidential backend stuff, but I'm happy to address the open standards we use and the open source projects involved.
Starting in the UI space, we use technologies like Closure and GWT to build rich, responsive user interfaces. We use a technology vaguely similar to what you see in the Google App Engine Channel API to push real-time updates to the users. GAE is a really good choice for real-time web applications right now.
On the API side of things, we try to use open standards wherever possible. We use the Atom syndication format to enable feed readers to consume Buzz content, and Pubsubhubbub to enable real-time pushes of the content. In fact, we use Pubsubhubbub for our activity firehose — it's possible to subscribe to the entire real-time stream of all updates that happen in Buzz. Needless to say, this sends a massive amount of traffic to your application. On the JSON side of the equation, we use Activity Streams, and we're actively working with the community to refine and improve that specification. Our Atom feeds include Activity Streams as well, but the focus there is on syndication. All our secured API endpoints for Buzz use the OAuth standard for authorization.
On the backend, I think the only thing we're willing to say publicly is that Protocol Buffers are pretty awesome.
The technology is called Real-time web (http://en.wikipedia.org/wiki/Real-time_web). You have many application models to achieve real-time and one of them is Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29). Good server to use it in your implementation is APE (http://www.ape-project.org/). It supports many common javascript frameworks. More you can check in provided links.
I am about to use Apache Hadoop, the headlines read:
The Apache Hadoop project develops
open-source software for reliable,
scalable, distributed computing.
I can relate "scalability" to programming, but I just don't know how this "distributing" can help me in my development. According to wikipedia:
A distributed system consists of
multiple autonomous computers that
communicate through a computer
network. The computers interact with
each other in order to achieve a
common goal
So does this mean I can deploy my web apps across multiple computers and do some sort of "intense computing"? The terms that come into my mind are Content Delivery Networks and Cloud Computing.
Web development has always been about distributed computing, since clients have been on different machines to the servers they talk to, web pages can pull in resources from many servers to build a page's content, and servers may talk to other machines to achieve their goals. CDNs make this more obvious than before, but really they're just an evolution, an introduction of a virtualization/indirection layer between what you ask for and the hardware used to provide it.
Clouds are about taking the concepts of virtualization and applying them to remote hosting, both of low-level OSes and higher-level software platforms. The really interesting thing about them is that this enables different business models on the part of customers (and with different risks too, but that's mostly not related to the fact that it's distributed computing but rather that it is not wholly under your control in your own jurisdiction).
I've found that the most effective use of distributed computing is when you think in terms of connecting together distinct services, each of which with different capabilities (which might be for technical reasons, or might not; sometimes, it's for business or legal reasons that things have to be divided up) and where each of those services may be provided by many components in multiple locations. There are, and continue to remain, issues with balancing the need for performance (which is a force that brings components together) and the need for robustness (which tends to lead to distribution and replication) within the overall context of the general capabilities map.
My goodness! That paragraph sounds like terrible piffle! What I'm trying to say is that it's all trade-offs, and you should be prepared for not getting it right first time.
(Hadoop is a mechanism for doing a distributed file store, and for efficiently applying certain classes of operation – those that fit well with MapReduce or other similar scatter-gather algorithms – across that whole dataset. If that shoe fits, use it. But it doesn't solve all problems, and thank goodness for that! Things that can do everything tend to look very much like things that can't actually do anything at all, and usefulness and comprehensibility come in the restrictions.)
Hadoop is typically used to process massive data sets by distributing the processing of that data set across multiple machines.
What this means is you probably don't want to use it to "deploy an application". You might use it to process stats on your application, however. For instance, you might have very large logs of user data. This would happen if your user data grows to become too large to fit on a single hard drive, and/or would take too long for one machine to process stats on (using standard methods like an SQL query).
Ygam. While the traditional role of "clients" and "servers" have been pretty stable from 1960 till about 2005.
I believe with every fiber of my being, that distributed computing is that we all carry processors around in our pockets.
Phones do computing work. Phones do NOT need centralized servers, but they DO benefit from them.
Phones , Smartphones, tablets are an example of where distributed computation is going.
You can make a wifi base-station out of an Android device now. So now a phone becomes a server of sorts for just that instant in the coffee shop that you turn it on for that cute person next to you without internet ....and now I digress.......
Does anybody knows how several tens of display screens are refreshed each second in stock exchange buildings?
Of course the server pushes the data to each screen, bud is this custom technology or some well known technology like example MSMQ ?
Are there any study papers, books or something for the architecture of this kind of software ?
Regards
I believe this is generally referred to as Messaging. From RabbitMQ:
What is messaging? Messaging describes the sending and receiving of
data (in the form of messages) between
systems. Messages are exchanged
between programs or applications,
similar to the way people communicate
by email but with guarantees on
delivery, speed, security and the
absence of spam.
A messaging infrastructure (a.k.a.
message-oriented middleware, a.k.a.
enterprise service bus) makes it
easier for developers to create
complex applications by decoupling the
individual program components. Rather
than communicating directly, the
messaging infrastructure facilitates
the exchange of data between
components. The components need know
nothing about each other’s status,
availability or implementation, which
allows them to be distributed over
heterogeneous platforms and turned off
and on as required.
In adopting this architecture, the
developer is insulated from the
details of the various operating
systems and network interfaces
involved and the interoperability,
scalability and flexibility of the
application are improved.
Please see this presentation on Why
you might need messaging for a general
introduction or this page on Wikipedia
for more information.
One popular paradigm for implementing messaging is publish/subscribe. Some implementations are implemented using point-to-point communication on TCP, some are using multicast on TCP/UDP.
For stock exchange displays, including other financial software that provides real-time prices, the prices are pushed to the clients rather than let them periodically request for the information (poll.) This is done to provide as near real-time prices as possible.
It tends to be proprietory software, with all the information providers (Reuters, Bloomberg etc.) supplying their own client libraries and/or applications. Most big banks (or at least the ones I've worked for) use Sun enterprise class servers, and Windows trading desk workstations.
I believe they use custom protocol through TCP/IP. Each display is connected to internal LAN network and requests for information as needed.