Technically SharePoint illustrates neatly what Microsoft's .net strategy is all about: integrating Windows with the Web. Microsoft has previously made accessing stuff on a PC easier, (Windows) then on a network (NT) and now on the web (.NET). SharePoint is an application written to let a user access a web accessible directory tree called the Web Storage System.
SharePoint was written with a set of technologies that allow the programmer to pass data, functions, parameters over HTTP, the web's medium. These are XML, XSL and SOAP, to name a few.
To the user it looks easy, like Hotmail, but every time they click a button or a link, a lot has to happen behind the scenes to do what they want to do quickly and powerfully. Not as easy as you might think, but SharePoint does it for you. Accessing this Web storage system and the server itself is also done using technologies like ADO, CDO, PKMCDO, LDAP, DDSC, ADSC. SharePoint is a great example of how the Internet Platform can be extended and integrated into an existing well adopted technology, Windows.
SharePoint from a Technical Perspective
Labels:
MOSS,
MOSS2007,
SharePoint,
Windows SharePoint Services,
WSS
Business Benefits of MOSS 2007
• Provide a simple, familiar, and consistent user experience.
• Boost employee productivity by simplifying everyday business activities.
• Help meet regulatory requirements through comprehensive control over content.
• Effectively manage and repurpose content to gain increased business value.
• Simplify organization-wide access to both structured and unstructured information across disparate systems.
• Connect people with information and expertise.
• Accelerate shared business processes across organizational boundaries.
• Share business data without divulging sensitive information.
• Enable people to make better-informed decisions by presenting business-critical information in one central location.
• Provide a single, integrated platform to manage intranet, extranet, and Internet applications across the enterprise.
• Boost employee productivity by simplifying everyday business activities.
• Help meet regulatory requirements through comprehensive control over content.
• Effectively manage and repurpose content to gain increased business value.
• Simplify organization-wide access to both structured and unstructured information across disparate systems.
• Connect people with information and expertise.
• Accelerate shared business processes across organizational boundaries.
• Share business data without divulging sensitive information.
• Enable people to make better-informed decisions by presenting business-critical information in one central location.
• Provide a single, integrated platform to manage intranet, extranet, and Internet applications across the enterprise.
Advanced Features of MOSS 2007
- User Interface (UI) and navigation enhancements
- Document management enhancements
- The new Workflow engine
- Office 2007 Integration
- New Web Parts
- New Site-type templates
- Enhancements to List technology
- Web Content Management
- Business Data Catalog
- Search enhancements
- Report Center
- Records Management
- Business Intelligence and Excel Server
- Forms Server and InfoPath
- The “Features” feature
- Alternate authentication providers and Forms-based authentication
Prototype - As a Design Guideline
"A picture can replace a thousand words; a prototype can save you lots of meetings and possibly avoid a project failure."
A prototype is a dynamic view of the system, while a requirements documents and design documents create a static view. It is the same with blueprints; they are a static model. A small-scale model is a dynamic view. Using a dynamic view, you can see things in action; you can add another dimension to the design phase: the time dimension.
The most important benefit of using prototypes is that it helps promote communication with the client, project managers and other developers.
Prototypes help in tracking the requirements back and forth. They ensure that you implement what is needed, no more and no less.
A prototype is a dynamic view of the system, while a requirements documents and design documents create a static view. It is the same with blueprints; they are a static model. A small-scale model is a dynamic view. Using a dynamic view, you can see things in action; you can add another dimension to the design phase: the time dimension.
The most important benefit of using prototypes is that it helps promote communication with the client, project managers and other developers.
Prototypes help in tracking the requirements back and forth. They ensure that you implement what is needed, no more and no less.
Building Blocks of Design
There are three high level elements that are considered for design:
- Patterns
A pattern is a specification for addressing a common problem in solution design. Patterns are not algorithms, they are higher level and more broadly applicable. Adopting a widely accepted pattern as part of solution design can help us address not only the problem we recognize, but also the related problems we may not recognize on first glance.
- Frameworks
Occasionally, you may find targeted reference implementations of patterns that may be useful, and they are often in the form of a framework. In classic object-oriented design, a framework is a set of abstract classes to be incorporated into and reused as part of a software application. The current thinking is that a framework also may be a set of abstract data constructs, rules, or processes. A framework is different from a pattern in that a framework is something real that can be incorporated into and used as a foundational element of your solution—it is commonly the implementation of a pattern or specification.
A framework provides guidance beyond that of a pattern, and typically provides deployable elements that can be used as the foundation for your solution. The more well- understood the framework, the easier it will be for an organization to support it over time.
- Components
Components are encapsulated elements of a system (hardware, software, network, etc.) and are by definition not case-specific. Components can be wrapped into your solution seamlessly, or can be managed as separate entities, regardless of deployment environment. Incorporating well-understood components into your solution definition can save time in delivery and increase the quality of your solution, but components may have associated support costs that can be considerable.
Most components can be satisfactorily configured to meet our needs without any custom work. Incorporating a component and customizing it beyond the standard configuration is risky—you should understand the cost associated with supporting it going forward, and the risk of losing vendor-provided support.
Enterprise Architecture
The definition of an architecture used in ANSI/IEEE Std 1471-2000 is: "the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."
An enterprise architecture (EA) is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change.
Normally an enterprise architecture takes the form of a comprehensive set of cohesive models that describe the structure and the functions of an enterprise. Important uses of it are in systematic IT planning and architecting, and in enhanced decision making.
The individual models in an EA are arranged in a logical manner, and this provides an ever-increasing level of detail about the enterprise, including:
An enterprise architecture (EA) is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change.
Normally an enterprise architecture takes the form of a comprehensive set of cohesive models that describe the structure and the functions of an enterprise. Important uses of it are in systematic IT planning and architecting, and in enhanced decision making.
The individual models in an EA are arranged in a logical manner, and this provides an ever-increasing level of detail about the enterprise, including:
- Its objectives and goals.
- Its processes and organization.
- Its systems and data.
- The technology used.
Software Architecture
Software Architecture can be defined in terms of building blocks and software components. These building blocks are software components, frameworks, IDE’s, SDK’s, and Commercial off the shelf (COTS) packages.
The primary role of a Software Architect is to choose the components, integrate the ones that can be incorporated, and lead the team in creating custom supporting code to link the components in times where there are no obvious connectors from one component to another and build something that will benefit the business.
The primary role of a Software Architect is to choose the components, integrate the ones that can be incorporated, and lead the team in creating custom supporting code to link the components in times where there are no obvious connectors from one component to another and build something that will benefit the business.
WSS 3.0 - WorkFlows
A workflow allows you to attach a business process to items in Windows SharePoint Services 3.0. This process can control almost any aspect of an item in Windows SharePoint Services 3.0, including the life cycle of that item. For example, you could create a simple workflow that routes a document to a series of users for approval.
Workflows can be as simple or complex as your business processes require. You can create workflows that the user initiates, or workflows that Windows SharePoint Services 3.0 automatically initiate based on some event, such as when an item is created or changed.
Windows SharePoint Services 3.0 workflows are made available to end-users at the list or document-library level. Workflows can be added to documents or list items. Workflow can also be added to content types. Multiple workflows may be available for a given item. Multiple workflows can run simultaneously on the same item, but only one instance of a specific workflow can run on a specific item at any given time. For example, you might have two workflows, SpecReview and LegalReview, available for a specific content type, Specification. Although both workflows can run simultaneously on a specific item of the Specification content type, you can't have two instances of the LegalReview workflow running on the same item at the same time.
Workflows can be as simple or complex as your business processes require. You can create workflows that the user initiates, or workflows that Windows SharePoint Services 3.0 automatically initiate based on some event, such as when an item is created or changed.
Windows SharePoint Services 3.0 workflows are made available to end-users at the list or document-library level. Workflows can be added to documents or list items. Workflow can also be added to content types. Multiple workflows may be available for a given item. Multiple workflows can run simultaneously on the same item, but only one instance of a specific workflow can run on a specific item at any given time. For example, you might have two workflows, SpecReview and LegalReview, available for a specific content type, Specification. Although both workflows can run simultaneously on a specific item of the Specification content type, you can't have two instances of the LegalReview workflow running on the same item at the same time.
Labels:
MOSS,
MOSS2007,
SharePoint,
Windows SharePoint Services,
WSS
WSS 3.0 & MOSS 2007 - WebParts
Web Parts in Windows SharePoint Services provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.
The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.
Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.
Following are some ways in which you can use custom Web Parts:
The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.
Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.
Following are some ways in which you can use custom Web Parts:
- Creating custom properties you can display and modify in the user interface.
- Improving performance and scalability. A compiled custom Web Part runs faster than a script.
- Implementing proprietary code without disclosing the source code.
- Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.
- Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.
- Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.
- Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.
- Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.
- Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.
- Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.
Labels:
MOSS,
MOSS2007,
SharePoint,
Windows SharePoint Services,
WSS
WSS 3.0 - Content Types & Site Columns
Windows SharePoint Services 3.0 provides two new tools to help you organize and standardize your data: content types and site columns.
Content Types
Content types—a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0—are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.
For example, consider the following two types of documents: software specifications and legal contracts. It is reasonable that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.
Content types enable you to store multiple, different types of content in the same document library or list. In the preceding example, you could define two content types named Specification and Contract. Each content type could include different columns for gathering and storing item metadata, as well as have different workflows assigned to it. Yet items of both content types could be stored in the same document library.
You can further extend content type functionality by using content types to assign additional settings, such as workflows or even custom attributes, to your items.
Because you can define content types independently of any specific list or document library, you can make a given content type available for the lists on multiple SharePoint sites. This enables you to centrally define and manage the types of content you store in your site collection. For example, you could use your Specification content type to ensure that all software specifications track the same metadata, even if those specifications are stored across multiple sites.
Content types are independent of file formats. For document libraries, you can specify a document template; when the user requests a new document of this content type, Windows SharePoint Services creates a document based on the template. However, users can still upload a document based on a different template, or even of a completely different file type.
Site Columns
Site columns provide a central, reusable model for column definition. When you create a site column, each list that uses this column has the same definition, and you do not have to do the tedious work of reproducing the column in each list.
A site column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. Site columns decrease rework and help you ensure consistency of metadata across sites and lists. For example, suppose you define a site column named Customer. Users can add that column to their lists and reference it in their content types. This ensures that the column has the same attributes, at least to start with, wherever it appears.
Additionally, site columns provide you with the simplicity of a single maintenance point. For example, you can create a status site column, which might contain multiple choices of an enterprise's specific statuses, and implement the column in dozens of project master lists across the site collection. If you add a new status, you can modify the site column instead of having to modify each list that contains a status column.
Much like site content types, you define a site column at the site level, independent of any actual list or content type.
When you add a column to a list, Windows SharePoint Services copies the site column locally onto the list as a list column. You can then make changes to the list column; these changes apply to the column only as it behaves on that list.
In certain situations, you may want to modify the column for a specific list. For this reason, you still have the option of one-off customization of columns at the list level. For example, suppose all projects within your company's Information Technology department have an additional status of On Hold—Waiting for Hardware. You could add this status to the column within the IT department's master project list.
You can also create your own list columns, directly on a list. Either way, list columns apply only to the list to which you add them; they cannot be added to multiple lists.
You can reference a site or list column in a content type.
Content Types
Content types—a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0—are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.
For example, consider the following two types of documents: software specifications and legal contracts. It is reasonable that you might want to store documents of those two types in the same document library. However, the metadata you would want to gather and store about each of these document types would be very different. In addition, you would most likely want to assign very different workflows to the two types of documents.
Content types enable you to store multiple, different types of content in the same document library or list. In the preceding example, you could define two content types named Specification and Contract. Each content type could include different columns for gathering and storing item metadata, as well as have different workflows assigned to it. Yet items of both content types could be stored in the same document library.
You can further extend content type functionality by using content types to assign additional settings, such as workflows or even custom attributes, to your items.
Because you can define content types independently of any specific list or document library, you can make a given content type available for the lists on multiple SharePoint sites. This enables you to centrally define and manage the types of content you store in your site collection. For example, you could use your Specification content type to ensure that all software specifications track the same metadata, even if those specifications are stored across multiple sites.
Content types are independent of file formats. For document libraries, you can specify a document template; when the user requests a new document of this content type, Windows SharePoint Services creates a document based on the template. However, users can still upload a document based on a different template, or even of a completely different file type.
Site Columns
Site columns provide a central, reusable model for column definition. When you create a site column, each list that uses this column has the same definition, and you do not have to do the tedious work of reproducing the column in each list.
A site column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. Site columns decrease rework and help you ensure consistency of metadata across sites and lists. For example, suppose you define a site column named Customer. Users can add that column to their lists and reference it in their content types. This ensures that the column has the same attributes, at least to start with, wherever it appears.
Additionally, site columns provide you with the simplicity of a single maintenance point. For example, you can create a status site column, which might contain multiple choices of an enterprise's specific statuses, and implement the column in dozens of project master lists across the site collection. If you add a new status, you can modify the site column instead of having to modify each list that contains a status column.
Much like site content types, you define a site column at the site level, independent of any actual list or content type.
When you add a column to a list, Windows SharePoint Services copies the site column locally onto the list as a list column. You can then make changes to the list column; these changes apply to the column only as it behaves on that list.
In certain situations, you may want to modify the column for a specific list. For this reason, you still have the option of one-off customization of columns at the list level. For example, suppose all projects within your company's Information Technology department have an additional status of On Hold—Waiting for Hardware. You could add this status to the column within the IT department's master project list.
You can also create your own list columns, directly on a list. Either way, list columns apply only to the list to which you add them; they cannot be added to multiple lists.
You can reference a site or list column in a content type.
Labels:
MOSS,
MOSS2007,
SharePoint,
Windows SharePoint Services,
WSS
Subscribe to:
Posts (Atom)