- If any engroup modules need to tag some resource, which resource can be a document or a CRM Lead etc, it does not call tag service (if it do so, tag service must be available and it depends on tag service) but send a message with necessary information to a specific channel name 'add.tag'. If a tag service is available, it will receive message from that channel and save tag as requested.

- When a new user register to engroup system, engroup must do: 1. Create new user document workspace 2. Synchronize user information with its forum and wiki and several tasks later we will add, for example create a account with the same name in chat server, email server. Instead of adding code in register user part and modifying code when there is new added action when register user, we simply send a message to 'add.user' channel, any interested parties would listen this channel and do their tasks.

Engroup runs in Spring Osgi platform that we can control the dependencies among engroup modules and engroup external libraries. With the goal to make engroup modules are loose coupling, Engroup uses publish-subscribe pattern to make two modules have no dependencies in code can talk together with the help from ActiveMQ (messaging server) and Spring Integration framework.

Here are an example that we use all of these tools in engroup: we have two modules engroup document management module and engroup tag resource. Each document could have many tags, when a document is saved into engroup data-store, it will post message to appropriate channel to notify engroup tag module to save its tag. The similar process is applied for any module support tag source in engroup.

• Set up embedded ActiveMQ server:

For deployment simplicity, engroup uses embedded ActiveMQ instance in its community edition.

        <!--  lets create an embedded ActiveMQ Broker -->
        <amq:broker useJmx="false" persistent="false">
                <amq:transportConnectors>
                        <amq:transportConnector uri="tcp://localhost:0" />
                </amq:transportConnectors>
        </amq:broker>

        <!--  ActiveMQ destinations to use  -->

        <!-- JMS ConnectionFactory to use, configuring the embedded broker using XML -->
        <amq:connectionFactory id="jmsFactory" brokerURL="vm://localhost" />

        <bean id="connectionFactory"
                class="org.springframework.jms.connection.SingleConnectionFactory">
                <property name="targetConnectionFactory">
                        <ref local="jmsFactory" />
                </property>
        </bean>

• Using Spring JMS to send message:

          <!--Convert java object to Json message format-->
          <bean id="messageConverter"
                  class="com.engroup.integration.jms.converter.JsonMessageConverter" />
  
          <bean id="jmsTemplate"
                  class="org.springframework.jms.core.JmsTemplate">
                  <property name="connectionFactory" ref="connectionFactory" />
                  <property name="messageConverter" ref="messageConverter"></property>
          </bean>
  
          <bean id="messageDispatcher"
                  class="com.engroup.integration.dispatcher.jms.JmsMessageDispatcher">
                  <property name="jmsTemplate" ref="jmsTemplate" />
          </bean>

• Define message destinations:

In engroup tag module, we define two message destinations: tagRemove and tagAdd

        <!--Import spring service connection factory from engroup esb module-->
        <osgi:reference id="connectionFactory"
                interface="javax.jms.ConnectionFactory" />

        <bean id="tagRemoveDest"
                class="org.apache.activemq.command.ActiveMQQueue">
                <constructor-arg value="tag.remove" />
        </bean>

        <bean id="tagAddDest"
                class="org.apache.activemq.command.ActiveMQQueue">
                <constructor-arg value="tag.add" />
        </bean>

• Define service activator for channels:

Now, we define service activator to handle tag add request

        <bean id="tagServiceActivator"
                class="com.engroup.module.tag.integration.TagServiceActivator">
                <property name="tagService" ref="tagService" />
        </bean>

        <!-- Establish add tag channel and related things -->

        <jms:inbound-gateway id="jmsTagAdd" request-destination="tagAddDest"
                request-channel="tag.addChannel" reply-timeout="5000"
                request-timeout="5000" />

        <integration:channel id="tag.addChannel" />

        <integration:channel id="tag.addChannelAfterTransformer" />

        <integration:channel id="tag.result" />

        <engroup-esb:json-to-map-transformer input-channel="tag.addChannel"
                output-channel="tag.addChannelAfterTransformer" />

        <!--Method addTag is used to receive message from channel &#39;tag.addChannelAfterTransformer&#39;,
