With SharePoint 2013 the server part to edit/view Office documents with the browser is now a separate product and needs to be also installed separately. Therefore why not use this new server to show office documents from other sources?

We are using WOPI (Web Application Open Platform Interface) so that SharePoint 2013 and OWAS 2013 can communicate. A colleague wrote a great article what you need to know to implement WOPI into your own Web Application.

This blog post describes how to create a custom WOPI host. A WOPI host is document storage location that can connect to Office Web Apps Server to open Office documents in the browser. When the WOPI host is configured to use Office Web Apps Server, users are able to view and edit documents stored on the WOPI host by using Office Web Apps. Tyler Butler, Program Manager, Office Shared Experiences team, authored today’s post.

One of the great things about the Office Web Apps is that they let people work with their documents anywhere, on any computer. It turns out that there are lots of documents in lots of different places. For example, consider Outlook.com, or more generally, web-based email. You probably get documents sent to you via email every so often, and you probably want to open those documents to read them. One option is to download the file and open it in an application on your local computer. But if you're really just wanting to quickly check out the contents of the document, wouldn't it be easier if you could just click the document and have it open immediately in the browser? Wouldn't it be cool if that worked regardless of what software you had installed on your local computer? It could work when you're traveling and using an internet cafe computer, when you're using a friend's computer, or when you're at a conference and using a shared computer there.

With the most recent release of the Office Web Apps, developers can enable such scenarios in their apps directly by implementing the Web Application Open Platform Interface (WOPI). WOPI provides web-based services a way to view and edit documents in the Office Web Apps, with all the high-fidelity and richness that you expect from an Office document. While email attachments are a great example, there are plenty of other places where documents are used on the web -- bank statements, file-synchronization services like SkyDrive and Dropbox, etc. -- and there are compelling ways developers can leverage WOPI to treat those documents as something more than just a file that users download.

So if you’re a developer, this post is for you. Simply put, WOPI is the glue that connects the web apps to your documents, and it's an interface that you can implement yourself -- to dazzling effect. In this post series I'll talk about what WOPI is, walk through the basics of implementing it, and show you an example implementation.

In addition to this post, WOPI is documented in the [MS-WOPI] protocol document. That document is the authoritative documentation on the interface.

Fundamentals

To better understand what WOPI is conceptually, consider this: Have you ever opened a document on your computer by double-clicking the file and watch it open in Word? When you did that, you signaled the operating system that you wanted to open the file, so the OS figured out what application was associated with that file type, then passed the file over to the application to handle. That's a very basic description of the process, but conceptually that's what happens.

WOPI provides similar semantics for web applications, but the web is a little different than your local hard drive, so the process of opening the file is also a little different. In my simplified example above, the document was stored on your hard drive, and the operating system handled passing the file off to the application to open. In the scenarios for which WOPI was designed, though, the document is stored somewhere on the web. We call those document storage locations WOPI hosts or WOPI servers. This term will become a little clearer in just a moment, but think of a WOPI host as a service like SkyDrive. It's a place where you can put your documents or other files and make them accessible on the web.

If a WOPI host is a place where your files are stored, then what about the actual applications that open those files? We unsurprisingly call those WOPI applications or WOPI clients; the Word/Excel/PowerPoint/OneNote web apps are all examples of WOPI applications. These applications support various different actions, such as view or edit, and these actions can apply to different file types.

Going back to my original example of the document on your hard drive, the WOPI host is kind of like the hard drive -- but a little smarter. It stores the documents. The WOPI application is the app capable of performing an action -- doing something, in other words -- on those files, and WOPI is the interface that those two entities use to talk to one another. If you're a service or application that stores documents, then you can implement WOPI, making yourself a WOPI host, and WOPI applications such as the Office Web Apps can then consume the documents you're storing. Pretty compelling, huh? The rest of this post will go into the details of the interface.

...

..."

Interesting and cool that it's documented in detail (in my mind, a 59 page PDF for something like this equals detailed documentation ;)

In thinking about this, this could be pretty wow. Imagine you're an app provider/host (like say in the eDiscovery space...) and want to provide very high fidelity views of Office doc's, without the user having to download the file and open it locally, without requiring a plug-in or third party component. Where the file and service is under your control, all private cloud stuff, and neither is hosted in SharePoint.... I think WOPI fits this bill... hum... Must research this.