I was wondering what currently is the lightest VS project to make calls to a web API and that can be hosted on IIS? From what I see available, I can either do an ASP.NET WebApp or WCF Service Application. However I'm not sure which one would be considered overkill for something that will only interact with Active Directory and make a few calls a day.
edit: After reading this SO Question and the provided link to an official comparison I realize it's pertinent to note that half of the calls to to be made will be triggered through a browser.
None would be overkill for that. However, a WCF service application will be much lighter for your specific use case.
Related
We have an existing cross-platform Mobile Application, that also has an accompanying web application, that uses AWS as a back end (RDS for Database, Four server instances, and a Load Balancer to distribute traffic). APK and IPA files are packaged and sent to the stores, while components are retrieved from our server per request, which enables us to reduce the number of store builds, and make the process easier for getting changes out to clients.
We are at the stage of Development that we need to move to another platform to better facilitate our fast growing client base.
Due to the conditions upon our clients, these things must be considered.
must be cross platform (Android / iOS).
must be offline based (users need to be able to access without an internet connection)
must be able to sync with an existing database when there is a connection
requires Authentication
Cloud based (? may not be the right term, but meaning the ability for us to store components on a server and have a device check for updates and download a local copy - enabling us to work and distribute fixes faster)
Ideally compatible with AWS
We are currently looking at Xamarin to facilitate us for this move, however there is a lot of documentation and plugins out there to do all sorts of different things.
As developers, we all have some .net / c# experience, however none particularly with Xamarin.
We have a particular timeline that we need to adhere to (and need to ramp up in the next couple of weeks), and right now are essentially stuck in Limbo in a research phase, as we can't afford to get some things right. We are unable to move forward until we know Xamarin (or some other framework) is able to do everything that we need it to do.
It's hard to escape from the 'code it all ourselves' mentality - especially as we don't know where to start looking in terms of third party packages for Xamarin, and their documentation itself.
A lot of documentation mentions various systems of Azure - we would not be against moving to Azure over AWS if it _had to be done*, but because of the existing infrastructure with AWS - staying with AWS is obviously the preferred option (users need to access the current system whilst we build the new system)
This stack overflow post is to ask for recommendations, comments, or other observations on anything and everything involved with the process in regards to choosing frameworks, design patterns, methodologies, third party packages, etc.
Obviously we would like to use best practises for everything moving forward for optimum scalability and cleaner, more robust code. It's just hard to know where to start!
Any input will be highly appreciated.
Cheers!
edit: I am aware that this is 'asking for recommendations' which is 'specifically off-topic'. I have read the posting guidelines about open ended discussion, and am quite confident that this case is different. There is an underlying problem here, in that we are seeking advice on combinations of frameworks and plugins that are fully compatible with all of the items in the list (above)
Let's try to breakdown each of your requirement and constraint mentioned in the question.
1. You need a offline first architecture (With Sync mechanism)
Xamarin + Azure would make a good comdo for you, as it would support offline storage out of box (With a simple PullAsync call).
Albeit there are AWS SDK available for Xamarin. Here it goes http://docs.aws.amazon.com/mobile/sdkforxamarin/developerguide/setup.html
So the call is yours. There are few other ways to achieve caching offline storage in Xamarin, you can build upon those strategy in your logic. Alternatively there is a very interesting C# library Akavache for caching and offline storage.
2. OAuth 2.0 Authentication
Xamarin has a very good library named Xamarin.Auth. Though I would not say it is very easily extendible at this but there has been some serious work going on from Xamarin on this library.
But I would say it is very easy to use. The apps I have developed so far that includes - Google OAuth, Facebook integration, Microsoft account integration. It worked fine for all of them.
3. Cloud based distribution
There are nice tools available with Microsoft. Which makes the distribution easy. Have a look at https://mobile.azure.com . Also hockeyApp is good for distribution I found.
Where to start:
A very good starting point for you would be https://channel9.msdn.com . Just go there search with keyword "Xamarin" and view some videos. May be all these cross platform dynamics will be much easier for you.
Overall I found Xamarin a cool product to work with. Because anything that can be done in native Objective C/Swift or Java can very well be done in Xamarin using C#.
I would like to load test my MVC web api and get the best hardware configurations or number of load balanced servers to achieve specific number of concurent requests.
But I do not know where to start. Can someone point me in the right direction?
As regards to ASP.NET Web API, the steps are pretty straight forward.
create a unit test project for your web api method(s). check this out
add a load test to the test project check this out
perform the load test in the cloud. Take a look at this and this.
Note that the last step requires that you have visual studio ultimate and a visual studio online account. Your visual studio online account gets you 15,000 user minutes free every month to load test your app. You should be able to glean useful information in the test results to help in your decisions e.g how many VM instances you might need, etc.
What's your experience in using web technologies (HTML, XML, CSS, JavaScript) to implement part of the functionality of a GUI application? Pros and cons, please.
No servers, relational databases, AJAX, or cookies for session management, nor an existing webapp either, but rather a GUI app that uses web widgets (like Qt WebKit) to render and handle substantial parts of the UI, while taking advantage of a GUI framework to achieve an even richer interaction and better desktop integration.
I've already validated that the approach is possible using PyQt. Content can be rendered from the file system or from strings, and URL requests (images or clicks) can be captured and served by the form's event handlers. CSS and JavaScript are supported, perhaps with some limitations.
# ...
self.webView.page().setLinkDelegationPolicy(
QtWebKit.QWebPage.DelegateExternalLinks
)
#...
class TotiMainWindow(QtGui.QMainWindow):
def linkClicked(self, url):
pass # events arrive here
Note: This question is different from this one and this one made before, among other things because there is no requirement to use web technologies on the GUI, but there is the requirement that the application should work without a network connection available, and should integrate well with the default desktop over different platforms, without previous infrastructure requirements (no .NET, Java, browsers, or database servers).
Note: I posted a different version of this question on PMS but found very little experience with this approach there.
Closing Note
I just found most of the information I was looking for in a series of blog posts by André Pareis.
I think the largest advantage to using web markup like HTML/CSS and other web technologies is that desktop apps may very well have their days numbered.
As we speak, Google engineers are working on the Chromium OS, which essentially consists of a single GUI application... the browser...
Now, while nothing may never actually come of it, there is clearly a rising trend in the number of applications accessible through a web browser, accessible anywhere. It seems to me that this is the future of application development.
By using these technologies, this becomes one less headache you have to deal with when or if you determine that your app should be available as a web application.
Update: A few years ago, we developed an Agent Desktop for our call center that is essentially a local application that opens sockets to integrate with the phone system. The user interface the agents use is built with HTML, CSS, and JavaScript, and the experience is stunning. When we released our latest update in 2010 with a professional CSS redesign, our agents were all very impressed with not only how easy it was to interact but also how easy it was to use.
In the future we will port this 100% to the browser, but for now it needs to be a local application because of the COM integration with the phone system.
We did exactly this for a project back when Windows XP was new.
This gave my team several benefits:
A good-looking UI with relatively little effort
Easily change the style of the UI in a consistent manner using CSS
Relatively simple integration with C++ (invoking functions from the ui and vice versa)
The drawbacks we saw were:
Some not-so-good firewalls considered accessing internal resources (ie other html pages in the ui) to be a web request
Adding and accessing the needed resources could in some cases be a bit cumbersome
It was possible set properties in Internet Explorer that would prevent JS from running in the application
Note that some of Windows XP:s programs are using this approach.
This probably works best with small, more Wizard-like parts of the ui (which our ui consisted almost entirely of).
I have since then not really been involved in ui projects, so I cannot really tell you whether this approach is still valid... I know that MFC-based applications will let you use HTML-based dialogs though.
In a similar situation in 2005 I created a stand-alone webapp using XForms, CSS, JavaScript, XML and XML Schema for offline data retrieval and verification. With a good XForms -> HTML + JS transformer (Chiba) it did the job with no bug fixes after the initial release. It was used for 6-12 months (IIRC) by about a dozen engineers for a project gathering test data in the tunnel of the Large Hadron Collider. The biggest surprise of that project was just how much you get for free when going for a web platform, even for offline use. Highly recommended.
The major problem is that it reduces your development speed, or the quality of your user interface. A lot. Unless you're using Seaside, it is much faster to develop a desktop app.
There is quite some number of applications built on top of Mozilla platform. It isn't 100% web technology, as instead of HTML you use XML based XUL, but the rest is indeed web stack (JavaScript, CSS). The most successful of these it the OpenKomodo and it's commercial big brother Komodo IDE.
On the other hand, as far as Qt goes, the newest version 4.7 you can build GUI using QML language. Don't let the name mislead you, it's not markup, it acctually JavaScript with app-specific extensions.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
Has anyone had experience with developing web apps using ClearQuest? Looking at the features, it mentions process automation but I'm not sure how large of a process/application it can support. Our group gave up a small section of a larger application to another group that used ClearQuest to web-enabled the process but now the ClearQuest tools are being pushed on us to web-enable the entire application. I have a ASP.NET background but ClearQuest is very wizard like and the only code that I've seen is called "BASIC" and it looks a lot like VBScript.
Clearcase/Clearquest has decent integration with Rational Applicaiton Developer. I am not sure if you arsking about its strenghts or actually exposing ClearQuest to the web. You can do the obligatory and lame activity of writing CGI/PERL scripts to expose some of the features to the web. You can use perl or VBScript to write CC/CQ hooks. It has its own perl build included in the product called ratperl. It has fantastic command line support but it comes at a price of complexity. CC/CQ is very powerful provided you think about the implementation in your organization very carefully. It can support very powerful work flows and is highly customizable.
There are several APIs which allow you to do what you want, write a WebApp.
CQWeb itself is built using the CM API, which allows a Java application (web or non-web) to be build. A tutorial is here:
http://www.ibm.com/support/knowledgecenter/SSSH5A_9.0.0/com.ibm.rational.team_api_cq_tut.doc/topics/teamapi_cq_abstract.htm
You could implement a basic web application using perl-CGI, since CQ has a Perl API.
You can write an ASP/C# web application because ClearQuest has a OLE (Visual Basic) API. The original ClearQuest Web application was built using the Visual Basic API
So the answer is yes, it is possible.
Wouldn't it be nice it supported a JavaScript API? Then we could write nodeJS CQ applications.
Sure it's possible, for a VS style integration I would either wrap the cqole.dll or use the OSLC connectors to get access to the RESTful interface. While the cqole is the C++ API and it is not officially supported this will suite you better than trying to implement this with the VBScript API. If you are more comfortable with just using the web services I would check out jazz.net where the wiki explains the bridge in gory details.
You dont exactly develop webapp with ClearQuest, CQ is only a process automation tool that build on logic and state transitions, and the interactions are scripted in either VBScript or Perl.
However do note that it has always been a pain to manage CQ codes as the "Designer" itself is a completely broken tool. It supports version tracking but doesnt tell u the difference between versions. The built-in code editor doesnt have syntax highligting, and it doesnt support parallel development. I can go on and on.
In the later versions, (version 7 onwards I supposed), CQ comes with eclipse based client AND designer tools, which supposedly enhance the whole experience. But I dont have too much experience with it to comment.
As for the web component, it runs on the websphere layer and simply is a application/presentation layer for users to access CQ through a HTTP protocol. It has 90% of the features of a full CQ client, and is usually easier to maintain and deploy to a wide user group.
Check out http://open-services.net/ for information on development using Open Services for Lifecycle Collaboration.