Sharepoint proprietary specs out

Microsoft have released some interesting reading in the SharePoint Products and Technologies protocol documentation. It provides detailed technical specifications for Microsoft proprietary protocols (including extensions to industry-standard or other published protocols) that are implemented and used in SharePoint Products and Technologies to interoperate or communicate with Microsoft products. 

The documentation includes a set of companion overview and reference documents that supplement the technical specifications with conceptual background, overviews of inter-protocol relationships and interactions, and technical reference information.

Enjoy by downloading it at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5e94ad07-902c-422f-aadd-ff2bba9e540a#tm!

© Copyright 2009, Tomas Elfving

Skype staus field in Sharepoint

A company named ObjectConnect have developed a Skype integration into SharePoint.Its first version available on Codeplex now (http://skypestatusfield.codeplex.com/) featuring the Skype status field. It allows you to store the account name in the field, and it's rendered as the nice status (green / grey) picture in the list and item view. 

Also, clicking on the icon will bring you the chat window to that person if you have Skype installed locally. Nice! 

 © Copyright 2009, Tomas Elfving

An architecture of base-system-independent web services

One of the most common mistakes of SOA implementation is to leave out the common data model. Without that, the web service layer is no more than a function-mapping layer between clients and base systems. By letting the ESB manage a common data model, the web services published to clients are independent of various base system definitions of common objects, and also independent of change in theses base system definitions.

© Copyright 2009, Tomas Elfving

SharePoint 2007 Backup/Restore options and things to consider

Going through the native Sharepoint backup, I've found some limitations I'd like to shed some light on. The backup:

• does not Provide Scheduling Functionality. You must use the command line with Windows Task Scheduler for scheduled backups
  
• does not Backup any Configurations/Customizations to any files in the “12 Hive” or Web.config files. You must manually back up front end files.
• does not Backup IIS Settings/Configurations
  
• does not Backup Alternate Access Mappings (AAM)
  
• dannot Backup Directly to Tape (only to UNC)
• high restore time means low availability

If using the SQL Only Backup/restore strategy, you'll have the following issues to consider:

• it does not backup any WFE configurations or solutions
  
• it requires Admin to manually reattach content databases to the web applications after a recovery
  
• you'll need to manually backup/restore all customizations on WFE Servers (.Net Assemblies, Features, IIS Metabase, etc. – batch file can help automate this process)
  
• no need to backup Search database (as it can’t be synchronized with Search Index)
  
• backup/restore of SSP separately via SharePoint native backup/restore
  

© Copyright 2009, Tomas Elfving

First (?) Computer "Bug", 1945

© Copyright 2009, Tomas Elfving

Version management of web services

You basically have 2 choices: Either use separate URI's or use the "target namespace# for version numbering. Target namespace can also be used for multilanguage support.
Using the tagret namespace way together with a proxy or ESB, you can reduce client dependence on URI's. Say you have:

/Customer
/Customer/v1
/Customer/v2
/Customer/vX

/Customer always gives the client the latest version. The ESB acts here to sort out what WS is the latest version and supplies that WS to the client. Clients call /Customer for services they know is backwardcompatible.

/Customer/vX is for non-backwardcompatible services where the client needs to be sure exactly what version of the service he gets.

The "target namespace" solution follows the Amazon’s recommendation form publication of services (http://docs.amazonwebservices.com/AWSEcommerceService/2005-03-23/ApiReference/ServiceVersioningArticle.html)

© Copyright 2009, Tomas Elfving

What capabilities can a proxy in a SOA service layer handle?

When implementing a SOA web service layer, a number of issues keeps reappearing in service after service. They should, in other words, be taken care of in a separate service proxy layer on top of the services. The proxy layer could be implemented as a custom developed layer or with an ESB (Enterprise Service Bus).

Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary. An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. The ESB tries to remove the coupling between the service called and the transport medium.

The following capabilities a proxy/ESB can handle:

- Invocation - Support for synchronous and asynchronous transport protocols, service mapping (locating and binding)
- Ruoting - Addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing
- Mediation and integration - Adapters, protocol transformation, service mapping
- Messaging - Message processing, message transformation and message enhancement
- Process Choreography - Implementation of complex business processes(think twice before getting into that as it ties you heavily to the ESB product)
- Service Orchestration - Coordination of multiple implementation services exposed as a single, aggregate service
- Quality of Service - Security (encryption and signing), reliable delivery, transaction management, SLA controls
- Management - Monitoring, audit, logging, metering, admin console, BAM
- Thread management - i.e limit number of concurrent calls to a base system

© Copyright 2009, Tomas Elfving