Is it recommended to use hawtio as a host for several small user interfaces? What we have are a lot of discreet services performing fairly focused tasks each with it's own (angularjs) UI for configuration and management. A thought I had was that we might deploy each of these UIs so that they could be incorporated into hawtio where they would live on individual tabs.
Additionally we would want to have some kind of authentication/authorization to limit which tabs users could see. For example we would not want everyone to see the JBoss or Camel tabs but we would want them to see the UIs that we created for the individual services (and probably levels of authorization within them).
Is this even a reasonable use for hawtio?
You can build your custom distribution of hawtio, or turn off various plugins etc by providing a html file where you can turn off them in the various perspectives.
There is some examples how to do that at
https://github.com/hawtio/hawtio/tree/master/hawtio-plugin-examples/custom-perspective
You can build 3rd party plugins for your own apps and have them integrated as first-class in hawtio.
hawtio is designed as a pluggable web console.
Related
I would like to gather some metrics about usage for an Electron-based cross-platform desktop app. This would consist of basic information on the user's environment (OS, screen size, etc) as well as the ability to track usage, for example track how many times the app is opened or specific actions within the app.
These metrics should be sent to an analytics server, so they can be viewed in aggregate. Ideally I could host the server-side component myself, but would certainly consider a solution hosted by a third party.
There are various analytics solutions for the web (Google Analytics, Piwik), and for mobile apps, as well as solutions for Node.js server-side apps. Is it feasible to adapt one of these solutions for desktop Electron-based apps? How? Or are there any good analytics solutions specifically designed for use with desktop apps which work with Electron / javascript?
Unlike a typical webpage, the user might be using the app offline, so offline actions should be recorded, queued, and sent later when the user comes online. A desktop app is typically loading pages from the file system, not HTTP, so the solution needs to be able to cope with that.
Unlike a Node.js server-side application, there could be a large number of clients rather than just a single (or a few) server instances. Analytics for a desktop app would be user-centric, whereas a server-side Node.js app might not be.
Ease of setup is also a big factor - an ideal solution would just have a few lines of configuration to gather basic metrics, then could be extended as necessary with custom actions/events.
The easiest thing will be to use Google Analytics or a similar offering.
For most you'll have two major issues to solve over hosting on a website:
Electron does not store cookies or state between runs. You have to store this manually
Most analytics libraries ignore file: urls so that they only get hits from the internet
Use an existing library and most of these issues will already be solved for you.
Is this even possible? I have a logic application that is an unit of functionality (mixture of card connectors and API apps I created) that I would like to share among other logic apps. From what I can see, this doesn't appear to be allowed. If this is not possible, I am going to have to recreate the same cards in the logic apps I need this unit of functionality in.
You can definitely factor your Logic Apps in smaller flows that can be orchestrated and with the support of conditions and iterations you can do lots of powerful stuff.
Unfortunately today it is not as straight forward to leverage the "Action of Type Workflow" that we have in the system since the User Interface does not expose the capabilities you would want such as adding actions of type Workflow, editing the access keys, and the outputs.
I wrote a quick blog here that shows you how you can do that today using the ARMClient to edit the access keys and make it work:
http://blogs.msdn.com/b/carlosag/archive/2015/05/31/using-nested-azure-logic-apps-or-invoking-flows-from-another-logic-app.aspx
In my notes from the Logic Apps talk at Ignite I wrote that it is possible to nest logic apps. I don't have an example handy, but it might be worth skimming through the slides/video from that talk.
I am starting a new project. This will be a Java EE web application. The application will consist of 3 parts, each one having different functionality, but they all belong to one application. I am thinking of using the following architecture:
There will be 4 separate projects (JSF web applications). The first one will be responsible for communication with database and will expose remote EJBs. Let's call the first project "DataLayerProject". The other 3 applications, which I have mentioned above, will consume the EJBs from the "DataLayerProject" in order to communicate with the database. They will represent the presentation layer of the application.
In my opinion this approach will allow to maintain and develop the 3 parts independently of each other. This will make the project more scalable (in case there will be need to add another sub-projects to the main application).
Is this is a viable solution?
Should I use REST services instead of remote EJBs. (Sorry if I am misunderstanding something here)?
There will be the main page from which I will access the other 3 parts. The question is that I need to have single sign on for every application. Thus, by logging in on the main page user is automatically gets logged in the other 3 applications.
Should I use any portal solutions for making the separate web applications work together?
If all your applications are deployed on a single server, then you can use local interfaces for EJBs instead of remote ones and that would be the fastest implementation.
I believe that the mvc mini profiler is a bit of a 'God-send'
I have incorporated it in a new MVC project which is targeting the Azure platform.
My question is - how to handle profiling across server (role instance) barriers?
Is this is even possible?
I don't understand why you would need to profile these apps any differently. You want to profile how your app behaves on the production server - go ahead and do it.
A single request will still be executed on a single instance, and you'll get the data from that same instance. If you want to profile services located on a different physical tier as well, that would require different approaches; involving communication through internal endpoints which I'm sure the mini profiler doesn't support out of the box. However, the modification shouldn't be that complicated.
However, would you want to profile physically separated tiers, I would go about it in a different way. Specifically, profile each tier independantly. Because that's how I would go about optimizing it. If you wrap the call to your other tier in a profiler statement, you can see where the problem lies and still be able to solve it.
By default the mvc-mini-profiler stores and delivers its results using HttpRuntime.Cache. This is going to cause some problems in a multi-instance environment.
If you are using multiple instances, then some ways you might be able to make this work are:
to change the Http Cache to an AppFabric Cache implementation (or some MemCached implementation)
to use an alternative Storage strategy for your profile results (the code includes SqlServerStorage as an example?)
Obviously, whichever strategy you choose will require more time/resources than just the single instance implementation.
I am currently devising 3 database desktop applications for different users in a manufacturing company (one for the accounting department, sales department, production department). All applications have different functions but they should be able to access the data of the other department to reflect business transactions. What is the best programming language and database to use for this kind project? The three computers are not physically connected so I was thinking of having them to access a remote database. The language I am most familiar with is Java but I am very open to learning others if it would be more beneficial to the company. I was also thinking of having to use Adobe Air as I am adept with web programming but could still run as a desktop app but I can't seem to find sufficient resources of distributed systems using Adobe air. Any ideas would be very much appreciated. Thanks!
Lots of languages will do this just fine, including Java. You're familiar with that so my advice is stick to it with one caveat: depending on your requirements I would seriously suggest examining the possibility of making it a Web app instead. Desktop database apps are somewhat... old-fashioned. More to the point they'll create a bunch of headaches for you such as installation, Swing is annoying and tedious, etc.
As for what database, barring requirements you haven't specified, anything will do so pick something free like MySQL.
So for a desktop Java app I would:
Put the database on a remote server;
Put an application server or Web container on that same server;
Create a Webapp on the app server for handling RPC;
Pick a method of RPC, be it Web services or whatever, and use Spring to implement it;
Create a desktop Java app in Swing and distribute it to clients from the app server via Webstart (JNLP).
If it's a Web app:
Put the database and appserver or Web container on one server;
Pick a Java Web framework and create a bunch of Web pages that do what you want.
In all cases, have it be the same app but just act differently on the user type. This is much better than maintaining three different apps.
Also if you do a Web app, you might want to consider using PHP as it's a fast and proven way of knocking up Web pages and probably sufficient for the kind of internal application that you're doing.