Release posts are about all I have time for these days…been heads down for a month getting an amqp/rabbitmq thing ready for release.

https://s3browse.springsource.com/browse/maven.springframework.org/milestone/org/springframework/integration/

Install and build Erlang

First, Check for the latest Erlang GA Release and note the version.

1. cd to the dir you wish to install into
2. wget http://erlang.org/download/otp_src_{version}.tar.gz
3. tar xzvf otp_src_{version}.tar.gz
4. cd otp_src_{version}
5. NOTE: run ./configure –help to see what opts you want to run with
6. ./configure
7. make
8. sudo make install
9. cd ../

Install RabbitMQ Server

First check the latest version of RabbitMQ Server and note the filename.

1. wget http://www.rabbitmq.com/releases/rabbitmq-server/v1.7.2/rabbitmq-server-generic-unix-1.7.2.tar.gz
2. tar xzvf rabbitmq-server-generic-unix-1.7.2.tar.gz
3. Complete the install and config from http://www.rabbitmq.com/install.html#generic-unix, making sure the logs, clustering, data and config dirs are set up
4. Start RabbitMQ: run rabbit../sbin/rabbitmq-server

If you need a few things first

1. First, if you don’t have it, download Apple XCode so you can compile Erlang with gcc. FYI the XCode download could not take longer, start it and go build an enterprise app in ROO, deploy it to the cloud, and when you’re done it may have completed. If I knew more about it I’d just download the particular compiler needed which is some form of C compiler. If I find out I’ll update this for a simpler install. if you know, send me a tweet: @hollyedelson
2. While that’s downloading, if you don’t have it, get the latest version of wget from http://ftp.gnu.org/pub/gnu/wget
3. On the command line:
   1. tar -xzf wget-{version}.tar.gz
   2. cd wget{version}
   3. ./configure
   4. make
   5. sudo make install
4. Now run the steps from Version A above.

Find Out More

rabbitmq.com erlang.org

Let’s start by adding the spring jmx dependency, which will be something like this, depending on the repos you are using:

<dependency>
<groupId>org.springframework</groupId>
<artifactId>org.springframework.core</artifactId>
<version>${spring.framework.version}</version>
</dependency>

Service Pojo

Now let’s set up some java classes for management. I have a business service that I want to monitor and a pojo to instrument.

@BusinessService
@ManagedResource(objectName = "bean:name=inventoryManager", description = "Inventory Service",
        log = true, logFile = "oms.log", currencyTimeLimit = 15, persistPolicy = "OnUpdate", persistPeriod = 200,
        persistLocation = "foo", persistName = "bar")
public class InventoryServiceImpl implements InventoryService {

    @Autowired private InventoryDao inventoryDao;

    @ManagedOperation(description = "Add two numbers")
    @ManagedOperationParameters({
            @ManagedOperationParameter(name = "x", description = "The first number"),
            @ManagedOperationParameter(name = "y", description = "The second number")})
    public int add(int x, int y) {
        return x + y;
    }

