We have two application one is in Ruby On Rails and second is in Java EE.
We want to integrate those two application so that if user has done login in one of them other one should be accessible without login.
How can we implement this??
this two applications are running on different servers, ROR on webrick and Java EE (JBoss or Tomcat)
What are the various ways to integrate such applications??
What you're looking for is called Single Sign On, and the there are practically infinity answers to how you could do it. This question will probably be closed.
But, if you want one (of the many possible) solutions, you could run a JBoss PicketLink server for Identity Management. Expose a SOAP API from the PicketLink server, and then consume that one the Rails side for authentication/authorization.
As #messick mentioned you will have to go for a SSO (Single Sign On implement ion), There are standard libraries for that and the most famous is CAS (ruby)
You could either implement the CAS server in JAVA and use a ruby client or CAS server is ruby with a java client
This is the standard CAS guidelines project (you could find links to implementation in various languages as well)
Related
We want to develop a Java based Web-services (since the API's we want to use are Java based)
I would like to know if it's possible to use the IBM Rational Team Concert Plain Java API's (https://jazz.net/downloads/rational-team-concert/releases/5.0/RTC-Client-plainJavaLib-5.0.zip) as part of the Web-servicesand deploy them in the server?
Basically we use these API's on a client based Java applications. What I am looking at is more like a services which can be consumed by many applications
Anyone has any experience in deploying the client based API in the server as Web-services?
After multiple tries, it is possible to use the RTC Plain Java API's as Webservices.
How I did:
Followed the simple Webs Service creation tutorial (http://wiki.eclipse.org/Creating_a_Bottom-Up_Java_Web_Service)
Adapted to my needs
First added the "RTC plain Java API's (JAR's)" to the Eclipse build path
Then added the "RTC plain Java API's (JAR's)" to the "WebContent/Lib/" folder of my Dynamic web project
Created a new Web service & Web service client
I was able to login to RTC via this for starters
I don't know very much about CAS, except that I need Single Sign On for a few internal websites, and that this is probably my best option.
What's a good CAS Server to use in an all Ruby on Rails environment?
What's a good CAS Server to use in a mix of Ruby on Rails and Java environment?
I see rubycas. They have a client. Will this client work in Rails with all CAS Servers or just the rubycas server?
If I'm looking to overhaul the entire sign on system, should I add LDAP behind CAS?
If it needs to be an all Ruby environment you will need to use rubycas-server (http://code.google.com/p/rubycas-server/) and the unofficial Ruby CAS client (https://wiki.jasig.org/display/CASC/Ruby+on+Rails+CAS+Client).
If it can be a mixed Ruby/Java environment, I'd imagine that you would want to look at using the original Java CAS server (http://www.jasig.org/cas/download) and the unofficial Ruby CAS client. The Java CAS server is really just a webapp that can be run on something like Tomcat.
Any client should work with either server according to documentation (I've tried a few for the Java "server" and all have worked fine).
The backend should not really matter to the overall architecture. If you want to use LDAP...go for it. In fact, if you want to use the original CAS Server and don't want to write much Java, there will be projects you can leverage to use LDAP whereas if you are using a homegrown solution, you will need to write that implementation.
I have just became a partner of a company that has a site developed in JAVA. As part of the agreement they allow me to create a section on their site (so I can take benefit of their traffic), but the development of this section needs to be as less intrusive as possible.
So ideally I would like to implement an independant web application in JAVA (with same layout) with a separate database that runs in the same application server. And in the application server to make a mapping like this:
All the traffic that comes to www.domain.com/MY_FOLDER
its served by my web application, all the rest should be served by my partners site.
I have no experience in JAVA but I found that in php this can be done, so I was wondering if it can be done also in JAVA.
About the application server I dont know yet which one they are using but I guess that are using "resing server" (by caucho: http://www.caucho.com/).
I would really appreciate if you can give me any ideas of how I can achieve this.
Thanks in advance,
Juan
Only one application can listen at a given socket at one time, so you need to have the existing server forward "your" requests to your web application, if it is not Java capable in itself.
The way to do that is not standardized so you will have to talk to the server administrator.
The easiest way to start from scratch with a Java Web Application is in the Netbeans bundle with Glassfish.
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.