Im newbie in java.
I want make a web application (like a remote controller) for 3rd party server(via xml api).
I think to make a java applet for user gui and a service for parcing xml to (and from) 3rd party server. Whole app will run on separate server with apache.
Is it correct way in general or i need change my concept?
And I need advice how to make communication between web user gui (applet) and service, that parcing xml, on same host? Through or make it in one application with different threads?
Applet? So 1998.
Web UIs in browser speak HTTP to web services now. Applets are NOT the way to go.
IF you deploy on a Java EE app server or, better yet, Spring Boot, all that threading stuff will be taken care of for you.
It's not for newbies. By all means attempt if you want to learn; get some help if this is real.
Related
I am developing a chat website that makes use of the Openfire XMPP server, with the client side using Smack API. The web project that makes use of the Smack API is implemented using the Play! framework making it RESTful. I chose Play! because of its Asynchronous Programming offerings (Comet Sockets/WebSockets).
Basically, my architecture, so far, is like below:
Openfire <-> Webserver <-> User/Browser.
In order to support Android devices too, and to maximize code-reuse, should I implement the XMPP client side code as a RESTful webservice that is common for both the web site and the Android clients?
Openfire <-> Webservice <-> Website <-> Browser/User.
Openfire <-> Webservice <-> Android App.
I'm afraid of scalability issues, because of the introduction of an intermediate web service? Would I be introducing latency in the communication as a result of having to go through multiple components?
Any advice on the above would be helpful. Thanks.
The key to scalability is decoupling. So in an essence you can think of the problem in terms of "If one of the components fail, will the other components continue to work normally?". In addition to avoiding end of the world scenarios you can also independently scale horizontally each component.
With that in mind lets now move on to your specific use case. Layers for the sake of layers are what still make me see nightmares about some Java EE architectures around. Not only does it introduce unnecessary latency, it also makes it harder to pinpoint a problem. If your service fails, was the failure caused by the web server, android application or the web service?
If you want code reuse, reuse code instead of duplicating components. That`s what libraries are for. Take your common code and extract as a library and use it in both the web server and Android application.
I think that the best it to make a light webpage that consumes directly the webservice (like any App) from the browser once it's loaded.
So the only difference between the App and the Webpage is that the webpage will be loaded by the browser each time the user access to it.
I am working to create a web app. Simultaneously I am also developing a REST web service that will use the same codebase...What I want to know is, can I make the same codebase on a server function as base for both the web app and the web service. (In the web app a user can log in and perform operations while the web service is like an API).
Or do I need to keep 2 distinct code bases for the web app and the web service?
Also, I want the same web app to act as both producer and consumer of the web services...Is this possible?
Yes you can. Technical a REST API is the same thing as the server side of a web application.
But if your REST API is accessed by third parties you might want to have a different versioning strategy then for your web app, so for anything of serious size I would probably separate those.
Sorry can't speak about the producer/consumer part of the question. Don't understand that part of the question.
You can do it that way, but it means that you'll have to deploy the two together. That might not always be desirable.
The alternative is to refactor the common classes into a third project, removing them from the app and the service. Package those into a JAR that you add to both the REST service and the app, just as you would any other 3rd party JAR. If you do it that way, you can deploy the two independently. The cost is maintaining the common classes.
Yes you can do both things from one codebase.. app and web service also, the complete game will be around URLs i.e. app URL and Web service URL..
And Yes it's possible, same web app to act as both producer and consumer.
I'm starting to study GWT now, and have a very general question, I could maybe teach myself with a little more experience, but I don't want to start it wrong, so I decided to ask you.
I always develop using JSF, having separate packages for beans, controllers and managedbeans.
However, as the GWT uses RPC, I will not have managedbeans, right?
So, GWT automatically handles user session for me, or do I have to do it myself?
What is the best package structure for the project?
It is best to use RPC, or create a webservice and access the webservice in GWT?
It's hard to host the application on a tomcat server?
Is there a test saying which server is faster for GWT?
Thank you.
However, as the GWT uses RPC, I will not have managedbeans, right?
True, GWT RPC uses POJOs.
So, GWT automatically handles user session for me, or do I have to do it myself?
GWT is pure AJAX APP - client code (normally) runs in one browser window (similar to gmail) and does not reload the web page. This means that the application state is always there - no need for sessions (as a means of saving state). You still might need sessions for user authentication, but this is usually handled by servlet container.
What is the best package structure for the project?
Three packages: client, server and shared. Client for GWT client code, server for server (also RPC) code and shared for POJOs that are used by both client and server.
It is best to use RPC, or create a webservice and access the webservice in GWT?
Go with GWT-RPC or (better, newer) with RequestFactory.
It's hard to host the application on a tomcat server?
It's straightforward: GWT client code is compiled to JS/html and is hosted as any static content. RPC server code is just Servlets - normal web.xml registration.
Is there a test saying which server is faster for GWT?
No clue, but IMHO does not matter, because most of the latency will come from database and network.
Also have a look at http://code.google.com/p/gwt-platform/
This framework is really great and follow all suggested best practices(e.g. MVP) by google and give you as well great support for gin, gwt dispatcher, website crawling, history with tokens, code splitting via gwt async etc.
If you want to set up a good project structure try to use the maven gwt plugin(http://mojo.codehaus.org/gwt-maven-plugin/) it helps you a lot with setting up an initial structure and manage your build process.
I'm really new to JSF but what I need to do is a webpage which can connect via JSF to database and show some statistics for given user and I know that JSF will do for such purpose.
What I'm worried about is that I need to write game server for turn-based game and my question is if this is common/good approach to include such server in JSF? Clients will be android devices so I will probably have to include some socket logic under whole JSF which will exchange XML messages.
At least thats how I see it.
Please let me know if my concept is valid or tell me what other tools I will need.
Yes, this is possible. JSF is great for building the web based admin or statistics pages.
But do note that the socket connections from the Android client to the Java EE server do not go via JSF. If it's simple turn based game, you could consider using REST calls to JAX-RS resources. These are very easy to create in Java EE (no config needed, just a simple annotation on a pojo).
So basically, your question is not phrased correctly. The game server is not build in or on JSF, but JSF makes use of some of the same backend resources.
Java Server Faces is only the framework for a web frontend and the communication or interaction to the backend. It's absolutely possible to write a little game server for android games with java ee.
As I understood your text the architecture is really simple: You've a client/server architecture and the server use the framework JSF for administration.
I think it's a good idea to write the server first and add the administration (JSF Part) later as component to the server.
I'm creating a prototype for a java web application.
Frontend is a Swing-based java applet.
Backend should be a type of web-service, that is called by applet.
Backend should run inside a servlet container and should have its own security (username/password) database. I know, that Tomcat has its own user database (realm), but the app should have own. Web-services, in turn, carrying out app logic and database access (via Hibernate).
I'm a newbie for a web development and I'm getting lost in a huge amount of the java web frameworks. Even just reading 'introduction' and 'getting started' documents takes a lot of time.
So I need an advice which framework(s) are suitable for the task and not very complex for a quick start.
Thank you
I would avoid any web framework in such case. Most frameworks are designed so that it is easier to connect bussines logic (backend) with WWW user interface. In your case you don't need web GUI - you have an applet, so web framework like Stripes, Struts, etc. would not help to much.
I think you can use servlet or several servlets as a connector between backend and you applet. Servlets are simple, easy to learn.
If you want to have some abstraction layer with additional services, like security, for instance, you can consider Spring Framework, but it has its own learning curve.
Spring (http://www.springsource.org/) seems like a good choice to handle DB access, and server side logic. Spring-security can be used to integrate security (it takes some time to get started, but it works very well). SpringMVC can be used to output simple XML documents, or if you need more complex remoting capabilities, SpringRemoting is a good solution.
If you want to go the full WebService (with a capital W and a capital S) Spinr-WS can be useful.