Canonical Models

Here we go, my recent work on canonical models. @copyright

Canonical Models

 

I have vested my recent time researching on Canonical Models. It has caught my attention since I see enterprises drifting towards opting canonical models as a solution for integration needs. It definitively nails the problem provided that it is applied to the right situations in the right way.

Here’s a briefer. We know that many organizations around the world work today by talking to several legacy applications, third party systems, B2B feeds and so on which only grow considering the business and technological enhancements. To add to that, all these systems understand their own language, format and data. In order to make them talk to each other, it requires having various transformations between all the participants. That means varying models, changes and other booby traps in order to establish a successful communication!

Is there a way to simplify this all? Yes, canonical models is the solution out there for these demanding situations. What are these? How can they be applied? When should they be applied? What are the technological and functional requirements? Are there any tools to help ease the entire process? Well, the list of questions can only grow.

I have spent some time researching on this and spoke to subject matter experts from business and technical backgrounds. I will be publishing an article on this soon.

Evolution of Open-Source Enterprise Service Bus (ESB)

 

Evolution of open-source Enterprise Service Bus (ESB):

Developers involved in complex system integration will know how intriguing system integration can get to. Integration of disparate enterprise applications is always challenging because of the need to get them work together. It also has become an increasingly essential element of IT, where we oftenly come across terms such as BI (Business Integration), B2B (Business to Business) etc. A decade earlier, technology choices were limited. Integration of enterprise applications had to chose either an application server or a heavyweight enterprise application integration (EAI) solution that required a huge upfront investment in infrastructure, money, and human resources. There was a need for a lightweight solution which is easy to deploy and manage. Many enterprises at that time, built thier own abstractions on top of thier messaging servers. By doing so, it was an extreme undertaking and a huge burden on the developers.

Since IBM first released MQSeries, enterprises have been sold on the benefits of decoupling systems using point-to-point message queues. When TIBCO brought Rendezvous to the market, it expanded the horizons of messaging by introducing the publish-subscribe model. The Java Message Service (JMS)—born through Sun’s Java Community Process (JCP)—set out to unify the point-to-point and publish-subscribe messaging models. It wasn’t long before enterprises required more than just messaging, they also needed a way to orchestrate messages between systems and perform transformations.

To address this need, major vendors such as IBM, Oracle, and Microsoft built EAI brokers that added message brokering and centralized transformation engines on top of their existing messaging servers. The problem with the EAI approach was that it adopted a hub-and-spoke architecture where all data had to flow through the EAI broker. Although this worked for many applications, enterprises were soon pushing the boundaries of these systems and it became clear that something more flexible, scalable, and distributed was required. Enterprises needed connectivity, transaction management, security, and message routing, and they needed to host services that operated on data moving around their systems.

Working on integration projects used to mean working with enterprise application integration (EAI) products, each of which implemented its own stack of tools with proprietary technology. To switch from one EAI product to another meant learning the proprietary technology and toolset from that new product. With more focus on open standards that emerged in the integration market, the market changed from EAI to service oriented architecture (SOA) and enterprise service bus (ESB) products. Examples of these open standards are Java Message Service (JMS), SOAP, XML, and WS*. With open standards available, more and more open source projects began to implement these specifications.  There was a need for an open source solution built on open standards.

The next step of this evolution led to what is now known as an ESB: Data and exchanges are conveyed from system to system in a single logical bus, decoupling all the systems from each other. This leads to a much more maintainable system and can save a lot of time in the long term. Integration technologies are becoming commodity software, and the rise of open source integration frameworks is hence becoming increasingly important. Open source is now unavoidable, from JMS brokers to SOAP stacks to ESBs. Companies generally use ESBs to convey sensitive data, and they sometimes need advice when they’re developing the applications hosted in the ESBs or when they’re putting these applications in production. The industry needed the ESB. 

Subversion, Apache Server, Subclipse installation & configuration

 

Ever wanted to have a code repository of your own? Either working on a small project or working with your friends on the next big thing, it would be great to have a repository where you can maintain your code, just as you would while working at your office. Lot of you might have been using version controls at workplaces such as CVS, VSS etc. Many will have an urge to maintain their homework using a version control mechanism. But is it all that easy? Well, it isn’t a one-go shot for a starter. Here is this post throwing light on how precisely to do that.

