I have a different set of applications, each having their own war files and they could be deployed in different servers.
Assuming that all application sets may need to interact with each other I am trying to develop them as web services. It may happen that an application 'A' installed on server 'X' needs to launch an application 'B' but B's resources like HTML and js are not present on the server where A is installed.
How can we do this? I have come across a few sites where Viewable is used but then it needs the JSPs to be in the same instance. What if I want to achieve this when the calling application doesn't have HTMLs or JSPs with it.
I hope I have been able to put up my question properly. Thanks for any inputs.
As Pesskillet says, you can use a redirection to resource of server B.
If that resource is an HTML view, you don't need to worry about the loading of static files (CSS, JS, Images etc.) that are bound to the HTML view. Because the browser of the user will load it automatically as soon as it will get the HTML document.
Related
I am not able to understand the difference between active and dynamic web pages.
I know that Active web pages are first downloaded on the client machine and then executed.
Dynamic web pages are executed on the server and then sent to the client.
But I am not able to correlate it with some real time example.
Kindly explain me the difference with some simple examples.
Also explain what is Applet and why it is active web page not dynamic.
As you said, dynamic is what's being executed on the server and then the result is being sent back to the client (browser). So for example when using PHP, your browser isn't able to execute PHP, so the server executes the PHP file and performs all logic in your code. The result will be an HTML file, which is then sent back to the client. The important thing to understand is that when the result is served to the client, the information in it won't change.
An active web page is a page where the browser performs the logic instead of the server. So for example when you've got a page where you're showing share prices, then you want it to update e.g. every 5 seconds. A solution would be to use AJAX with JavaScript. In contrast to PHP, your browser is able to execute JavaScript, so it is happening without reloading the page. So with an active page, everything is happening inside your browser without the need to reload the page every time you want new information.
An applet is an embedded application, like Flash or Java (not to be confused with JavaScript). To execute an applet, you most likely need a browser plugin. Because the applet is executed by the plugin and your browser, it is active and not dynamic (you don't need to request a new applet for information in it to change). The advantages of using an applet is that the programming language (like Java) has more possibilities than HTML. A lot of browser games are made with applets, but nowedays it is used less and less because we can achieve the same with techniques like JavaScript, HTML5 and WebGL.
I have a Vaadin v6 application that uses the embed component to show a JSP page from another application (JPivot, in this case). Both applications are running in the same application server (Tomcat). I need both applications to communicate and I'm trying to do this by using session attributes. However, each application has its own session and so one is ignorant of the other attributes. My question is how to make these applications communicate without using a database or an external file? It can be other solution than session attributes.
What you wish to do is either IPC between two web apps,
or sharing some informations between them.
If you have a cache available (memcached or similar) you could
store/retrieve the information there.
If no cache is available, then CrossContext=true might help you.
With this you can call "the other" webapp from inside the servlet/request.
Here is a simple explanation how this works
http://lukaszbudnik.blogspot.ch/2009/06/session-sharing-in-apache-tomcat.html
If you google for "tomcat session sharing" you will get many more results.
Please note that this CrossContext stuff only works as long as they are in the same tomcat instance.
As soon as you add another tomcat instance for load balancing or high availability this will break. In that case you should use some sort of message bus or message queue.
I have big WEB application (jsp). What is the best way to put images files? Where to put images files in multi modules web application?
I have many images so I would like to have easy, separate access to modify them. The best way will be some separate project which I can redeploy without stop my main application part. Is this solution acceptable?
Yes, it is completely acceptable. You can create an "assets" project, and have images/module1/, images/module2/ folders, etc.
Just, in your main application, you will need to configure the path to the assets application. It can even reside on a different host. For example http://assets.yoursite.com. And then in your main application you'll have:
<img src="${assetServer}/images/module1/logo.png" />
(the assetServer request attribute may be put there and configured in multiple ways, depending on the setup and your preferences. One example is - configure as context-param in web.xml, and put in the request by a filter)
I am new to web programming...I have been asked to create a simple Internet search application which would allow transmit to the browser some data stored remotely in the server.
Considering the client/server architecture (which I am new to) I would like to know if the "client" is represented only by the Internet browser and therefore the entire code of the web application should be stored in the server. As it's a very generic question a generic answer is also well accepted.
As you note, this is a very generic and broad question. You'd be well-served by more complete requirements. Regardless:
Client/server architecture generally means that some work is done by the client, and some by the server. The client may be a custom application (such as iTunes or Outlook), or it might be a web browser. Even if it's a web browser, you typically still have some code executing client-side, Javascript usually, to do things like field validation (are all fields filled out?).
Much of the code, as you note, will be running on the server, and some of this may duplicate your client-side code. Validation, for instance, should be performed on the client-side, to improve performance (no need to communicate with the server to determine if the password meets length requirements), but should be performed on the server as well, since client-side code is easily bypassed.
Either you can put all the code on the server, and have it generate HTML to send back to the browser. Or you can include JavaScript in the HTML pages, so some of the logic runs inside the browser. Many web applications mix the two techniques.
You can do this with all the code stored on the server.
1)The user will navigate to a page on your webserver using an url you provide.
2)When the webserver gets the request for that page, instead of just returning a standard html file, it will run your code, perhaps some PHP, which inserts the server information, perhaps from a database, into a html template.
3) The resulting fully complete html file is sent to the client. To the client's browser, it looks like any other html page.
For an example of PHP the dynamically inserts information into HTML see: (this wont be exactly what you will do but it will give you an idea of how PHP can work)
code:
http://www.php-scripts.com/php_diary/example1.phps
see the result (refresh a few times to see it in action):
http://www.php-scripts.com/php_diary/example1.php3
You can see from this the "code file" looks just like a normal html file, except what is between angled brackets is actually PHP code, in this case it puts the time into the position it is at in the html file, in your case you would write code to pull the data you want into the file.
We have several images and PDF documents that are available via our website. These images and documents are stored in source control and are copied content on deployment. We are considering creating a separate image server to put our stock images and PDF docs on - thus significantly decreasing the bulk of our deployment package.
Does anyone have experience with this approach?
I am wondering about any "gotchas" - like XSS issues and/or browser issues delivering content from the alternate sub-domain?
Pro:
Many browsers will only allocate two sockets to downloading assets from a single host. So if index.html is downloaded from www.domain.com and it references 6 image files, 3 javascript files, and 3 CSS files (all on www.domain.com), the browser will download them 2 at a time, with the other blocking until a socket is free.
If you pull the 6 image files off onto a separate host, say images.domain.com, you get an extra two sockets dedicated to download your images. This parallelizes the asset download process so, in theory, your page could render twice as fast.
Con:
If you're using SSL, you would need to either get an additional single-host SSL certificate for images.domain.com or a wildcard SSL certificate for *.domain.com (matches any subdomain). Failure to do so will generate a warning in the browser saying the page contains mixed secure and insecure content.
You will also, with a different domain, not send the cookies data with every request. This can increase performance.
Another thing not yet mentioned is that you can use different web servers to serve different sorts of content. For example, your static content could be served via lighttpd or nginx while still serving your dynamic content off Apache.
Pros:
-load balancing
-isolating a different functionality
Cons:
-more work (when you create a page on the main site you would have to maintain the resources on the separate server)
Things like XSS is a problem of code not sanitizing input (or output for that matter). The only issue that could arise is if you have sub-domain specific cookies that are used for authentication.. but that's really a trivial fix.
If you're serving HTTPS and you serve an image from an HTTP domain then you'll get browser security alert warnings pop up when you use it.
So if you do HTTPS, you'll need to buy HTTPS for your image domain awell if you don't want to annoy the hell out of your users :)
There are other ways around this, but it's not particularly in the scope of this answer - it was just a warning!