I'm thinking about possible alternatives for our EJB based service layer and wondered if it would make sense to use just the service and database layer of Grails together with the Remoting Plugin or is this using a sledgehammer to crack a nut?
Speaking of the Remoting Plugin: is there a standard way of generating a JAR file, that contains the necessary classes to make a remote call to a Grails service from a non-Spring Java application?
Interesting idea. I don't think it'd be overkill at all. The nice thing is that your service would be very portable across protocols and deployment options (e.g. put a controller layer on top and it's instantly embedded). This gives you the benefits of EJB's (persistence) + the ability to use Groovy and GORM.
FWIW, we're using Grails as our service tier; in come cases we use it embedded (as a plugin), in others we expose the services (via controllers) as JSON or SOAP; I see exposing as RMI as a variation of what we're doing (without the controller layer).
Related
I'm working on a webapp running on Tomcat which using spring-data to connect to a neo4j graph in embedded mode.
I would like to use neo4j server instead of the embedded mode and I am looking for some help to be sure about how to do that.
Some of my application services are quite difficult and combine, in a single transaction, the result of several cypher requests in a dto sent back to the user.
First I thought that I have to create a server unmanaged extension and I think I should follow these following steps.
- Keep my webapp with springMVC and spring security to hold and secure users sessions.
- Regroup all my transactional services in a specific jar my-app.jar
- Use Jax-RS to add a REST access point on each of my service of my-app.jar
- use something like spring restTemplate from my spring controller to call services from my-app.jar
First question : is this way of doing things is the good way ?
Second question : I have many spring injection in my services layer. How can I keep them working (how can I add dependencies in the server extension ?
Then I discovered graphAware and I wonder if I should use it instead.
And finally I just read this post http://jexp.de/blog/2014/12/spring-data-neo4j-improving-remoting-performance/ and it seems that I should use
the SpringCypherRestGraphDatabase (as explain in the bold text at the end of the article).
Well, I'm a little bit lost and I would appreciate any help to use neo4j server instead the embedded mode for my application which contain some complexe transactions.
You have a number of options here and you are on the right track with your thinking.
Option 1:
If your use cases are business-logic-heavy, and your question suggests that they are, going the unmanaged extension route is one option.
Essentially, you can then combine the most performant Java API and Cypher (if you wish) to perform your use case. I wouldn't use SDN here by the way, so you have to do your mapping manually, but is there really any mapping? Maybe you just want to execute traversals / Cypher queries for each one of your use cases.
Each use case then exposes a simple REST API, which is consumed by your Spring-powered application running Spring MVC, Spring Security, and all that. You can use the RestTemplate from Spring in your app's Controllers.
To add a twist to all that, you can use the GraphAware Framework to develop the "unmanaged extension" using Spring MVC as well. That would be my preferred option, knowing nothing about your domain/app.
Option 2:
Use the new version of SDN (v4) as Michael suggests. This allows you to run your application with annotated domain objects, Spring MVC, Security, et al. Operations (CRUD and other) are automatically translated to Cypher and sent across the wire to Neo4j running in server mode (no extensions needed). Results are then marshalled back to Java objects.
We're about to release Milestone 1 of SDN v4. It shouldn't take more than a week. That said, it is still going to be a Milestone release, thus not ready for production. A GA release is expected in May (ish).
You can already try SDN v4 yourself. Clone this repo: https://github.com/spring-projects/spring-data-neo4j, make sure you're on the 4.0 branch, and do an mvn clean install on it. Here's a sample app, built using Angular JS and Spring Boot.
Please do get in touch with feedback / questions / problems (best by email info at graphaware dot com). Cheers!
I suggest you wait a bit until SDN4 Milestone 1 comes out (developed by GraphAware) this was written from scratch for Neo4j-Server.
I am a bit confused on the difference between using Grails domain model/service to inlcude my biz logic or make my Grails controller/services to talk to my application server and make the web layer separate from the application logic layer?
When do I select which?
What are the pros and cons of each approach?
Any gotcha using the Grails domain stuff specially for scalability and what not?
If you already have a web service that handles your domain and business rules, you can turn off db support.
If you do that, your grails app is effectively a thin web layer on top of another service. In this case, if you are going to enforce business rules, you could still do it in service/domain layers. However, I would not do this, and certainly not any complex validation, because the service should be your single source of truth for the app, and you don't want to duplicate business rules in 2 apps.
I would still use controllers for handling web requests, and services for interacting with the other service. I would also have some sort of simple domain layer for passing data thru the sections of the web layer (i.e. services return anemic domain objects, controllers serialize them to the client however makes sense). The majority of the work would be in the service layer, which would serialize and deserialize the communication with the other service.
Based on your comment, Grails is a fine technology for building your server layer. Why would you think it isn't? Grails bills itself as a rapid development environment; it provides everything you need for all layers of a standard web-app. You don't lose anything; quite the contrary, you gain quite a bit, such a integration with persistence, spring, a robust testing framework, etc.
Imagine two Grails applications which share a domain class. Maybe a Book domain class.
One application is identified as the owner of the data, one will have to access the domain data. Something like amazon and the amazon web services.
I guess it is trivial that the owning application will use a normal domain class and will expose the data through web services - no problem in grails.
But what would be best practice to implement the domain in the other application?
use a service to access the remote domain and not implement a local domain class at all?
implement a local domain class, overwrite the get()-method in order to fetch the remote data and use the local database as cache?
what other solution comes to your mind?
Ryan Geyer has a very interesting article Modularizing your Grails application domain classes which lists 3 solutions to this problem:
As a RESTful JSON Service - easy to get this setup in Grails but then you lose the automatic GORM functionality.
Separate out the domain classes into a library JAR file and reference that library in both of my other applications. This is not as easy as it first sounds
Create a Grails plugin. Put the domain object in the plugin. Each of your applications can then import this plugin. You can then create different controllers with different functionality as required. The sample code for this is available at:
git clone git://ec2.nslms.com/grails/blog_example_modular
Ted Naleid gives a great tip later in the post and recommends...
"create a grails-app/conf/BuildConfig.groovy file and put the plugin name and path to the source in it. ... If you do this, your applications will see the live changes to your domain/controller/service/etc classes as if they were actually in current app and there isn't any need to repackage and reinstall the plugin when you make changes."
Using memcache should enable both applications to have a consistent view of the data and would avoid each individual application having it's own inconsistent cache.
I think you can make JAR file of your domain classes and add reference to other grails application .
Found another interesting solution:
Riak is a key/value database with a first class REST API. There is a grails plugin for riak which maps most of the GORM functionality (relations, dynamic finders etc) to the REST API of riak: http://grails.org/plugin/riak
Now comes the part which I haven't tested yet: if you make use of the DataSources feature of grails 2.0, it should be possible to only connect those "remote" domains to a riak database.
As a result, there would be a domain stored in a riak database and several applications would be able to access it via a clean REST API without effort.
OK. This also show how silly my question is - it would be the same if you connect several apps through the same SQL-database. But sometimes people want to have something more funky like webservices.
I would like to share the data access portion of my grails app (Grails domain classes and services) with another grails app. One is a standard client facing web app, the other (not yet written) will be for periodic background tasks such as reminder emails and such using the Quartz plugin or similar, where the UI will just be for statistics/control for internal users.
I do not want this all bundled in one Grails application because I want to be able to scale them and run them on different machines. What is the proper way to do this? I have accomplished this in the past in more legacy Java web applications by bundling the shared data access classes into a .jar and including them where needed in multiple apps, but I'm not sure if this is the right approach for Grails.
I've considered a full blown service oriented architecture where a third grails application is responsible for all data access and the two described do all their data access through REST calls to this service app, but this is out of scope for the short term since the client facing webapp is already written.
Usually this is done via plugins. Create your domain classes, services, controllers and even default gsp's that you want to share among apps and create them as a plugin. That way you can install them in any Grails app that requires that behavior.
I've done this with some generic accounting type behavior that is fairly common among apps I write like receivables, payables, etc.
One great thing is that you can write the plugin and test separately with a test data source and then when you install it into a Grails app it will use the apps data source. And it will have default gsp's and controllers that give you a basic set of behavior that you can override in the actual app.
I have two separate installs of WebSphere. (Actually one is WebSphere Application Server V6.1 with EJB 3.0 and Web Services feature packs, and the other server is WebSphere ESB Server V6.2). However, I know that ESB is really built on top of WAS, so it has all the configuration settings that a regualr WAS server has.
In my ESB server, I am trying to expose a service written as EJB 3.0 that will be deployed to the WAS 6.1 server. My question is not how to get EJB 2.1 calls to call into an EJB 3.0. We've done that already. My question is how to call across physical VM's. The WebSphere Application Server is running in its own cell/node/server from the ESB Server. From what I've read in IBM documentation, it is possible to set up a namespace binding on WAS to point to a remote EJB on another WAS instance. Thus you could use JNDI to lookup a bean on one WAS instance that really resides in another WAS instance. The beauty of this method is the location of the EJB you want is abstracted to the container level, and you don't have to drag around properties files of the IP addresses and ports that you need to access the bean should it change servers, etc. You just make a standard JNDI lookup to a remote EJB and you get it.
Sounds like it can be done. (See the following links:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tnam_view_bindings.html) Especially follow the links on EJB and Indirect namespace bindings.
But I've been hitting my head against this for a while. It makes sense. It looks like it can be done. And the Indirect namespace binding looks the most promising. But I can't get it to work quite right. My ESB server keeps complaining about not finding comp/env/ejb in the context in which I am asking for it. Very puzzled by this one.
Just wondering if anybody has done this kind of thing before. Can you give me a concrete example of how you set this up in WAS to do so? Any help is appreciated
Well, I have since talked with IBM on how to do this and was surprised by their answer. They answered that if you are talking EJB to EJB within the same server or server cluster, then use EJB RMI via IIOP. With JNDI this abstracts where the bean is actually running (in a clustered environment).
If you are going from one server (or server cluster) across into a different server (or server cluster) regardless of whether or not the target and source are in the same cell, IBM recommended that you use messaging or web services. They felt that was a better method of abstraction between applications to keep them from being "tied" to each other. They did say that you could get EJB's to talk RMI via CORBA, but said to do that ONLY if absolutely necessary. And of course, you would need to know the IP and port number for coming in over CORBA (and that times each cluster member if in a clustered environment).
Again, this kind of surprised me, but it does make sense. Just thought I'd share these thoughts with the world, especially if you are working with WebSphere.
how to lookup from tomcat
use IBM JDK as runtime for tomcat
find bootstab port , use iiop in PROVIDER_URL
I was stuck with the same problem. After trying to include all the websphere and ibm orb jars found this article at ibm
How to lookup an EJB and other Resources in WebSphere Application Server using a Oracle JDK client - http://www-01.ibm.com/support/docview.wss?uid=swg21382740
basically used the CNCtxFactory instead of WsnInitialContextFactory
//props.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
Hashtable env = new Hashtable();
env.put("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
env.put("java.naming.provider.url", iioppath);