All About Interop : MOSS

Sharepoint SDK includes BDC Tool

DotNetInterop — Thu, 23 Aug 2007 19:21:00 GMT

The August SharePoint SDK is now available and has some good stuff for interop. In particular, the refreshed SDK includes the new Business Data Catalog (BDC) Definition Editor, aka the BDC tool.

The BDC is the set of metadata that describes the various LOB systems that can be accessed from Sharepoint apps. One challenge with the BDC is that the tooling support for it was not good - it was difficult to add or edit systems into the BDC. It was MANUAL xml hacking, yeck.

This tool addresses that problem, which should make lots of Sharepoint devs very happy.

Check out Brian Coyne's blog post for more info on the BDC tool.

In the near future you'll see the Sharepoint team deliver more prescriptive guidance around connecting SharePoint to LOB systems. We started with SAP but will be expanding to Oracle (Siebel, PeopleSoft) and others. Check the Sharepoint Interoperability site for details.

BEA AquaLogic User Interface (ALUI) - write portlets in .NET

DotNetInterop — Tue, 30 Jan 2007 16:44:00 GMT

Hmm, what's ths?!?! BEA has introduced a new line of stuff, under the name Aqualogic Interface, or ALI (I think). As part of that, there is the Aqualogic User Interface (ALUI?). One of the things under that umbrella is the .NET Application Accelerator, whereby BEA is offering technical magic to enable .NET Developers to write code that runs on or adds value to an Aqualogic server. Intriguing!

The Java Portal Spec describes the model and APIs for Java developers to write portlets - fragments of Web UI that could be composed together to build a single, aggregated portal page. The goal was to enable developers to produce something like my.yahoo.com or one of any number of other web portals, but developers would be able to build these things inside enterprises, and the portlets (or fragments) could theoretically connect to any other system in the enterprise - mainframe transaction systems, databases, packaged apps, custom operational apps, and so on. The portal idea was a good one, lots of companies and vendors latched on to it, including Microsoft, with its Sharepoint products, which were at one point the fastest growing products at Microsoft.

The portal spec was good for Java vendors like BEA and IBM, because it extended the idea of the "application server" to include personalization features, membership, and so on - all extensions beyond the rapidly commoditizing J2EE specification on which their application server businesses were based. Java portal servers were like Java app servers++. And so BEA and IBM charged LOTS of money for these things. [ actually, until just now, I did not know, precisely how much money these other vendors were charging for portal servers, but I thought that it was "lots of money." Now that I looked, it knocked my socks off! IBM is charging $980 per value unit for WebSphere Portal Server. Just what is a value unit, you say? A value unit is 1/100th of a CPU, if you are running a dual-core Xeon or Opteron on your server, as near as I can tell. If you go to quad-core or some other processor, then you'll probably have to call IBM to find out how many "value units" you need to buy for your server. So for an x86 server, you will pay, I think, $98,000 per CPU to run WebSphere Portal Server. Zowie! I promise that Microsoft Office Sharepoint Server is not that expensive. ]

The model of selling pricey server licenses continues today, for both BEA and IBM, But, apparently BEA is noticing there are a whole lot of .NET developers in the enterprise today, and if they want to continue to sell high-priced servers, they better somehow allow enterprises to take advantage of all the .NET talent.

Hence, the .NET Application Accelerator.

Where does the interop come in? Well, if I have understood the product literature correctly, this widgetry allows .NET developers to build stuff that shows up as portlets in a BEA Portal server, using the WSRP standard or RSS. Hence, on-the-glass interop, via the portal server.

This looks like more of a good thing. In general, more options and choices for interop is good for customers, I think. I will be interested to hear any feedback on this interop-focused product, based on hands-on experience.

cheers!

Call Java from Excel Services? Yes you can!

DotNetInterop — Thu, 28 Sep 2006 22:17:00 GMT

This is an example of what is possible when web services is baked into the platform. Excel Services in MOSS 2007 supports the creation of User-Defined Functions (UDFs) in .NET. The .NET methods show us as @ functions within the Excel spreadsheet, pretty nifty. Inside the UDF function, which is just a normal vanilla .NET method, you can do ... anything.

Like... for example... call a web service. And that web service could be running under WebSphere, or WebLogic, or .. anything.

What this means is you can very easily create UDFs for Excel Services, then have server-hosted spreadsheets in MOSS 2007 use those UDFs in cell formulas. The UDFs can call out to essentially, any remote resource in your distributed network - retrieve a result from a WebSphere analysis application, or an Oracle table, or a WebLogic process flow, etc.

Remember, you can also call into Excel Services from Java.

Go forth and interop!

AXIS connects to Office 2007 Excel Services

DotNetInterop — Thu, 07 Sep 2006 15:35:00 GMT

Office 2007 introduces all sorts of new cool things. One of the things that has me most jazzed is the Excel services, which is part of the Microsoft Office Sharepoint Server 2007 (aka MOSS 2007). What Excel Services gives you - you can now use server resources to run spreadsheet computations. Previous to the release of Excel Services, spreadsheets would have to run on the desktop. They were a "client" resource.

For a long time though, running spreadsheets on the server has been done in financial services companies. These companies design and build complex, long-running computational models in an Excel spreadsheet, and they love the power Excel brings in that area. But then running the sheet - oh, a big one can take hours on a fast workstation. These companies often want to share the access to the computation model, without actually requiring every user to install MS Excel, load the particular XLS, and run the calculation on the local machine. So they'd like to share out that spreadsheet, as a service.

How is this possible? Before MOSS 2007, there were a couple approaches. One is the do-it-yourself, rubber-bands and duct-tape approach. For example, you could build an ASP.NET web page or web service, and from within the program logic, use COM interop to instantiate Excel on the server, and run the spreadsheet that way. But this was never supported by Microsoft and Microsoft issued a KB article discouraging the practice of running Office applications from server-side artifacts like ASP.NET or ASP. There are just too many pitfalls. There are third parties [ link, link, link ] that have come up with engines that essentially take an .xls and then convert it to some server-side executable artifact. But there are challenges with this approach as well. Some people did not like the third-party tools. Some people wanted a cleaner solution.

Now with Office 2007, this is possible within Office itself. You can either display a server-side spreadsheet in a browser, even better, MOSS 2007 exposes this capability via webservices, so you can open a workbook, and run a calculation, from any web services client.

Any client? I haven't tested them all, so I don't know for sure, but it seems so. I just tried this with a Java client using AXIS 1.4, and it worked the first time. Source code is attached here.

The only trick for AXIS was, I had to use the Commons HTTP client - this is the piece of the jakarta framework that supports NTLM authentication. Look here for info on how to set that up.

Check the webcast on using Excel Services