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):

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. 

With the advance of service-oriented architecture (SOA) in the last several years, there has been confusion unfold about what SOA really is. One affirmation that has resonated well in the industry is that the ESB is the foundation of SOA. The term SOA covers a much broader topic than just technology. ESBs realize the benefits of what service orientation has to offer. The ESB bridges the gap between old and new. It acts as a mediator between application integration and service orientation, enabling enterprises to build new applications and processes from existing technology.

The notion of an ESB involves a common messaging bus which is used to communicate between different enterprise systems. Typically, there is a shared messaging format on the bus. The adapters between the bus and back-end applications translate data from the proprietary data formats to the shared message bus format. The power of this model is that applications can share information while being totally decoupled from one another. Additionally, the ESB provides a common platform for handling security, transformations, message routing, transactions, and monitoring.

Enterprise service bus is a loosely defined term, and lots of products are claiming to implement the ESB concept. The goal of an ESB is to provide a distributed and reliable mediation framework that different systems in an IT environment can use to communicate, thus removing the need for a given system to know how to talk to the others in a specific way. Integration, which is what ESBs are about, is complicated: Each time you add a system, it needs to talk to all the other systems, and ad-hoc integration between the systems has long been considered a bad solution.

The open source model is perfect for integration and henceforth for ESB. After all, ESBs are about surfacing, manipulating, and moving data between applications. Application integration is complex on many levels. The permutations of applications, protocols, message formats, environment restrictions cause system integrators an unholy amount of grief. No single vendor of an EAI can realistically claim to understand the intricacies of your application environment, so all the proprietary vendors have instead chosen to offer products that make their customers abide by their rules when building an ESB solution. This quickly becomes a problem when the vendor’s approach doesn’t suit your needs. Sometimes, you want to get into the code and customize for the problem at hand.

By providing access to the source code, open source ESBs can alleviate these problems—but the benefits don’t stop there. By nature, open source projects are developed to be lean and modular. Developers working on an open source project don’t have time to maintain a huge product, and they would want the code base to be accessible to their community to encourage contributions. Given that the use cases for ESBs and integration are so varied, it’s impossible to have one vendor test every scenario. It’s far better to give the code to a community of active users who provide testing and feedback about their experience with the ESB. That same user community has connectivity and message format requirements far beyond what can be provided by a single vendor, so it makes sense to enable the users to build support for the more exotic protocols. These extensions can then be committed back to the open source project for the benefit of the rest of the community.

Basing on these fundamentals, the Mule project was founded in 2003, and after that many open source ESBs have emerged. Each has its own way of doing things, and each focuses on different areas. As examples, Apache ServiceMix is built on Java Business Integration (JBI), whereas Apache Synapse is built around the Web Services (WS) standards, and Apache Tuscany uses the Service Component Architecture (SCA) standard. Mule takes a pragmatic approach by embracing these standards without forcing the use of any of them, giving the user a great deal of flexibility when building an ESB solution.

In the recent years, Mule and Apache ServiceMix have proven to be mature and have good communities backed by vendors that can provide the needed support. Mule and ServiceMix have a lot of differences, but they also have common ground that’s focused on integration functionality. Mule was one of the first projects that provided a large set of integration functionality. After a while, it was called an ESB. Mule focuses on ease of development with support for all kinds of payloads, and it uses an architecture and design model, which isn’t based on a specification. ServiceMix implements the JBI specification and therefore focuses on XML payload and the implementation of binding components and service engines. ServiceMix implements the Java Business Integration (JBI) specification. JBI defines a framework to connect components and make them talk together in a standard way. In the JBI world, components can host business logic (a BPEL engine or a rules engine) or handle a particular protocol (HTTP, JMS, and so on). The key benefit of JBI is that new components can be wired easily on the bus as they all abide by the JBI specification. For example, ServiceMix doesn’t provide a BPEL engine by itself, instead you can plug in any JBI-compliant component for BPEL (ex: Apache Ode). The JBI specification though doesn’t target end users, but rather is intended to be implemented by ESB vendors and other software vendors who want to integrate their products in a JBI-compliant environment, such as a BPEL engine, a business rules engine, a transformation engine, or another specific technology. This is the key benefit of JBI.

