Can Drools be used with non-Java applications? Most examples that I've seen are in conjunction with Drools interfacing with Java applications.
EDIT: Looks like http://docs.jboss.org/drools/release/5.5.0.Final/droolsjbpm-integration-docs/html_single/ describes the Drools API on techniques on getting information in and out of Drools.
I would suggest to expose the functionality that you need from Drools via REST or SOAP and interact with it from your application using that. I wouldn't spend time checking the Drools .NET port is old and out of dated.
A JS implementation is a good idea.. but just for specific cases.. you don't want your whole business rules running on the client side.. (for a web app of course).
HTH
Well, it doesn't have to be Java, but it does have to be a JVM language (I've used Groovy in the past with Drools). Even then, there's nothing to prevent you from calling a REST service, for example, when a rule fires, and interacting with another system that way.
That said, there are other rules engines in other languages. I believe there is a .NET Drools port, and a Javascript implementation.
Related
I want to exchange data between two applications JEE6/JSF2.0 and i'm looking for the best solution. I thought of the below solutions :
by using a JSON file.
by using XML file.
by using GSON file.
by using Remote interface (EJB 3.0).
For you, what's the best solution to use ?
edit : This two applications will be always running on the same network (but can not be on the same JVM)
I want to provide an alternative to David's answer, as I feel that there are some drawbacks to RMI that he underplayed.
This is a Java specific technology. If a third server needs to be introduced and it is a Microsoft Reporting Services server for example, then it cannot talk in the same language.
RMI is an OLD technology and doesn't particularly look well on a CV. Web services are the future. Experienced RMI developers are more uncommon than experienced web service developers.
Cumbersome and heavy framework
A better solution in my opinion would be to use SOAP XML based web services. Here are some advantages to this approach:
Universal acceptance in nearly any development framework. No matter the technology, nearly all have helpful libraries for interacting with web services.
Java has good support for object serialization into XML. This means objects can be quickly serialized into a SOAP XML request, sent to the other server, and deserialized back into a Java object by the other application server for processing.
A service layer can give you the decoupling interface between the two applications just as RMI can.
I hope you reconsider the use of SOAP XML based web services in your application.
There's two options really as you yourself stated.
Using RMI to connect to a EJB or using a webservice and communicating by JSON/XML etc...
From my experience RMI can be favorable if your applicaitons are on the same network, if not then you might get problems with firewalls etc and be forced to tunnel the RMI using HTTPS... which pretty much makes the RMI calls webservice calls.
If your on two different machines then webservices are nice as they dont cause as much trouble with firewalls. Also as they use the HTTP protocol you dont have to worry about the data being transfered.
These examples are kinda generalised but should give you some insight.
GSON vs XML vs JSON is a completely different subject... Non is superiour to the other, and all are fairly easily read by the human eye.
UPDATE
From what I've understod you wont have to worry about firewalls and such, I would recommend using RMI. It usually results in cleaner code and somewhat better performance.
Since I have seen both in action, I can make a comparison between the two technologies, EJB and WebServices. I can confirm that EJB is way more efficient, has support of transactions (including distributed transactions, if that is your requirement), exception handling, and binary streaming out of the box. In terms of performance EJB may exceed SOAP by a factor of 5 times in speed, and REST for about 3 times.
However, EJB is not an integration technology. In fact, it has never thought to do so. The biggest flaw of EJB is that it is very coupled to the Java Platform. Therefore, both endpoints must be written in Java and should use the same Java EE version.
Another problem is that EJB is not a protocol per se, so the implementations from two containers/vendors is probably different. If you need to access a remote EJB from JBoss AS on an Oracle WebLogic server, you must bring JBoss EJB client implementation with you.
Another big problem related to integration with EJB is a lack of data exchange format. Since it uses Java Serialized objects for communication, the data types must be shared on both ends. If you create a new exception type on the server that is classified as an Application Exception, if the client who consumes this service triggers the exception, his code will break. Note that, in this case the remote API was not violated, but another unknown type was introduced.
And, of course, by depending solely on the class type as an exchange format, you are giving the programmers opportunity for doing very stupid things. If you have many different teams in large projects using EJB as integration technology using different versions of Java EE, prepare yourself to experience uttermost pain. I've seem a programmer including a JPA entity on the client, who was annotated with named queries, the table which was accessing, its columns, etc, essentially giving away all the database layout to the service consumer. But it can get even worse. I've already seem a programmer returning a data structure that belonged to a dependency, namely Eclipselink 1.0. However, if you access this from a JBoss server, Eclipselink is also a JPA implementation technology, which conflicts with JBoss' hibernate. So, now you have to include Eclipselink jar in your JBoss APP classpath and configure the container for not loading JPA related packages, which otherwise will break your application completely. Even so, it can get WORSE than before: some other service you need to connect had also the bright idea of using the same datastructure, but now from Eclipselink 1.1.1, that has a different implementation, but the same class signature. Now you are in a very bad situation.
The bottom line: NEVER, EVER, use EJB as an integration technology. Use SOAP using a contract-first approach, where you define a canonical data model for the application, mapping java datastructures to a XML exchange format that can be used by any client, be it written in any language or using different stacks. Or use REST implementing a resource based, using HATEOAS principles. These days I rarely seem a reason for using EJB at all, since CDI is now on the market, support many features that EJB does and does not include any RPC related technology.
I'm learning how to develop with OSGi in recent days, but facing a lot of problems.
I don't know how to design my client-server system based OSGi with Equinox as framework. Should I use socket connections to implement this or use a distributed model?
I'm also confused whether I need to import some third party packages to support my programming on socket, jdbc, swing, etc, or there're existing packages offered by Equinox or other OSGi open source projects?
First time to ask questions here, can anybody help me?
just take a look at OSGi Remote services implementations (more details in OSGi spec):
Web services (Apache CXF: distributed OSGi) - http://cxf.apache.org/distributed-osgi.html
Eclipse Communication Framework - http://www.eclipse.org/ecf/
Cheers,
Dmytro
The HTTP model is probably the simplest to implement, as opposed to protocols based on low-level socket handling and binary protocols.
The first question I'd ask is what kind of information your clients and server need to exchange. If you can live with HTTP (and in many cases you can), you can just use servlets on the server-side, http client libraries on the client side and a RESTful communications model.
Servlets are easy to implement in OSGi using the HttpService, see for example http://www.osgilook.com/2009/09/08/osgi-http-service-registering-servlets-on-the-fly/
Working with sockets is not more or less complicated in OSGi than it is in 'plain' Java. You design your application in much the same way as you would normally, but gain the benefits of modularity and services by using OSGi.
You could, for instance, decouple connection acceptance and request handling by introducing something like a WorkerFactory, or maybe reuse services on both the client and the server; those are the things that OSGi is good at.
OSGi as a 'technology' (as far as that notion holds water) does not mandate any specific interaction method. The compendium specification mentions Remote Services (a.k.a. Distributed OSGi), but it also contains an HTTP service specification is Servlets are your thing.
In short, just pick the interaction solution that best matches your scenario, and let OSGi help you with the services and modularity.
We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.
For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.
The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.
Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.
Edit2: We (realistically even if you doubt) expect at least 10000 users.
Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.
Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.
Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.
On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.
Vaadin is just framework base on GWT but have two very important features:
don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.
I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.
In this case you should use MVP pattern and Domain Driven Development.
Bussines beans is domain objects and logic that use view interfaces to send responses.
Custom Vaadin components (could extends standard components) implements view interfaces.
That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.
My 3 cents:
If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .
If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)
Hope this will help you make the decision.
My question is very simple, my intention is to generate a repository with your responses so it could serve to the community when selecting frameworks for developing enterprise general purpose applications.
This could apply very well for general purpose languages such as C++, C# or Java.
What Framework do you recommend for generating Layered Architectures?
Based on you experience why do you prefer the usage of some Framework versus your own architecture?
How long do you believe your selected Framework will stay as a preferred option in the software development industry?
This is indeed an overly general question, especially since there are so many interpretations of the very word framework, and within the world of frameworks many different kinds for different tasks. Nevertheless, I'll give it a shot for Java.
Java
Java EE
The default overall enterprise framework of Java is called Java EE. Java EE strongly emphasis a layered architecture. It's a quite large framework and learning every aspect of it can take some time. It supports several types of applications. Extremely small and simple ones may only use JSP files with some scriptlets, while larger ones may use much more.
Java EE doesn't really enforce you to use all parts of it, but you pick and choose what you like.
Top down it consists of the following parts:
Web layer
For the web layer Java EE primarily defines a component and MVC based Web Framework called JSF - JavaServer Faces. JSF utilizes an XML based view description language (templating language) called Facelets. Pages are created by defining templates and letting template clients provide content for them, including other facelets and finally placing components and general markup on them.
JSF provides a well defined life-cyle for doing all the things that every web app should do: converting request values, validating them, calling out to business logic (the model) and finally delegating to a (Facelets) view for rendering.
For a more elaborate description look up some of the articles by BalusC here, e.g. What are the main disadvantages of Java Server Faces 2.0?
Business layer
The business layer in the Java EE framework is represented by a light-weight business component framework called EJB - Enterprise JavaBeans. EJBs are supposed to contain the pure business logic of an application. Among others EJBs take care of transactions, concurrency and when needed remoting.
An ordinary Java class becomes an EJB by applying the #Stateless annotation. By default, every method of that bean is then automatically transactional. Meaning, if the method is called and no transaction is active one is started, otherwise one is joined. If needed this behavior can be tuned or even disabled. In the majority of cases transactions will be transparent to the programmer, but if needed there is an explicit API in Java EE to manage them manually. This is the JTA API - Java Transaction API.
Methods on an EJB can easily be made to execute asynchronous by using the #Asynchronous annotation.
Java EE explicitly supports layering via the concept of a separate module specifically for EJBs. This isolates those beans and prevents them from accessing their higher layer. See this Packaging EJB in JavaEE 6 WAR vs EAR for a more elaborate explanation.
Persistence layer
For persistence the Java EE framework comes with a standard ORM framework called JPA - Java Persistence API. This is based on annotating plain java classes with the #Entity annotation and a property or field on them with #Id. Optionally (if needed) further information can be specified via annotations on how objects and object relations map to a relational database.
JPA heavily emphasizes slim entities. This means the entities themselves are as much as possible POJOs that can be easily send to other layers and even remote clients. An entity in Java EE typically does not take care of its own persistence (i.e. it does not hold any references to DB connections and such). Instead, a separate class called the EntityManager is provided to work with entities.
The most convenient way of working with this EntityManager is from within an EJB bean, which makes obtaining an instance and the handling of transactions a breeze. However, using JPA in any other layer, even outside the framework (e.g. in Java SE) is supported as well.
These are the most important services related to the traditional layers in a typical enterprise app, but the Java EE framework supports a great many additional services. Some of which are:
Messaging
Messaging is directly supported in the Java EE framework via the JMS API - Java Messaging Service. This allows business code to send messages to so-called queues and topics. Various parts of the application or even remote applications can listen to such a queue or topic.
The EJB component framework even has a type of bean that is specifically tailored for messaging; the message driven bean which has a onMessage method that is automatically invoked when a new message for the queue or topic that the bean is listening to comes in.
Next to JMS, Java EE also provides an event-bus, which is a simple light-weight alternative to full blown messaging. This is provided via the CDI API, which is a comprehensive API that among others provides scopes for the web layer and takes care of dependency injections. Being a rather new API it currently partially overlaps with EJB and the so-called managed beans from JSF.
Remoting
Java EE provides a lot of options for remoting out of the box. EJBs can be exposed to external code willing and able to communicate via a binary protocol by merely letting them implement a remote interface.
If binary communication is not an option, Java EE also provides various web service implementations. This is done via among others JAX-WS (web services, soap) and JAX-RS (Rest).
Scheduling
For scheduling periodic or timed jobs, Java EE offers a simple timer API. This API supports CRON-like timers using natural language, as well as timers for delayed execution of code or follow up checks.
This part of Java EE is usable but as mentioned fairly basic.
There are quite some more things in Java EE, but I think this about covers the most important things.
Spring
An alternative enterprise framework for Java is Spring. This is a proprietary, though fully open source framework.
Just as the Java EE framework, the Spring framework contains a web framework (called Spring MVC), a business component framework (simply called Spring, or Core Spring Framework) and a web services stack (called Spring Web Services).
Although many parts of the Java EE framework can be used standalone, Spring puts more emphasis on building up your own stack than Java EE does.
The choice of Java EE vs Spring is often a religiously influenced one. Technically both frameworks offer a similar programming model and a comparable amount of features. Java EE may be seen as slightly more light-weight (emphasis convention over configuration) and having the benefit of type-safe injections, while Spring may offer more of those smaller convenience methods that developers often need.
Additionally Spring offers a more thoroughly and directly usable security API (called Spring Security), where Java EE leaves a lot of security details open to (third party) vendors.
To specifically answer the second question:
Developing your own framework gives you the burden of having to maintain it and educating new developers in using it.
The larger your framework becomes, the more time you have to devote specifically to it and the less time you thus have to solve your actual business problem. This is okay if your business problem is the framework, but otherwise it can become a bit of a problem, even for very large companies that can dedicate a group of people to such a framework.
If you're a smaller company (say ~15 developer max) this can really become a huge burden.
Additionally, if your own framework is the kind of framework that can take advantage of third party developments (e.g. third parties can develop components for JSF), then your own framework obviously won't be able to take advantage of that.
Unless of course you open source your own framework, but this will only significantly increase the burden of supporting it. Just dumping your source code on sourceforge does not really count. You will have to actively support it. All of a sudden your framework becomes their framework with maybe 'weird' feature requests and awkward error reports for environments that you have no personal interest in.
This also assumes that your framework will actually be used by external users. Unless it's really very, very, good and you put lots of energy in it, this will probably not happen if it's simply the umpteenth Java web- or ORM framework.
Obviously, some people have to take up the job of creating new frameworks, otherwise the industry just stagnates, but if your prime concern is your business problem I would really think twice of starting your own framework.
Very vague question, I'm not really sure it's ever a good idea to "write your own" at this point for a work project (unless writing your own, IS the project). If it's a learning exercise, fine, but otherwise go use one of the libraries written by people who have been doing it far longer. If you really want to get involved, read their code, try and contribute patches etc.
For .Net there is Sharp Architecture Which is a pretty popular framework for layered applications.
Here's some of the stuff I use (I don't use Sharp Architecture)
First, the infrastructure stuff
For Dependency Injection, I use StructureMap. I use it because it's way more robust and performant than anything I would or could write, and it's very well supported within the .Net community. It also sticks to being DI, and doesn't venture out into other things that I might want to use other libs for (AOP etc). The fluent configuration is fantastic (but many .Net DI Tools have that now)
For AOP, I use Linfu Dynamic Proxy. I know a lot of people that like the code weaver variety for performance reasons, but that's always seemed a bit like premature optimization to me.
For a DataMapper, I use AutoMapper. This is one where I'm on again off again. If you can do your mappings based just on convention, then great, I'll use it. Once I have to start tweaking the configuration to do special things.... to me that starts to get into the gray area where the code might be more clear with just some left=>right wrapped in a function.
Web/UI
Asp.Net MVC. Although to be quite honest, I'm having a falling out lately and may soon be moving to FubuMvc. Asp.Net MVC seems like it has split personalities in terms of API design (dynamic over here, static over there, using blocks to render forms, but System.Actions to render other things etc). Combine that with the fact that it's not really OSS (you can't submit a patch), and to me there's a compelling reason why the community should come up with something better that's OSS.
Persistence
NHibernate, Specifically Fluent NHibernate. Sure I'd love to write my own OR/M, but at the same time I'm certain that the hordes of developers who have worked on NHibernate are way smarter than me.
Services/Distribution etc
WCF for Synchronous calls
NServiceBus for Messaging and most async calls.
Most of this stuff is OSS, so how long will it be around, well, I would imagine a good long while.
This question doesn't work very well. Selecting frameworks is difficult, and very context specific. For each selection process you might end up with a simple shortlist and a simple list of questions to answer, but those lists do not transfer well to other selections.
The number of parameters and the parameter sensitivity influencing a decision is very large, and at enterprise level a lot of them are not technical.
Currently, there are no frameworks available that are ready to support these near-term enterprise needs:
the switch for most of the workforce from pc to tablet and phone;
the switch from web client and rdbms to p2p/disconnected based storage and distribution
For web application development, I've been steeped in dynamic languages such as Ruby, PHP, and Python. Using popular frameworks for these languages, all my knowledge about HTML, CSS, and JavaScript transfers fairly straightforwardly: templates are basically HTML with embedded code that the server executes to generate the dynamic sections of the page.
Lately, I've been thinking about using GWT for building the UI of my next project. At this point, I'm just trying to wrap my head around how development with GWT works, as seems to follow an entirely different paradigm. In addition, it seems there's an unstated assumption that the server-side part of the app is written in Java. Would it be impractical to use something other than Java for the server side?
Related question:
GWT + GAE python: frameworks for COMET & RPC
While not actually impractical I would say that you get the most value from GWT by having the same code on client and server, since it allows for easy code reuse (fx. if your data objects are serializable then you could just send them directly to the client). So I guess my answer would be; yes you can do it and it's going to be more work than just having Java on the server side.
I don't think there's any requirement that you use Java on the server. At the end of the day, GWT compiles Java to JavaScript. You can do all the comms via the RequestBuilder object, you don't have to use the RPC services.
I guess the question is: if you don't like/know/prefer Java on the server side, why would you use it on the client when it's effectively an abstraction over JavaScript anyway?
There is no requirement to use Java on the server side. GWT supports JSON out of the box. Any server side component that can generate JSON ( or other supported serialization methods ) will work. You could use PHP on the server side, or bash shell scripts, it doesn't matter to the Javascript code that is generated by GWT.
Yes, it can be practical. I use Rails as my backend and GWT/GXT as my frontend. I love every bit of it! I couldn't stand worrying about browser incompatibilities, so GWT/GXT was a real joy. Also, I had already started my backend in Rails and did not have much experience with Java on the server, so I stuck with Rails.
You may want to take a look at an appropriate GWT Rest framework, as you won't be using RPC.
As an aside, there is one exception where you should use Java on the server. That's if you want to use Google App Engine.
Feel free to ask me any specific questions and I'll be happy to help you out.
Good Luck.
-JP