Labels: Scala, Spring

¶ 11:14 4 comments

Labels: AMQP, RabbitMQ, Spring, Spring AMQP

¶ 10:22 0 comments

• Every project with a certain complexity has this problem. It needs to be adjusted to different users, use cases etc. A common problem should have a standardized solution
• Reading in configuration files is not that easy. You have to handle exceptions if the file does not exist. You need to figure out what to do if a certain value is not set. You might want to have multiple files that can override configurations. I have to admit that I have seen projects in which the most complex code handled the configuration. Spring's XML configuration is already a powerful solution for this. And if you want to use properties files: The PropertyPlaceholderConfigurere allows to use those for configurations as well without writing any code. The PropertyPlaceholderConfigurere is very flexible - see its JavaDoc. But even if this is not enough: Using the BeanFactoryPostProcessor interface you can add your own configuration extensions.
• As configuration is needed almost anywhere the class handling the configuration file becomes a dependency for a lot of classes. This is not a good design. Using DI the configuration will be injected and there is no such dependency.
• Testing will also be hard if each class depends on the class handling the configuration. You will need a complete and correct configuration even for the smallest unit test. Otherwise the configuration cannot be read in. Changing the configuration for a specific test will either be impossible or the code for the configuration will become even more complex. Using the DI approach this is no problem as the configuration is injected and you can easily inject different values.

Labels: Configuration, Dependency Injection, Spring

¶ 11:08 1 comments

• Agim Emruli will start the day by discusssing "Web, RIA and mobile Aapplications with Spring". The client technologies are constantly evolving and this talk will present an overview about the current state of affairs.
• Then Jürgen Höller will talk about the upcoming Spring 3.1 release. Jürgen is the lead engineer so we will get some information from the source.
• Next is a talk by me about "Spring in the Cloud". I will show why Spring is a good solution for the Cloud and what you can do with it right now.
• Oliver will discuss Spring Data. He is one of the developers on that project which will support relational databases as well as NoSQL databases.
• Stefan Scheidt will show how to create a backend for an iPhone application using Spring Roo. This is a very good show case about Roo's capabilities.
• Finally we will have a panel to discuss any questions and get some feedback. So all the speakers will be there and it will be highly interactive.

Labels: JAX 2011, Spring

¶ 14:52 0 comments

• In the original post I mentioned Groovy/Grails and Spring Roo as new approaches to gain more productivity. Shortly after the blog post Spring Roo 1.1.0 (blog post) was launched and 1.1.1 shortly thereafter (blog post). The new releases include Google App Engine support, GWT support and database reverse engineering.
• For NoSQL there is the Spring Data project (see project homepage) which supports many NoSQL and relational datastore. I believe this is the most important and most ambitious project in the NoSQL space for Java. The broad support for all the different data stores is quite unique.
• Spring Social offers uniform support for most social web site, see project homepage. This is very important as social media change the way the internet is used and in particular offers new ways to become more popular on the web.
• Another challenge is integration into existing applications. Spring Integration 2.0 was launched, see this blog post.
• Besides the Caching abstraction in Spring 3.1 already mentioned in the original post there is also Spring GemFire to support our own Data Fabric GemFire in Spring.
• Messaging: Support for AMQP is developed in the Spring AMQP project (see project homepage).

Labels: Challenges, Spring, SpringSource

¶ 11:00 2 comments

History

Spring has established itself as a very popular solution for Enterprise Java applications. In particular the advantages of Spring as compared EJB 1.x / 2.x were very obvious and were a major reason for Spring's success.

The Current State

Due to Spring’s early success and adoption, Java EE 5 and Java EE 6 were pushed to greatly simplify the Java EE programming model, increase developer productivity and become much simpler to use than previous versions. The current Java EE 6 solutions are thus just now achieving the ability to compete against Spring's programming model. Developers now are ready to ask the question "Why you would prefer Spring?" Here is my take:

• Many key elements of Java EE 6 such as JSR-330 (@Inject), Common Annotations (@Resource, @RolesAllowed etc) and even some EJB annotations (@TransactionAttribute, @Asynchronous etc) are supported by Spring. So you can choose a programming model that is very similar to the Java EE programming model.
• There are differences, among others: Spring typically uses Singleton beans, EJB typically used pooled beans - and of course the annotations for them are different. But do you really think this will impact productivity or even the success of a project?
• However, Spring is much more flexible. Instead of the annotations mentioned above you can choose XML or Java based configurations. You can create custom extension using AOP. You can use the JMS and JDBC abstractions - all of that is not included in Java EE. So the programming model Spring can almost be considered a superset of Java EE. Usually more power and flexibility to choose different options is considered a superior solution.
• There is a difference in platforms that you can deploy on: Typically you will need to use Java EE application server for Java EE solutions while Spring is perfectly happy to run on Tomcat or other simple servers. Tomcat is the predominant server in the marketplace so this is actually an important difference. (Let me add that you might use OpenEJB on Tomcat i.e. you can support more of the Java EE APIs on Tomcat if you really want to.) Also there are problems: If you want to run Java EE 6 you are limited to the very small set of certified servers. If you have a strategic commitment to an application server vendor who doesn't support Java EE 6 you can still use Spring. If operations won't install the latest release of your application server, you can still use Spring. Spring happily runs in these environments.
• Of course Java EE also has an advantage: the fact that Java EE is baked into the server. Therefore you don't need to deploy it with the application which can make some things easier. It might be easier to set up your infrastructure. It might be easier to package and share your application. But I personally would prefer to be flexible in deployment over these advantages.

