Brane brings together recognized experts from key Eclipse projects, professional processes and the ability to meet the technical requirements of commercial adopters. Brane delivers industrial strength solutions to respond to increases in typical IT requirements — support, extension, custom technology, management, etc.
We are ready and compliant as the adoption of Eclipse in conventional software circles such as rich desktop and internet applications, middleware and servers continues to accelerate. Brane has chosen Eclipse as the foundation technology for its desktop applications and its MDA platform. Eclipse is a robust, extensible, and scalable Java IDE (Integrated Development Environment) supporting a wide range of tools for Web technologies, data manipulation and reporting. Eclipse is also a community of developers that contribute top quality, well tested open source components with regular scheduled releases. Brane team has been among the pioneers and contributors of Eclipse since its inception.
Brane provides a complete range of products and services from fundamental technology development, support, training and mentoring to commercial management and solution provisioning .
We were among the first to utilize EMF (Eclipse Modeling Framework) in commercial applications. We also contributed to the evolution of Equinox project (Eclipse’s implementation of OSGI – a standard for dynamic, modular Java runtime). Following our visionary path, major commercial Application Server vendors have pledged to support OSGI in their up-coming releases.
Benefits of OSGi
- Modular Development – The OSGi framework defines a unit of modularization called a bundle. A bundle is nothing more, and nothing less, than a Java .jar file. A .jar file is a valid OSGi bundle if it contains resources that provide functionality, and a Manifest file containing metadata about the bundle. The resources can be Java classes, html, images, Servlets, and even JSP. The metadata is defined using required and optional key/values pairs. Since all developers are familiar with .jar files, creating a valid OSGi bundle is relatively straightforward. OSGi changes the deployment model for enterprise applications. Traditional thinking is centered around web application development, and teams devote valuable resources to identifying functionality contained within webapps, and inter-webapp communication. With OSGi, you won’t develop traditional web applications. Instead, you’ll develop bundles that are assembled into an application, so your development philosophy turns from application-centric to component-centric. While we’ve been attempting to design modular software for a very long time, OSGi enforces the design of modular software through these bundles and managed dependencies.
- Managed Dependencies – OSGi accepts reality that the .jar file is the predominant method of reuse and deployment with Java. OSGi treats a .jar as a first class component. The Manifest within an OSGi bundle defines export packages that other bundles can use, as well as import packages used by the bundle. Think of this as public and private access to the packages within a .jar file. With OSGi, you can now truly establish a component’s published interface simply through how classes are allocated to packages, and the packages made visible through export by a bundle. OSGi offers local transparency for it’s bundles, because you don’t need to include .jar files on the run-time classpath. Instead, exported packages within an OSGi bundle can be used by other bundles running on the OSGi platform. Optionally, some OSGi implementations may provide a Security layer that allows access to a bundle if permission has been granted.
- Component Platform – OSGi is a service platform because it reduces coupling between bundles. Yet viewing OSGi as only a service platform tends to lump it in with all other service (as in SOA) solutions. OSGi is also a true component platform that hits a sweet spot not presently accommodated for in enterprise Java development or SOA. OSGi is not a distributed service technology. Instead, OSGi bundles are deployed and communicate within a single JVM, making inter-bundle communication in-process and lightweight. OSGi bundles are true software components. The OSGi platform contains a framework specification, making it similar to any other specification you’ve worked with in Java, like the Servlet API, JDBC, etc. There will be numerous implementations of the OSGi specification, but your code should only ever refer to the OSGi package structure (org.osgi.*). Additionally, when you compile, you’ll want to compile against the specification, not the specific implementation you choose to use.
- Versioned Bundles – When exporting and importing packages from other bundles, you can specify a version number. Because bundles can be versioned, you can deploy multiple versions of the same bundle on the OSGi platform without experiencing fatal errors, such as a ClassCastException commonly experienced when the same class definition is deployed multipled times within the same JVM.
- Dynamic (Re)Deployment – OSGi allows you to deploy bundles individually, without performing a restart. When functionality within a bundle changes, you simply redeploy that bundle to the appropriate OSGi platform, and clients of that bundle automagically discover it through the packages it exports and it’s version. No need to redeploy entire applications. This offers tremendous flexibility if you separate implementation from specification in your application bundles, by allowing you to completely swap implementation without any interruption to other deployed bundles.
- Environmental Control – Because OSGi is a managed container environment, you have the ability to install, start, stop, update, and uninstall individual bundles.