Choice is usually a good thing for consumers, but with so many choices, it can be difficult to navigate the landscape of open source ESBs. With the wealth of emerging robust and reputed open-source ESB soultions, it can rather be a difficult question of which ESB solution to opt. But it can be narrowed down by asking few questions. All of them aim at a common goal but support different means to implement them. So the question should be on which means you would like to implement an ESB solution (Java Business Integration standards, Webservices standards, Service Component Architecture etc).

Source: Open source ESB in Action. 

]]> https://tecnoesis.wordpress.com/2015/10/15/evolution-of-open-source-enterprise-service-bus-esb/feed/ 2 tecnoesis https://tecnoesis.wordpress.com/2014/11/24/subversion-apache-server-eclipse-installation-configuration/ https://tecnoesis.wordpress.com/2014/11/24/subversion-apache-server-eclipse-installation-configuration/#comments Mon, 24 Nov 2014 05:00:21 +0000 http://tecnoesis.wordpress.com/?p=1601  

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:

• http://svn.spears.at/
• http://queens.db.toronto.edu/~nilesh/linux/subversion-howto/
• http://www.codinghorror.com/blog/archives/001093.html
• http://www.devx.com/codemag/Article/38974/1763/page/2
• http://lifehacker.com/188582/hack-attack-how-to-set-up-a-personal-home-subversion-server
• http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
• http://wiki.archlinux.org/index.php/Subversion_Setup
• http://www.codeandcoffee.com/2007/07/how-to-setup-a-subversion-server-on-windows/
• http://www.codeproject.com/KB/winsdk/SubversionApache.aspx
• http://www.linuxjournal.com/article/7655
• http://turnleft.inetsolution.com/2007/07/how_to_setup_subversion_apache_1.html
• http://www.abbeyworkshop.com/howto/misc/svn01/
• http://www.howtoforge.com/subversion_web_access_apache
• http://articles.techrepublic.com.com/5100-10878_11-5902186.html
• http://onlamp.com/pub/a/onlamp/2002/10/31/subversion.html
• http://oreilly.com/pub/a/apache/2002/12/19/svn2.html
• http://better-scm.berlios.de/subversion/Svn-Win32-Inst-Guide.html
• http://svnbook.red-bean.com/en/1.0/ch06s04.html
• http://www.baccoubonneville.com/blogs/index.php/eclipse/2005/12/04/p121

Most of the softwares (subversion, TortoiseSVN, Apache Server, subclipse) are version-dependent, so you should always install the latest version of each and be certain of the compatibility.

In a nutshell:

Subversion: Subversion is an open source version control system  similar to CVS in many respects used primarily by developers to keep every revision of important and frequently changing files. One major differing component is that, unlike CVS, there are multiple means of accessing your repositories. There are two popular svn-servers, the built in svnserve that comes with the subversion installation and the more advanced option, i.e., Apache server with svn plugins. Subversion is like a wiki-like repository for your files. Each time you make a change to a file or group of files that you’re happy with, you can commit those changes to your Subversion repository. If you don’t like with the changes, Subversion can compare your current version with any previously-committed version and pick out the best so you never have to worry about finding your way back to a good or working version of a file. Once you have a sharable repository, you can work with your team and work with the same piece of source controlled code.

Tortoise SVN: Tortoise SVN  is a Subversion client for Windows that makes dealing with Subversion repository easy. Tortoise isn’t a program but more of a shell extension and provides much like a front-end UI to access subversion. To interact, all you do is  right click in Windows Explorer and find the SVN specific commands such as  “SVN Checkout”.