process and return message to channel &#39;tag.result&#39;-->

        <integration:service-activator ref="tagServiceActivator"
                method="addTag" input-channel="tag.addChannelAfterTransformer"
                output-channel="tag.result">
        </integration:service-activator>

Here is a part of code of TagServiceActivator:

public void addTag(Map tagInfo) {
        String contentId = (String) tagInfo.get("contentId");
        String[] tags = (String[]) tagInfo.get("tags");

        tagService.deleteTagRelationshipOfContent(contentId);

        for (String tag : tags) {
            tagService.saveTagRelationship(contentId, tag.trim());
        }
    }

Remember to add dependency Spring integration packages into MANIFEST.MF file, otherwise you will get ClassNotFoundException while
running Osgi.

• Send message to tag module channels

We go to the code of any modules are interesting in tag resource, in our example it is document module. First, we import messageDispatcher to document service bean:

         <osgi:reference id="connectionFactory"
                interface="javax.jms.ConnectionFactory" />

        <osgi:reference id="messageDispatcher"
                interface="com.engroup.integration.dispatcher.MessageDispatcher" />

        <bean id="internalAccessValidatorFileService"
                class="com.engroup.module.ecm.service.impl.AccessValidatorFileSystemServiceImpl">
                <property name="jcrTemplate" ref="jcrMappingTemplate" />
                <property name="transactionService"
                        ref="contentTransactionService">
                </property>
                <property name="messageDispatcher" ref="messageDispatcher"></property>
        </bean>

When we want to send a message to add tag channel of engroup tag module, we just simply construct a message and messageDispatcher will do the rest:

    private void sendSaveTagRequest(String contentId, String[] tags) {
        Dictionary
 props = new Hashtable();
        props.put("contentId", contentId);
        props.put("tags", tags);
        messageDispatcher.dispatchObject(AvailableDestinationNames.TAG_ADD,
                props);
    }

Osgi can help you control strictly dependencies of a module with external packages if we control well, we can limit dependencies of one engroup module with other module. Spring Integration framework provides solution to integrate data among modules without modifying existing code base. At the beginning, we feel it is complex solution while combining Spring Integration with Osgi platform. However, after number of modules is grown continuously also data exchange among modules are increased, such complex solution become a simple one on both development and deployment. Could you have other solutions?

The following screen-shots are result of displaying tag in document module.

Engroup 1.5.07082009 has the following new features and improvements according with the previous one:

• eSoftHead replaces Engroup AIR client application by Flex client browser. In the past, several clients complained the security warning while they install Engroup client and additional steps they must do to install client application. With engroup web client, such obstacles are disappeared. eSoftHead will only distribute Engroup AIR client application in its commercial delivery since Engroup 1.6. It will interact with native application, processes and file system that a web application cannot do.
• Document Management Module:
• • Bookmark content: user can bookmark their favorite content and manage bookmarks and its folders easily.
  • Access control: it is the key feature of this release. Now, Engroup Document Management manage contents like Operating System manages its file systems.
  • Improve performance of listing/reading contents.
• Improving caching model and create web session-like variable to manage user sessions.
• Various bug fixes of other modules

All your suggestions/comments will be highly appreciated. Please do not hesitate to drop some lines to us at info@esofthead.com.

The most feasible solution that many companies choose is to developboth web and desktop presentations and reuse the back-end layer since, in general,the main difference between desktop and web applications is presentation layer. However, the middleware and persistent layer in web and desktop applications could be different depending on application architecture as well as communication protocol between presentation and back-end layers. Moreover, for enterprise applications, the cost for developing two separate presentation layers is so high. Let's imagine that your application has hundreds of views and many business processes at client side.

eSoftHead found a better solution - AIR/Flex. Being inspired by the article Building web and Adobe AIR applications from a shared Flex code base, we applied that Adobe solution on our product - Engroup ( http://esofthead.com/node/25) to build the both desktop and web applications using the same code base (this does not mean
that all source codes are portable between desktop and web environments but most of them). Our goal is to deliver Engroup to our customers in the same form. Engroup 1.5 Milestone 2 will be released in both versions: Web (for community use) and Desktop (for commercial use). You can see its two screenshots respectively below:

