I recently had my mind expanded by a new concept: Web Services for Remote Portlets, or WSRP. I learned of it during a presentation on a Java-based web portal we are considering purchasing at work; we are a .NET shop and WSRP would be the means by which we would extend this portal.
Although I cannot control the end decision as to whether or not we purchase the product, I can provide input as to how difficult it would be to build WSRP-compliant portlets. Unfortunately, my recent queries into the subject have turned up almost nill.
So I ask you, the SO community, the following: what libraries or frameworks are out there for building WSRP-compliant portlets in C#/.NET? What are some of the pros and cons of using WSRP in general?
Because there is no correct answer here, I will make this a community wiki post.
So far, I have only found the following:
WSRP Toolkit for Sharepoint by Microsoft (but requiring Sharepoint).
WSRP Portal and WSRP .NET Framework By NetUnity.
Given that WSRP is on top of SOAP, this seems like a perfect candidate for a WCF binding and channel, and yet I see nothing on the subject, anywhere.
WSRP is very contrarian. By now the world has seen that tight coupling between the data model and the presentation model is suboptimal. The success of RSS, REST, MVC, and web services in general shows this. Despite the WS in the name, WSRP stands against the core principles of Web services. The WSRP spec ignores the sound advice to keep data and presentation separate, and couples them tightly.
WSRP promises integration, at the UI level. This seems like the wrong problem to be solving.
It baffles me that this thing has lived as long as it has.
The problem it attempts to solve is often not the problem that should be solved.
If you read the WSRP spec carefully, you'll find it is a remote version of the Java Portlet Specification (if I'm spelling that right). That means that it's useful for integrating Java Portlets. Anything else will have to look like a Java Portlet, which is not very generic.
I think its popularity / adoption can be inferred by the fact that the last release from NetUnit was "This latest release adds support for Visual Studio 2005 and .NET 2.0."
I would have to agree with Cheeso. Integrating the UI with the Data only serves the portlet consumers and adds a big, unnecessary, risky layer to portlet producers. Our .NET shop has been recently forced to consider WSRP and I have found a lack of support and experience. The best MS-centric approach I have seen discussed is here. But I have not found any specific WCF implementation/support. Any leads greatly appreciated!
WSRP is essentially a portal-to-portlet web service standard. What is the primary data exchanged between portal and portlet? It's markup and largely because most portals use a web UI. This whole idea that it is not pure data versus UI is moot point. It's meant to be a web service for portlet discovery, meta data, markup, interactions, caching, portlet-to-portlet communication, etc. That's what a portal does even if not WSRP. WSRP however is an open, cross platform standard.
What is a portal that only integrates portlets from its own products and/or platform? Got Java-based PeopleSoft HR and would like to provide access to their portlets from SharePoint to your employees? Good luck. Why can't this be an achievable scenario for most enterprise software? And yes, I realize it is integration related to UI. That is one of the primary reason for why I'm using a portal. It's not like I'm expecting to get PeopleSoft integrated with SharePoint at the "pure" data level and somehow an Employee Benefits Web Part magically pops up in SharePoint ready for use. However, that is what I expect if the portlet-to-portlet integration is based on WSRP.
WSRP, although not perfect, is a superior solution in my opinion. Besides easy integration of portlet within a portal, it separates the portal from the application. No deploying of binaries to the portal server or even running on the same server. This makes sense. Never run applications on the same server as the portal server: neither will ever be upgraded. I've come to the conclusion that it's insane to put application binaries on the same server as the portal server. "Please deploy this application to the portal server and have it affect security, stability, performance, and everything in between and I would like create as many dependencies as possible and bring down the whole portal sever whenever I upgrade the application". It's a dependency nightmare. Better get a couple of portal vendor consultants to hold hands with when upgrading and to have someone to blame.
Do you need to load balance an entire portal platform when only a select number of portlets are hit the most? Portal vendors would like you to think so. A lot of the time, the portal is doing nothing more than waiting on portlets to finish processing. With WSRP, you have the flexibility to load balance portlets independently of the portal platform. It always breaks down to a few portlets that are hit the most. Why not load balance just those portlets? So instead of unnecessarily load balancing the portal on 80 CPU, you could load balance those few portlets on 10 CPUs. WSRP is also absolutely perfect for cloud computing.
WSRP is a portal-to-portlet standard. If you want to write a portlet that works in multiple portals and potentially across platforms, WSRP is it. If you are remotely contemplating integrating third party portlets, WSRP is it. It's the only standard. However, it also has some significant benefits over other proprietary local portal-to-portlet interfaces and should be considered for those benefits as well.
Related
I am responsible for developing the software for a printer-like device, for which I am using C#/.Net and WPF. We now have the necessity for making this software network-capable, so that the device can be remote-controlled over a local network.
The idea I currently have, is to be implement some way of calling the API-functions of our software over the network. This could be done by a client-side DLL, which sends the commands for the API and receives their responses as well as any events, that the device-software issues.
To this date I have only worked a little with socket-based communication using TCP/IP, where I explicitly sent strings over the network and received them on the other side. I did this completely synchronously. However for the new implementation I will need asynchronous calls to the API to query state, issue events, etc. and it seems like it would require considerable effort to implement this using socket-based communication (am I wrong?). I will have to avoid too much custom implementation, since I am under a time-constraint for the implementation.
In my search I came accross the possibility of using SOAP in ASP.Net, which from this CodeProject post, seems to be what I am looking for and does not seem to be too complicate to implement. However in my Visual Studio 2015 installation I am unable to find the project-type they are using there, which is a "ASP.Net Web Service".
My question is now:
Given my choice of technologies (.Net), would this be the most effective way for achieving, what I have in mind? Is it still possible to do this in Visual Studio 2015?
Update:
As always I found one of the questions afterwards: Here is an explanation of how to create an "ASP.Net Web Service" in Visual Studio 2015, which I have tested to work. Leaves the question, of whether this is the best way to go for what I need.
I think that you would have better luck using web api. Calling a REST based api is a lighter load on the network and is generally easier to set up. It is also easier to call from non-Microsoft based clients and usually requires less coding to get started.
Here is a good tutorial on creating a RESTful web api using .Net Core. If you have a PluralSight subscription, they have a number of tutorials on Web Api. If you don't have a subscription, it is well worth the money.
Web Api and WCF are two completely different frameworks. WCF uses SOAP, which is XML based, meaning that the number of bytes needed to send information is much larger than a RESTful service in Web Api. It is much easier to write and deploy a Web Api application and client than it is to write the equivalent in WCF.
Apologies for the vague question, I am looking for pointers rather than exact answers. I have an application I am developing in Silverlight which requires some back-end persistent data. I can certainly do this myself using IIS / SQL Server, but I am eager to learn something new!
Are there any suitable, free, cloud services I could use? A bit like Google App Engine, but preferably allowing me to use the .NET stack, e.g. via a WCF connection to my client.
As this is just for learning purposes I don't have many requirements regarding data volumes etc, however, it would be nice if I could run some scheduled services on my data in the cloud, e.g. some statistics calculations every hour.
Any pointers?
You can get Azure free for 30 days here. If you have a premium/ultimate MSDN subscription, you can get Azure free for 8 months.
if it's only a test and you do not expect high volume you could do with Windows Azure and SQL Azure, at least you learn how to deal with leading products and if afterwards you decide to develop something more commercial, you will reuse the know how. I do believe for testing reasons or low volume you should get it either for free or extremely cheap.
Try EyeOS. You can go for the trial version and test your applications.
Others are
icloud
Cloudo
Force
I have less information about share point (only basic info). Microsoft released SharePoint for web developers. Microsoft also said SharePoint has compatibility with other .NET technologies like Workflow Foundation, WCF, etc and it's easy way to develop web sites and web apps.
Also as I know ASP.NET has compatibility with .NET technologies and C#. And it easy for every one whom at least work with C# or VB.NET.
So with these advantages of SharePoint:
Why we must use asp.net instead SharePoint?
Why Microsoft develops ASP.NET (new version 4)?
What's major reason to chose one of these?
Is really developing base-on share-point faster and easier than asp.net?
SharePoint is an Application that sits on top of ASP.net (3.5 SP1 in the current SharePoint 2010 - No ASP.net 4.0 will be possible). They do override a lot of ASP.net built-in functionality (they have their own .aspx Parser and Virtual Path Provider for example).
With ASP.net you have a very well documented, battle-hardened, mature and stable platform with a good API.
With SharePoint you gain a poorly documented, bug-ridden, very limited application that handles a lot of features that you would have to code yourself (e.g., User Profile Management, Document Organization and Versioning and Social Features like Commenting and Tagging), although for the most point SharePoint handles them really poorly and does not allow you to override them, which means that you spend a lot of time rewriting them anyway and trying to integrate them back.
Basically my advice as a SharePoint developer since 2006: Use it when you absolutely have to, avoid it whenever you can and stay with just ASP.net.
SharePoint is good as a simple document management and very light social system. You can quickly customize smaller parts of it and add a lot of value to your company. But in the moment you need something that even only slightly different from what Microsoft envisions, you hit a wall that you can't pass. It's great for what it does, nothing more, nothing less.
I am a Sharepoint Developer... And let me say that I wish it was just ASP.NET! That would be great... It brings with it it's own paradigms which are pretty complicated.
ASP.NET and Sharepoint are 2 'different' technologies. Sharepoint is mostly built with ASP.NET, and delivers ASP.NET pages to a user.
You can use either VB.NET or C# with Sharepoint.
In my opinion, Sharepoint development is only quicker if you are planning on using it's in-built lists, user management etc. Though these do take time to learn. The cool thing about sharepoint is that you can develop web parts, and re-use these web parts on multiple pages throughout the installation.
Microsoft continues to develop both ASP.NET and sharepoint because they are two different beasts, with ASP.NET pages being deliverable through Sharepoint.
As to which is best for you, you haee to make that call. Do you need Sharepoint? Or would a pre-built CMS such as DotNetNuke be better? Or even creating your own site with Windows credentials management so you can use SSO (Single Sign On).
It really depends on what you want to get out of your install. Sharepoint is expensive, and developers for Sharepoint are also expensive because of the specialist knowledge.
As a developer... (I hope my boss isn't watching!!) I much prefer to build things from scratch than to use SP, but that's my job...
Don't use sharepoint unless you need it, check this article:
Challenges when using SharePoint compared to ASP.NET
If you just want to create a website, go for ASP.net.
However, if your company has a SharePoint installation and you want to integrate with that, you should go for SharePoint.
SharePoint is build on ASP.net, but has many extensions that allow data to be shared throughout the company.
However, if you are just building a website and don't need all that, ASP.net is the way to go.
I'll try to answer point by point:
SharePoint isn't a replacement for ASP.NET. It's an extension of the ASP.NET platform that simplifies the implementation of several common use cases that are mostly relevant to enterprise websites: document management, knowledge retention, collaboration etc... SharePoint relates to ASP.NET in a similar way that Wordpress relates to PHP: it's a specialized extension rather than an alternative.
Same explanation as in (1).
Use SP if the things you need to develop are in the scope of what SP provides, which is mostly enterprise solutions of one sort or another. Here's a good summary of what SP can do.
Again, it would be faster and easier if you're trying to develop the things that SharePoint is meant for. Also, SP isn't so well-documented, so if you're not familiar with it, you might have a slow start.
SP is a very powerful platform, however, it does seem to bring complexities to the table that otherwise may not be there with simple ASP.net. Plus when you move "OOTB" with SP it becomes a bit challenging with RTM, etc. I live in blogs with "weird" things that happen. I am not a full blown SP developer but have been working with it for over 7 years and well, I find building solutions that will work within SP, but not necessarily built withIN SP generally are going to be easier to maintain and controllable. Just my opinion!
I would compare all for you and its up to you to decide.
ASP.NET >> Its a programming language by Microsoft which means you would need Windows Server + IIS + Database server like SQL Server + some Anti Virus on the server.
Say now you need some more PC for your servers and so your costs go up all the time you need a new server
Sharepoint Server are again from Microsoft and so everything above applies.
Is it wise to build a large application entirely based off SOA? Or just some portions? User account logins, accounting, gis mapping, sales, etc?
In other words, would it be wise to build a GUI to such an application in HTML & Javascript which does all it's exchanges via ajax to .NET web services on the back-end?
I can't see it worth loosing all the .net .aspx functionality such as forms authentication, view state, etc. But my co-worker is saying if we are going to go SOA there is no need for .NET on the front end. But i think there should be some sort of balance. Where do you draw the line? Should all calls to the database go through the web services?
I just want to say that "with SOA we’re building for change, while with Traditional systems engineering, we’re building for stability."
The problem with stability, of course, is, it only takes the business so far — if the organization requires business agility, then they’re much better off implementing SOA.
So, It solely depends on what you want to achieve, you are the one who should draw the boundary.
I read it in article on SOA few days back as I'm too working on SOA.
EDIT:
Meanwhile I came across this article and thought of sharing with you.
The video quite explains the current scenario of SOA and its views by different people.
I'm getting the words of the song 'If I had a hammer' coming to mind. SOA is an architectural approach to develop software as a series of services. In my opinion this is best for systems that have less than immediate latency and limited bandwidth, and high cost in access etc (these are all obviously highly subjective). You don't need full SOA just get loose couping between components which I would argue is a good goal to achieve.
DB calls can go through a service, take ADO.NET data services for example however you really have to weigh up with what the service is to provide. Take caching. A decent approach to SOA will consider that data is may need to be cached to reduce service load. So can your data be stale in the UI? Are you allowing that use case? Is right for login info to be stale (a rough example I know but possibly something that may need to be addressed).
All in all - it depends. I think some things lend themselves to SOA very well. If you take a DDD approach then the services that represent Domains would probably do so. In this way your UI talks to domain services and not rows in table as the DB is abstracted behind domain services.
Don't use one methodology to solve all problems.
See this SO question too
It's a service oriented architecture, not a service exclusive architecture.
Presentation logic and plumbing have to live somewhere; it all depends on where it makes the most sense for it to live.
For example, let's say you have a UI component that relies on a highly chatty but efficient set of calls to a database to generate a complex analysis of something (take your pick). If your web browser is making all those calls, you introduce massive network latency and concurrency issues. If a web service makes all those calls, you are potentially putting presentation logic into it to format that result.
If you are using Session state (or web services period), you are essentially using ASP.Net anyway. Try uninstalling it and see if your web services still run.
If presentation logic needs to live on the server side, it is better for it to live within a framework intended for presentation rather than a web service, IMO. If you haven't looked at MVC 2, do so. It makes it incredibly easy to set up an application that melds browser and server UI support (for example, jQuery validator controls backed by server-side validation).
Conversely, the web browser provides an expressive platform. Assuming browser support and team knowledge, the AJAX/SOA architecture you describe is a good one. I'm using it more and more and trying to make my server pages cleaner and simpler but I have no plans to exclude ASP.Net from my toolkit any time soon.
Client implementation should be completely disconnected from the back end web service in a SOA. The service should be able to be consumed by ANY client. If you are using .NET on the back end and front end because they can be coded to directly communicate, then you are missing the point, because now they are tightly coupled and what you have now is a stove pipe application. The client should have no idea how the server side is implemented -- shouldn't matter if the back-end web service is built using .NET, Java, or whatever.
In a true SOA, you should be able to search for services in the services repository, perhaps tie the outputs in with other services or use XSLT to create alternative outputs that weren't necessarily considered when the original service was built, and consume it in a standard way in any client on the front end.
It sounds like what you're really asking is how to build a single application. The point of a SOA is to provide standard data sets through re-usable interfaces, that have no specific application or implementation in mind. To start out building a single application with the entire back-end comprised of SOA services would be a huge undertaking. In MY mind, each back-end service should be built because of it's intrinsic value all on it's own and be provided to the entire SOA "domain". Then when you or I decide to make a client that does X, Y, and Z, we can just go find those capabilities in the SOA and injest them.
I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!