For beginners, probably the only thing relatable is the name of the version control alone, but how to get it, how to install it, how to configure it and then how to use it, will all be things to follow. There are many open-source free version controls available, do explore their features and chose the one best for you. This post though specifically guides your way through installing and configuring Subversion. Before reading the rest of the post, it would be helpful to get into a primer about subversion / subversion client / using subversion locally/ using subversion remotely etc. For a comprehensive look into subversion, read it here.  Subversion  is a small and simple enough version control to run on a development machine to give a full-fledged source code control. You can get down and dirty by manually installing and configuring subversion like many others who have shed enough time doing it manually starting with downloading subversion here.

 

Manual Download/Installation/Configuration of subversion:

Here are the list of few links that should help get started with manually installing and configuring subversion:

Learn To Build Beautiful HTML5 And CSS3 Websites In 1 Month

 

I was recently going through Udemy (a good online tutoring website) and found this course titled “Learn To Build Beautiful HTML5 And CSS3 Websites In 1 Month” handy. The tutor is giving away the course worth 50$ for 5$ for a while. The following is what the tutor Ryan Bonhardt quotes:

 

Hello again and hope you’re enjoying the course! Almost all of our students from the first course have joined this second course which is awesome and I’m stoked that we’re at over 900 students. It’s incredible!

I have a favor… can you help me reach 1,000 students in the next 24 hours? It would put us at 1,000 students in the first 10 days! There’s only about 100 spots to go so I think it’s doable with your help.

Can you think of anyone that would want to take this course. If so I want to give you a BUDDY PASS to share with your friends. With this buddy pass they can get this $50 course for only $5.

Please share the link with your friends on facebook/twitter/email etc: I’ve enrolled in ‘Learn To Build Beautiful HTML5 and CSS3 Websites in 1 Month’ and so far its pretty awesome. I think you should too so we can do it together. You can enroll for only $5 (its usually $50) with the coupon ‘friendscodingwithfriends.’ Here’s the link: https://www.udemy.com/learn-to-build-beautiful-html5-and-css3-websites-in-1-month/?couponCode=friendscodingwithfriends.

 

Here is the link again: https://www.udemy.com/learn-to-build-beautiful-html5-and-css3-websites-in-1-month/?couponCode=friendscodingwithfriends. I am sure it will help those who want to get quickly started with website designing. There is also a free course from the tutor on HTML5 and CSS3 titled “Build Your First Website in 1 Week with HTML5 and CSS3” which on itself is a great quick start for designing websites of caliber.

 

Good read for building high traffic website

Another read on considerations for high traffic websites

http://mashable.com/2011/08/16/high-traffic-web-app-development/

Build Twitter with Groovy Grails in 90 Minutes by Jeff Brown – Youtube

Few of the best inspiring videos on “Power of One”

SpringSource Tool Suite

 

What is SpringSource Tool Suite (STS)?

SpringSource Tool Suite has been a much awaited release from Spring Source. Interface21 (builders of Spring Framework) had partnered with Tasktop Technologies (builders of Eclipse Mylyn) to develop Spring Tool Suite, with the goal of reducing complexity in Java development and maintenance.  Mylyn is an open source Eclipse project (task-focused UI for Eclipse that reduces information overload and makes multi-tasking easy) while Spring is a popular open source framework for enterprise Java.  Built on Eclipse and Mylyn, Spring Tool Suite simplifies the large aggregation of tools used to develop complex enterprise Java applications.

This suite includes Spring IDE, the AspectJ Development Tools (AJDT), AspectJ, and Mylyn to create a task-focused approach to the development of Spring-powered enterprise applications. When Integrated development environments (IDEs) are used for large enterprise applications, they flood developers with tens of thousands of artifacts, wasting productive time by forcing developers to constantly find and identify the information relevant to the task at hand. In addition, the enterprise developer’s IDE consists of many tools that do not provide a unified workflow. While the Spring Framework and Portfolio projects already integrate many key technologies at the framework and library level, there is currently no tool solution that provides Mylyn’s task focus, tool integration, and workflow streamlining benefits to enterprise application developers. Building on the existing success of Eclipse, Mylyn and Spring IDE, the Spring Tool Suite will simplify the complexity dramtically.

 

Spring Source Quotes: 

