Programming Excel Services

Posted Sun, May 13 2007 16:49 by vapordan@hotmail.com

Here is a link to the new book:

https://www.microsoft.com/MSPress/books/10933.aspx

Here are a couple of paragraphs exercepted from chapter 1:

Every now and then, a product hits the market that causes a significant shift in the way software is designed and built. Excel Services is one such product; it completely changes the way Microsoft Office applications are written. Chapter 1 will focus on introducing and explaining the Excel Services architecture that drives this fundamental shift in thinking so that you can gain an appreciation for the product. The focus is less on code and more on painting Excel Services in broad strokes allowing you to grasp the grand design. Later on, we intend to probe the basic building blocks that drive this new technology. We will then work our way up to some of the more advanced concepts of building and integrating sometimes disparate applications on top of the common infrastructure backbone exposed by Microsoft Office SharePoint Server 2007.

What is Excel Services

Excel Services is a new technology that allows developers to load, calculate, and display Excel workbooks on Office SharePoint Server 2007. In some respects, Excel Services behaves much like a development framework that allows developers to build applications based on Excel workbooks. The concept of providing a framework for developers is certainly not new, think the .NET framework. However, the way in which this technology is exposed is fundamentally different from legacy approaches. It is this radically different architecture that enables new applications that target Microsoft Office and SharePoint to be efficient, robust and scalable. Legacy Office applications can scarcely make that claim ring true.

Excel Services is built on ASP.NET 2.0 and Microsoft Office SharePoint Server 2007.  The architectural decision to platform Excel Services on .NET and Microsoft Office SharePoint Server (MOSS) is significant because it means that Excel Services benefits from best-of-breed software. Consider that SharePoint is a mature technology that provides, among other things, collaboration, content management and business intelligence capabilities while ASP.NET provides a framework for building web application software. Excel Services, a part of MOSS, provides for some exciting ways to build and deploy enterprise software with internal support for key SharePoint functionality and application extensibility.

Filed under:

Comments

# re: Programming Excel Services

Friday, June 08, 2007 1:51 PM by vapordan@hotmail.com

If any KB article indicates a session is related to an OWC object, it is wrong and needs to be corrected. Point these kb articles out and I will see that they are corrected.

microsoft.pulic.office.developer.web.components is a public forum, I'm free to comment as I please and so are you.

Frames hold their own session... what is the context of this statement? Perhaps you might want to look at this article to understand frames and session a bit more. www.15seconds.com/.../030528.htm

# re: Programming Excel Services

Friday, June 08, 2007 2:59 PM by vapordan@hotmail.com

Another good source of information on frames and sessions is this link: forums.asp.net/.../7504.aspx

The relevant section is posted here.

"

In normal case, if the frameset is an aspx file, when you request the page, it will first send the request to the web server, receive an asp.net session cookie (which holds the session id), and then the browser will send individual requests for the frames, and each request will carry the same session id.

However, since your frameset page is an htm file, the first request comes back without any session cookie because the page was serviced by ASP and not ASP.NET.  Then again your browser sends out individual requests for each frame.  But this time each individual request will NOT carry any session id, and so each individual frame will create its own new session.  That's why you will see different session ids in each frame.  The last request that comes back will win by overwriting the cookie written by the previous two requests.  If you do a refresh, you will see them having the same session id.

This behaviour is by-design, and the simple solution is to change your frameset page to .aspx.

"