    @ManagedOperation(description = "Get inventory levels")
    @ManagedOperationParameters({@ManagedOperationParameter(name = "product", description = "The Product)})
    public long getInventoryLevel(Product product) {
        return getInventoryLevel(product.getSkew());
    }
}

First, let’s peak into my @BusinessService annotation in case you are wondering:

@Transactional
@Service
@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface BusinessService {
}

Annotating any of my service layer pojo’s makes them both transactional and with an instance created in the Spring context.

Entity Pojo

Now here is a simple pojo as an entity or javabean, what have you:

@ManagedResource(objectName = "bean:name=myPojoEntity", description = "My Managed Bean", log = true,
        logFile = "oms.log", currencyTimeLimit = 15, persistPolicy = "OnUpdate", persistPeriod = 200,
        persistLocation = "foo", persistName = "bar")
public class MyPojo {

    private long somethingToTuneInRuntime;

    /* Creates a writeable attribute for managing */
    @ManagedAttribute(description = "Tunable In Runtime Attribute",
            currencyTimeLimit = 20,
            defaultValue = "bar",
            persistPolicy = "OnUpdate")
    public void setSomethingToTuneInRuntime(long value) {
        this.somethingToTuneInRuntime = value;
    }

    @ManagedAttribute(defaultValue = "foo", persistPeriod = 300)
    public String getSomethingToTuneInRuntime() {
        return somethingToTuneInRuntime;
    }
}

Spring Config

Now let’s configure Spring to autoregister our pojos to export and manage/monitor:
Create a jmx-context.xml file in your WEB-INF/* dir

Add: <context:mbean-export/>

Activates default exporting of MBeans by detecting standard MBeans in the Spring
context as well as @ManagedResource annotations on Spring-defined beans.
Rather than defining an MBeanExporter bean, just provide this single element. I could walk you through a simple, simpler and simplest config of spring jmx but with annotational config in the simplest requirements, this is all you need to do to get up and running. If you need object naming in multiple vm situations, you can easily do that and other things too but, that’s out of scope for this post

This week I’m finally getting it finished and available to check out from svn. I’ve had a project set up in one of our public-facing repositories, the code will be available next week. Shoot me an email via my SpringSource address – attendees have that email, or find me on linkedin.com

May 10 I officially move into engineering!

@Repository
public class MyDaoImpl implements MyDao { .. }

spring creates an instance of it in the IoC container as with any other stereotype annotation (@Component, @Service) but it can also add exception translation if you explicitly add this bean declaration to your config:
<bean class=”org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor”/>

This enables translation of native runtime resource exceptions that would otherwise be vendor-specific (database (oracle, etc), orm (hibernate, jpa, etc) to Spring’s runtime exception hierarchy regardless of what vendors you use over time. As it is simply enabling a feature in the Spring Framework vs something you would use, it does not require a bean id.

Also as the stereotype annotations are meta annotations you can do this to enrich behavior easily

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Repository
@Primary
@Lazy
public @interface MyRepository {
}

@MyRepository
public class OtherFooDao implements FooDao { .. }

In college I wrote a 300-page senior thesis entitled, “Energy Pathways In Biological Systems”. It was within the context of genetics to microbiology up through complex pathways of micro-climates to ecosystems and even pathways of migratory animals (Arctic Wolves that cover at least 1,000 mile territories to Terns and Whales that have annual migration patterns covering half the earth). For each there is movement of elements in space and time. I had a blast researching and writing it but my fascination revolved around that shared concept over seemingly vast discrepancies of scale that were actually sharing massive similarities, being only sizable to other scales, can only be in a relative framework of complexity.

Think of systems as an atom. There are layers or levels and activity going on all the time. Now think of this atomic model with pathways repetitively used for resources to move, kind of like corridors. Resources behave differently from other resources, thus the corridors are different, the speed of motion is different and the size is different. Also production and consumption of those resources is different. Entropy works differently based on environment, among other factors.

The pathways of genetic information through a cell move in a seemingly small scale to Nitrogen pathways in a rain forest but the complexity in a cell looking down to the smaller elements in that system is great. Also in a rain forest, Nitrogen molecules and everything they interact with as they move through that system, looking up to larger components, are equally great and yet looking down to the components that amass that system we see the same thing.

Think about that – scale, if only quantifiable by the scale of other systems, is relative. So what could lend to differentiation? Complexity could be an important part of the equation. So what about this – System A is larger and has more components than System B. System B is less complex than System A. If both systems are replicated many times and distributed which may fare better? Hard to say with such a limited theoretical idea but what about Okham’s Razor – the simplest way is the best, essentially. In mechanics, the less moving parts, the less points of failure. A human is a complicated system, a virus is a very simple system and yet a virus can so easily attack the more complicated system. Cells replicate very quickly, and each new cell gets its own copy of the genetic instructions the original parent cell had. I’m rambling but just trying to give some simple examples to think about.

So how do we properly think about scale in systems? What can we learn from successful patterns of scalability that are all around us?

This is a good guide to simply generating ssh keys: http://help.github.com/mac-key-setup

1. I have a simplistic junit test that merely kicks off the service method to view the path of execution:

/**
 * TaskTests
 *
 * @author Helena Edelson
 * @since v 1.0
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"classpath:infrastructure-context.xml"})
public class TaskTests extends BaseTest {
    protected static final Logger logger = Logger.getLogger(TaskTests.class);
    @Autowired private OrderService orderService;

    @Test
    public void testExecution(){
        logger.debug("Starting execution thread...");
        orderService.dispatch(new Order());
    }
}

2. A simple context config:

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:context=”http://www.springframework.org/schema/context”
xmlns:task=”http://www.springframework.org/schema/task”
xmlns:aop=”http://www.springframework.org/schema/aop”
xmlns:p=”http://www.springframework.org/schema/p”
xsi:schemaLocation=”
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task-3.0.xsd”>

<bean id=”taskExecutor” class=”org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor” p:corePoolSize=”5″ p:maxPoolSize=”25″/>

<!– OR alternately: Creates a org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor –>
<task:executor id=”taskExecutor” pool-size=”5-25″ queue-capacity=”100″ rejection-policy=”CALLER_RUNS”/>

</beans>

3. OrderService that delegates to the ThreadPoolTaskExecutor:

/**
 * OrderServiceImpl is used for both orders and returns
 *
 * @author Helena Edelson
 * @MessageEndpoint which is a @Component
 * @since Dec 29, 2009
 */
@Service("orderService")
public class OrderServiceImpl implements OrderService {
    private OrderDao orderDao;
    private MerchantService merchantService;
    private ReceivingService receivingService;
    @Autowired private TaskExecutor taskExecutor;

    @Autowired
    public OrderServiceImpl(OrderDao orderDao, ReceivingService receivingService, MerchantService merchantService) {
        this.orderDao = orderDao;
        this.receivingService = receivingService;
        this.merchantService = merchantService;
    }

    public final void dispatch(final Order order) {
        logger.debug("Starting dispatch execution...");

        if (this.taskExecutor != null) {
            this.taskExecutor.execute(new Runnable() {
                public void run() {
                    executorAsync(order);
                }
            });
        }

        logger.debug("Completed dispatch execution...");
    }

    private final void executorAsync(final Order order) {
        logger.debug("Starting Async execution...");

        daoDatasourceOne.createOrder(order);
        daoDatasourceTwo.createOrder(order);

        logger.debug("Completed Async execution...");
    }

/* Where the output will be: Note the dispatch method returns control to its caller before the async method begins:
2010-01-27 13:23:27,546 [main] DEBUG org.springsource.oms.infrastructure.TaskTests  - Starting execution thread...
2010-01-27 13:23:27,546 [main] DEBUG org.springsource.oms.domain.services.OrderServiceImpl  - Starting dispatch execution...
2010-01-27 13:23:27,546 [main] DEBUG org.springsource.oms.domain.services.OrderServiceImpl  - Completed dispatch execution...
2010-01-27 13:23:27,546 [taskExecutor-1] DEBUG org.springsource.oms.domain.services.OrderServiceImpl  - Starting Async execution...
persisting org.springsource.oms.domain.entities.Order@1f10a67
*/

/**
* Alternately for a different scenario you can play around with this:
*/
public void withExecutor(final Order order) {
        try {
            CompletionService