SpringSource Tool Suite™ (STS) provides the best Eclipse-powered development environment for building Spring-powered enterprise applications. STS includes tools for all of the latest enterprise Java and Spring based technologies as well as the most advanced tooling available for enterprise OSGi development. STS supports application targeting to local, virtual and cloud-based servers and provides built in support for SpringSource dm Server and tc Server. SpringSource Tool Suite is freely available for development and internal business operations use with no time limits.

 

What’s available in STS?

Spring Integration with Eclipse – SpringIDE

 

  

Spring Framework Integration with Eclipse IDE:

 

Now that we have downloaded Spring Framework, we will see how to integrate it with Eclipse IDE.

Eclipse IDE by default is just a platform for development, which doesn’t carry all the JEE features required. It doesn’t ship with support for Spring Framework as you would know by now. So we will see how to integrate Spring Framework with Eclipse IDE using a standard plugin available called SpringIDE. Eclipse IDE is available in different releases, and these steps are almost similar to all of them. This post demonstrates using Eclipse Galileo (Eclipse version 3.5.0 release). If you have any doubts related to Eclipse IDE releases or its download / installation / configuration, refer to Eclipse IDE Installation & Configuration post.

 

What is Spring IDE? 

SpringIDE provides a user interface for Spring configuration files, built as a set of plugins on the Eclipse platform. It is a set of free plugins for the Eclipse platform that helps in developing Spring Application. The IDE provides a wizard for creating Spring projects, and using the Graphical Editing Framework, displays graphs of all beans (objects) and relationships either within a single configuration file or within a set of configuration files. The files, or sets, are also validated as they are added / modified. There’s also support for Spring AOP, so pointcut expressions are validated in your Spring configuration. 

