‘architecture’

Building COMET applications with Redis PubSub, Atmosphere and Akka

Tuesday, August 3rd, 2010

Atmosphere is a brilliant framework when you need to make your JVM web application COMET-enabled. It’s simple, lightweight and written in a very good manner (wise OO and OSGi bundles that makes it easy to extend). However, if you want to build a durable application of a really high load with thousands of clients simultaneously flooding the network with the tones of messages, you’ll probably want have to more control over the COMETed broadcast of messages. Simplifying the state of things, Atmosphere broadcaster is based on two in-memory queues: the queue of messages and the queue of references to the waiting clients. The aim is to replace those queues with a MQ solution that will allow managing active topics and clients waiting for messages.

Since recently, Redis has a strong story to tell about messaging – Redis PubSub is a nice performant alternative to the messaging mastodons like ActiveMQ. Its API is extremely simple though it offers more than enough, if you just want to take message queues away from the JVM. Bonus and the source of additional motivation (at least for me) is that Redis PubSub has a Scala actor-based client API and integration with Akka Framework

So, the following components will make the core of the COMETed system based on Redis:

  1. Akka. Offers Scala idiomatic integration with Redis and capabilities for building fault-tolerant publishers/subscribers;
  2. Atmosphere. One of the most attractive Atmosphere framework features is that it knows how to enable NIO capabilities at the most popular JVM application servers. Whilst client works with a high-level abstract API (say, suspends HTTP connection), an appropriate server NIO implementation is used on the background (Continuations mechanism, if the server is Jetty, or CometProcessor for Tomat). Moreover, in the latest versions the same API can also be used to transfer data over Websockets;
  3. Redis PubSub as a provider and background of messaging (gives ability to post/control topics through Redis admin utilities; watch queues, etc.);

(more…)

Tags: , , , , , , , ,
Posted in Software Development | Comments Off

Flexible load balancing with Akka in Scala

Monday, May 10th, 2010



    Scala concurrency is based on Actors paradigm. Actors communicate with each other sending messages and doesn’t share global state, which guarantees safe concurrency. Every actor has own mailbox the messages are added to, and processes one message at a time.
    Akka framework introduces simplifications and richer capabilities compared with the native actor model. Configurable message dispatchers and fault tolerance make Akka’s Actors implementation an enterprise-scale alternative. 

    Dispatcher   

    Work stealing dispatcher, like any other Akka’s dispatcher, delivers messages to actors’ mailboxes. Message delivery is backed by Java’s ExecutorService (with manageable thread pool). Unique feature of the work stealing dispatcher is that if the message was initially sent to the busy actor, dispatcher finds another actor (“thief”) that can process the message, and puts it to the actor’s mailbox.
    Below we create a new instance of work stealing dispatcher that will be used by the pool of actors. Dispather has its own thread pool that is used for effective asynchronous distribution of messages. Thread pool size equals to the count of actors that will be load balanced:

(more…)

Tags: , ,
Posted in Software Development | 2 Comments »

Implementing Jersey REST-services in Scala

