It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm new to StackOverflow. I've searched about the topic, but I did not find anything really relevant.
Basically I need to develop a web 'Support Chat' system for our company. I know that there are a lot of available solutions out of there, but we need a custom solution in Java. We need to build a Support Chat web system where users that visit the web site can ask for support using the chat, and on the other side we have 'n' agents that take care of requests. We need to store each bit of conversation in our Cassandra cluster for Business Intelligence purpose. We need to develop the solution in Java (server side) and JavaScript+JQuery (client side).
EDIT:
After examining many XMPP based solutions (many are pretty old and no longer supported), probably I'll go with a XMPP-like custom protocol that covers only the features we need. To develop the solution WebSocket seems to be the most appropriate technology.
The question is, where to start ? I googled but nothings or less about how to use WebSocket with Jetty. Any link? Any resource?
Basically my thought is:
A CHAT SERVER based on Jetty Embedded
A small front end for the web applications (JQuery) that needs to talk to the server.
Communication is based on WebSocket to avoid polling (the real problem)
The XMPP-style protocol for XML over WebSocket. But this is not the problem.
The problem in how to use WebSocket with a Jetty emdedded custom server and web application.
ADD
As many have pointed out, WebSocket is not well supported for a general purpose usage. Instead AJAX is a more natural solution, but this implies the usage of polling. I've found some example on how to circumvent the problem with long polling, but I was unable to find a rock-solid implementation based on JQuery that was able to:
Use WebSocket when available
Otherwise, use JQuery-based long polling
I think that now the question is more clear. Sorry for my previous 'talk about' style question.
I have used Atmosphere Framework (https://github.com/Atmosphere/atmosphere). They provide several chat-related samples here: https://github.com/Atmosphere/atmosphere/tree/master/samples
I would not suggest you to require Websocket for a support system, because there are plenty of people who use Internet Explorer which does not support it yet and likely will never support it on Windows versions previous to Windows 7: http://caniuse.com/websockets
You said you want to use "Java+JQuery" on the client-side. Are you sure you aren't confusing Java and JavaScript? These technologies have as much in common as Iced Tea and Long Island Iced Tea.
When you really want to use Java, you needn't use WebSockets, because Java applets can communicate with a server using normal TCP or UDP sockets.
When you mean JavaScript, I would recommend you to create a solution based on AJAX, because it's much more widely supported and you don't need the real-time performance of WebSockets for a chat application.
You might want to check out the Fastpath plugins (Service and Webchat) for Openfire. This is an XMPP based solution that is intended to support your use case. It is open source and Java based, so you can easily extend it to suit your purposes.
There is also support in Smack for Java client based solutions (under the workgroup package).
If XML usage is not a requirement, I would like to suggest Bristleback Server. You can choose Jetty as the WebSocket protocol engine. Currently Bristleback uses JSON as messages format so this might be a limitation for you. Using Bristleback you can easily define recipients of the message, and everything is done without using low level WebSockets protocol components. Client side (using jQuery) library is also provided. On our website you can find some samples and tutorials (constantly expanding).
Full disclosure: I am one of the co-creators of Bristleback Server.
Related
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
I'm working to learn some good frameworks (o set of frameworks/languages) for to build some RIA java based, not exclusively business-oriented ones. I'm at my start so excuse me for so general question.
Actually I've spent some time on GWT, and i like that philosophy. Problem is Java 8; I'm working with Java 8, and there is an incompatibility with GWT; I know is only matter of time to be resolved, but in the meantime i'm working around.
Now, I've understood (?) that GWT is the best for to build client-side RIAs but lack somewhere in the server-side aspect, and it probably need to be reinforced in some way. But what's means "reinforcing"? what can be the "good partner" server-side for GWT?
I've gived a look at Vaadin, but i don't like so much that philosophy: the Gwt idea to spare the elaboration load from server and client is winning, in my opinion, while in Vaadin, if i don't understand wrong, the elaboration is almost only server-side.
Now the question is: what is the best 2014 practice road?
Only GWT ? GWT + server side add on's (and what addons?)?
Vaadin? Or something different?
I think you must consider what you wish to do.
If you wish to stay with java, then a GWT based solution is great.
GWT gives you many features and not much hassle with javascript.
If you need only client side application with not much server interaction this is a good choice.
Of course you then need a server-part of your project.
Vaadin commes in, when you anyway have a server side solution,
with much businesslogic, datalayers, background jobs etc. etc.
Or when you don't wish to write GWT stuff yourself. (You still can if needed)
Your business logic is running on server side, the communication with the webbrowser is secured agains usual web exploits/attacks.
(You would have to implement them yourself when using a own or xml/json based protocol)
Vaadin integrates client+serverside, without the need to hassle with GTW or Javascript.
So:
For projects with no (or not much) server side code (Business layer)
go for GWT
For all else go Vaadin
In my current project (trading terminal) we are using GWT with interop with server side over web sockets. It is fast, tiny and allow interact in both directions.
We used custom protocol but you can use Protobuf for serialization/deserialization on both sides. Web sockets are not supported on old browsers.
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
I want to start to make a chat client that runs in web browsers, upon a colleges requests. Its my first time doing something like this, so i made some research about this mostly about HTML5. I did research on the platform itself, how fast and how used it is, but my most important factor was: mobile support
I plan to develop this chat for a long while for experience because, as a coder/programmer I am still inexperienced.So i was thinking in the future as well. i have a forum community with pretty limited chat access. I want to change that as well, and as an extra include mobile support.
i researched Flash, java and HTML5, the two most obvious choice in web applications, and pretty much the new comer HTML5.
Flash is more widely used as web app(at least what i saw and found.), and its more designer oriented than programmer, but many chats are written in this, and are used. but there is no mobile support for it, to my knowledge. thats hinders my future plans.
Java, is a robust programming language, and saw a few webchats in this, but my main issue with this is performance: its much slower than flash. But at least there is mobile support, at least the android mobiles.
as for HTML5....its pretty much still a child, not all web browsers support it fully but the major ones support web socket already, except IE9. and IE9 is the most used web browser, sadly. And i cant find any support for it on mobiles yet.
And i don't know any other platforms out there in the Internet that could do the same as the above three, but i'm open.
So my question is: Which is the best platform for writing a webchat, that lest me do mobile support at a latter stage?
No, the correct answer is: Understand which method is quick to deploy, cost-effective and easy to learn. You'll need to integrate languages to make this work. HTML 5 is the latest and greatest, that's one. JAVA ~ still in demand on the Android side..learn it..
Flash is dying..don't learn that.
Windows ~ .NET..don't count this out...Microsoft is planning on coming out with a mobile platform...this is still good to learn..always learn a language that's going to give you job opportunities in the future.
You cannot write a chat in HTML 5 alone (because it operates on the client and there needs to be server code), you would need PHP or JSP for that.
I wouldn't use flash except if you are already very proficient in it because:
it needs an extra plugin
it frequently blocks or crashes some browsers
I think it is difficult to develop and I am not sure if the development software is free
So my choice would be Java Applet by default. It needs an extra plugin but it is much more stable than flash and you need it for many applications anyways but it has so much functionality that is very easy to make a chat with it.
P.S.: Java's speed is absolutely no problem for a chat. Java is maybe 10% behind C++ depending on the application but we are talking about languages like Flash or PHP so Java is not slower but it doesn't matter anyways because a chat has next to no resource requirements.
The correct answer is: it depends. You can implement such a program using many technologies. Each of these technologies have different characteristics and pros and cons but you have mentioned that this is going to be made for a university task. This way i recommend you to choose HTML5, this is a quite new technology, i think it worths it to have a little experience in that!
If you want to have the least work with this project, you should use java.
This is MY opinion.
You should have a look at nodejs:
http://nodejs.org/
Also the socket.io module for nodejs which allows you to use websockets as a transport mechanism for capable browsers and provides fallback methods for older browsers:
http://socket.io/
There's a node and socket.io chat tutorial which might be helpful and a working chat demo based on node (though I couldn't see any reference to socket.io when I reviewed the code).
I would not discount using Flash. It is still an industry standard in web development. It is way faster than a Java applet, but you are right, Java is not going anywhere. Flash allows you to deploy your project to the web, stand alone application on Mac and PC, and on mobile.
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 9 years ago.
Improve this question
I want to create simple server having low load. The goal is to give a few javascript clients access to some functionality implemented in Java through WebSockets. I seek for best library to use for that - it should be simple, robust etc. Now I consider 3 alternatives
- jWebSocket
- jetty
- netty
What is the best? Or may be something else?
Thanks in advance
I'd go with proven Java servlet servers: Jetty or Resin. The have both been extended to handle WebSockets:
Jetty WebSockets
Resin WebSockets
My personal choice would be Jetty, as it's very simple to use and I've been using it as embedded server in several projects.
There are also some new kids on the block like Atmosphere and jWebSocket, but for servers I prefer to go with a proven solution. Jetty and Resin are also generic Servlet servers, so you can go with one product for all your serving needs.
jWebSocket now includes the Jetty 8.0 engine including SSL and includes many nice-to-haves on top of it. It provides cross-browser and cross-platform compatible clients even more mobile apps e.g. under Android, Symbian and BlackBerry. The server can easily be extended with plug-in and already includes lots of them (e.g. for Authentication/Autorization, JDBC, SMTP, XMPP/Jabber, RPC, Twitter, Filesharing, Chat etc.). Just check it out... http://jwebsocket.org. Looking forward to your feedback.
Regards
Alex
The PlayFramework! is the other very good option.
FYI, Atmosphere run on top of Resin, GlassFish and Jetty. Atmosphere free you from being stuck with one server by giving you Websocket portability amongst Websocket server. It also offer a client library that can be select the best transport in case websocket isn't supported by the browser. So you can't compare Atmosphere with Jetty or Rsin
Take a look at Atmosphere. Here is an article about websocket and atmosphere.
While I value the implementations of JWebsockets and Autobahn a lot, I prefer Atmosphere.
Ramp-Up::
Ramp-Up time is low. Francois Arcand puts a lot of effort into testing and examples, helping everyone to achived quick wins. (And I have no clue why he's able to respond so quickly to any architectural questions I rise. Impressive.)
Maintenance Perspective::
To me, maintainability is fundamental, if a software goes beyond major release version 1.0.0. The project is maintained at a top Maven-POM level with a properly constructed hierarchy. It prevents library incompatability. Libraries are reference at the correct level. That is well done.
Technical/Functional Perspective::
It offers a Java SE client library (wasync) that can either do native websocket communication (onMessage) or build on Jersey REST annotations (#Path). Subsequently this makes it as simple as it gets with the benefit of maintaining an open connection for subscriptions and the popular remote procedure calls (RPC) paradigm. It is a common attempt to merge those two paradigms. See also http://wamp.ws/, which heads for the same approach. Also, the library offers to establish QoS properties like robustness (e.g. in case a client disconnects) and reliability (caching undelivered messages). That is great for professional software to harness.
Maybe you should try Bristleback Server? Using Bristleback, you may choose from several WebSockets engines, like Jetty, Netty and Tomcat. You can have standalone server as well as web application that uses WebSockets (Jetty and Tomcat 7). Bristleback uses Spring Framework. If you have worked with web frameworks like Struts, Stripes or Play!, it will be very easy for you to start. Of course, Bristleback has its own JavaScript client library for even easier development.
Full disclosure: I am one of the co-creators of Bristleback Server.
I would also add vert.x to the list. It can server Websockets and SockJS (websocket emulation when the browser doesn't support them).
Update:
Undertow http://undertow.io also supports websockets.
Follow my blog. I'll be ready for release sometime in the not too far off future. Light-weight has been emphasized through the whole thing - but it's also fast. I don't know yet how well it will ramp up to higher loads. But I've been running the demo for a while now with relatively low load and what I have has been working well. (I'll test heavier loads later and make sure that it can be ramped up.)
http://highlevellogic.blogspot.com/2011/09/websocket-server-demonstration_26.html
If you are looking for infrastructure around message management, user grouping ("rooms"), and data synchronization ("shared variables"), you might want to consider Union Platform:
http://www.unionplatform.com
[Full disclosure: I am one of the co-creators of Union]
Why don't you just write your application on an open standard like JMS, and let the clients sit on the JMS bus as message clients?
The whole point of websockets is to bring any native TCP protocol directly to the client instead of converting it from your back end to http request/response.
Your back end services would talk to a JMS broker like ActiveMQ, and your clients speak AMQP in the browser via a Javascript API that looks just like the JMS API in Java. All you need for that is a websocket gateway, for example Kaazing has such a gateway, all it does is route your JMS TCP traffic out to the web clients over websockets. They also provide fan-out so that you don't overload your JMS bus, i.e. you just use a handful of connections to the broker to offload a million browser client connections.
The bottom line is that you don't need to tie yourself to any specific platform. Stick with standards, that way you have 100% freedom to swap out components as your environment changes.
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 9 years ago.
Improve this question
What's the best method for performance testing Flex applications with a BlazeDS/Java severs backend. We're looking at JMeter but can it be used with the amf the protocol at a more sophisticated level where values in a request can be manipulated?
My Company (UBIK-INGENIERIE) distributes a commercial Flex/AMF Apache JMeter plugin.
You can easily record, variabilize and replay FLEX/AMF based application with standard knowledge of Apache JMeter.
See a tutorial on it:
Performance testing Flex applications
https://www.ubik-ingenierie.com/blog/load-testing-flex-with-jmeter-made-easy/
https://ubikloadpack.com
We are having the same issue. I will definitely look into www.gorillalogic.com for our site.
Another option (which we overlooked) was choosing LiveCycle Data Services ES2 instead of BlazeDS. While BlazeDS met our functional needs, LiveCycle comes with a Load/Stress tool... something that we really could have used.
Here is the comparison chart:
http://www.adobe.com/products/livecycle/dataservices/compare.html
Try Neoload
http://www.neotys.com/
(haven't checked it yet myself to be honnest, but I will do it soon)
The "Java AMF Client" API might help you here. It's a Java API for building and sending AMF requests to the server.
http://opensource.adobe.com/wiki/display/blazeds/Java+AMF+Client
I've also heard good things about Gomez but I believe it's a pay service and will require some overhead to get up and running. But if you're looking for a more comprehensive solution, many people in my company have used it on projects with a Java / BlazeDS backend.
http://www.gomez.com/
Neoload will cover LCDS, BlazeDS, JBoss, WebLogic, WebSphere, PHP, .NET
We chose it as our tool for testing a Flex app after looking at several options.
You can alter the requests and pass in any variables you like. Very easy to use but it's not free.
I have tried both NeoLoad and LoadRunner. We had more success with LoadRunner. The only problem was that we had to manipulate the LoadRunner configuration of the generators (including the machine we scripted with in vugen) to allow enough memory to handle the massive requests that Flex made. We were able to run far fewer vusers on generators that tests Flex than those that tested http since each vuser used more memory. It was about a 10:1 ratio or fewer.
Currently, there is no perfect solution for amf encode/decode in JMeter.
Something you can try:
Find a programmer (good at Java) develop JMeter plugin for amf
encode/decode, according to our experience, it is not hard and our
plugin works fine in the following projects. the plugin should be
able to decode AMF request when you record request by proxy and easy
to customize the parameters within the request.
Use the charles record the amf request, and attach the data package
in JMeter http sampler. it works when the app is not complex.
Use loadrunner or other commercial software if you can afford.
The best answer for automated testing of Flex application is FlexMonkey - www.gorillalogic.com
The tool is open sourced, can be used in CI environments, has over 5,000 users and is supported by Gorilla Logic (Jave, Flex and mobile development consultants).
Check it out and if you would like more information or a demo, let me know.
Chad S.
Gorilla Logic
I want to create a webservice that allows users to enter the longitude and latitude for a particular building. Buildings will belong to a broader category called a Region. If a specific building does not exist in a region the user could add the longitude and latitude data through the webservice. Similarly if a user finds data to be inaccurate, they could update it.
This webservice would not need to have a web front-end only a RESTful API that would only be accessible to my application(s). I want the webservice to be able to accept new and updated data (as described above) and also print out relevant data (in xml format) based on the appropriate API calls.
I need to ensure that this data would be secure - i.e. nobody would be able to gain access to the data i have accumulated.
What is the best way to do this? I have familiar with client side Java and not much server side technology (not familiar with server-side Java, rails, django, etc...). What language/frameworks should i use that would accomplish my needs with the shallowest learning curve?
You can just use basic authentication (username/pw) with ssl enabled. That way you are encrypting the connection and providing a broadly supported means of authentication. I believe apache Axis will take care of most of it for you.
I've used the Restlet framework to deploy web services that are password protected. It supports basic authentification and several others out of the box. You can also set up your services behind an https "server connector".
Another approach is to run your application in a Java EE application server which supports JSR 196 (eg, Glassfish or JBoss). You would then use the server's facilities to establish the authentication.
Here is the Glassfish security page.
If you have never programmed server-side code you will be facing a pretty steep learning curve, I'm afraid. If you are comfortable with Java then the Restlet framework mentioned by another commenter is a good choice. It is easy to use, includes both client and server tools, and has pretty decent documentation. The video screencasts are very good.
Another option is Ruby on Rails. I am currently implementing something very similar to what you are planning and Rails has worked extremely well. Rails has built-in support for XML output through both the ActiveRecord class and XML Builder templates. I used Atom Authentication (http://www.xml.com/pub/a/2003/12/17/dive.html) between the client and server and it is working beautifully. There is a learning curve for both Ruby and Rails but the power of the framework makes it worth it. I am partial to the Ruby and Rails books at The Pragmatic Programmer but O'Reilly has some good ones, too.