Spring IDE (http://www.springsource.com/products/springide) is a product from Spring Source (http://www.springsource.com/). Refer to Spring Primer for details. Latest SpringIDE version avaiable is 2.0.3.

 

Follow the steps below: 

Developing Spring Application in Eclipse IDE

 

 

Spring Application Example:

Now that we have installed SpringIDE in Eclipse, let’s explore what we can do using Spring IDE and also create a Spring application. By integrating Spring IDE, we now have a Spring Project Wizard in the New Project option of Eclipse Workbench. We will start our Spring application with a demo project namely springide-demo. This is just to explore the SpringIDE features in Eclipse and not a tutorial on Spring application. This will help in getting started with our detailed tutorial ‘Exploring Spring Framework’ Series.

 

1. Creating a Spring Project:

• Open the New project dialog box by choosing File Menu > New and Choose Spring Project below in the Wizard.

• You will see the New Spring Project Dialog wizard. Here type the project name as “springide-demo” and keep all the options at their default values and click the Finish button.

• This will create a new Spring Project. SpringIDE provides visual indicators in the Package Explorer view which will be shown in Java Perspective. Note the S symbol upon the project name. This is to indicate that this is a Spring project.

 

 

2. Create a working package and class in the project:

Things to know about Spring Download, Installation & Configuration

 

 

Things to know about download/installation/configuration of Spring Framework:

 

The Spring Framework and container is packaged in several JAR files. Spring is a library(.jar files) of classes that will be packaged with and used by your Spring-enabled applications. Installing Spring involves adding one or more JAR files to your application’s classpath. It does not have an executable runtime. Therefore, Spring is more similar to a library like Jakarta Commons than an application server like JBoss.

How you make Spring available to your application’s classpath will vary depending on how you build and run your application. You may choose to add the Spring JAR files to your system’s classpath or to a project classpath in your favorite IDE (as we will see in the post on configuring Spring Framework with Eclipse). If you’re building your application using Ant or Maven, be certain to include Spring in your build’s dependencies so that it will be included in the project’s target deployment.

 

Downloading Spring:

There’s plenty of additional materials in Spring’s full distribution, including Spring’s API documentation, examples, and the full source code for the Spring Framework. Therefore, the first thing you’ll want to do is to download the full Spring distribution. Refer to Spring Framework Installation & Configuration post. When downloading Spring, you will have 2 main choices: you can either download a Spring distribution that comes with its own dependencies or you can download a distribution that contains only the Spring JAR files. Even though the former is a much larger download, its better to download the one that comes with dependencies so that you won’t have to hunt down other JAR files that your application needs.

 

Exploring the Spring distribution:

Once you’ve downloaded the distribution, unzip it to a directory on your local machine. The Spring distribution is organized within the directory structure described in the table below. Several of these directories contain the Spring source code. The aspectj/,mock/, src/, and tiger/ directories contain the source code that makes up the Spring Framework itself. Meanwhile, the test/ directory contains the unit tests used to test Spring Framework. Although it’s not essential to using Spring, you may want to venture around in these directories to see how Spring does its stuff.

 

 

The Spring developers are extremely talented coders and there will be probably a little something to learn by reviewing their code. The docs/ directory contains two important pieces of documentation. The reference document is an overview of the entire Spring Framework. Also, the JavaDocs for the entire Spring Framework can be found under docs/—you’ll probably want to add this as a bookmark in your web browser, because you’ll refer to it often. The samples/ directory contains a handful of sample Spring applications. Of particular note are the petclinic and jpetstore examples. Both of these applications highlight many important elements of the Spring framework.

 

Building your classpath:

Spring Download & Installation

 

 

Spring Framework Download & Installation: 

 

At the time of this post, the latest Spring Framework release available to download is Spring Framework 3.0.0.RC2, which is a development release. Previous releases are also available for download such as Spring Framework 2.5.6.SEC01 which is the current production release. All you have to do is navigate to http://www.springsource.org/download, chose and download the Spring Framework release that you want to work with.

Since our posts on Exploring Spring Framework will be based on Spring Framework 2.5 production release, we will see the download and instruction steps for this release. Steps should be the same no matter what release you chose.

 

Download Instructions:

1. Navigate to http://www.springsource.org/download site, here you can download the Spring Framework release from the Spring Downloads section:

 

 

2. Once clicking on the download link, you will be presented with community / enterprise download of Spring Framework. Chose the community download option:

Why Spring Framework?

 

 

Why Spring Framework?

 

Since the widespread implementation of J2EE applications in 1999/2000, it has not been an unqualified success in practice. While it has brought a welcome standardization to core middle-tier concepts such as transaction management, many — perhaps most — J2EE applications are over-complex, take excessive effort to develop, and exhibit disappointing performance. EJB  soon became  a widely accepted enterprise solution. But as time passed, many could recognize the disadvantages of using EJB.

In EJB versions prior to 3.0, a single EJB component requires a remote/local interface, a home interface, and a bean implementation class. Hence EJBs were called heavyweight components. Moreover, in those EJB versions, an EJB component could only run within an EJB container and had to look up other EJBs with JNDI (Java Naming and Directory Interface). So EJB components were technology dependent because they could not be reused and tested outside the scope of an EJB container.

Spring framework hence came out to reduce such complexities in enterprise application development. You can think of Spring framework as, minus of EJB’s disadvantages plus a comprehensively layered modular Java/JEE  framework which is flexible, light-weight, less intruisive and technology independent. Spring is applicable in a wide range of environments, not just server-side J2EE applications which was the original motivation. Spring also offers many valuable services for J2EE applications.

 

Problems with the Traditional Approach to J2EE:

Experience has highlighted specific causes of complexity and other problems in J2EE applications. (Of course, not all of these problems are unique to J2EE!) In particular:

• J2EE applications tend to contain excessive amounts of “plumbing” code. Many code reviews repeatedly reveal a high proportion of code that doesn’t do anything: JNDI lookup code, Transfer Objects, try/catch blocks to acquire and release JDBC resources. Writing and maintaining such plumbing code proves a major drain on resources that should be focused on the application’s business domain.
• Many J2EE applications use a distributed object model where it is inappropriate. This is one of the major causes of excessive code and code duplication. It’s also conceptually wrong in many cases. Internally distributed applications are more complex than co-located applications, and often much less performant. Of course, if your business requirements dictate a distributed architecture, you need to implement a distributed architecture and accept the trade-off that incurs (and Spring offers features to help in such scenarios). But you shouldn’t do so without a compelling reason.
• The EJB component model is unduly complex. EJB was conceived as a way of reducing complexity when implementing business logic in J2EE applications; it has not succeeded in this aim in practice.
• EJB is overused. EJB was essentially designed for internally distributed, transactional applications. While nearly all non-trivial applications are transactional, distribution should not be built into the basic component model.
• Many “J2EE design patterns” are not, in fact, design patterns, but workarounds for technology limitations. Overuse of distribution, and use of complex APIs such as EJB, have generated many questionable design patterns; it’s important to examine these critically and look for simpler, more productive, approaches.
• J2EE applications are hard to unit test. The J2EE APIs, and especially, the EJB component model, were defined before the agile movement took off. Thus their design does not take into account ease of unit testing. Through both APIs and implicit contracts, it is surprisingly difficult to test applications based on EJB and many other J2EE APIs outside an application server. Yet unit testing outside an application server is essential to achieve high test coverage and to reproduce many failure scenarios, such as loss of connectivity to a database. It is also vital to ensuring that tests can be run quickly during the development or maintenance process, minimizing unproductive time waiting for redeployment.
• Certain J2EE technologies have simply failed. The main offender here is entity beans, which have proven little short of disastrous for productivity and in their constraints on object orientation.

 

The traditional response to these problems has been to wait for tool support to catch up with the J2EE specifications, meaning that developers don’t need to wrestle with the complexity noted above. However, this has largely failed. Tools based on code generation approaches have not delivered the desired benefits, and have exhibited a number of problems of their own. In this approach, you might generate all those verbose JNDI lookups, Transfer Objects, and try/catch blocks.

In general, experience has shown that frameworks are better than tool-enabled code generation. A good framework is usually much more flexible at runtime than generated code; it should be possible to configure the behavior of one piece of code in the framework, rather than change many generated classes. Code generation also poses problems for round-tripping in many cases. A well-conceived framework can also offer a coherent abstraction, whereas code generation is typically just a shortcut that fails to conceal underlying complexities during the whole project lifecycle. (Often complexities will re-emerge damagingly during maintenance and troubleshooting.)

A framework-based approach recognizes the fact that there is a missing piece in the J2EE jigsaw: the application developer’s view. Much of what J2EE provides, such as JNDI, is simply too low level to be a daily part of programmer’s activities. In fact, the J2EE specifications and APIs can be judged as far more successful, if one takes the view that they do not offer the developer a programming model so much as provide a solid basis on which that programming model should sit. Good frameworks supply this missing piece and give application developers a simple, productive, abstraction, without sacrificing the core capability of the platform.

 

Using J2EE “out of the box” is not an attractive option. Many J2EE APIs and services are cumbersome to use. J2EE does a great job of standardizing low-level infrastructure, solving such problems as how can Java code access transaction management without dealing with the details of XA transactions. But J2EE does not provide an easily usable view for application code.That is the role of an application framework, such as Spring.

 

Recognizing the importance of frameworks to successful J2EE projects, many developers and companies have attempted to write their own frameworks, with varying degrees of success. In a minority of cases, the frameworks achieved their desired goals and significantly cut costs and improved productivity. In most cases, however, the cost of developing and maintaining a framework itself became an issue, and framework design flaws emerged. As the core problems are generic, it’s much preferable to work with a single, widely used (and tested) framework, rather than implement one in house.

No matter how large an organization, it will be impossible to achieve a degree of experience matching that available for a product that is widely used in many companies. If the framework is open source, there’s an added advantage in that it’s possible to contribute new features and enhancements that may be adopted. (Of course it’s possible to contribute suggestions to commercial products, but it’s typically harder to influence successful commercial products, and without the source code it’s difficult to make equally useful contributions.) Thus, increasingly, generic frameworks such as Struts and Hibernate have come to replace in-house frameworks in specific areas.

The Spring Framework grew out of this experience of using J2EE without frameworks, or with a mix of in-house frameworks. However, unlike Struts, Hibernate, and most other frameworks, Spring offers services for use throughout an application, not merely in a single architectural tier. Spring aims to take away much of the pain resulting from the issues in the list we’ve seen, by simplifying the programming model, rather than concealing complexity behind a complex layer of tools.

 

Spring enables you to enjoy the key benefits of J2EE, while minimizing the complexity encountered by application code.The essence of Spring is in providing enterprise services to Plain Old Java Objects (POJOs). This is particularly valuable in a J2EE environment, but application code delivered as POJOs is naturally reusable in a variety of runtime environments.

 

 

Spring in Context:

Spring is a manifestation of a wider movement. Spring is the most successful product in what can broadly be termed agile J2EE. While Spring has been responsible for real innovation, many of the ideas it has popularized were part of the zeitgeist and would have become important even had there been no Spring project. Spring’s greatest contribution — besides a solid, high quality, implementation — has been its combination of emerging ideas into a coherent whole, along with an overall architectural vision to facilitate effective use.

 

Inversion of Control and Dependency Injection: