I am working for a client and they are creating an application that they want to host on Unified Service Desk.
As you all know that Unified Service Desk's new version 4.1 has been released earlier. I read a related article on Microsoft as well that things to keep in mind when you check the existing Unified Service Desk Version.
But the thing I want to know here is on what technologies should they built there third party applications are there any nitty gritties that
Are there any points that should be considered so that we can make an application compatible and workable inside Unified Service Desk,
I want to know like,
What platform should they consider
What Language should they consider
And any other specific details that we keep in mind before
creating the application
Any help would be appreciated.
This can depend on their internal dev skillset and whether they want the application to be accessible outside of USD. For web apps, they should consider whether they are targeting a browser that will have long-term support from Microsoft. We're starting to see Chrome support, and will eventually see Edge support also. IE will eventually go away, but it's not clear when. If no one needs the application outside of USD, then a C#/XAML compiled control would naturally provide reliability and speed above and beyond any web app.
Related
I'm looking at enterprise JavaFX, and how to integrate JavaFX with server-side code. In the last few weeks I've done a certain amount of research in DataFX and Open Dolphin, and downloaded some videos, as well as looking at a couple of other frameworks. For example I've looked at the video on DataFX at:
https://www.youtube.com/watch?v=EN4fo6x0DcQ
However, although this video and others I've looked at explain how to set up a client application that connects with a server, I've found very little information on how to put together some server-side code that the client can connect to. Sure, one could use JAX-RS, but why re-invent the wheel? In the first instance I would like to put together some really simple server-side code that some test client-side code can connect to using DataFX or one of the other frameworks. The aim eventually is to get a client using JavaFX to communicate with a server.
My second question is that of the various frameworks available, is DataFX the best to use for a simple application?
I have experience with a Glassfish server hosting a JSF application, and it may be useful to have such a server hosting a JSF application communicating with a browser as well as communicating with a client JavaFX, as that way I can test out that the communication with the JavaFX application.
The latter is a bit of an aside, and my main questions are where can I get information on server-side programming for this, and the best frameworks to use?
Many thanks in advance.
If you are able to manage yourself the client-server communication you can pick any JavaFX Application Framework listed there:
https://github.com/mhrimaz/AwesomeJavaFX
Any of them allows to separate UI code from communication code.
As I'm author of JRebirth, I can advice you to create some RemoteService (extends Service and providing JAX-RS facilities or whatever) to perform this job.
If you search an all-in-one library managing client AND server side, DataFX + OpenDolphin is probably the most advanced one.
I'm the author of DataFX & Dolphin Platform (https://github.com/canoo/dolphin-platform). Both are valid frameworks that fill fit to your needs. Maybe a combination of both - Dolphin Platform as remoting layer between client and server and DataFX to define the routing and mvc based views on the client.
Some days ago I copied all the DataFX sources to GitHub (https://github.com/guigarage/DataFX) and currently trying to create a new version based on the modules that are maintained by me. Maybe I will extract the MVC related stuff and create a new framework based in it, we will see. What I currently can say is that I plan to work on it the next month next to the Dolphin Platform since I think a combination of both will be a good fit.
I would use this combination today to create applications but yeah, I'm the main developer of both frameworks so the choice is quite easy for me ;)
As you mentioned JSF I think that Dolphin Platform is a perfect match for you since one idea of the framework is to have a modern successor for JSF that can be used to create desktop & web based applications but provide managed controllers on the server. We provide a cool maven based jumpstart (Maven archetype) that will give you a quick introduction and a runnable client / server application with a desktop and web client in 2 minutes: https://canoo.github.io/dolphin-platform/#_dolphin_platform_jumpstart
platform: ASP.NET 4.5, MVC 4, C#
I'm currently designing a website that's available on the public domain. However, there is a meaningful % of my target market that would be uncomfortable putting some information on a public site, even if it's https etc.
What I'd like to be able to do is allow corporate users use my site, and one way to do that is to allow them to host my website on their intranet. The usual disadvantages are, of course, that they don't get their site updated as fast as the public one would, and it's also a headache for me in terms of support.
My questions are
What are some strategies to make "corporate friendly" deployments easy and hassle-free?
Are there ways I could keep the site public with just the database inside the intranet (can't see how... but then I'm no techno-know-all)
If I have no choice but to make it locally hosted - then what's the best way to do it to keep my development/support overheads at a minimum?
I hope the mods don't lock this. I'm asking for specific methods and technical approaches to a very real problem.
Thank you,
For #1, there's a many facets to the question. A couple thoughts that might help you think it out:
Deploying your app: Make it simple to deploy, and to upgrade, between versions of your application. Try to make it happen as a single operation, not upgrading different parts by hand manually. As Darin Dimitrov mentioned, you could look into a technology like Web Deployment Packages, especially with Visual Studio 2012 which will have incremental database publishing (in VS2010, the database was non-incremental so there wasn't really an "update" story). Keep the cost of deployment down so that they can afford to upgrade more frequently (not the cost of your product, but the overhead of who's getting paid to keep the system updated and running).
Consider differences between running on the Internet and on an Intranet: For example, authentication on the Internet is usually done with forms based authentication. On an intranet, you may want to consider supporting Windows authentication for a seamless login experience for corporate users. This should impact your designs to allow authentication to be modular between your deployments.
Corporate adoption of newer technologies might be slower than you want: You're using the latest and greatest (ASP.NET 4.5/MVC4). Some companies might not be prepared to deploy this now, or for a couple years. Consider if you could use an older, established technology, such as .NET 4 - having been out for a few years, it's already somewhat proven and has adoption.
For your 2nd question, it comes down to what their IT is willing to accommodate. Many corporate sites have the database within a secured LAN, but the web server is accessible from the public Internet. It's certainly a well-understood network design, but depending on the assets involved in your application, your customers may or may not agree to it. This one's a business decision.
For #3 the answer is common to any long term software project. It has to be high quality and maintainable if you want to minimize the hassle.
If you're only going to support the last N versions, make that very clear. Avoid supporting code that you're already fixed long in the past. Consider providing extra support or affordable upgrades to keep your customers on newer (and hopefully better) releases.
Keep in mind what components need to be upgraded between versions. Your web app (obviously), but also your database schema and any dependencies or libraries you're using. This is mostly the same considerations as #1. Make sure you have a good plan for upgrades and rollbacks.
Most importantly, test, test, test. Have functional regression tests and install/upgrade tests, and try out as many possibilities as you can think of.
Answer to only 1) above.
I would recommend a continuous integration tool. We use TeamCity and deploy mvc3 and mvc4 applications to our public as well as privately hosted sites with a click of a button. Previously, we used cruise control, but now we are more satisfied with TeamCity. Read up on them. Might lead you in the right direction.
You may checkout Visual Studio's Web Deployment Packages. They allow you to prepare a package that could directly be installed on your client's web servers.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Our team is divided on this and I wanted to get some third-party opinions.
We are building an application and cannot decide if we want to use .Net WPF Desktop Application with a WCF server, or ASP.Net web app using jQuery. I thought I'd ask the question here, with some specs, and see what the pros/cons of using either side would be. I have my own favorite and feel I am biased.
Ideally we want to build the initial release of the software as fast as we can, then slow down and take time to build in the additional features/components we want later on. Above all we want the software to be fast. Users go through records all day long and delays in loading records or refreshing screens kills their productivity.
Application Details:
I'm estimating around 100 different screens for initial version, with plans for a lot of additional screens being added on later after the initial release.
We are looking to use two-way communication for reminder and event systems
Currently has to support around 100 users, although we've been told to allow for growth up to 500 users
We have multiple locations
Items to consider (maybe not initially in some cases but in future releases):
Room for additional components to be added after initial release (there are a lot of of these... perhaps work here than the initial application)
Keyboard navigation
Performance is a must
Production Speed to initial version
Low maintenance overhead
Future support
Softphone/Scanner integration
Our Developers:
We have 1 programmer who has been learning WPF the past few months and was the one who suggested we use WPF for this.
We have a 2nd programmer who is familiar with ASP.Net and who may help with the project in the future, although he will not be working on it much up until the initial release since his time is spent maintaining our current software.
There is me, who has worked with both and am comfortable in either
We have an outside company doing the project management, and they are an ASP.Net company.
We plan on hiring 1-2 others, however we need to know what direction we are going in first
Environment:
General users are on Windows 2003 server with Terminal Services. They connect using WYSE thin-clients over an RDP connection. Admin staff has their own PCs with XP or higher. Users are allowed to specify their own resolution although they are limited to using IE as the web browser.
Other locations connects to our network over a MPLS connection
Based on that, what would you choose and why?
I am especially interested in hearing from developers who have experience with both ASP.Net and WPf.
Reasons to choose WPF:
Much faster and easier development than ASP.NET and jQuery
Much easier to implement quick incremental background loading of data
Much easier to implement client-side caching of commonly used data (important for remote offices)
More efficient data transfer from server (can use advanced WCF features unavailable to web browser)
Keyboard navigation better, since you can easily define shortcuts, etc, and not be limited by browser
Maintenance overhead much better using MVVM pattern
Softphone integration easy
Reasons to choose ASP.NET and jQuery:
None that I can see
In your scenario I would definitely choose WPF.
First of all, I would sit down and write the business requirements and specifications. It really doesn't matter what tech you use - proper planning will affect your project timeline more than technology choice. This is especially true for an in-house custom built app.
As far as development, I would take the requirements and lay out the backend functionality. I would actually implement the backend in WCF, regardless of the client technology - that way you could use best of both worlds if needed (for example for phone integration you could write a stand-alone WPF app). ASP.NET with jQuery can easily use WCF services (JSON or XML version) together with desktop client.
As far as development of the client forms, this highly depends on developers experience and your future plans. I am not going to go into advantages/disadvantages of developing web software here - there are a ton of articles in the last 10 years about cloud/web based software (for example salesforce). I would rather concentrate on deliverables - what is your team most comfortable with today and in the future. There's a huge difference between WPF and web development, from development standpoint, and it requires completely different experience.
Why not consider a hybrid solution - Silverlight
With Silverlight you get most of the goodness and statefullness of WPF (with almost exactly the same XAML and code), plus you get the deployment characteristics of ASP.NET
Many people consider Silverlight the next step after ASP.NET/AJAX, and it would definitely deliver all of the benefits of WPF relevant to your scenario.
WPF is the way to go, without a doubt. I agree with all that #Ray Burns has said.
Because:
You will get a richer, slicker, faster application.
It will be easier to build1.
Softphone/Scanner (i.e. hardware) integration is going to require browser plugins etc. and this can be a nightmare with a browser based application.
Keyboard navigation is still better with native applications.
IME Maintenance is easier with WPF applications.
Definitely use WCF to provide the backend via The Entity Framework, see The Entity Framework In Layered Architectures. You can do have a better integration with the backend in a native application because it can be called inline - no need for callbacks or ajax. I've built components for WPF that are linked via EF to the business logic to provide aware controls for simple stuff like validation. It's stunningly good to drop a customer name field onto a form and it just works.
To add additional components you need to build it with a proper well thought out plugin architecture. This is the same in both environments. I've got some thoughts on this I jotted down in my journal entitled Designing a plugin architecture for an application
When building a WPF application you will be writing in one language (e.g. C#) + markup (XAML). When building asp.net you endup with two languages + markup, as you always have to code some Javascript.
So, based on your requirements it has be to WPF / WCF (EF). A web based application will be a lot more work, more complexity, and not be as nice.
About 12 months ago I was fortunate enough to be given a free hand to choose the technology for a new application. I spent almost a month evaluating all of the options and came to the conclusion that it had to be C#, WPF, Entity Framework. After writing the application I can confirm that it was the right choice...
1. It will still be easier even if your programmers have to learn WPF first. WPF is much better thought out, great and lovely. very lovely. It just works right.
Hi
I think The question at issue is Windows-application or Web application(WPF for win-app VS asp for web-app), Which one is better for you and your project?. In this case your platform is network and your program must work on the net. so for this usage Web-app is better but there are a lot points existing which can make decisions hard. Network platform has great challenge.(according to my personal experience)
Working with web-app by asp.net is nearly hard. you must try to handle many thing's for web-app(request time, session management, even poor UI in comparison to WPF, j-query, etc ). Remember this is not as easy as simple web site.
But win-app is good for network with this condition: "local network"(mpls is almost the same). Absolutely developing win-app is easier than web-app ("At least number of users expert in net-program developing"). for this case WPF has many good things(UI , command, etc) also has many challenging point(like multi-threading and lack of expert developer in this field ) . I'm rather with wpf than asp but decisions is yours
And chalk point to good thing Silverlight but if you want to use this you must look at prism framework : http://compositewpf.codeplex.com/
I have recently developed a project separately with asp and silverlight(prism framework). developing silver-light version is too hard and takes more time than asp.net version but at the end SL-ver have great look nothing else!
Burns pointed to good issues about wpf. also consider Artemiy's post. your environment conditions is same for both of them. WPF/ASP can work with scanner and soft-phone cuz the base of both is on C# and .net library
Finally what ever your decisions is you must hire advance developer at least develop one business-app for the network platform.
Is your app a desktop app or web app.
If Desktop wpf is best.
If web based asp.net is best.
Don't front load your development with your get it up quick scenario. That never works well and results in a sloppy deployment. Take your time, cover all the steps (Business Requirements, System Design, Program Design, Code, TEST and TEST some more, Deployment)
Some points to be made for ASP.NET:
The pool of ASP.NET developers is much larger then the pool of WPF developers.
Which means you can probably find qualified ASP.NET developers easier.
ASP.NET is probably more future proof, chances of WPF getting large changes and being hard to port to later versions is probably larger.
Also keep in mind that the focus of MS seems to be on Silverlight so there might be a consolidation down the road which makes WPF obsolete.
More mature eco system of ASP.NET makes for more out of the box solutions to use to solve problems.
With multiple locations you might be able to skip a few layers and go directly to a website?
Over the past 6 months I've been developing web sites using asp.net. When I design something such as a contact form, 99% of the time I find myself using a script manager and update panels. Recently I tried out silverlight and expression blend, and I love it.
Is there any big cons for me to start building my forms with silverlight instead? The only big one I can think of is the user might not have silverlight and not want to download the plugin.
I guess to solve the has and has not issue, I could make a silverlight version and a standard version until it comes to the point where the plugin is as popular as flash.
Personally i would advocate doing everything in SL because i love what you can do with it. But common sense dictates otherwise. There is no point replacing relatively static webpages with a SL app. While there are methods to communicate/cooperate between SL apps and the web pages that host them, you don't really want to do this unless you have to, you can end up with quite a kludgy solution.
SL is not suitable for everything. The times you want to use it are when you can redo (or create) a whole web app (or significant chunks of it), and you want to create a more immersive and interactive desktop-like experience for the user. You also need to read up on authentication with SL and WCF services, SL navigation, and become familiar with the SL4 Out of Browser feature as it offers you some features/benefits beyond what is available to an in-broswer SL app.
The Silverlight plugin is not available in mobile devices. Also, SL 3/4 is not yet 100% supported in Linux.
You really have to take in consideration your targeted audience.
If your app is meant to be used anywhere SL or event Flash is not a good choice. None of them run on iPhones for instance.
The Silverlight platform is a good compromise between the richness of a fat client and the easy of deployment of a web app. Intranet environmentss are great candidates to take advantage of that.
The platform runs well in both Windows and Macs, and should get better in Linux too.
I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.