There is quite a bit of confusion over what Jangle actually is and I, myself, have at times been one of the confused as well. Since the scope and focus of Jangle has changed dramatically (although not completely fundamentally) since its inception as a project, there is a lot of detritus about past ideas of what Jangle is or should be. While it's possible that the current direction of Jangle might join that flotsam, I think we've found a reasonable direction.
So, what is Jangle?
In short, Jangle is an open specification for exposing siloed content (starting with, although not exclusive to, library services) consistently and simply using the Atom Publishing Protocol. The end result will be a set of conventions, authoritative terms and URIs, and a published API for how to overlay AtomPub (and its momentum and client and server tool support) over library applications (and specific examples of how this would work for an Integrated Library System or a repository or an Interlibrary Loan application, etc.). Another outcome would be an open source reference implementation as well as simple open source applications to bridge the gap between Jangle and the recommendations of the Digital Library Federation's ILS and Discovery Systems API task force, such as an Jangle to OAI-PMH service.
The Jangle architecture is made up of two components: the core, which is the AtomPub server front end, that federates the requests between the external client and the backend connectors. The business logic would exist in the connector for a specific application and pass responses to the core via JSON objects which the core then transforms into Atom feeds.
The spec currently defines the following entities:
although entities can be layered on each other to enable association (Actor has Items, Resource has Items, etc.).
The basics behind Jangle are intended to be quite simple, but scalable for greater sophistication if needed.