To make the dream of developing web and desktop applications in the same codebase become true, the following design is applied:

• Build projects based on component responsibility: if a component requires specific classes of AIR libraries, we split the project into 2 sub projects; one for web (if needed) and one for AIR. One example is dynamic loading Engroup modules. We created Platform_AIR including classes responsible for loading the modules of Engroup desktop and Platform_Web including classes responsible for loading the modules of Engroup web.
• Use Abstract Factory pattern instead of Factory method pattern: Abstract Factory pattern creates a family of different implementation services between web and desktop. It helps you manage the set of differences easier.
• Try to keep shared code between desktop and web as much as possible: While implementing, we always kept in mind of reducing the size of project specific for AIR and web as small as possible. For example, if we have 5 services that need to be implemented, we try to write 5 implementation classes. The result we got is 6-7 classes.
• Standardize communication protocol between client and server (regardless of whether client is desktop or web application): we chose Flash/Flex as platform of our Engroup rich internet application due to its capacity of developing both web and desktop application. To avoid using web frameworks for developing web client and Java/Qt etc for developing desktop client, Flash is a good choice with more than 95% code is shared in both web and desktop applications (including hundreds of page and components) in our project. Using Flex makes our application run on Flash platform easier. If we used standard web technology (AJAX and other web frameworks), we would have to use another communication to connect between client and server.

That's our story. If you need to develop an application running on both Web and Desktop, what will you do?

In our last project, we faced 2 challenges of how to build the SaaS platform including various modules; some are developed by ourselves and some are third parties (Forum, Wiki, Mail, etc.). With third-parties, we limit modifying their code base and database schema due to client's requirements. Here are our challenges:

Challenge 1: When a new user is registered, some our modules need to acknowledge and have re-actions. For example:

• Document Management module creates a personal document workspace for that user.
• Calendar module creates a personal calendar for that user.
• Forum and Wiki register that user to their user database because Engroup supports Single Sign On (SSO) mechanism. That means any user registered to Engroup user database can access Forum and Wiki resources without registering their user database.

Since our application follows SaaS model, the modules acknowledging and having re-actions to that registered user are dynamically discovered at runtime. This prohibits us from invoking module API in static manner.

Challenge 2: We want to implement audit trail process. Each module installed into our platform must follow the rules of tracking our user activities. Our goal is to build a common API sending user activities to reporting server but all our modules must loose coupling with the reporting API. This design helps us to configure reporting server in different machines easily.

We found out the solution for 2 application integration problems above - service bus. After evaluating 3 open source enterprise service bus (ESB) frameworks: Spring Integration, Mule, and Service Mix, Spring Integration finally is our choice, based on the criterion we set as follows:

Our sample project is an existing application that uses Spring as IOC container, we would like to expose service method to third-party applications. We have the interface and its implementation already.

public interface FileSystemService {
    SimpleFile getFileByPath(String filePath);
    ...
}

Enable Restful service

The request /filesystem/getFile/<path of file> will return the file information if it is existed. To make it happen, we add java REST annotation to our service:

@Path("/filesystem")
public interface FileSystemService {
    @GET
    @Path("/getFile/{filePath:.*}")
    @Produces("application/xml")
    SimpleFile getFileByPath(@PathParam("filePath") String filePath);
    ...
}

Because the path of file may contains the '/' character, '/' is also the special characters of Http request, thus in line 4 we must use regular expression * to tell RESTeasy that all requests starts with /getFille is mapped to method getFileByPath (for example: /getFile/content/A or /getFile/content/A/B/C is valid path). @Produces("application/xml") annotation tells RESTeasy that the output must be in XML form.

Content marshalling/unmarshalling

Class SimpleFile is the complex type, to force RESTeasy produces XML data to client you must instruct RESTeasy how to marshal SimpleFile class.

@XmlRootElement(namespace="http://www.esofthead.com/engroup")
public class SimpleFile extends Content {
    private long size;
        ...
}

Installation

