I have my own application server ( like oracle weblogic ) which handles HTTP request.
Now what changes required in my software to make it cloud ready.I was searching on the net and got one multi tenency documents.
what are other aspects in which i need to look into.
None, EC2 should act like any other web server. You still have the added overhead of maintaining the open ports and the like through Amazon's interface as well as on the server itself, but in terms of actually running a web server, it should be exactly the same.
In terms of multi-tenancy, again this is just down to your database architecture which RDS should take care of (if you have a tenancy key).
Related
Context: I'm working on Spring MVC project and using Hibernate to generate database schema from my classes using annotations. It uses MySQL server running on my local machine. I'm aiming to get hosting and make my website live.
Do I use mySQL server of a hosting provider in that case to run my database?
What are the pros and cons? Would they normally do db backups or its worth to do that myself and store it on my machine?
Am I going to loose data in case of server reboot?
Thanks in advance. I'm new to this, hence feel free to moderate questions if it sounds unreasonable.
Much of this will depend on how you host your site. I would recommend looking into CloudFoundry which is a free Platform as a Service (PAAS) provided by the folks at VMWare. If your using Spring to setup hibernate, Cloudfoundry can automatically hook your application into a MySql service it provides.
In any case, your database will most likely reside on the hosts server, unless you establish a static ip for your machine and expose the database services. At that point, you might as well host your own site.
Where the data will be stored depends on the type of host. For instance if you use a PAAS, they will choose the location they store your database on the server. It will be transparent to you. If you go with a dedicated server, you will most likely have to install your database software.
Most databases supporting websites should provide persistent storage or be configured to do so. I'm not sure why your MySql database loses data after you restart, but out of the box it should not do so. If your using hibernate to autogenerate your DDL, I could see the data being blown away at each restart. You would want to move away from this configuration.
1 Do I use mySQL server of a hosting provider in that case to run my database?
Yes. In your application you only change the JDBC connection URL and credentials.
There are other details about the level of service that you want for the database: security, backup, up time. But that depends on your hosting provider and your application needs.
2 Is it stored somewhere on the server?
Depends on how your hosting provider hosts the database. The usual approach is to have the web server in one machine and the database in another machine inside the VPN.
From the Hibernate configuration perspective, is just changing the JDBC url. But there are other quality attributes that will be affected by your provider infrastructure, and that depends on the level of service that you contract.
3 Should I declare somehow that data must be stored f.e. in a separate file on server?
Probably not. If your provider gives you a database service, what you choose is the level of service: storage, up-time... they take care of providing the infrastructure. And yes usually they do that using a separate machine for the database.
4 Am I going to loose data in case of server reboot? (As f.e. I do when I restart server on my local machine)
Depends on the kind of hosting that you are using. BTW Why you loose the data on reboot in your local machine? Probably you are re-creating the database each time (check your Hibernate usage). Because the main feature of any database is well... persistent storage :)
If you host your application in a virtual machine and you install MySQL in that VM... yes you are going to loose data on reboot. Because in this kind of hosting (like Amazon EC2) you host a VM for CPU execution, and all the disk data is transient. If you want persistent data you have to use a database located in another machine (this is done in this way for architectural reasons, and cloud providers like Amazon gives you also different storage services).
But if the database is provided, no.. a persistent database is the usual level of service that you should expect from a provider.
We're trying to design a new addition to our application. Basically we need to submit very basic queries to various remote databases accessed over the internet and not owned or controlled by us.
Our proposal is to install a small client app on each of the foreign systems, tiered in 2 basic layers, 1 that is tailored to the particular database its talking to, to handle the actual query in SQL or whatever, the other tier would be the communication tier to handle incoming requests and send back responses. This communication interface would be the same over all of the foreign systems, ie all requests and responses have the same structure.
In terms of java remoting I guess this small client app would be the 'server' and our webapp (normally referred to as the server) is the 'client'.
I've looked at various java remoting solutions (Hessian, Burlap, RMI, SOAP/REST WebServices). However am I correct in thinking that with all of these the 'server' must run in a container, ie in a tomcat/jetty etc instance?
I was really hoping to avoid having to battle all the IT departments controlling the foreign systems to get them to install very much. The whole idea is that its thin/small/easy to install/pain free. Are there any solutions that do not require running in a container / webserver?
The communication really is the smallest part of this design, no more than 10 string input params (that have no meaning other than to the db) and one true/false output. There are no complex object models required. The only complexity would be from security/encryption etc.
I wamly suggest somethig based on Jetty, the embedded HTTP server. You package a simple runnable JAR with dependency JARs into a ZIP file, add a startup script, and you have your product. See for example here.
I often use Sprint-Remoting in my projects and here you find a description how to use without a container. The guy is starting the jetty from within his application:
http://forum.springsource.org/showthread.php?12852-HttpInvoker-without-web-container
http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html
Regards,
Boskop
Yes, most of them runs a standard servlet container. But containers like Jetty have very low footprint and you may configure and run Jetty completely out of your code while you stay with servlet standards.
Do not fail to estimate initial minimal requirements that may grow with project enhancement over time. Then have a standard container makes things much more easier.
As you have tagged this question with [rmi], RMI does not require any form of container. All you need is the appropriate TCP ports to be open.
I'm working on a project which involves writing web services on mainframe enviroment.We are going to be provided a test enviroment on which we can do development and see the inital results. That process is taking a lot of time and I wanted to see if I can simulate some of the parts that I've to do.
Finally I've to get web services talking with mainframes which would have webservice talking with DB2 and IMS segments. I've never worked with mainframes before and I wanted to know how can I create mocks for IMS segment which then my webservice can read and update to. I would appreciate any insights into this
I've done the mainframe side of POX and SOAP web services in CICS. (CICS can access both DB2 and IMS) The thing that seems to surprise the distributed folks is the tag names. They tend to be generated from language structures, so they look like (in our case) COBOL variable names.
Other than that, the SOAP looks like what the WSDL says it should, the POX looks like POX.
If you've got a schema, work from that. Don't worry about the fact that it's a mainframe or that the data is stored in IMS or DB2, write to the specification.
You might want to ask about authentication mechanisms, as this is another stumbling block regardless of platform. Generally people are nervous about unauthenticated access to their business systems, even if that access is coming from another part of the same organization. No one wants to have created an exploitable hole in their security.
In our case, using CICS, we required a logon ID and password for each transaction - http basic authentication as per RFC 2617. Depending on your policies and procedures, that password may be required to expire on a regular basis. Some organizations allow non-expiring IDs, some don't.
An option we looked at but did not implement was SSL certificates. CICS allows one to send a certificate along with a request and then CICS matches the certificate to a logon ID under whose auspices the rest of the transaction runs. The ID is authenticated by virtue of the certificate. This is done in the TCPIPSERVICE definition in CICS.
I realize I'm going on about CICS and you didn't even mention it in your question, but I have to believe you're going to run into similar concepts/issues. IMS also does web services, and I seem to remember there being a mechanism to expose a DB2 stored procedure as a web service. IMS, DB2, and CICS all use the same external security manager behind the scenes.
I am working on a server application that does the following:
Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
Exchange data (read and write) with another server application using sockets.
Insert data from (1) and (2) into a database using JDBC.
Offer the data from steps (1) to (3) to a JavaScript-based web app.
My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.
This server application needs to start up and work also without any web clients being present.
I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.
Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?
Edit:
The reasons I want to use a Java EE container are:
I would like to have a clean external interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.
In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.
A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.
So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.
For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.
For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.
My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.
I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.
Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.
I am curious as to how, for example Beanstalk and Server Density, create custom domains (e.g. custom.beanstalkapp.com, custom.serverdensity.com) for each sign-up. I would like to do something similar so that clients and their staff access the web-app at their own sub-domain. Each app either uses LDAP or our own native user storage depending on client choice and would share a common API.
Does each custom domain share the same web app code base?
Taking this further what if I wanted to allow a completely custom domain as you can get with bit.ly pro. I'd imagine in this case the customer would point the A record for their domain to our web servers and then we would have to programatically edit our Apache configuration to add a new virtual host for that domain?
In this application the API is written in Java (using Restlet) with the front-end written in GWT. The data layer is built in MongoDB.
You can use wildcard dns and name based virtual hosts in apache to accomplish the subdomain bit.
You want a web server where you can programatically change the configuration notably for the virtual hosts.
This will most likely mean that you will want an embeddable server to have full control of what goes on instead of hacking on a stand-alone server. That is the first step. Do that first.