SharePoint Search
Die erste Session heute war zum Thema Search. Es wurde hauptsächlich das Customizing der Search besprochen. Es gab aber auch Einblicke in die interne Struktur der neuen Search Topologie mit FAST.
FAST soll gemäss Microsoft im Enterprise Bereich eingesetzt werden. Die SharePoint eigene Search und Index Engine bleibt bestehen und sollte für kleinere Anwendungen in ihrer verbesserten Form (z.B. Wildcardsearch) ausreichen.
FAST erweitert die bestehende Search und Index Engine. Bestimmte Arbeiten, wie z.B. die erweiterte Content Indexierung werden von FAST übernommen. Andere Elemente, z.B. die Profil-Indizierung bleiben Aufgabe der SharePoint Search Engine.
So wie's aussieht arbeitet FAST mit einem eigenen Index neben dem bestehenden SharePoint Search Index. Beide Engines arbeiten Hand in Hand um über das UI und die API eine konsistente Oberfläche anzubieten.
FAST bietet neben der Unterstützung von grösseren Datenmengen eine grosse Menge neuer Funktionen:
Infix und Prefix Operators
Nested Sub Expressions
Search Refinement
Result Collapsing
Federated Search Support
Find Similar Results
Um nur einige zu nennen.
Feststellungen:
- Die SharePoint Search Architektur ist durch FAST massiv komplexer geworden. Vom einfachen Hinzufügen von WebParts über customizing der Elemente über XSLT bis hin zur Programmierung der Search Objektmodelle ist eine weite Spanne von Möglichkeiten und Dingen zu kennen.
- Search steht offensichtlich immer zentraler im Zentrum der SharePoint Applications. Wie Search sinnvoll eingesetzt werden soll (MetaData, Taxonomien, Federated Search, People Search usw.) ist eine hoch anspruchsvolle Architekturaufgabe in die auch Organistorische Aspekte von Kunden, Prozessabläufe usw. hineinspielen.
- Search muss im vornherein massiv geplant und designed werden.
- Search ist ein so weites Gebiet, dass es nur von Spezialisten in genau diesem SharePoint Bereich wirklich beherrscht werden kann.
Architecture Guidance for Building Applications in SharePoint 2010 (Ammelan)
Der beste Vortrag seit Beginn der Konferenz. Es sprengt den Rahmen dieses Blogeintrags, alle Information, die der Vortrag geboten hat aufzuführen. Wir können nur empfehlen, diesen Vortrag im Internet anzuschauen, wenn er verfügbar wird.
Es wurden verschiedenste Applikationsszenarien und Best Practices behandelt. Dazu viele Dinge, an die man bei der Modellierung von SharePoint Applications denken muss.
Probleme wie:
Customizing von MySites
Stapled Features
Delegat Contols
Performance Issues using SPWeb, SPSite
Boundaries
Code-based provisioning
Security, impersonation vs. Elevation
Is SharePoint a datastore ?
Boundaries for using SharePoint as a datastore
Clientside APIs
Silverlight in SharePoint
Big List vs. Multiple List Pattern
Database vs. SharePoint List
Cross Sitecollection Access
Sandbox Applications
UI Performance
Man kann gar nicht aufzählen, was alles erwähnt wurde. Dieser Vortrag ist definiv ein must für SharePoint Entwickler.
Building Service Applications for SharePoint 2010
Der vorherige Vortrag hat mich motiviert, mir die neue Infrastruktur der Service Applications als Weiterentwicklung des SSP und das Erstellen eigener Services anzuschauen.
Die alte SSP Infrastruktur wird in SharePoint 2010 abgelöst durch eine freiere Architektur von gleichberechtigten einzelnen gemeinsamen Services für die SharePoint Applications. Diese Services können zu Gruppen zusammengefasst und den Applikationen angeboten werden. Es gibt schon einige oob Services wie Search, UserProfile, Excel Service, MetaData Service etc.
Das Interessante ist nun, dass man eigene Services schreiben kann. Ein typisches Anwendungszenario sind gemeinsame Konfigurationsdaten. In MOSS 2007 hätte man die in irgendeiner Site einer der Applikationen untergebracht und dann irgendwelche Cross SiteCollection Zugriffe von anderen Applikationen darauf gebaut. Dies natürlich mit erheblichem Aufwand und Sicherheitsproblemen.
Für eine solche Anwendung kann in Zukunft ein eigener Service gebaut, auf dem Application Server untergebracht und mit SharePoint Administrationsbefehlen den Applikationen zur Verfügung gestellt werden.
Eine eigene Service Application zu erstellen ist ein ordentliches Stück Coding Arbeit, für bestimmte Anwendungen lohnt es sich aber bestimmt und bietet eine flexible und erweiterbare Infrastrukur für die Lösung vieler applikatorischer Probleme.
Es ist hier nicht der Platz, um detailiert auf die Erstellung von Service Applications einzugehen. Der Vortrag war sehr gut und verständlich. Er lohnt sich anzusehen, sobald er im Internet verfügbar ist.
Feststellung:
- Wir denken, dass das Konzept der Service Applications auch von Microsoft in Zukunft weiter getrieben werden wird. SharePoint wird in Zukunft vermutlich noch viele zusätzliche Services erhalten.
- Die Service Infrastruktur ist auch für Custom Developer interessant. Sie bietet eine neue interessante Variante für Problemstellungen wie „Daten vielen Applications zur Verfügung zu stellen" oder „Long Running Actions" usf.
Jetzt kommentieren