i'm starting to develop a web application for which I need real-time capability. In particular, as result of a server-side event (without client request), the client must refresh the view. The best solution seems to be a websocket communication.
My doubt is mainly between Node.js and JavaEE 7. Which language do you recommend for development? And with which framework?
The main requirements are:
Interoperability with browsers
Support for mobile devices
Availability of tools for the creation of the graphical interface
Thanks
The question is a bit broad and leads to opinion-based results - that's why it is likely to get close votes, so don't be surprised if it happens ;-)
Nevertheless, I would generally state, that "web application" and "real time" won't work together, because you have components like the network or containers in between which you don't control and thus cannot guarantee real-time requirements.
But I assume, that you are more looking for an "instant" reaction, so that your clients get informed instead of having to ask for something. In that case, web sockets are the state of the art for doing so.
Regarding technology selection, I don't think one is better than the other, it is more a question about available skills or your general programming model or customer requirements. I would think you can perfectly use Java EE 7 for that.
As a reference on that topic, I visited Adam Bien's workshops last year and he talked about an example, where he had a huge number of clients which communicated with a Java EE app server using web sockets.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to develop real time web application like chatting & real time message conversion. I searched the internet and got confused with few technology
erlang ejabberd nodejs openfire
Right now im in java domain but won't hesitate to learn new things. So can anyone explain what is these technology in a very simple words and what technology i will need to achieve my target ? Does all these do the same thing ? and new technology suggestion from your side will be appriciated.
These are entirely different things :)
At the lowest level you have:
Erlang/OTP is piece of technology, that lets you built low latency, fault tolerant systems. It includes Erlang programming language, Erlang VM and OTP, which is set of patterns, libraries and good practices for writing those systems.
nodejs is a platform, that lets you code JavaScript on server side. It makes your life a little bit easier, when dealing with events, but Erlang is still better saving you from callback hell with actors and messages between them.
At the higher level you have xmpp:
xmpp is eXtensible Messaging and Presence Protocol. This is great for implementing chats like facebook chat, but because it is extensible, you can use it for any kind of messaging.
ejabberd is implementation of xmpp in erlang. There is also fork of ejabberd called MongooseIM. Those will give you great start at developing your messaging application. They implement not only basic xmpp, but also couple of extensions (called xeps in xmpp community).
openfire is solution based on xmpp, so it is even higher level. For chatting and message conversion, this might be overkill, but it depends on your specific needs.
Totally an opinion post:
Erlang: Doing this from scratch with yaws and Erlang is the most straightforward way (its even a code sample in "Programming Erlang" 2nd ed.).
Ejabberd is famously undocumented (and overkill for most webchat services), but it and its better documented/saner cousin (MongooseIM) are robust and already written.
node.js is a cosmic joke played on monolingual ex-frontend web developers.
I've never heard of openfire.
None of these things are bad to learn -- but that's because nothing is ever bad to learn (though some things aren't worth the time you would spend learning them).
The basic problem, I think, is that your goal is probably more broad than you realize, at least in terms of methods by which you can achieve the goal of "develop a web-based chat and communication service". There are a hundred web servers out there, each with its own way of doing active content service, each with a hundred more back-end plugins to a thousand more chat/conversation/comments/blather service frameworks. Any given "technology stack" will often involve a dozen languages throughout it (consider service pages written in PHP from an Apache server which proxies to a Tomcat webserver for pluggable content which calls out to a tiny scheme chat service which stores data in Postgres...).
The situation with most web stacks is, in my opinion, laughable. That is at the core of the Node.js idea, actually: pick a language most people know and stick with it throughout. The problem there is that not every language is well suited to every task (or any task...). But the basic idea that cutting the web tech clutter down is quite sound.
That said, I sincerely think the easiest place to get started is with a relatively tiny language with a small, hyper-knowledgable community around it, and focus on doing everything you can in that language. For this particular task (live web comms) I prefer Erlang and Yaws, writing the service from scratch until some element of it obviously is in need of some pre-written framework treatment. (That is not the right choice of tools for everything, though, so keep an open mind and learn to hate every language, at least a little -- they all suck, just some less than others.)
I've got an app that's been started on the Microsoft stack as a smart client (notionally WCF/WS enabled) with a small client app that gets deployed and the rest of the app running in our private cloud. It's only real dependency is internet connectivity, .net 4 and a windows operating system.
I am under pressure to convert over to a browser based architecture for all future development. Based on other web apps I've worked on, I'm concerned that the way that client IT organizations can control the browser, it will cause more problems down the line than what I really want to deal with.
Do you have experience making this kind of decision? What technical factors did you consider when deciding to go smart-client vs. browser? What resources were helpful in making this decision?
My app is a healthcare app targeted at healthcare providers (eg. hospitals), so everywhere I go, I have to worry about the Healthcare CIO looking over my shoulder.
Interesting. Originally I'm from C# winform and WPF Desktop programmer, and later being assigned to do web development. Haven't touch Smart Client yet but I think it should almost be the same with Native app. Based on experience, the technical things to consider are:
Multi browser support
Especially for reporting and graphic processing, without some library / plugins / framework for your component, it will be insanely hard to keep your app multibrowser. Especially in css style and less in javascript.
Client programming(javascript)
You will lose the ability to create controls and animation using C# controls. Instead you must using javascript (jquery or other library) in exchange. Javascript is not fully OOP, and intepret language (no compile error), making it harder (maybe there is some framework like coffeeScript which I haven't yet explore). In addition, it is harder to make since it will need server request / response activity in between the process, which I will describe later.
Request / Response Client-Server Architecture
This means that most process in client will need to request for the server (request for data to display, request to modify the data, etc). It also means that you lose the ability of control event, even if you use asp.net webform (it still need some tweaks for the event to work). However I assume you already used the WCF so this kind of architecture must be that hard.
Security
Don't keep important information such as password, etc in client (hidden field, javascript variable, etc). The concept should be the same with multitenant client, however in browser, user has free access to debug your webpage.
Concurrent and Multithreading
In browser, it is easier for multitab page and concurrent process will be very highly to occur. Your code must able to handle the multi threading for client side. For server side, you can still use your WCF to handle concurrencies.
My 2 cents.
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.
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!
I am looking to develop a browser-based front-end/client to what is essentially a database-like back-end/server.
The server application will need to access some local hardware I/O and will be logging events to a database (or even a fixed format text file).
The front-end needs to display real-time status of the remote I/O, as well as be able to browse the event log by date. This means that the server will likely need to be able to push to the client as events happen or status changes.
My background is in embedded/firmware, assembly, C/C++, and I have done a fair bit of work with Windows/MFC clients providing UI to devices via TCP/IP, UDP, and serial connections, but I don't have any web based experience.
The number of choices for web development these days is overwhelming, so I am really looking for somebody with experience to point me in the right direction for which technologies/platforms to consider researching. (ie. AJAX, ASP.NET, NODE.JS, Javascript, PHP...)
I suspect providing the information to the front-end will be the easier part, and that the back-end will require two parts (one app/service to interface with the hardware and create a database/file that the other part can access and serve to the client).
What tools/platforms/technologies would you recommend to tackle this, and why?
Any advice is appreciated. (Links to references/tutorials also appreciated).
Thanks!
I would recommend looking at the ext.js framework. This is a client-side framework that is server agnostic that can greatly speed up development. Being a client framework it is based on JavaScript an can talk via AJAX with JSON/XML to server-side systems. It offers a very rich and professional experience and wirth the $595 price tag.
You build most of your application client-side and it can works with almost any back-end. The engine is fast enough to display real-time data and has a strong developer community.
I've been developing web apps for over a decade now, all the way from CGI to ASP.Net and Struts+Spring+Hibernate. The prevalent architectural style seems to be server-assisted MVC, e.g. Struts, Ruby on Rails, etc. Recent developments lead me to ask if these are on the decline.
Adobe's AIR and Flex
Microsoft's WPF and Silverlight
Google's Chrome and Gears
SOFEA and SOUI
All of this leads me to believe that we're starting to come full-circle after a 15-year distraction kicked-off by the invention of the web. Over this period of time, we've been so fascinated by all the web has to offer that we didn't notice that the usability (and the developer experience) of web apps pretty much sucked in comparison to desktop apps. It seems we're now saying "Screw this! We love the web's benefits but we also want better usability, offline capabilities, and better integration with the desktop!".
All of the above mentioned developments seem to be moving us in this direction of putting the presentation logic back where it used to be: the client. Don't get me wrong, I don't think server-assisted MVC frameworks are going away anytime soon, but I do think they are on the decline and RIAs and RDAs are on the rise.
So, what do you think? Are server-assisted MVC frameworks near their peak?
I agree, to a point - we are becoming are more client-centric, but I think this is because the clients are actually advancing in a standardized way.
We started out with everything on the client - because thats all there was. Then it was client-server, which separated the two, then gradually the client bit was thinned out and pushed back to the server, for one reason:
clients sucked (win95, macos<10, unix X11), and deployment was a nightmare. Deploying a browser was trivial.
Thats changing tho. Air is an easy install, as is .NET 3.5. Air apps are easy to deploy (click here - say yes!) as is a WPF Click-once app. The network is now a defacto part of the environment, not something special that had to be added. A database is something you can embed into a silverlight app (SQL Server Compact Edition), or an iphone (SqLite), not something you have to have a big server for.
and everything has auto-updating, which makes the post-install story a lot better.
I dont think they are on the decline - I think the logic has just been pushed out again, and it'll be pulled back in the future, only to be pushed back out etc.
Silverlight/Air/Flash etc are all very powerful, but HTML + Javascript, which is the basis of the server MVC frameworks, has come forward massively, esp if you ignore the b'stard that is IE6.
Regardless, I'll still be writing the backend for RIA's in a server-assisted MVC framework, even if they are throwing out JSON, not HTML. So while they are no longer the be-all, they are far from dead (or peaking)
Lets clarify something!
MVC is only a design pattern for the seperation of concerns. There is no really relation to server side frameworks.
There is no technical Web 1.0 or Web 2.0 ... JavaScript and Flash were there for years. It's only about social networking, tagging etc.
The server side frameworks are not dead at all. I agree with Nic Wise in case of the bad client architectures/rendering. Can you print a HTML page (every time in the same way)? No, you can't, because every browser(-engine) has it's own representation your HTML description. Only because JavaScript/Flash... are restrictions for a lot of people/companies, the server side processing will stay there for a long time.
Developing "Run anywhere" JavaScript has been a burden for a long time! Nowadays we have Frameworks like JQuery which do this job for you. I've written my own homepage in JavaScript, using EJS (Embedded JavaScript) for the templates/mvc. The old bloated JSP/PHP pages have shown, that differing the business logic from the design is a really good thing.
A bad problem of every web application is to decide, where you save the state of the application! If you choose a bad way, you are not able to scale. Client centric frameworks with service oriented backends allow you to scale very good.
I have been working a little bit with SOFEA/SOUI. If you have an ready framework stack for the most common problems, you'll love it.
Air and Flex are nice, but they bring in a lot of restrictions (Flash/JS...).
Google's Chrome and Gears need you to install Google software at your computer. Who has Gears around here? Gears hasn't established as a wide distributed standard.
If you have experience with Hibernate/Spring and Struts, you sould try Grails! It is nice to develop GWT/FLEX&AIR/SOFEA&SOUI backends and also for the good old server side HTML rendering.
I like SOFEA/SOUI because it isn't such invasive, it offers an investment protection (SOA services) and high rate of reusability. It's also a nice way to move the load from your server to the clients.