In this post, we are going to explore the guts of our custom service application, expect lots of code in this post. As I mentioned in my first post in this series, the goal of this Service Application development exercise is to build an infrastructure within SharePoint 2010 for your company to add value to your SharePoint investment, by exposing 3rd party and custom capabilities and features to your farm(s) in a scalable and maintainable way.
SharePoint 2010 Service Application Development 101 – Logical Components
In this post we explore the essential components that make up a service application and the relationships between them: servers, services, service proxies, service instances, service applications, service application proxies, and load-balancers. In addition to these core components, we will also explore adding job definitions and databases to the mix.
load balancing, mycorp, saf, service application, sharepointSharePoint 2010 Service Application Development 101 – Getting Started
In this series, we will explore what it takes to build and manage a custom service application in SharePoint 2010. The most attractive reason to me for building a service application is to logically bundle a set of services and/or capabilities provided by in-house and 3rd party applications and systems within the SharePoint infrastructure.
.net, C#, integration, mycorp, saf, service application, sharepointCode generating a Python web application with LLBLGen, SqlAlchemy and the Tornado Web Server
Validating and binding PeopleEditor and custom SharePoint Editor/Picker controls
Building a Web API in SharePoint 2010 with ServiceStack
Scripting your SQL database (using SMO and the command line)
Adding LLBLGen to the Dapper performance benchmark test project
Using Autofac in SharePoint 2010
Up till now in my SharePoint 2010 projects, I’ve been using the very nice SharePoint Service Locator implementation, from the patterns & practices group. This has been really useful, and works great. If you’re not familiar with the service locator pattern, you can read up on it here. Using this pattern, it’s easy to build a lightweight common library that you pass out to your team (or as is often the case “teams”) of developers without them having to mess around with the implementation of every interface.
.net, autofac, di, ioc, sharepoint