(From the point of view of a user, not how it's built or which option is selected in Visual Studio)
...What is the difference between a "website" and a "web application"?
Is there a difference?
Are there characteristics that characterise the two?
Software applications are software tools designed to help the user perform specific tasks. Web applications simply provide a software application through a web interface. Think Google Docs as a typical example, but web applications can be much simpler.
On the other hand, a website can be regarded as just a collection of related digital assets (documents, images, videos, etc), relative to a common URL.
(Note: I take the definition of a website from Wikipedia and deduce a definition of web applications from that (or, better, define differences between the two concepts). Everything in bold face is meant, put together, to build the definition of a web application.)
Starting with the fundamentals: Is a web application a subset of a website? Following Wikipedia's definition of a website, that Daniel Vassallo has layed out in his answer, a website is a bunch of documents under a common URL. This also follows the definition in the Cambridge dictionary.
A web application, on the other hand, is a bunch of web-based dynamic HTML and JS documents, together with images, CSS files and other documents, that is most probably, but not exclusively located under a single URL. The purpose of a web application comes below.
Hence we can state: If a web application is located on a single server only, without using client-side cross-domain techniques or extensive local storage (which I'd like to define here as everything beyond standard cookies and default caching), it is also a website.
Corollary: There can be web applications, that are not websites.
Hence we have to extend the definition of web application: A web application, under certain circumstances being a website, is a set of interactive documents. Interactive thereby means, that the user can do more than just follow hyperlinks to get from resource to resource. She can actively and in a well-defined manner change the state of resources. The web application is, for this task, not confined to a single server, or to the server side at all.
Now we yet have to define, where a web application ends and quite anything else starts. Therefore we state: A web application has always an entry point, that is located at a website. If it has multiple entry points, they must all together be part of the same website.
qed
I am open for any suggestion on how this epic piece of wisdom could be refined to meet the requirements of reality. ;-)
Clarification:
This answer is in no way disrespectful to the question. However, I took a semi-serious approach, by which I mean, that the provided definition may or may not fit into one's personal idea of what a web application is compared to a website, but (and that is the serious part) is based on and deduced from a (possibly random) collection of facts.
Clarification 2: This answer has nothing to do with Visual Studio.
Related
what is the best approach to work with ibm worklight website which has lots of content ..should it made multipgage?if it is multipage how do we access worklight context on each page
IMO there are multiple aspects you need to think about and take into account with respect to your specific scenario and needs. Since you did not describe those in detail, I will try to generalise my suggestions:
Your are not required to have an app per-se
You could also re-design your website with responsive web design in mind. This way, as your users load the website in either Desktop browser or Mobile browser apps, the website fits itself to the device's viewport size.
If you do choose to create an app
Not all aspects of your website must exist on the mobile app. Re-consider your strategy and find the right balance of what you should present to your end-users. Make it lighter
Think mobile-first; the paradigm is different and so should be your approach and design: UI Design Dos and Don'ts
As for the technical aspect, many UI framework provide ways to present "pages" within your app. Worklight can work with any of them. Read more about the challenges and solutions, here:
Building a multi-page application tutorial
Example application showcasing multi-page navigation in Worklight 6.2 using jQuery Mobile
Stack Overflow questions about Worklight and multi-page apps
Strictly speaking Worklight hybrid apps are single page apps: there is a single HTML page and we never navigate to a new "URL". However from the UI point of view the user sees what appears to be multiple pages, typically this is achieved by manipulating the DOM of the single page. For example we have a DIV for each "page" the user sees, and we navigate by showing and hiding those DIVs.
With that philosophy in mind your question about accessing the Worklight context now becomes trivial: we're on a single page, so the context is always avaialble.
As Idan says it usually simplest to implement such a single-page, multi-view app by using a JavaScript framework that manages the navigation. Many folks these days use angularJs. Using such frameworks we can decompose the app into a number of small HTML and JS files that are dynamically loaded, from the app perspective it's still a single page but from a development perspective we now have finer-grained artefacts that allow easier parallel development in a multi-person team. When you have an with many 10s of "pages" such decomposition really pays off.
This post is intended to start a deeper discussion on Single Page Applications for the web. There are questions that do not seem to have a clear answer in most resources on the subject.
They are in my mind
Authorization and authentication.
With entire web app being on the client, it may make calls to the server in any of its functions, even those that the user does not have rights to. The fact that the user cannot see a menu, does not preclude that person from invoking java script functions. This is easily handled in MVC app, for example, by using controllers that validate user rights to a specific function based on a cookie for example. However, some SPA apps just use single controller with Breeze or Web Api, which make authorization server side impossible.
Memory management on the client
For small sample apps this is not an issue, but imagine an app with 100's of screens or an app with a single screen that pulls thousands of records over the course of one day. With persistent caching one could imagine large memory issues, especially on under-powered devices with little RAM, like phones or tablets. How can a group of developers had SPA route without a clear vision of handling memory management?
Three Tier deployment
Some IT departments will never allow applications with a connection string to a database located on front end web servers. Every SPA demo I have seen is structured exactly like that, including Breeze or Web Api for that matter.
Unobtrusive validation.
It would require developers to use MVC partial views and controllers instead of just HTML files, which seems to fly in the face of SPA concepts, while it provides a very robust way to easily incorporate validation and UI to support it into web applications.
Exposing primary integer based keys in the url.
This is non-no in OWASP.
As a result, SPA applications "seem" to target areas with few security requirements and small feature sets. What do you think?
Thanks.
#Sergey - I think this is just too broad a question for StackOverflow. S.O. isn't a discussion forum; it's a place to go for specific answers. So while your questions are potentially valid, I don't think you should hold out much hope for deep substantive responses here.
May I add, in the friendliest possible way, that your sweeping, unsupported, and negative statements make you look like a troll. You're not a troll are you Sergey?
On the chance that you are in fact authentically concerned, I offer a few quick reactions, particularly as they pertain to Breeze.
Authorization. In Web API you can authorize at the method level. The ApiController base class has a User property that returns the IPrincipal. So whether you have one controller or many (and you can have many in Breeze if you want), the granularity is method level, not just class level.
Memory management. Desktop developers have coped with this concern for years. It may cause you some astonishment if you've always developed traditional web apps where process lifetimes are brief. But long-running processes are not news to those of us who built large apps in desktop technologies such as WinForms, WPF, and Silverlight. The issues and solutions are much the same in the land of HTML and JavaScript.
Layers on the backend. You've been looking at demos too long. Yes most demos dump everything into one project running on one server. We assume you know how to refactor the server to meet scaling, performance and security requirements for your environment. Our demos are concerned mostly with front-end SPA development. We do dabble at the service boundary to show how data flow through a service API, through an ORM, through to the database. We thought it sufficient to identify these distinct layers and leave as an exercise for the reader the comparatively trivial matter of moving these layers to different tiers. We may have to re-visit that assumption someday. But does anyone seriously believe that there are significant obstacles to distributing layers/responsibilities across server-side tiers? Really? Like what?
Unobtrusive validation. When most people start using the word "unobtrusive" in connection with HTML, they are usually making a point about keeping JavaScript out the HTML. Perhaps that's what you mean too, in which case SPA developers everywhere agree ... and that's why there are numerous "unobtrusive validation" libraries available. HTML 5 validation, jQuery validation and Knockout validation come to mind. All of them are in the SPA developer's toolkit and none of them "require developers to use MVC partial views and controllers". What gives you the impression that a SPA would need any server-side resources of any kind to implement validation with JavaScript-free HTML markup?
Ids as security risk. Really? This is bogus. The key value is no more a security risk than any other data value. Millions of applications - not just SPAs - communicate key values to the client, both in the URL and in the body. It's standard in REST APIs. It's standard in ODATA. And you want to dismiss them all by saying that they "target areas with few security requirements and small feature sets"? Good luck with that. I think you'll have to do better than rest your case on a link to a relatively obscure organization's entire web site.
I have built some SPA applications, ranging from small to large (over 100 scripts and views). Only a handful of them had every view accessible to the public. The rest went through a strict access structure. It was so simple to return a 401 unauthorized from the server and the client just handling the 401 to redirect it to the login screen. Mr. Ward and Mr. Papa put it right. Get out of the Demo mode and try to find solutions to the issues you come across. I have watched John Papa's SPA on pluralsight, gone through numerous articles and applications on Breeze and I have to tell you, none of my applications use Breeze to do queries from the client side, because YOU DON'T NEED TO!!
Moreover, I have only extended what I have learnt and come up with my own way of solving problems. This is not an answer to your queries, but I only can provide a short comment. No technique is perfect and there is no ONE way to do everything. My server side is locked down where it needs to be locked down, my routes on the client side are locked down (if using durandal take a look at guardRoute), my scripts are minified and my images are sprited (if there is a word like that). All in all, SPA is a great technique, you got to find solutions to the quirks!
When setting up a SharePoint farm, is it technically possible to use the following URL structure?
http://myfarm/webapp1
http://myfarm/webapp2
http://myfarm/webapp3
etc.
where each URL points to a different web application on the same farm/server.
MDRoz,
Generally speaking, the answer (in a vacuum) is "no." As far as SharePoint is concerned (or rather, IIS), a hostname without any qualifying port information can be mapped to one IIS website.
Now that I've said that: there are variety of creative ways you might address this, and most are going to involve URL re-writing and remapping. A couple of ideas that come to mind:
A wonderful URL rewrite module can be obtained for IIS 7 that might work for you as-is (http://www.iis.net/extensions) ... assuming you're on Windows Server 2008, of course.
You could probably leverage Microsoft ISA Server 2006 to map incoming requests to different SharePoint web applications (IIS websites) based on path information. I don't have an ISA admin console open in front of me right now to explicitly confirm that, though.
You could develop an HttpModule that rewrites incoming URLs so that they are redirected or handled by different sites/web apps. This would ensure that redirection logic is specifically what you want.
Another link that might have some helpful tidbits comes from Todd Klindt, SharePoint MVP and all-around nice guy: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48.
Regardless of the route you choose, I'll point out one potential sidenote and watchout: hierarchy and path depth. Generally speaking, any rewriting you do shouldn't alter a page's depth. For example, this would be okay:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/testpage.aspx
... but avoid doing something like this:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/newsite/testpage.aspx
These are fabricated examples, but I hope the point I'm trying to make is clear. In the first example, testpage.aspx is "2 levels" deep from the hostname -- and it stays that way on re-write/redirect. In the second example, it goes from 2 levels deep to 3 levels deep. Depth changes like this can lead to all sorts of insidious little problems during normal operations, as SharePoint depends on the path depth and ordering for some operations and determinations.
I hope this helps!
Can I ask why you would want to do this? You can separate out content databases this way for instance.. no need to create separate webapps.
I agree with Sean and Arjan. Sean is right to point out IIS does not support this and Arjan is right in saying that if you ahve the need for more web apps then actually create them as such, if it is just for URL sake create 1 webapp with multiple site collections each using their own content db.
I'm currently looking at developing an application, and have a choice between doing a standard ASP.NET web application or integrating it into SharePoint. Our client would like it to be SharePoint if possible, as they are under pressure to put all new development into it, but standard ASP.NET is still an option.
It is an application to manage and view data in a database with about 10 tables, including an approval workflow when certain new items are added. Referential integrity of the data is important.
I have experience of developing ASP.NET applications, but very little with SharePoint. Does anyone have any criteria they would apply to deciding between the two?
So far I am thinking along the lines of:
Referential integrity of the data is important and SP doesn't seem to handle this very well without writing lots of custom code
SharePoint doesn't seem very scaleable with the suggested limit of 2000 items in a list
The application has an approval workflow, which does seem to be something SP does well
On the wholem, it seems like we would end up writing lots of custom code and not really using any of the out of the box SP features. So my thinking is why not just write a standard ASP.NET application.
Are there any other key things we should consider?
By now, you may have already found this link: http://blogs.msdn.com/sanjaynarang/archive/2009/06/19/should-i-build-my-application-in-sharepoint-vs-asp-net.aspx. If not, it's a decent starting place with some good questions to ask.
What follows is my take as a long-time .NET developer (for as long as the platform has been around) and a SharePoint architect (since 2003). That's basically my way of saying that I've been on both sides of the fence.
In my opinion, SharePoint is a platform, not a product. As ASP.NET provides valuable web-based services to the core .NET framework, SharePoint supplies additional services and capabilities on top of ASP.NET. The platform removes the need for writing common code pieces that are a part of so many ASP.NET apps: security code, user profile management, personalization, UI/UX baseline, etc. When you get into the plumbing, you get even more: rich caching support that requires minimal configuration, customization modularity via Features, and more.
Should every application be built in SharePoint? I'd never push for that. With my current client, we use a mix of SharePoint-based and custom ASP.NET applications. Whether an application gets built in SharePoint vs. written from the ground-up in ASP.NET is a function of what we're doing. We conduct the same sort of exercise you are. If SharePoint's features and functionality can be brought to bear to reduce development time, it goes in SharePoint. If the need is too specific or we feel we'd be working around SharePoint, we go the custom app route.
You have some very specific concerns for your application, so let me take a crack at them with the little I understand about your requirements:
REFERENTIAL INTEGRITY: based on what you're saying, it sounds like your data model is pretty specific. Building your information architecture to natively leverage site columns, content types, and lists probably doesn't make sense. That doesn't throw SharePoint out, though. There's absolutely no reason why you couldn't build the data model you want (presumably in SQL Server) and then consume it with components that reside in SharePoint. If you're using MOSS, some of the BDC WebParts might work for you straightaway. If not, you'd still be writing controls and/or pages to work with the data, correct? There's nothing wrong with using SharePoint as your presentation layer for access to SQL directly or (in a more scalable, n-tier fashion) go against business services somewhere else.
2000 ITEM LIMIT: this is a common concern and one that is misunderstood. There is no 2000 list item limit; the actual measurement is 2000 items per view (and that's with out of the box views, by the way) or "container" (such as a folder). You can store many more times that (millions, if you like) in a list if you partition with folders, build your own view to page, etc. Again, given your data structure and the likely need you have to dodge SharePoint's lists, this wouldn't be an issue if you simply consumed data from SQL Server.
WORKFLOW: SharePoint is nice as a workflow host, and the OOTB workflows are handy. I'm assuming you're looking at MOSS (versus straight WSS), but just in case: the approval workflow comes with MOSS. If you're constrained to WSS, you only have one workflow available to you: the three-state workflow.
At the end of the day, SharePoint is .NET and built on top of ASP.NET. Much of the code you'd have to write in a SharePoint app you'd need to write in a custom .NET anyway. I'd look at things from the perspective of understanding whether the experience and features SharePoint affords you (as a developer) can help speed your development cycle and/or improve the user experience (something we, as developers, sometimes forget).
David in Dakota does have an excellent point, though, in that the dev experience for SharePoint is different from straight ASP.NET. The need (or rather, best practice) to deploy via Features, understand specific SharePoint concerns (e.g., lifetime and disposal of SharePoint objects), etc., mean that there will be ramp-up time if you do build in SharePoint. There are quite a few good resources out there (including folks here on StackOverflow) that can help, but you'll need to factor some learning into the equation of whether or not SharePoint makes sense.
One more parting thought: Microsoft is slowly shifting many of its own products and platforms to leverage SharePoint as their UI/UX layer, and the trend is picking up some steam. PerformancePoint, Project Server, Team Foundation Server, and Commerce Server all use SharePoint as their presentation tier. The trend will probably continue, though I don't know how far. If you use any of these products (or their on your technology roadmap), a SharePoint investment now might pay off later.
Despite all of my writing about and advocating for SharePoint, I don't think it's the right tool in every scenario. I still build WinForms apps, smart clients, command line apps, and more quite a bit. It just comes down to weighing "what I get" for "what I spend" (in both time and money).
I hope this helps!
Your evaluation is quite accurate. (It would help to have more detail about every feature your application needs but that's not really practical for this medium.)
The problems you mention have been largely solved but you would need to understand and implement the solutions. For example, there is a CodePlex project that can assist with referential integrity and there are recommendations on how to manage the number of items in a list. But using SharePoint is never going to give you the freedom of writing an ASP.NET application from scratch.
Another thing to consider is how you and/or the client expect the application will evolve in the future. If it will need more collaboration-style features or features such as version history on list items and integration with the Office client then SharePoint may be the better option.
You should also think about the complexity of deploying and updating your application on SharePoint.
Our organization started on the SharePoint path about two years ago. Before that, we (the developers) wrote mostly asp.net front ends for SQL back ends. Now it seems like every time a new project comes up, we are asked to “make” it fit in SharePoint; and we have stuffed some things into SharePoint that probably should have been stand alone applications or web applications due to complexity and interactions with other technologies.
My question is: Where do you draw the line as to developing a project in SharePoint versus Web/Winform application, and how do you convince your manager(s) that SharePoint may not be the best solution for a particular project?
I sort of agree with you that this is sometimes a tough question. In general, though, I agree with the cliche that you just have to think about a sharepoint app a little differently. If your data can be considered as list-based, then SharePoint probably isn't a necessarily bad development framework. It may seem like more work on the surface, but IMO the challenges just move from one place to another. If you use things like custom field templates and web parts, you can relatively naturally handle all sorts of data. And you get the positive aspects of SharePoint for free (an already mature security framework, built-in searching, site and list templates/definitions, personalized page customizations, yada, yada).
I also I don't know what you mean by "complexity and interactions with other technologies" here, so it's hard to imagine what specific issues might be introduced when SharePoint is added to the mix.
If your dev team is relatively inexperienced with SharePoint and you care about quality and deadlines, I can definitely see your point. It's not an easy learning curve, but I think the SharePoint product is more naturally extensible than many people give it credit for.
There is, in some cases, a third option between a SharePoint application and an ASP.NET application. You can build custom site and application pages and deploy them to a SharePoint site. (The book Inside Windows SharePoint Services 3.0 gives a good overview of how to do this.) This will allow you to use ASP.Net and SQL Server within a SharePoint environment (which means you can also take advantage of things like SharePoint security). It's not as easy as developing a plain ASP.Net application, but it's a compromise.
Of course, this is sort of a technicality if they're wanting these new applications to be built on SharePoint technologies (lists, libraries, workflow, etc.), not just to be "inside" SharePoint.
One of the primary reasons why you might put an applicaiton in SP is when you want to take advantage of the building blocks SP gives you:
Security (share security with the site)
Data (store some or all of your data in lists)
Provisioning (if you want you app on multiple sites)
Some basic data UI e.g. Lists give you that and you dont need to build it.
One thing to consider when trying to 'integrate' a new app into the existing pool is whether there is any overlap in data (customers, inventory, etc) that would benefit from the merger.
There is also the benefit of being able to back up multiple applications and all of their respective data in one place.
Why are they asking for it all to go into SharePoint?
In my experience it is because the 'ole SharePoint intranet is being great as a portal to keep everything together and findable under the one information architecture.
Approach the issue from a uses perception of the application space in the organisation.
So long as the application looks and feels just like part of the intranet site and the user does not have to think about how to get to it (and how to get back out), you can pretty much take any architecture decisions necessary to get the best bang for the organisations buck when it comes to implementation and maintainence.
When we started thinking about the site less from SharePoint vs other stuff to the nice woolly concepts of Information Architecture, findability and usability, our decisions not to make it actually inside SharePoint, but still skin it like the Intranet became easier to sell.