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:
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.
Eclipse IDE Workbench, Editing, Ant, Help Tips & Tricks:
In continuation to the previous post, this one has Tips & Tricks for Views in Eclipse IDE. Refer to posts in Eclipse Tips & Tricks for others.
Note: If the image displayed below is unclear, then click on the image. Then hover over the image in the newly opened window. You will get a zoom icon, click the image with it and it will be displayed with better visibility. Read more…