Before we start a flame war and get lost in technical details let me reiterate: Java EE and Spring can have a similar programming model. Spring is more flexible and I would prefer it. But: I don't think your project will fail because of the decision you made concerning this. And: I think a Java EE vs. Spring shoot out will be boring. If you do a side by side comparison you will end up with minor differences such as @Component instead of @Stateless or whether you will need to deploy some additional JARs. While that might be impressive in a demo I don't believe this will convince anyone to use one platform or the other. Certain features of Spring (e.g. the flexibility to use XML or Java based configuration) will probably not be shown as they just cannot be done using Java EE.

Why I don't care

So if a side by side comparison doesn't make a lot of sense - why would I choose Spring? There has to be a clear advantage somewhere to definitely answer this question. A personal note at this point: I am frequently work at a shared office space with some JavaScript and Ruby on Rails guys - I am the only Java guy there (and sometimes I think they pity me). After talking a lot with these other developers, I believe we need a compelling Java story that can live up to their developer experience. If Java EE and Spring are both on a comparable level concerning productivity we need to come up with novel ideas to improve. Looking at Ruby on Rails helps here - the approach is to combine a dynamic language with a powerful framework and a code generator. The next level of productivity is not Java EE vs. Spring. It must be something that can counter the productivity of Ruby on Rails. I believe this is:

• Groovy / Grails: it combines a dynamic language with a powerful framework and a code generator - like Ruby on Rails. The only difference is that the solution is more adapted to the JVM and has better integration with Java, the most important platform in the Enterprise space.
• Spring Roo: it combines Java/AsepctJ with a powerful framework (Spring) and a code generator - like Ruby on Rails. This is easier to learn for Spring developers than Groovy / Grails and has therefore appeals to a different audience.

So if you look at productivity the comparision should not be "Java EE vs. Spring" but rather "Groovy / Grails vs. Spring Roo vs. Ruby on Rails". Better productivity is not gained on the level of the framework or the programming model any more.

Asking the Wrong Question

The other reason why I think "Spring vs. Java EE" is the wrong question is: Both models on their own do not solve the challenges I typically see in projects. Let me give you some examples:

• Integration: Today almost any project will need to integrate with other technologies through file transfer, Web Services, messaging etc. There are well known patterns for this - the Enterprise Integration Patterns by Gregor Hohpe. Neither Java EE nor the core Spring Framework help here - you will need to use a framework like Spring Integration, Apache Camel or its competitors.
• Batches: A lot of project use batches. They might import data - or to run complex business logic. In the latter case, chances are that the batches are actually mission critical. Neither Java EE nor the core Spring Framework help here - you will need to use a framework like Spring Batch. (I believe there are no real competitors but I might be wrong).
• Caching: Like many of our competitors we at SpringSource believe that caching is a very important part for a performant enterprise solution - you can tell by the product strategy in the Java EE space. Again this is something that Java EE does not cover. However, for Spring a cache abstraction is planned in Spring 3.1. A standard in Java EE - if there is ever to be one - won't be there until the next Java EE release.
• Again looking at my Ruby on Rails office mates: They deploy a lot of projects into the cloud. Offerings like Heroku make that extremly simple. Of course you could run Spring or Java EE on an IaaS like Amazon EC2 or VMware vCloud Director cloud. But it might be easier to use a PaaS that will deal with scaling, fault tolerance etc automatically and it usually offers some interesting additional services. Google App Engine as the predominant public PaaS as well as VMforce have strategic commitments to Spring. The Cloud has clear economic benefits so this technology will become more and more important. The Java platform has to have a solution here - otherwise it will eventually become irrelevant.
• More and more data is stored in non relational databases (NoSQL). Actually that is the only way we will be able to cope with the exponentially growing amount of data and the structures like graphs in social networks or unstructured user content. Again it this quite common in the Ruby on Rails camp - while for Java there is currently a lack of APIs. Java EE has no support - and it won't for a while. There are so many non relational stores a standard will be hard to define in a standards body.
• Also integration in social networks like Twitter, Facebook and other common internet services will be more and more important. Again this is common in the Ruby on Rails community. And at least one of my customers with a very large web site mentioned this as "a feature marketing will love" - remember Facebook is almost as important a source for internet traffic as Google nowadays. We need solutions for this in the Java space.
• Messaging: In the Java EE community the JMS standard has been very stable for 10+ years. Outside the Java community there was actually innovation. Therefore a lot of the office mates use RabbitMQ - and that is also the predominant messaging solution on the EC2 cloud. It is standardized on the protocol level (AMQP) and it is much more flexible (not just topics and queues). That is why SpringSource bought Rabbit Technologies and why we are investing considerable resources in the Spring-AMQP project.

