Archive for June, 2008

Java To SharePoint Interface – Follow-up

Sorry its been a while since I blogged on this topic (or any topic for that matter).

As you saw in the previous post on this subject, it is possible to interface to SharePoint’s web service interface from a Java client. What I didn’t get into in that post was the extreme grief that you have to go through to parse the XML that comes back from SharePoint. In fact, SharePoint does some stuff with it’s web service implementation that Axis2 didn’t like at all.

The other key issue with this direct interface approach is that SharePoint occasionally puts CAML (SharePoints special XML language) into it’s SOAP responses. Well, Axis2 really doesn’t like that. This became so painful that we decided to look at alternatives.

Some of the alternatives were:

1. Be masochistic and continue with the pain (not preferred option as too time consuming and risky).

2. Look at alternate web service technologies (the option of using JDK 5 based implementations became an option as the client upgraded to J5). A basic prototype of a Java to SharePoint web service interface was tried, but we found this to be almost as painful as the Axis2 implementation.

3. Implement dedicated standards (WS) based custom web service interface in .NET on the SharePoint server, which talks directly to the SharePoint APIs. These custom web services provide dedicated APIs to do only what the client Java application requires (retrieving content from SharePoint).


I’m guessing that by now you have already guessed which option we chose? Correct, #3.

By using WCF to create standards based dedicated web services we could provide an interface that Java clients could talk to easily, we could limit these services to just the capabilities we needed and could handle any changes in the SharePoint APIs without affecting the Java client.

Problem solved and lessons learned.


Unfortunately, we never did get to proceed with this project, but next time I have to interface from SharePoint from a Java client, I’ll know how to do it the most effective way. Tags:

DSL Project (2)

So to get started, create a DSL Designer project in Visual Studio (I’m using VS2008 but it should be almost the same in VS2005 although there have been some improvements). This creates a solution with 3 sub-projects (and why Microsoft keeps insisting on placing project folders under solution folders, I’ll never understand, as it makes it more confusing to re-use projects in other solutions). In the case of DSL designer, I’d highly suggest you leave it in the structure the VS guidance creates as there are heaps of dependencies on the structure and relative locations of things in that structure that is very easily broken and very difficult to correct afterwards (this is speaking from experience, I reverted to guidance structure). In any event it’s pretty much stand-alone and creates a VS add-in so its unlikely you would re-use any of these projects in other solutions.


The 3 projects the guidance creates for you are:

1. DSL Designer – The actual DSL project.

2. DSL Package – Setup

3. DSL Debugging  – VS hive for testing your DSL during development


I’ll follow up on this with details on creating a basic class diagram DSL in a future post.