I'm moving an existing backend application into a new SharePoint service application and have a couple of questions about best practice for our "complex" requirements. I'm happy with the general principles of developing an SA (thanks to ACs sample from
SPC09) but what we're trying to achieve is an order of magnitude more complex IMHO.
Our existing application has around 12 different WCF interfaces and all talk to the same backend database. The user interface elements (WebParts and Pages) that consume all this backend goodness are packaged up and sellable as four different WSP's.
- My thoughts on developing this revolve around producing a service application per User interface WSP and wrapping two or three existing WCF interfaces into one bigger SA API. Pros / Cons? Can a SA easily have multiple (WCF) Interfaces to keep changes to
- There is a single database for the application. Each installed service application will add the tables it needs to this common database. Pros / Cons? Provisioning to a central dB? Sharing a connection / string ?
I'm sure there are loads of other issues that I've not uncovered yet but hopefully this will get us going for now. Finally does anyone know of any top notch developer / partners who may be able to develop this as we may consider outsourcing too (I'd ex
View Complete Post