SharePoint as a SOA Platform

1. SharePoint as a SOA Platform PM356,CIO356,IA356

2. Bradley Smith, former MVP • Black Blade Associates, Inc. • www.blackbladeinc.com • bsmith@blackbladeinc.com • Programmer, Marine, Consultant, MVP, Entrepreneur.

3. Agenda • SOA? • Cost vs. benefit? • Making SharePoint a SOA platform • Nodal Topology • Content Definition • Service Discovery • Building on the core services • Replication services • Management services • Personalization services • Case Study: The USMC Enterprise Portal Architecture

4. SOA? • Service boundaries are explicit • Services share schema and contract, not class • Service compatibility is determined based on policy • Services are autonomous • System design strategy, not a technology • Environmental boundaries

5. SOA vs. web services

6. SOA Requirements • Common requirements that drive SOA strategies • Geographically distributed locations • Multiple pre-existing applications or data stores, likely to have overlapping functions • Continuity of operations • Maintenance cost reductions • Interoperability

7. Cost vs. benefit • SOA strategies can be expensive to implement • Requires more costly personnel resources to implement and maintain • Lots of code • Trading operating efficiency for interoperation reliability • Do you really need distributed computing? • There can be other options • Enterprise Application Integration • Application to application, technology specfic • Platform upgrades to encompass new requirements • Much business software has built-in integration with certain partners and products

8. Making SharePoint a SOA platform • Isn’t SharePoint services oriented already? • Federated search, records center • SOA vs. web services • SharePoint service nodes, and why you want them • SharePoint saves a ton of code • A service node is a collection of services within a specific boundary • Farms and service boundaries • The hierarchy of services • Portal technologies are the UI for a services-oriented architecture • Modular applications, modular enterprise

9. Service boundaries and interoperability

10. Nodal topology service • Supports the registration of service nodes as logical parent/child service nodes • Manual or automatic? • Defines extra-node communications pathways across service boundaries • Your service nodes will rely on this capability to identify service providers within your topology • Defines nodal context for service boundaries, and should represent the environmental boundaries of your enterprise

11. Service discovery service • Service discovery services support service registration at each node within a accessible directory • UDDI • A service node can query for a list of registered services from any service node in the current service node topology • This service allows applications to query service registries for the most local instance of a needed service • Go to the parent (greater service boundary)

12. Content definition service • Defines and exposes the structured, unstructured, and semi-structured data within a node’s service boundary • Metadata correlation • Exposes the portal ontology and taxonomy structure to users • Enables the moving or copying of portal content from one service node to another • Replication • Supports the actions that must be performable on content managed by a service node as well as content that is referred to by a service node

13. Content definition service Service discovery service Nodal topology service This diagram shows an example of a functional nodal topology and how each node’s core services interact with the larger architecture.

14. Building on the core services • Replication service • Supports identification of potential replication partners • Automation? • Supports rules-based content replication • Allow the definition of replication pathways based on topology • No replication storms

15. Building on the core services • Management • Allows SharePoint to propagate management events through the topology • Solution, feature installation • Updates • IIS Reset • Service node status, health, and state

16. Building on the core services • Personalization • Replication of User Profiles and/or MySites from one node to another • Audience replication • Replication of page views and list views

17. Case Study: Marine Corps Systems Command • Responsible for the planning and implementation of information technology and services for all Marine Corps commands, and for the integration of new systems with hundreds of legacy applications and data stores • Regularly has programs implementing new technologies that should communicate • Business pains: • Many changes happening very rapidly on many different teams, with functional overlap occurring often • Individual commands implement systems for missions that are not aware of the larger enterprise strategy (trading stability for efficiency)

18. The Black Blade solution • Enterprise Portal Architecture (EPA) • Service-oriented architectural definition of the business rules that will govern the USMC enterprise • Technology agnostic • Portal Deployment Kits (PDK) • Instances of the EPA business rules for specific implementations • Technology specific

19. The end result • Interoperability • Between SharePoint v2 and v3 • With other government organizations • Compliant with current integration policy • Automated integration of new systems into existing topology • Enterprise-wide configuration management capabilities • Repeatable process of system implementation • The ability to the same level of service to every Marine worldwide • You can have centralized systems management, with a distributed computing platform

20. Resources • SOA vs. web services http://www.blackbladeinc.com/en-us/community/Documents/SOA Services vs. Web Services V2.pdf • Black Blade Associates, Inc. www.blackbladeinc.com

21. Thank you for attending! Please be sure to fill out your session evaluation!