Thursday, March 4th, 2010



    In this article I’m going to continue exploring enterprisy (thanks JavaPosse#298 for this expression) development with Scala and sharing my experience with those Java developers, who slowly start to recognize power and usability of this beautiful language, combined with ability to stay in the comfort area of both known and new high-grade Java frameworks. Previously, I briefly described, how iBatis 3.0 framework can be used together with Scala in order to build a robust persistence layer. In what follows I will show, how easy it is to build REST endpoints with JAX-RS and SJSON library in Scala.

    Jersey is the free production-ready implementation of jsr-311. It’s one of the simplest JAX-RS frameworks to use due to POJO (and also POSO) support with a wide range of annotations, and a very small additional configuration to be done in web.xml (no web.xml alteration at all is required if you use Grizzly (Simple/lightweight) HTTP web server, but I’m going to deploy my services on Tomcat). SJSON is the library developed by Debasish Ghosh that allows users to serialize/deserialize Scala classes into JSON with a very small effort (literlly, 1-2 annotations per class).

(more…)

Tags: , , , , , , , ,
Posted in Software Development | 1 Comment »

RESTful orchestration with JOpera

Wednesday, January 20th, 2010



Web services orchestration

In considering the concept of orchestration, we generally think about the sequence of activities (calls to the services) representing the business process. Decoupling orchestration logic from service layer provides with agility (services orthogonality, increased re-usability, and overall scalability of the system). The other orchestration purpose is in defining compositions (mashups) of services that significantly reduce complexity of the system to consumer (encapsulation of the composition’s inner organization increases its steadiness).

Enterprise integration methodology addresses orchestration with on the most complex patterns – process manager. With the benefit of centralized execution, simplified monitoring and prompt reaction on the changed situation, it adds significant complexity to design. Order of components execution (process) is described in the appropriate script. After each call to system components, control returns to the process manager that stores instances of the running processes, and knows, which next action should be executed within the process. Real-world example of the language that describes execution of activities is BPEL. BPEL is supported by a variety of process management engines (both commercial and open-source). Though it’s not an easy language to read (it’s rather machine-readable, than human-readable), majority of process management systems provide tools for visual process modeling, which make development rapid and comfortable (among them well-known TIBCO BusinessWorks, Microsoft BizTalk Server and many other)

Orchestration in REST

The composition of RESTful Web services is typically associated with so-called Web 2.0 Mashups, where this emerging technology helps to reduce the complexity and the effort involved in scraping the data out of HTML Web pages. Demand for orchestration has the very same nature as for the Big web services. The problem is that industry standard forWS orchestration, WS-BPEL, is tightly coupled with WSDL and can hardly be applied to REST. One way to work with a REST service in BPEL would be to generate WSDL/Schema that described the REST interactions and then create an adapter service or other means to communicate with the REST endpoint.

RS-world alternative to WSDL – WADL, which is claimed for repeating the mistakes of WSDL. Status and usability of WADL is still in question (it doesn’t have much followers), and it’s not supported by the current version of BPEL.
BPEL4REST is a lightweight BPEL extension, separate branch of BPEL, natively supports the composition of RESTful Web services using business processes. It declares communications with services without WADL interface.

Tools for RESTful orchestration

In spite of the fact orchestration is a trendy topic these days, there are not so many tools that can cope with REST orchestration. The engines I’ve set my choice on are:

a. Apache ODE (http://ode.apache.org/).

Pros: Apache reputation (long service life, overall solution quality); process container can be deployed to any application server and has an internal database (Derby).

Cons: supports only one orchestration language – WS-BPEL (primarily intended on integration of big services, though documentation has some good examples of declaring REST services as BPEL partners http://ode.apache.org/restful-bpel-part-ii.html ).

b. JBoss jBPM (http://www.jboss.com/products/jbpm/).

Pros: has visual process modeler; supports 3 orchestration languages (jPDL, BPEL, Pageflow); supports REST-services.

Cons: process server is the java application that was developed to work onJBoss (though there are many examples of porting Process Virtual Machine to other application servers on the Web, problems may exist, as PVM was tested only against JBoss)

c. JOpera for Eclipse (http://www.jopera.org/).

Pros: Big variety of components that can be parts of the process (not only WS or RS, but shell scripts, Java snippets, XSLT transformations, etc.); has good UI to design processes, based on Eclipse; process definitions (service compositions) deployed to JOpera server, can be accessed via REST and WS endpoints.

Cons: uses it’s own orchestration language built on top of BPEL; process server is tightly coupled with Jetty.

From me, subjectively, it’s a great joy to work with JOpera process designer. Development process wasn’t that fascinating to me for a long time;

Simple use-case

A simple use-case to demonstrate JOpera in action is caching of REST-service feedback via EhCache Server REST endpoint. The benefit of this approach is that the change is non-intrusive, and at any moment of time consumer may access both the original service and the composition (specified by the process).
Though it’s not the best example of a business process (as a matter of fact, caching has nothing to with business vertical), it can display implementation of different process tasks and elements inJOpera.

JOpera implementation

You can find basic information about JOpera installation at the home page (http://www.jopera.org/docs/help/jop.html). I’ll further concentrate on the steps required to implement the orchestration task described above. Service composition in JOpera is defined with a Process, which defines the control and data flow between the various components (the both flow are modelled visually).

(more…)

Tags: , , ,
Posted in Software Development | 3 Comments »

Basic toolkit for building a RESTful SOA

Tuesday, January 12th, 2010





Whilst REST is growing in popularity now more than ever, and SOA is here for more than a decade, a lot of developers (even experienced ones) are still confused with RESTful SOA definition. SOA is often considered as a system built of loosely coupled services calling each other in RPC-style, whereas SOA as a matter of fact is a fundamental methodology for building applications of different domains from reusable services (and their compositions), using orchestration and choreography principles (SCA is wonderful demo of this approach). Distinctive features of SOA are:

  • Description. Service has a contract that explains consumers the rules of collaboration;
  • Discovery. Ability of service (and its contract) to be found and reused;
  • Orchestration and Choreography. Loose coupling/decoupling is achieved with meta-languages such as BPEL;

WS-* has a well-defined stack meeting all requirements above (and many others): WSDL for service definition, UDDI for discovery, BPEL for defining orchestration, etc. As for REST, there’s no de facto SOA toolkit. Keeping simplicity and extensibility in mind, I’m setting my choice on AtomPub and jPDL.

Atom publishing protocol

Atom publishing protocol originally created to serve Atom Syndication Standard, can be applied to a wider range of resources, and work as an application level protocol for resource publishing and discovery. AtomPub defines “collections” of resources and “workspaces” as group of collections. “Service [Document]” contains the location and capabilities of one or more Collections, grouped into Workspaces.

Small example below explains how the simple REST-service can be described with AtomPub:

   <?xml version="1.0" encoding='utf-8'?>
   <service xmlns="http://www.w3.org/2007/app"
            xmlns:atom="http://www.w3.org/2005/Atom">
     <workspace>
       <atom:title>My Pictures</atom:title>
       <collection
           href="http://example.org/pic" >
         <atom:title>Pictures</atom:title>
         <accept>image/png</accept>
         <accept>image/jpeg</accept>
         <accept>image/gif</accept>
       </collection>
     </workspace>

In this example, a new resource will be created only if “accept” element with the appropriate type exists.

jPDL (jBPM)

jBPM is a platform developed by JBoss supporting business process definition languages, such as jPDL (visualized process modeling language), BPEL and Pageflow. Process languages are running under Process Virtual Machine (PVM) – another JBoss solution, process server that builds and executes process graphs in runtime. PVM is integrated with JBoss application server, although you can find demos of porting PVM to Glassfish, Weblogic and other app servers on the Internet (in the very core, PVM is nothing more than a simple Java library). Visual process modeling is done in a manner quite similar to BPEL modeling in NetBeans.

Here you can find a good demo of REST-services orchestrated with jBPM.

Tags: , , , ,
Posted in Software Development | Comments Off

Aspects in UML

Saturday, January 9th, 2010

     Several days ago I was somewhat stuck trying to find a consisten way to display aspects (AOP) on UML diagram. Surfing the Internet I’ve managed to find two good references:

     According to the first, apsects can be represented with the standard stack of component diagram: component, port and information flow. The diagram below is constructed in Enterprise Architect 7.5:

Tags: , ,
Posted in Software Development | Comments Off

The second life of AOP

Tuesday, January 5th, 2010

Going back to the times when I was playing computer games one of my favorites was Diablo 2. To my shame I’ve been sitting for it days and nights for almost 2 months. The second my favorite was C++, though I was far not as good in it as in Blizzard’s blockbuster.

A decade later not much has changed. Two things I’d be happy to see in late 2010 are Diablo 3 and Java 7 (and the both will unlikely appear).

One of the most anticipated features of Java 7 is “closures” (which are not fully defined yet). It was always hard to survive without them in Java world. Lack of closures has given birth to a huge number of best practices, patterns, workarounds and really bad code. The only elegant alternative before cheerful future of a new mighty Java has come is AOP.

AOP allows developers play with Plain Old Java Objects and Services non-intrusively, pulling away logging, monitoring, caching and other aspects that doesn’t depend on a specific context and domain. AOP can help you following modern best coding practices (like Single Level of Abstraction and Composite Method (see “Productive Programmer” by Neal Ford)) and make your architecture transparent.

Assume you’ve developed a business application that blindly implements business requirements, and at the end of the day you 1. don’t have much time to implement utility services 2. afraid to add complexity to the design. Spending just several hours with AOP you will achieve those goals, and moreover make your application look trendy.

Monitoring (performance tracking)

Monitoring is the simplest aspect you can start with. In terms of the simplified SCA described previously, I prefer to monitor methods of the flow (those methods are the highest level of the backend API that encapsulates calls to the service infrastructure and are directly called from the “controller” level).

With a very small code in XML to declare around aspects/endpoints and straightforward code of the aspects you can achieve the following:

  • Monitor calls to the methods (track start/end of the method execution and time to execute). In the legacy applications this code looked just awful – you had to put logging in the beginning/end of every method to be monitored. With aspects you keep the generic (horizontal) functionalities away from the business logic.
  • Agent/system performance analysis. Making the aspect a bit more intellectual (so that it can tie calls to the agent sessions, distinguish services, etc.) and storing history of calls in the database you can build a huge number of charts that can be used not only for analyzing system performance and revealing bottlenecks, but also for analyzing the ways users interact with the system.

Caching

Caching logics without aspects has the same crucial impact on the code. Variety of calls is preceded with the same blocks of code to check/update the cache over and over again.

Leveraging around/before aspects you can plug any caching engine to your system non-intrusively. I argue strongly for EhCache as cache of choice – it’s the best freeware caching engine on the market. The benefits are:

  • If you’re not replicating/clustering your cache, using EhCache not much harder than using a simple Map;
  • You can declaratively configure in-memory/disk cache ratio, TTL and TTI policy, and much more;
  • Health of the server (cache misses, number of element in cache, etc.) can be easily monitored with JMX (via  JConsole or other monitor);
  • EhCache Server is shipped with Glassfish, can be started in one click and has REST/WS-* endpoints;
  • EhCache is integrated with Terracota (the most promising feature for me);

Properly ordering caching and monitoring aspects you can track the cache performance and fine-tune it.

Bean validation

I bet, JSR-303 that has already been implemented by Hibernate and Spring (and will be implemented in Java 7), is going to be a de-facto standard in the industry soon. It delivers the same vision of the validation at all levels of the application and saves from a burden of writing rule-checking code (in particular, null-checking and exception throwing code). You’re just calling validatior.validate(bean), and that’s it.

With Bean Validation enabled, every single bean is aware of its own constraints (contract), so validation process is fairly generic and can be moved to the aspect.

Tags: , , ,
Posted in Software Development | Comments Off

In-box SCA with Spring for home-made CRM

Wednesday, December 30th, 2009

It’s a know fact that CRM roll-out may cost twice or even thrice more than CRM solution to be implemented. Even worse the chance to fail is very high, unless you create a detailed program of implementation and invite integrators with a good reputation (that will not give a 100% chance of success though). Generally, pains of CRM implementation resemble the pains of BPM roll-out. In case of BPM, risks may be decreased with building the value up step-by-step and implementing “behind the scene” initiatives. In case of CRM it’s generally counted as not a very good practice (however IBM Global Service uses this approach), but until concepts and benefits of CRM are understood thoroughly, quick wins achieved by “denormalized” CRM components (that normally cover one process or just a part of it, whereas leading CRM products may be adjusted to any process of a company more or less painlessly) can be a good start.

Path of stepped roll-out is usually taken by the companies that don’t have much experience in CRM (and probably tied to ERP system that they want to extend with CRM features). With the means of their own development department (or delegating development to the offshore/nearshore) they sequentially, with small steps, cover different areas of CRM (mostly operational) with the components that offer the clearest ROI. Home-made CRM solutions have the following disadvantages among the others:

  • single solutions introduce a lot of code duplication;
  • architecture is not flexible and changing requirements may be crucial, as those applications are mostly developed in a very short time frame under the pressing of marketing or sales departments (value and behavior comes first);
  • maintenance is painful as quantity of spaghetti-code grows over time;

At the same time, it’s hard to predict, which area of the solution under development requires the highest flexibility, and making all parts of the system too generic and flexible can also add complexity to design and affect performance (generic solutions that, say, may work with different databases will never work as fast as those that uses all tricks of a specific database). Another point is the human factor – if you leave developer alone with the program, it will definitely create another framework.

Solution of my choice that can address all the mentioned problems and requirements is Service Component Model (aka Service Component Architecture). Key concepts of SCA are:

  • service (also called “asset”) – independent reusable functionality;
  • component – composition of services (1+ services) that address a particular horizontal (technical) or vertical (business, domain) problem;
  • assembly – complete system assembled of independent components and assets;
  • orchestration and choreography – define behavior and ways of communication within assembly;
  • event – way of intercommunication;
  • storage – single place where assets (components) are stored to reuse lately;

Many specialists think of SCA (and SOA) as the equivalent to implementation of WS-*. WS-* stack certainly has the most technologies to realize SCA (WSDL, UDDI, SOAP, WS-BPEL, WS-CDL), but conceptually, complete SCA can be achieved with REST, CORBA, while in-box (or better say in-container) SCA may be implemented with Spring Framework. Dependency Injection paradigm (used for orchestration and choreography) keeps assets decoupled, and defines relationships between assets in components and content of the assemblies. System availability may be later achieved with REST-services (over service interfaces) and Spring Integration engine.

(more…)

Tags: , , , ,
Posted in Software Development | 3 Comments »