It is easy to install RESTeasy in java application, read the Installation section of RESTeasy documentation. Read more Spring integration section if you want to integrate RESTeasy with Spring. And we finish enable RESTful support in our Java application! Like its name, it is easy to deploy Restful solution by using RESTeasy.

Unit test

After all above tasks, it is time to look unit test solution. RESTeasy provides two approaches to write unit test:

• Embedded Container:RESTeasy packages TJWS embeddable servlet container with JAX-RS. You can start the embedded server in your unit test and use Apache HttpClient to test your code. See the sample in attachment files for detail.
• Server side - Mock framework:If you are not comfortable with starting the embedded server and would like a simpler solution, RESTeasy Mock framework would be a good option.

  Create Dispatcher mock object and integrate RESTeasy with Spring

  dispatcher = MockDispatcherFactory.createDispatcher();
  SpringBeanProcessor processor = new SpringBeanProcessor(dispatcher,
                  null, null);
  factory = new ClassPathXmlApplicationContext("ecm-context-test.xml");
  factory.addBeanFactoryPostProcessor(processor);
   
  SpringResourceFactory noDefaults = new SpringResourceFactory(
                  "fileSystemService", factory, FileSystemService.class);
  dispatcher.getRegistry().addResourceFactory(noDefaults);

  Send the request and test expected output

  MockHttpRequest request = MockHttpRequest
                  .get("/filesystem/getFile/content/A");
  MockHttpResponse response = new MockHttpResponse();
  dispatcher.invoke(request, response);
   
  Assert.assertEquals(HttpServletResponse.SC_OK, response.getStatus());
  String responseBodyAsString = response.getContentAsString();
   
  JAXBContext jaxbContext = JAXBContext.newInstance(SimpleFile.class);
  Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();
  SimpleFile resultFile = (SimpleFile) unmarshaller
                  .unmarshal(new StringReader(responseBodyAsString));
   
  Assert.assertEquals(ContentConstants.FILE_ROOT_PATH + "/A", resultFile
                  .getPath());

  The result of request method is a XML string, the result of marshaling SimpleFile object to XML. To avoid testing base on XML data, we use JAXB to unmarshal XML data to SimpleFile object and validate data on this POJO.