Apache Webserver:  One of the more popular, and flexible ways of connecting to a subversion repository is through the use of the Apache 2 Web server. You will not need Apache 2 Web server though, if you plan on using the repository locally. You can choose to run Subversion without the server component (Apache) and it still works wonders for keeping versioned copies of your files locally. The only big miss is you won’t be able to access your files from other computers and via internet.

Subclipse: Subclipse is an Eclipse Team Provider plug-in providing support for Subversion within the Eclipse IDE. Using this plugin, you can access the repository.

Doing it the easy way – VisualSVN Server:

This is an easy choice for those who not only want to just set up subversion repository but also access it from other computers in the network LAN or via internet thro’ Apache server almost instantly. VisualSVN server sets up a typical Subversion installation for team work involving a single server machine being accessed from clients on computers all over the office or, perhaps, all over the world. There are many ways to configure Subversion server. VisualSVN Server is a package that contains everything you need to install, configure and manage Subversion server for a team on a Windows platform. It includes Subversion, Apache and a easily configurable management console.

Downloading / Installing / Configuring VisualSVN server is as easy as installing just about any other software in your system. Download it here. Follow the straight forward installation steps here. That’s it, you are not just done with setting up subversion repository in your preferred location, but also end up with lot many goodies such as a very user-friendly management console to create / delete / modify repositories, manage user accounts / authentication / privacy settings,  a default tree structure for repository (branch- a code that might not make it to a release, tag – code tagged for making it to a release, trunk – your code should be under this directory), and also Apache server installed with choice of access between http or https (secure). A  petite all in one goodie I must say!

Is it all done?

Accessing SVN via internet:

Either you have manually set up subversion with Apache or installed thro’ VisualSVN server, you will be all set to use your code repository in a network and also access it from within Eclipse IDE using subclipse plugin. Before you cheer up that you can now share your code repository with friends all over the world, there’s a small catch, but no worries! The catch is that if you are excited about sharing your code via http / https, say something like http://localhost:port/svn/ set during configuring VisualSVN server, you will be sad to realise that this will only work in your intranet behind your local router and your friends on the other side of the router can’t access it via internet.

The reason is that, though your computer is now a svn server and has a code repository with a url to be accessed, it’s working behind a router which does not forward external web requests to your svn server. There are few work arounds for this, such as using “port forwarding” on your router, but I would suggest a safer option. And that would be to opt for a free SVN hosting service, where in a third party server will host your code repository 24/7  and provide you with a easy management console and also a url that you can then share with your friends. Have a look at these options:

• http://www.straw-dogs.co.uk/09/20/6-free-svn-project-hosting-services/
• http://www.svnhostingcomparison.com/

Note:  Exposing web access to your computer is always bit risky provided your computer is well protected, using https via SSL (easily-configurable in VisualSVN server) is a much safer option. The default port for listening http request is 80, where as for https is 443.

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.

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 Application Tools:

• Spring project, bean and XML file wizards
• Graphical Spring configuration editor
• Spring 3.0 support including @Configuration and @Bean styles
• Spring Web Flow and Spring Batch visual development tools
• Spring Roo project wizard and development shell
• Spring Application blue prints and best practice validation

Enterprise OSGi Development:

• OSGi bundle overview and visual dependency graph
• Classpath management based on OSGi meta data
• Automatic generation of manifest dependency meta data
• SpringSource Enterprise Bundle Repository browser
• Manifest file validation and best practice recommendations

Flexible Deployment Targets:

• Support for all the most common Java EE application servers
• Advanced support for SpringSource dm Server
• Advanced support for SpringSource tc Server
• Cloud Foundry targeting for dm Server and tc Server
• VMware Lab Manager and Workstation integration and deployment

From April 2009, SpringSource Tool Suite (STS) has been free to download. STS is built on top of the Eclipse technology stack, and it can be installed and used with Eclipse 3.5 as a plugin as well.

Note:

• Refer to other posts in SpringSource Tool Suite catergory for further knowledge.
• Refer to other posts in Spring Framework category for further knowledge.
• Refer to other posts in Spring Installation & Configuration category for further knowledge.