BibSonomy ::  tag ::

order by ( date | folkrank )

"...allows you to have private conversations over instant messaging by providing: Encryption [...] Authentication [...] Deniability [...] Perfect forward secrecy ..."

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/begriff_objektorientierte_programmierung_de Alan Kay coined the phrase Object-Oriented Programming, but this is not his fault. He has repeatedly said that to him, OOP is about encapsulation and message passing, not inheritance and ontologies of types. But like so many other Cargo Cults in Computer Programming culture, OOP and inheritance are enchained like ancient mariner and albatross

Kilim is a message-passing framework for Java that provides ultra-lightweight threads and facilities for fast, safe, zero-copy messaging between these threads. It consists of a bytecode postprocessor (a "weaver"), a run time library with buffered mailboxes (multi-producer, single consumer queues) and a user-level scheduler and a type system that puts certain constraints on pointer aliasing within messages to ensure interference-freedom between threads. Why? Hardware facilities are getting distributed, from the micro to the macro levels -- increasing numbers of cores, CPUs in a box, boxes in a data center to a multitude of data centers. The current crop of software architectures, languages and idioms are not suited to this trend. Here are a few reasons: A multi-core/CPU box is internally a distributed system, but operating systems and hardware manufacturers go to great lengths to provide an illusion of local shared memory. In reality, the illusion is never complete, which is why programmers have no option but to learn about non-trivial memory models and consistency schemes. The problems with shared memory has been well documented [ PDF ]. Different mindset between "concurrent programming" and "distributed programming". Programmers have to deal with both (even embedded systems have network interactions) and require separate sets of tools for verification, profiling and debugging these two patterns. The "events vs. threads" debate unnecessarily conflates two problems: threads are considered bad because they are (a) heavyweight (which doesn't have to be the case) and (b) the thread paradigm is implicitly associated with shared memory locking constructs that are error-prone, which again does not have to be the case. As Kilim demonstrates, it is possible to have lightweight threads that are just as lightweight as state machines, yet provide the automatic stack management feature (there's no need for the "return to the mainloop" mentality). The combination of lightweight threads plus message-passing is a good fit for the emerging world. It permits us to blur the line between concurrency and distribution -- the API (send/receive) is the same (although the failure modes and frequencies may be different), and allows a uniform set of tools for debugging, profiling, and verification. For example, the most common verification tool in practice, the SPIN model checker, is based on a message passing mindset. There is a good reason why Tony Hoare used "communicating sequential processes" as a model for verification.

Enterprise Social Messaging Environment (ESME) is a secure and highly scalable microsharing and micromessaging platform that allows people to discover and meet one another and get controlled access to other sources of information, all in a business process context. You can hardly turn a web page these days without seeing a story that describes how people are using social networks, whether it is Twitter, Facebook or some other service to develop and build their personal communities. In business, we increasingly see blogs and wikis demonstrating utility in problem solving and communications but the real time nature of business process problem solving largely remains untouched by social networking tools. Existing services, while attractive do not scale well and have proven unreliable. This is unacceptable to business which must be 'Always On' and able to support people in their daily working lives. Such applications must therefore be scalable and reliable but also provide a lot more. When solving problems, how good might it be if a user was able to tap into the collective knowledge of her peers or surrounding groupsof people with whom she might naturally network in the workplace setting? How much quicker and with greater precision might she be able to solve daily problems? What if there was a communications mechanism that takes the best of what services like Twitter offers and co-mingled that with readily recognizable business processes? That solution is ESME.

Hazelcast is an open source clustering and highly scalable data distribution platform for Java, which is: * Lightening-fast; thousands of operations/sec. * Fail-safe; no losing data after crashes. * Dynamically scales as new servers added. * Super-easy to use; include a single jar. Hazelcast is pure Java. JVMs that are running Hazelcast will dynamically cluster. Although by default Hazelcast will use multicast for discovery, it can also be configured to only use TCP/IP for environments where multicast is not available or preferred.

Alice A RESTful access to the RabbitMQ queue server, administration functions and (soon) monitoring. Wonderland A web-UI front-end to Alice, driven by Sammy.