I include two samples unit test for two approaches FileSystemRestTest-EmbeddedServer.java and FileSystemRestTest-MockFramework.java.This unit test sample is gotten from our engroup ECM module (you can get the Engroup product at http://esofthead.com/node/25), the unit test can not run because it lacks some classes of Engroup ECM module (this module is released in upcoming Engroup 1.5 version) but it provides the detail how to write unit test with RESTeasy.

In our application, we use Spring as IoC container, though set up the Ehcache manager is the easy task but we would like to use it with our Spring beans and exposed it as Osgi service. Spring modules is the good library help us easy in configuration. It provides the consistent abstraction caching to our application, hence we can use our cache facade with other caching libraries such as JBoss cache, JCS, OScache without chaging our application code. You could download the Spring Modules at https://springmodules.dev.java.net/.

Here are the following steps to configure Ehcache in Spring application

Configuring caching via ehcache.xml file

<?xml version="1.0" encoding="UTF-8"?>

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">

 <!--
 Configure it if you have overflowToDisk or diskPersistent enabled for any cache.
 java.io.tmpdir - Default temp file path
 -->
 <diskStore path="java.io.tmpdir" />

 <!--

    Mandatory Default Cache configuration. These settings will be applied to caches
    created programmtically using CacheManager.add(String cacheName).

    The defaultCache has an implicit name "default" which is a reserved cache name.
    -->
 <defaultCache maxElementsInMemory="10000" eternal="false"
  timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true"
  diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
  diskPersistent="false" diskExpiryThreadIntervalSeconds="120"
  memoryStoreEvictionPolicy="LRU" />

 <!--

    Sample cache named sampleCache1
    This cache contains a maximum in memory of 10000 elements, and will expire
    an element if it is idle for more than 5 minutes and lives for more than
    10 minutes.

    If there are more than 10000 elements it will overflow to the
    disk cache, which in this configuration will go to wherever java.io.tmp is
    defined on your system. On a standard Linux system this will be /tmp"

 -->
 <cache name="engroupCache" maxElementsInMemory="10000"
  maxElementsOnDisk="10000000" eternal="false" overflowToDisk="true"
  diskSpoolBufferSizeMB="20" timeToIdleSeconds="300"
  timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" />
</ehcache>

Declarating Ehcache in Spring context

<bean id="cacheManager"
 class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
 <property name="configLocation">
  <value>classpath:ehcache.xml</value>
 </property>
</bean>
</pre>
<pre lang="xml" xml:space="preserve" xml:lang="xml">
<bean id="cacheProviderFacade"
 class="org.springmodules.cache.provider.ehcache.EhCacheFacade">
 <property name="cacheManager" ref="cacheManager" />
</bean>

Programmatic use

Using ehcache is so simple, a unit test to make the test whether configuration is set up correctly and take the simple put/get could explain all.

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/META-INF/spring/cache-context.xml" })
public class CacheTest {
    @Autowired
    protected CacheProviderFacade cacheProviderFacade;

    @Test
    public void testCacheConfiguration() {
        Assert.assertNotNull(cacheProviderFacade);

        EhCacheCachingModel model = new EhCacheCachingModel();
        model.setCacheName("engroupCache");

        cacheProviderFacade.putInCache("a", model, new Integer(1));
        Integer fromCache = (Integer) cacheProviderFacade.getFromCache("a",
                model);
        Assert.assertEquals(new Integer(1), fromCache);
    }
}

Besides of using ehcache to create the session like variable in our application, we would like to use ehcache to cache SQL statement in iBatis and integrate with Terracotta to complete our distributing caching solution in our future project. I will keep the post on further caching usage in future posts. Keep reading!

ApplicationContext ctx = new ClasspathApplicationContext("example.xml");
BeanEx beanEx = (BeanEx)ctx.getBean("beanEx");

However, such calling will throw an exception in Spring DM platform because Spring requires the bundle context is existed. To overcome this issue, you just simply retrieving Spring-Osgi bean in the Activator class. Here are the example:

public class Activator implements BundleActivator {
 
    static ForumAuthenticationService forumService;
 
    static BundleContext bundleContext;
 
    public void start(BundleContext bundleContext) throws Exception {
        Activator.bundleContext = bundleContext;
    }
 
    public void stop(BundleContext arg0) throws Exception {
        forumService = null;
 
    }
 
    public static ForumAuthenticationService getAuthenticationService() {
        if (forumService == null) {
            OsgiBundleXmlApplicationContext context = new OsgiBundleXmlApplicationContext(
                    new String[] { "META-INF/spring/forum-context.xml" });
            context.setBundleContext(bundleContext);
            context.refresh();
            forumService = (ForumAuthenticationService) context
                    .getBean("forumAuthenticationService");
        }
 
        return forumService;
    }
 
}

In the above example, we need to get the spring service to make authenticate user in the legacy class and it is the simple solution how to retrieve the Spring-osgi service from some class in Osgi platform.

I am very pleased to announce that Engroup 1.0 after more than one month of previous release date. It is the bug fix release for the previous one, Engroup 1.0 beta. You can download the Engroup at eSoftHead site and see the last changes at here.

It is the first time eSoftHead releases the Engroup source codes under GPL license, and it is the major difference between the current release and the previous one. Releasing the source code to community is the key factor to help us continuously improve our source code quality, share knowledge and help other non-commercial organizations build RIA application using Adobe technology faster base on Engroup codebase. These benefits are over the threat that some guys may steal our source code and release the product with their copyright. We faced many issues to manage such big project, overcome the limitation of external libraries and tools and continuously optimize our source code, so we are welcome any your valuable comments to help us work better. You could download Engroup source code at eSoftHead site and read carefully the instruction at here.

Our development team are developing the next Engroup version, it focus on Document Management area and integrate Enterprise documents with varies Engroup modules such as HR, CRM. I will write the road-map for the next Engroup version in next several days and the first release of Engroup 1.0 will be planned in the next 2-3 weeks. Remember to keep update Engroup information on our website and this blog.