Here's my situation: I'm running a JBoss 7 in Domain Mode with several nodes. One node is in charge of my Liferay 6.2 another one runs several other web applications. Now I'd like to implement some kine of Single Sign On routine. So to use my web applications you have to go through liferay first. Authenticate agains liferay, then go one to one of the web applications.
So the question is whether there is a way to expose some of liferays methods to access the user store and check if the user, who's accessing a web application is the same as logged in on liferay. Developing some sort of bridge is fine with me. I'm thinking of a portlet which does all the interaction with liferay and exposes some methods like readUser(). Maybe I can do a jndi lookup for this portlet or a component embedded in this portlet to call readUser() from my other web applications. I think this sounds a bit like EJB stuff.
Using Liferays API, Services and LocalServices to read user information etc. shouldn't be that difficult (already played a little with that). I just don't know how to establish a communication between a web application and liferay.
If it's not working this way, I would settle for something else, maybe a webservice or an other way that makes sense but I'd like to try the EJB/JNDI approach first (except this makes completely no sense). Maybe someone can point me in the right direction.
Turning my applications into portlets is not really an option because these applicaions are quite large and already exsist for quite some time. So I'd like to leave them mostly unchanged - outside of auth stuff.
Thanks and regards
Sebastian
You can use a service builder and you expose your service as remote.
Several Options:
Just access Liferay's API methods from your applications. You can access the JSON API at http://www.example.com/api/jsonws.
There's also a SOAP interface (http://www.example.com/api/axis), that's typically available only from localhost (you can configure otherwise in portal-ext.properties)
You can encapsulate calls to those services by creating your own services. Use the tool of your choice or Liferay's servicebuilder. You can create empty entities and just refer to Liferay's own entities. Servicebuilder will generate JSON or SOAP WS if you let it. (what Slimen Belhajali mentioned)
As you specifically talk about the check for user identity, you might even want to think of a completely different solution and just look at single-sign-on (SSO) solutions. This way you'd sign in only once (to the SSO server) and automatically (implicitly) to your webapp as well as to Liferay. This works best if both access the same userstore, e.g. on LDAP.
Related
Please consider me as a novice and this is my first web app I am creating.
I am planning to develop a web application where the traffic I am expecting is around 50 users will access the application at a single time.
The webapp is developed with Vaadin (for UI) and respective business logic implemented with Java. DB used would be MySQL. The war will be deployed in Tomcat.
So, my question is do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
But please let me know suggestions.
You must keep in mind that even if tomcat and vaadin manage multiple sessions, your server application will have only 1 instance. So if you use singletons, static methods or fields, use them with care: they should never hold session-dependant content. Try to favour stateless methods over statefull.
Apart from that, there shouldn't be any problem.
It should not have any code changes if you handle the session and your business logic with statefulness properly.
There might be some configuration changes, like increasing the database connection pool size, it depends on what kind of connection pooling you are using and what is the default size etc.
Apart from that it should work just fine.
Vaadin is built on top of Jakarta Servlet technology (formerly known as Java Servlet). See Wikipedia. Indeed, Vaadin is a servlet, a much bigger and more sophisticated servlet than most.
Within a Java Servlet container (engine) such as Apache Tomcat or Eclipse Jetty, any particular servlet has only a single instance running. If three requests from three users arrive at the same time, there are three threads running through that same single instance for that particular servlet. So a servlets are inherently a highly threaded environment.
If you share any variables or resources between those threads, you must be very careful. That means mandatory reading, rereading, and fierce study of the book Java Concurrency in Practice by Brian Goetz, et al.
While the Web and HTTP were designed to be stateless delivery of single documents, that original vision has been warped by the desire to make web apps. To maintain state, a servlet automatically maintains a session. Vaadin represents this session state in its VaadinSession object. All data in all the forms, along with business logic, running for each user is maintained as part of that session.
Depending on your particular Vaadin app, and when multiplied by the number of concurrent users, this may add to a large amount of memory. You should monitor your server to make sure you have enough available RAM on your server.
do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
No, nothing for you to set or enable. Tracking the requests/responses and session for each user is the very purpose of a servlet container. From the moment it launches, every servlet container expects multiple users. As a Servlet, Vaadin is built to expect multiple users as well. The only trick is making your own code thread-safe, hence the book suggestion.
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
Concurrency problems can be very tricky to detect and debug. Often potential problems occur on the random chance of coincidental timing. You need to focus on properly designing your code in the first place, rather than relying on testing. Again, hence the book recommendation.
Of special note, since you mentioned using a database, is JDBC drivers. Deploying them in a Servlet environment can be tricky. Basically you need to not bundle them within your Vaadin web app WAR file. Instead, deploy the JDBC driver separately within a shared library folder within Tomcat. If using Maven to drive your project, direct Maven in the POM file to give the dependency for your JDBC driver a scope of provided. This has nothing to do with Vaadin specifically, it applies to all servlets. Search Stack Overflow as this issue has been extensively addressed.
I'm creating an application that relies heavily on dynamic creation/management of various resources like jms queues, webservice endpoints, jdbc connections... I have a background in java EE and am currently working on a jboss 7 server however I'm finding it increasingly difficult to control these things programmatically. The hardest thing to control seem to be the webservices. I need to be able to generate WSDLs (and XSDs) on the fly, manage the endpoints, soap handlers etc and the system simply does not seem to be set up to do that.
Other application servers don't seem to really offer any groundbreaking solutions so I'm wondering whether perhaps java EE is not the best solution to this particular problem?
Is there an application server that allows you to do just that? Is there another technology that does? Should I just roll a custom solution that integrates all the separate modules (e.g. a jms server, a web server etc...)?
UPDATE
To clarify, most java EE stuff is accomplished through a mixture of annotations and XML configuration. This however assumes that you have a POJO and/or a jar/war/... per resource.
Suppose I have a #WebServiceProvider bean which can be reused for multiple input/output combinations (for example because it dynamically redirects the content). I need to be able to deploy a new "instance" of the provider on the fly. This means I do not want to duplicate the code and redeploy it, I just want to take that one existing bean on the classpath and deploy it multiple times with different configuration settings. This also means I need to manage the WSDL dynamically. The end result should be a webservice that works pretty much like a standard webservice on the application server with the necessary integrated security, soap handlers,...
I imagine that at some point in the application server code, there must be a class "WebserviceManager" which has a method like "createWebservice(...)" that is actually used by the deployment module whenever it discovers a webservice annotation. I want access to that method and similar methods for creating jdbc connections, jms queues,...
You can use OSGi for these kind of scenarios. It is perfect for hot deployment of varios modules.
I've got existing Play application, I need to add to it remoting capacities.
RMI would be ideal choose, since I don't need to rewrite original client application. It's possible to run rmi registry myself, but I would like to avoid it. In EJB container rmi registry starts itself.
Another option - is to use Hessian for example, but in this case I need to add special servlet mapping in web.xml Is it possible to do it in Play ?
Or I can use web-services, but it's more like overkill in my situation. And again I need to add mapping in web.xml for Axis of CXF for example.
Could you suggest fastest and easiest way to add remoting for play application ?
Play provides a library (WS) which makes it very easy to connect with 3rd party apps via HTTP requests. That would be your best bet if you can add a REST layer to the remote application.
If not, you could try to use RMI and run play within a Java EE container as a war file (to get access to container), but that will hinder the normal developemnt flow.
Choosing one or the other may depend on the effort involved to add that REST layer. If it's not too complex, I would favour that.
Just use REST json services, you have everything in play to do so, nothing else is needed
I am trying to familiarize myself with JavaEE. I am a bit confused as to what the purpose of each "component" (for lack of a better word) is: Session Beans and Servlets, and how they properly interact with a web application (client-side JavaScript).
In an attempt to understand this I am building a simple web application. What is the preferred way to use each component to build something similar to the following:
User visits a "Log in" page
User inputs data and clicks submit. I then send an request with AJAX to log in the user.
The server side then validates the user input and "logs" the user in (returns user profile, etc.)
When sending the request, do I send it to a Servlet (which uses an EJB), or to a Session Bean through WSDL? How do I go about maintaining a "state" for that user using either method? I assume with Session Beans it's as simple as annotating it with #Stateful.
Also, I assume the requests sent from the client side must be in SOAP format. How easy is it to use something more lightweight (such as JSON)? While I would prefer to use something lightweight, it's not necessary if SOAP makes development faster/easier.
The Java Enterprise Edition tutorial address pretty much all of the topics you bring up; what's the purpose with the different kind of bean types, how do I implement web services, how do I implement authentication, etc.
I highly recommend you take the time to build the sample application, especially if you're completely new to the Java Enterprise Edition (Java EE). It is important you build up a good understanding of the core concepts because it can be hard to know what to focus on in the beginning due to the breadth and depth of technologies and standards that comprise Java EE.
One thing to keep in mind is that while Java EE certainly tries to support best practice and enable design and development of secure enterprise applications that perform and scale well, it does not prescribe or limit enterprise applications to follow one particular protocol, data format, and enterprise application design pattern. Some protocols and formats are better supported out of the box by the core framework implementations, and some choices are vendor-dependent, but very few specific technology choices are locked into the specification.
To answer some of your specific questions, Java EE has great support for SOAP, but it does not preference nor limit web services to the SOAP protocol. With JAXB and JAX-RS it is just as easy to develop RESTful web services that accept and return XML or JSON, or both. It's up to you to decide whether you need to use SOAP, REST, or another protocol.
It's also your choice whether you want to use frameworks like JAX-RS or explicitly develop Servlets to handle HTTP requests and responses. In many cases, JAX-RS will have everything you need, meaning you'll be able to implement your web services as plain old Java methods with a few annotations without ever having to bother with marshalling and unmarshalling contents and parameters.
Similarly, with JAXB it's up to you whether you want to use WSDL or not. It's great if you have WSDL definitions, but no problem if you don't.
In many cases you will typically maintain state using the Java Persistence Architecture framework (JPA), and access and manipulate such data through stateless session beans. Developers new to Java EE are often tempted to use stateful session beans to maintain state that is better managed in the persistent storage. The tutorial takes you through the different kinds of bean types and their purpose.
Web services (WSDL, SOAP, etc.) are usually used for communications between applications.
Inside a single web app, you usually make simple GET/POST requests, using AJAX or not, and receive either a full HTML page, or a fragment of HTML (AJAX), or XML or JSON data (AJAX). The browser usually talks to a servlet, but it's rare to use servlets directly.
The usual way is to use a framework on top of servlets. The frameworks can be divided in two big categories : action-based frameworks (Stripes, Spring MVC, Struts, etc.) or component-based frameworks (JSF, Wicket, Tapestry, etc.).
In a n-tier application, all of the above technologies are supposed to only contain the presentation layer. This presentation layer talks to a business layer, where the real business logic happens, where transactions are used to access databases, messaging systems, etc. This business layer is where EJBs are used.
You can create basic architecture as follows :
Create EAR instread two different Project like EJB Jar and Web Application WAR
You can create servlets which will call some delegate class which has logic to reffer the EJB
Either by calling it as remote call/ Either by Using #EJB annotation in the Delegation Class.
ServletClass {
do/post(){
DelegateClass d = new DelegateClass();
d.callMethod(withParam);
}
}
DelegateClass {
#EJB
EJBlocalinterface ejbintance;
void callMethod(DefinPrarm){
ejbinstance.callEJBMethod();
}
}
#Statelss
EJBbeanClass implements EJBlocalinterface{
void callEJBmethod(someParam){
}
}
Typically in any web application, the major security concern is securing the resources from the malicious users who are trying to access un-authorized resources. They can change a value in the request parameter and try to access something that doesn't belong to that particular user.
For Example:
http://blah.com/id=foo
a user can change this to http://blah.com/id=bar and try to access the bar resource to access it.
With restful services this may lead to greater security concerns as the restful URL's are rather self explanatory.
eg:
http://hotels.com/hotels/1
a user can easily guess and change the id to 2 to see the details of it..
One design is to check at every request manually to see the access rights for the resources and deny it if needed.
but this is a cumbersome and not maintainable.
So the question is "Is there any tool/framework that can help achieve this in a easy manner? I know spring security supports static rules not dynamic.
Over the last couple of years, the de-factory standard for this has become Spring Security. This sits in frotn of any old java webapp (not just Spring webapps) and provides an interception authentication and authorization layer of your choice.
It's very powerful, although also rather complicated (over-complicated, IMO).
I would highly recommend looking into Seam Security. It can even be tied into a rules system.
edit: I believe you would need the Seam Core package for this to work. However, I have never tried using it without Seam, so I can't be positive about its dependencies.