So there are a lot of challenges Java EE just has no solution for. A side by side comparison of Spring and Java EE might lure you to believe that JSF + Spring / Java EE + database is all you will ever need. Look at your projects and decide for yourself if that is true. It certainly contradicts my experience.

Sum Up

To cut a long story short:

• You won't see a lot of change in your productivity if you use Spring or the newest Java EE releases. The next level of productivity is not about these programming models but about Groovy / Grails or Spring Roo.
• Spring and Java EE will only be a part of your technology stack. You will need to look at solutions for a lot of issues outside these. That is why SpringSource and others are currently investing heavily in creating such solutions for the Java crowd. And a lot of these solutions are well integrated with Spring.

...and a last thing

So you have read this blog post to the end. That is great - thanks a lot! Please don't start a religious battle now. Instead code something or do something fun. Enjoy!

Labels: I don't care, Java EE, Spring

¶ 10:42 37 comments

• What is the Cloud?
• Advantages of Cloud technologies
• Developing for the Cloud with Spring Roo
• Infrastructure as a Service (IaaS): How applications can be developed with Amazon EC2 and VMware technologies
• Platform as a Service (PaaS): Developing Java application for the Google App Engine and SpringSource Cloud Foundry
• PaaS: Concepts of VMforce
• Architecture for the Cloud
• Data in the Cloud: NoSQL with the example Redis
• Distributed Caching and Data Fabrics for better Scalability with GemFire
• Cloud messaging: RabbitMQ, the AMQP protocol and Java

Labels: Cloud, GemFire, RabbitMQ, Redis, Spring

¶ 10:00 0 comments

Labels: Consultant, Grails, Groovy, Hyperic, Job, Spring, tc Server, Tomcat

¶ 15:26 0 comments

• Web Site


• Agenda


• Vortragende

Labels: Grails, Groovy, S2G Forum, Spring

¶ 10:32 0 comments

• Web Site


• Agenda


• Vortragende

Labels: Grails, Groovy, Hyperic, München, S2G Forum, Spring, Tomcat

¶ 00:43 0 comments

Labels: Spring, Spring Buch

¶ 20:23 2 comments

package com.blogspot.jandiandme;
public class MyService {

 private MyRepository myRepository;

 public void setMyRepository(MyRepository myRepository) {
  this.myRepository = myRepository;
 }
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd"
 xmlns:context="http://www.springframework.org/schema/context"
 default-autowire="byType">

 <context:component-scan base-package="com.blogspot.jandiandme"
  use-default-filters="false">
  <context:include-filter type="regex"
   expression=".*Repository" />
  <context:include-filter type="regex"
   expression=".*Service" />
 </context:component-scan>

</beans>

Labels: Spring

¶ 14:15 2 comments

• Monitoring und Performance Optimierungen mit Spring (Eberhard Wolff)


• Portabilität auf Framework-Level - Spring als Runtime (Agim Emruli)


• Hyperic HQ - Die Open-Source-Monitoring-Lösung (Agim Emruli)


• Tomcat und OSGi als Plattformen: Alternativen, Vor- und Nachteile (Eberhard Wolff)

Labels: Betrieb, Düsseldorf, Performance, Skalierbarkeit, Spring

¶ 10:21 0 comments

Labels: SE-Radio, Spring

¶ 08:08 1 comments

• Chancen und Risiken


• Bedeutung von Vorgehen und Technik

• Spring als Grundlage moderner Architekturen


• Qualität und Wartbarkeit durch Testautomatisierung


• Effizienz durch Vermeidung nichtdifferenzierender Entwicklung

• Spring als Integrationsplattform


• Effizienz durch Vermeidung nichtdifferenzierender Entwicklung


• Fallbeispiele

• Monitoring und Administration


• tc Server, dm Server und Hyperic


• Praxisbeispiele

Labels: Opitz, Spring

¶ 10:40 0 comments

Labels: Betrieb, dm Server, Hyperic, Performance, Skalierbarkeit, Spring, tc Server, Tomcat

¶ 10:12 0 comments

• So das Projekt, das zwar auf einem vollständigen Java-EE-Server läuft, aber auf JDK 1.4. Java EE würde hier EJB 2.x anbieten, was niemand wirklich will. Die einzige sinnvolle Alternative ist also Spring.


• Oder das Projekt, dass auf einer Standard-Software aufbaut. Die läuft auf einem gebundelten Tomcat - der eben kein vollständiges Java EE anbietet. Selbst wenn man wollte, kann man kein vollständiges Java EE nutzen.


• Oder das Projekt, das von EJB 3 wegmigriert, um auf Tomcat umzusteigen - weil man Tomcat als gegenüber Java EE als Ablaufumgebung vorzieht.

Labels: Java EE, Spring, Tomcat

¶ 11:30 0 comments

Labels: Spring

¶ 12:14 0 comments

Labels: dm Server, QuinScape, Spring

¶ 12:38 0 comments

Labels: Architektur, Spring, WJAX

¶ 10:33 0 comments