This is an architectural question.
We are in the process of building a document management site with basic workflow which needs to be external facing.The external facing application needs to be branded and should have the capability to upload and download documents and also support versioning.We have decided to use WSS 3.0 as the collaboration tool as it has all the features we need.We are planning to support multiple clients with custom branding for each client.
My question is should we expose WSS to the client for external facing or build a standard ASP.NET application using WSS in the application tier and let the ASP.NET app interact with WSS using the WSS API/Web service.This makes it easy to customize the ASP.NET application without having to make any changes to the WSS.The internal users doesnt need any branding and hence could go to the internal facing WSS site to do workflow activities. Building features and getting to brand has been a challenge since I started WSS development.
Please let me know your thoughts.
SharePoint is big. Really big. As a result, if you plan to develop a home-brewed middle layer between your customers and SharePoint, be prepared to do a lot of work unless you plan only to expose a tiny piece of the SharePoint interface.
I recommend exposing WSS, and building your application within, instead of adjacent to, the WSS framework by creating Web Parts, pages, and lists that meet the requirements SharePoint alone cannot. This should reduce your workload to something manageable.
Take a look at tools such as VSeWSS or WSPBuilder to ease your WSS 3.0 development (should you use Visual Studio), and take advantage of SharePoint Designer where it is appropriate.
If you don't know a lot about SharePoint, creating and exposing a UI is going to be difficult. Can you do it? Absolutely. Should you do it? That depends on your requirements, and your level of expertise with SharePoint. In my opinion, the easiest path would be to create an ASP.NET application and have that interface with SharePoint, but I spend 90% of my day working with ASP.NET and only do SharePoint development about once a year.
In my experience, if you have to ask whether or not you should build a new product etc. with some tool, the answer is generally know. If I can't answer it myself with maybe some looking around on the tool, I try not to use it on a major project, because that means, that I don't know it well enough to get myself out of bind when something unexpected arises.
If you do a custom coat over WSS underneath, you are essentially writing code that already comes with the platform, especially with SharePoint. I assume that price is a factor in your decision making or you would not use WSS alone. In that case it can be tempting to leverage WSS as a code layer, but I would expect that it would be extremely difficult to make that work smoothly.
Depending on your business model I would look at what hosted SharePoint solutions can do, especially if you can host a custom SharePoint site definition on their platform.
It would take a very strong IP or financial requirement to make me consider wrapping asp.net over top of WSS.
I have worked with a solution that does that and it does work for our externally facing site, but it is a maintenance 'mare.
Related
We currently have a fully developed web forms application, basically its like WordPress using .net for multiple users to publish content. It does more than that but thats the simplest way to describe it. Our "webmasters" (I work in the gov) want everything put inside of SharePoint. We currently have SharePoint 2007. I have no experience developing within SharePoint so I don't know much about it.
My question is how do you decide when to develop your application in SharePoint and when to develop outside of it.
It depends on several things.
Is there any reason to use SharePoint features (lists for data storage, document libraries with versioning, groups for security, etc.) in your application? If you're just hosting ASP.NET pages within SharePoint but aren't using any of its features, it's not really worth the hassle.
However, if you would be adding the application to an existing SharePoint site, it might still be a good idea. Organizing everything in one place might be more convenient for users than setting up a separate web application.
If it is a requirement to re-architect your application to work with SharePoint, that is one very big reason to develop with SharePoint. Beyond that, the people influencing your architecture decisions may have good reasons of their own.
SharePoint provides security management, search and navigation to name a few relevant pieces to your web puzzle. If you are already creating dynamic web applications in .Net, a lot of what you've learned in the process will apply, but you have some learning to do.
Your orginization is not the only one moving most web applications to SharePoint. If you don't learn it now, you risk getting behind the curve.
You could also just 'show' your existing applications inside of a SharePoint web part (Page Viewer?). That way, your application remains the same, and it is 'shown' inside the SharePoint environment. This is somewhat a hokey solution, but in your particular circumstance, it could be viable considering development time, learning time, and control.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I am used to building java web applications.
I am used to MCV.
As I learn how to build a Sharepoint site, is it ok to think of building Sharepoint sites similarly, particulary where there is business logic layer, that, for instance, would grab data from various DBs, do some logic, then go to a certain page?
SharePoint and MVC do not play well together, not in a supported way at least. This isn't going to change for 2010 either. It's an ASP.Net Web Forms app, and so acts accordingly.
There is a Open Source Project for SharePoint MVC but you need to understand the plataform first, with some SharePoint for Developers tutorials.
I want to use a CMS that can be accessed by my clients via the internet. All SharePoint usage I have seen is for intranet sites only. What I am looking to do:
Landing page for all clients, with general information.
Client login to client specific portal page with client specific information.
Accessible via the internet. The clients may or may not have SharePoint.
General and client specific wikis.
I won't be hosting this myself. I would be looking for a hosting provider as well.
I am also looking at using DotNetNuke, which has a lower cost of entry. I am open to suggestions of other CMSs, but my skills are built around C# and ASP.NET.
Before going down the SharePoint path, I wanted to make sure these things are possible.
Thanks!
Update:
Thanks to all that have given me some points to ponder. In summary, here is what I have decided to do (given my current skill set):
SharePoint can be used for my needs (my initial question). Many great example sites.
DotNetNuke as my CMS. I realize other good CMSs are available, but I prefer to stick to the Microsoft stack.
Branding will be easier in DotNetNuke.
The site will not be very big and not used by many. SharePoint will be overkill at this point.
Many of the 'modules' I am looking to use (wiki, forum, ...) seem to have more options/maturity using DotNetNuke.
Biggest Deciding Factor
Integrating a CMS solution with my software product and then installing/implementing this solution for individual clients will have a much larger cost with SharePoint. DotNetNuke will allow me to 'leave behind' the solution with the client without having them to invest heavily in SharePoint if they do not already own it.
Thanks to all!
Ed
Everything you require is supported by Windows SharePoint Services 3.0, which is included at no additional cost with a Windows Server license. However, SharePoint does have an administrative and development overhead that you could avoid using a different platform. It doesn't sound like you would really be leveraging any of SharePoint's particular strengths (document management, Office client integration, ad hoc collaboration sites, etc), so it's probably not worth the extra effort.
So in short, the answer to your question is "Yes", but it's probably not your best option with these specific requirements.
Check out the Top 17 case studies for Microsoft Office SharePoint Server 2007 and several new MOSS-based web sites. There are some nice Internet websites too.
there are heaps of SharePoint sites out there facing the internet. There’s a great list of over 1,000 of them on the WSS Demo site here: http://www.wssdemo.com/Pages/websites.aspx
All of the requirements you’ve listed are achievable with the externally facing SharePoint model. There’s an obvious cost impact of going down the SharePoint path versus DotNetNuke but it’s certainly achievable in terms of functionality.
Kentico offers SharePoint Connector which allows to publish SharePoint content to external sites: http://www.kentico.com/cms-asp-net-features/sharepoint.aspx
All the things you mentioned are possible. Note that hosting a SharePoint server can be expensive. Most hosting providers charge you a dedicated server hosting plan.
Also I'm not impressed with the default wiki solution in SharePoint. You might want to consider a 3th party wiki tool and point your SharePoint Search towards it so that the results are shown in your search results. Drawback is that you loose the security trimming.
You might also be interested in the BPOS solution. A (kind of) hosting service for SharePoint that Microsoft is offering.
We build CMS's with ASP.NET using tools such as Umbraco and DotNetNuke etc
A client is asking us if we can build a site in WSS which I think is Windows Sharepoint Services.
Are there any experienced MOSS people out there who can tell me how hard we would find this?
Would it be just like learning another CMS?
Or will it be a nightmare?
Also, what software do we need to build the site in house for testing?
We don't have a MSDN subscription and use free Microsoft tools (Visual Studio Express and SQL Server Express)
Sharepoint is great for use with its own document management features, and it integrates well with Office products.
It's not such a good platform for development. The API is a nightmare, web parts are incomprehensible, and the database has a terrible structure (fields are named NumericField1, TextField2, etc. Yuck).
If you eventually need a web-facing server, MOSS is very expensive.
I will preface this by saying I am currently finally wrapping up a more-than-2 3-year project building one of the largest WCM sites deployed on MOSS in the world. We're talking thousands and thousands of content editors, nearly a million pages, millions of hits per day.
Depending on what you need, it could be moderately painful or extremely painful. MOSS is never a pleasure to use, so at the very least it will be an unpleasant exercise to deploy an out-of-the-box WCM site and make it look kinda like the design you want. However it should not be too terribly time-consuming or overly difficult.
If your needs look more like ours - do you need complex cross-loaded content on your pages? Content syndication and connected content? Flexible editor-controlled layouts? XHTML-compliant markup? Pixel-perfect design? If so, trying to use MOSS will absolutely be a nightmare.
Take note that WSS is not MOSS. WSS is the free version of SharePoint and MOSS is the paid version. MOSS is also the version designed for public facing CMS web sites.
With a bit of reading you should find MOSS relatively straight forward to develop a CMS site on top of. JP's link is a good one and I also recommend reading Andrew Connell's book Professional SharePoint 2007 Web Content Management Development: Building Publishing Sites with Office SharePoint Server 2007.
Depending on your requirements, in most cases you can work out-of-the-box with MOSS and SharePoint Designer. If you find you need more than what these can provide your learning curve will jump by quite a lot so tread carefully!
For development you will need at least a MOSS and SharePoint Designer license (as JP suggests MSDN is better and also gives you the option of using Visual Studio). Your client is going to need to fork out the licensing costs for MOSS. I think there are additional costs for public facing web sites but check with your Microsoft account manager.
See some cool stuff you can with public-facing web sites for the product at Top SharePoint.
It's not that hard. I don't find it as easy as DotNetNuke, but it's still fairly straight forward once you have some of the concepts down. There is a really great intro to CMS on MOSS at Web Content Management with SharePoint MOSS 2007. You are going to need least the lowest level subscription to MSDN because CMS is part of MOSS not WSS. Search around for deals on MSDN.
Actually if you are aware of the share point technology , then wont find it difficult to built CMS using it. Designing content management system using share point is actually possible.