febbraio 2009 - Posts
Ho già parlato in passato delle problematiche di Application Lifecycle Management applicate a progetti SharePoint.
Il tema è “caldo”.
Su piattaforma SharePoint si sviluppano applicazioni a volte estremamente complesse dal punto di vista architetturale, e questa complessità si ripercuote necessariamente anche sul processo di sviluppo (team numerosi e da coordinare, tecnologie e tecniche disparate da integrare, ecc…).
A questo dobbiamo aggiungere che SharePoint si appoggia su un intero stack di componenti, e spesso gli interventi di personalizzazione coinvolgono modifiche a livelli differenti (quindi differenti sono le competenze e gli approcci necessari).
La landing page su MSDN relativa all’ALM su SharePoint si arricchisce pian piano di nuovi documenti e di nuovi contenuti:
- General Information
- Guidance
- Unit Testing P&P
- Team Foundation Build Guidance
- Coding Practices: Disposable Objects
Come spesso accade, la documentazione prodotta dalla “SharePoint Community Worldwide” (sotto diverse forme) è molto più nutrita (e, davvero, evviva aggregazioni e tagging :-)).
Gli argomenti trattati, per loro stessa natura, non sono sempre “univoci” nelle conclusioni (e se è per questo nemmeno negli approcci).
Più in generale è necessario considerare le guideline per quello che sono: non prescrittive in maniera assoluta… da contestualizzare, quindi, sulla base dei requisiti del progetto e del team.
Da qualche mese è stato annunciata l’iniziativa CMIS, con una bozza delle specifiche disponibile per il download:
The CMIS specification defines a standard "domain model" for an ECM system - a set of core concepts that all modern ECM systems have, like Object Types (which in SharePoint we call "Content Types"), properties, folders, documents, versions, and relationships - and the set of operations that can be performed on those concepts, like navigating through a folder hierarchy, updating a document, etc.
The specification does NOT try to include all the capabilities of an ECM system - because many of these are simply too different between ECM systems. But the specification does attempt to include the fundamental concepts that are (a) relatively common across current ECM systems, and (b) enable the common integration scenarios that we've heard from customers to date.
The specification then defines how to bind the CMIS "domain model" to two different web service protocols: SOAP (Simple Object Access Protocol), the web services protocol used by many ECM systems (including SharePoint), and Atom, a newer web services model used in many "Web 2.0" applications.
Dietro CMIS ci sono *piccole* realtà quali Microsoft, IBM ed EMC… :-)
Dal mio punto di vista, la validità e la maturità di uno strumento si notano in maniera particolare nel momento in cui vengono affrontate e risolte problematiche di integrazione con altri prodotti.
L’approccio può esere di varia natura: si va dalla definizione di uno standard (come in questo caso, almeno nelle prospettive) alla realizzazione e alla distribuzione di veri e propri componenti o estensioni applicative.
Scot Hillier, ad esempio, ha appena pubblicato un articolo su MSDN che illustra un’architettura estremamente interessante
Ecco i link all’articolo e al codice sorgente.
Da http://www.mssharepointconference.com/Pages/spc2009.aspx:
Microsoft is delighted to announce the SharePoint Conference 2009 - the premier worldwide conference dedicated to SharePoint and related technologies.
There’s an exciting mix in the plans for this year. This year’s conference will be looking towards the future with a broad array of deep content centered on the next version of SharePoint, codenamed SharePoint “14” and at the same time be firmly planted in the present, sharing real world experience and guidance to help you maximize your investment in SharePoint Server 2007.
p.s. E’ a Las Vegas… ci sono stato oltre 10 anni fa dicendo, di rientro: “Non credo ci tornerò mai”… he he, strana la vita :-)
Come noto, SharePoint Designer, nel momento in cui lavora “live” su un sito SharePoint, memorizza i file che l’utente produce (css, aspx, js,…) all’interno del content database.
Michael Washam segnala una Custom STSADM Extension(*) che estrae tali file, rimuove alcune “particolarità” inserite da SPD e li memorizza sul file system.
La cosa viene presentata come strumento di source control applicato agli artefatti realizzati con SPD.
Ehm… sinceramente mi sembra più una soluzione di “backup”… ma il discorso diventa davvero troppo complesso, soprattutto per la domenica mattina presto :-)
(*) Se non avete mai sentito parlare di custom stsadm extensions - ma allora non siete venuti a sentirci :-((( - non posso che rimandarvi al blog di Mr STSADM Extensions, aka Gary LaPointe. Sbizzarritevi pure!