I have applications that have been written in Java, .NET and C++. They all use a common database.
Each app has it's own way of accessing the database, and so things are quite inconsistent.
I was thinking of writing a Data Access Layer using a ORM and having all applications use that.
The question is how to implement this ORM Data Access Layer:
Make a Java package using Hibernate;
use the Java package from the .NET and C++ apps
Make a .NET class library using Entity Framework;use the class library from the Java apps
In either case, is it easy to access the package/class library from the other platform? Any suggestions on the path to take?
Is communicating via XML between the two platforms the best way?
Ps. I have already seen this question, but I think my question is a super-set of that one.
Ps. Making a web-service is an option, but I would prefer not to write/use a web-service.
iKVM
This will allow you to share code between .NET and Java. I like most sane people in the world prefer to write data access bits in .NET, but if you've got existing code in Java you want to make available for .NET services this is available
http://www.ikvm.net/
RESTful Web Service++
This is the most sane and obviously the quickest way to get up and running. Again, you could use something like Jersey, ASP.NET MVC, NancyFx or whatever REST application server you wanted to get up and running.
I would recommend you use NancyFx and ServiceStack.Text. These are two very simple very pure implementations and are extremely fast, which is what you want if you're using it as a unified DAL on top of your database.
Nancy: https://github.com/NancyFx/Nancy/
ServiceStack.Text: https://github.com/ServiceStack/ServiceStack.Text
Jersey: http://jersey.java.net/
ZOMG T3h H0rror - COM+ / DCOM
This is actually a viable possibility if you can't use RESTful web services, and also assuming you're exclusively on Windows. This will also be the most troublesome depending on how insane your requirements are. That being said, I've seen this done before and seen it work quite well especially when you have legacy C/C++ components living inside different segments if your infrastructure.
Is communicating via XML between the two platforms the best way?
This will have a performance issue - but will provide a unified data layer in a language independent maner. You can consider the open source WSO2 Data Services Server, if you select to go ahead with this approach...
Thanks...
It sounds a bit like the database can be thought of as a service that your various apps consume to different extents.
What about writing a web service layer to wrap all access operations to and service-enable the database? You could use ORM in that layer and have all of your applications interact with the web service wrapper. If you can deploy it on the same server as the database you won't get much extra network overhead.
I think this would be a decent cross platform approach where you don't have to depend on libraries across platform boundaries, and you've provided a standard way of talking to the DB for all current/future apps.
Related
Well, I've taken help of Google, Stackoverflow and whatever else I could find, did as much as I could, but it seems that I am unable to find out an exact answer! I have multiple queries, and I would love to have answers from the database-people as well as from the programmers and framework users.
From the programming languages, I know C/C++, Java and Python. I have undertaken a CMS project that would require frequent C's & R's of the CRUD. The project would have 50k users atleast. The head-to-toe of the project has been all figured out, and now I need to code it and make it live online.
Well, I want to use Neo4j as my database as its data representation model (nodes and relationships) is closest to the real project model. Now, neo4j has bindings for various languages, and one of them is Python (whose python bindings are very oldish, the jpype hasn't been updated since ages). I am thinking of going for some Java based framework, but then I leave this idea as I personally haven't heard much of java frameworks. But one of my partner tells me to go for Zend (PHP) as it has some kind of functionality that lets us execute Java code. Won't this slow the code? I mean executing one language's code in another language...
So, it all comes to this:
1) Database: I would want to go for Neo4j. But does it goes well off when the scalability factor kicks in? (From what I could gather from google, there are no scalability issues).
2) What framework to use in case of Neo4j? I would require a framework that is able to handle tonnes of requests and large data as the users of the project would be Creating and Reading data a lot.
P.S.: I know it is a long question, but couldn't jot it down in lesser words!
I can't speak about the scalability or suitability of Neo4J for your particular project.
However, I'd strongly advise you against trying to mix and match languages like Java and PHP. It's so much easier to stick to the best one for your particular task. I'd also strongly advise you against using JNI for anything unless you have no other option. Java is fast enough that you should almost never need JNI for performance.
That said, it's OK to run Neo4j in its "full server" mode and then have your PHP or Python application access it using some driver over the network. I just wouldn't recommend making an ugly hybrid of PHP and Java at your application layer.
Some decent Java frameworks you could check out include:
Spring
Google Guice with Sitebricks
Apache Struts 2
They're pretty standard in the industry and there are tons of good resources available on all of them.
In regards to the mini-question about language interoperability, Java provides the JNI interface, which allows the JVM and user code to make calls into other languages and vice versa. When the native code (e.g. C code called by Java, or Java called from C) runs, it is actually running in its natural environment, so there's no performance loss in terms of actual execution.
Neo4j as a standalone server has also REST API: http://docs.neo4j.org/chunked/milestone/rest-api.html, if you can embedded your requests in single REST queries, there is no need to use native embedded neo4j. If there is no need to use the embedded neo4j, you can take any language of your choice.
Regarding the scalability, recently neo4j can be used on Azure, so it must be quite easy to scale. To learn more how to scale neo4j, go to this page on neo4j.org.
UPDATE: in the newest version of Neo4j, there is added the support for a new query language - http://blog.neo4j.org/2011/06/kiruna-stol-14-milestone-4.html.
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.
To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
I am not sure exactly what I am asking....The guys that do the software development for the company I work for write everything in VB. I am currently the Web developer for this company and I specialize in Flex apps. I am thinking about expanding into their area. But I do not want to do VB, I don't mean to bash on VB but the coding syntax is not for me. So I am wondering if Java can integrate with VB? Also not sure if it matters but I think everything they do is procedural, and I will be doing OOP.
Thanks.
There are lots of integration opportunities, but before examining them, if I were you I would re-examine the question itself.
It should be exceptional to introduce a new language into an established project. The desires or aesthetic preference or skillset of a single developer is not a good enough justification to do so. Introducing a new language into a project should be a strategic decision for the project, not a backhanded one.
If you do choose to expand the core languages used to develop the system,
COM interop
is possible with JACOB. I believe IBM has a bridge as well.(Check alphaworks)
Java-.NET bridging
is possible via JNBridge and other bridges. This makes sense only if VB.NET is in use.
SOAP, XML document exchange, REST
suitable over a services boundary. It requires TCP or HTTP or some network protocol.
common data stores
can serve as a rendezvous point. Both Java and VB can read and update data in SQL Server, Oracle, MSMQ, MQSeries, and so on. Even a filesystem can be an integration point.
Think of data format as related to, but ideally independent of, the integration mechanism. What I mean is: You can use an XML document for integration, whether it is stored in a database, or sent over a REST interface, or stored in a filesystem, or put/get on a queue. You can use a comma-separated file over any of those mechanisms as well.
Potentially they could expose a service layer via soap or something simpler? Also you could always work against the same database with different languages however unless most of the logic is in stored procedures (not necessarily recommending this approach) then you end up with repeated code.
Not really. Java uses CORBA for interop, and VB uses COM for interop. You may be able to make a bridge using JNI, but I understand that can be quite the pain.
I haven't done this by I believe you have the following options:
Use the Java-COM bridge, as VB uses COM. This library was already mentioned here several times
If you are using VB.net, you probably use hessian, As it has both Java and C# implementations.
You could bridge the two using a C/C++ adapter to map JNI calls with COM. But that would be horrible. I hope there is a better solution, but my understanding is that it is pretty hard to integrate .NET code and Java as both vendors (Sun and Microsoft) don't have any incentive to streamline that kind of development.
I have a rather large (80k loc) java desktop app that talks to a database. We're now looking at exposing some parts of the database via a web application, using the existing codebase and preferably not having to modify it.
I have good separation between the data access, business logic and presentation layers, but we haven't used enterprise java beans or anything like that (if that's important).
What's the best way forward? Which of the java web frameworks will be best suited to the problem? Learning curve isn't terribly important, since I haven't done any java development on the web...
To be true, it depends what you already have, and how well is the design of your current desktop application. You might not be able to use any or may be minimal of your existing code without modifying it, if its designed badly, and everything is tightly coupled.
Assuming that you are having a system with a good design, everything is de-coupled well enough. You can look into Stripes to make your presentation for the web, and use your existing data access and business code. I wish you all the luck.
Few other goodies to look into are, Groovy on Grail, Wicket.
I don't recommend anything like Seam and Spring they are more of a container and sophisticated large frameworks, which give you almost everything, solution for almost all of your problems. As you mentioned that you already have a complete system, and you just need to make a web interface to publish it for the web, these are not recommended, IMO.
JSF, is a good framework, but it might drive you nuts and has a big learning curve, according to few folks.
The two frameworks I would recommend would be Grails and Struts 2.
Grails comes with a whole bunch of stuff that it configures under the covers including Hibernate and Spring. It makes generating dynamic pages to send to the browser ridiculously easy. What you are probably going to need to do is set up controllers that call Grails services which reference your existing code as you probably don't want Grails managing your database interactions. The disadvantage with Grails is not so much that it is written in Groovy, which is easy to learn for Java programmers, but that the IDE support for Groovy is still maturing. Still if you want quick productivity this is the route to go down.
Struts 2 offers a clean command pattern framework implementation that talks to JSPs (or velocity or FreeMarker templates) on the front end. To use this you would configure actions to call your existing code. You may want to investigate adding Spring to the mix depending on what you need to do.
There are other choices but these are two that I have had some success with.