A favorite story at management meetings is that of the three stonecutters who were asked what they were doing.
The first replied, "I am making a living." The second kept on hammering while he said, "I am doing the best job of stonecutting in the entire country." The third one looked up with a visionary gleam in his eyes and said, "I am building a cathedral."
The third man is, of course, the true "manager." The first man knows what he wants to get out of the work and manages to do so. He is likely to give a "fair day's work for a fair day's pay."
It is the second man who is a problem. Workmanship is essential, . . . but there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in effect he is just polishing stones or collecting footnotes.
-Peter Drucker
Sunday, March 3, 2013
What is OSGi?
It’s a modularity layer for the Java platform. Modularity refers to the logical decomposition of a large system into smaller collaborating pieces.
Nearly all but the simplest of applications can benefit from the modularity features OSGi provides.
Common scenarios where OSGi can be helpful
The OSGi Service Platform is composed of two parts:
The framework is the runtime that implements and provides OSGi functionality. The standard services define reusable APIs for
common tasks, such as Logging and Preferences.
If you use an IDE to do your Java development, it’s possible you already have experience with OSGi.
OSGi layered architecture
General approach when creating an OSGi-based application
Nearly all but the simplest of applications can benefit from the modularity features OSGi provides.
Common scenarios where OSGi can be helpful
- ClassNotFoundExceptions when starting your application because the class path wasn’t correct. OSGi can help by ensuring that code dependencies are satisfied before allowing the code to execute.
- Execution-time errors from your application due to the wrong version of a dependent library on the class path. OSGi verifies that the set of dependencies are consistent with respect to required versions and other constraints.
- Type inconsistencies when sharing classes among modules: put more concretely, the dreaded appearance of foo instanceof Foo == false. With OSGi, you don’t have to worry about the constraints implied by hierarchical class-loading schemes.
- Packaging an application as logically independent JAR files and deploying only those pieces you need for a given installation. This pretty much describes the purpose of OSGi.
- Packaging an application as logically independent JAR files, declaring which code is accessible from each JAR file, and having this visibility enforced. OSGi enables a new level of code visibility for JAR files that allows you to specify what is and what isn’t visible externally.
- Defining an extensibility mechanism for an application, like a plugin mechanism. OSGi modularity is particularly suited to providing a powerful extensibility mechanism, including support for execution-time dynamism.
The OSGi Service Platform is composed of two parts:
- OSGi framework
- OSGi standard services
The framework is the runtime that implements and provides OSGi functionality. The standard services define reusable APIs for
common tasks, such as Logging and Preferences.
If you use an IDE to do your Java development, it’s possible you already have experience with OSGi.
OSGi layered architecture
- Module layer—Concerned with packaging and sharing code.
- Lifecycle layer—Concerned with providing execution-time module management and access to the underlying OSGi framework
- Service layer—Concerned with interaction and communication among modules, specifically the components contained in them
General approach when creating an OSGi-based application
- Design your application by breaking it down into service interfaces (normal interface-based programming) and clients of those interfaces.
- Implement your service provider and client components using your preferred tools and practices.
- Package your service provider and client components into (usually) separate JAR files, augmenting each JAR file with the appropriate OSGi metadata.
- Start the OSGi framework.
- Install and start all your component JAR files from step 3.
-OSGi in Action
Saturday, March 2, 2013
Fuse ESB
FuseSource was formed when Progress Software spun off this open source effort into a separate organization in mid-2010. It was acquired by RedHat in mid-2012 to enhance Red Hat's JBoss middleware portfolio.
Fuse ESB is the core product of FuseSource.
Fuse ESB is an open source integration platform. It is a flexible, standards-based enterprise service bus based on Apache ServiceMix. It combines features from the Apache ServiceMix ESB, the Apache Camel integration framework, the Apache ActiveMQ message broker, and the Apache CXF web services framework.
You can download it now from RedHat downloads page, but I wonder if the 90 day evaluation story here is a mistake or not! Isn't it open source any more???
Fuse ESB has a pluggable architecture that allows organizations to use their preferred service solutions in their SOA. Any standard JBI or OSGi-compliant service engine or binding component – including BPEL, XSLT or JMX engines – may be deployed to a Fuse ESB container, and Fuse ESB components may be deployed to other ESBs.
It differentiates itself in the following ways:
In addition, Fuse ESB supports event driven architectures. Services deployed into the Fuse ESB container can be fully decoupled and will simply listen on the bus until an appropriate service request arrives. Fuse ESB also supports events that occur outside of the bus. For example, a JMS service can listen on a topic that is hosted outside of the bus and only act when an appropriate message arrives.
Fuse ESB employs a layered architecture comprised of the following:
Fuse ESB kernel is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.
The kernel provides the following features:
Fuse ESB is the core product of FuseSource.
Fuse ESB is an open source integration platform. It is a flexible, standards-based enterprise service bus based on Apache ServiceMix. It combines features from the Apache ServiceMix ESB, the Apache Camel integration framework, the Apache ActiveMQ message broker, and the Apache CXF web services framework.
You can download it now from RedHat downloads page, but I wonder if the 90 day evaluation story here is a mistake or not! Isn't it open source any more???
Fuse ESB has a pluggable architecture that allows organizations to use their preferred service solutions in their SOA. Any standard JBI or OSGi-compliant service engine or binding component – including BPEL, XSLT or JMX engines – may be deployed to a Fuse ESB container, and Fuse ESB components may be deployed to other ESBs.
It differentiates itself in the following ways:
- Fuse ESB kernel is lightweight and can run on most platforms.
- Fuse ESB kernel uses the OSGi framework to simplify componentization of applications.
- The OSGi framework is a standard for managing the dependencies between application components. It also provides a standard mechanism for controlling the life-cycle of components.
- Fuse ESB supports the Java Business Integration (JBI) specification.
- JBI is a well defined standard for packaging, deploying, and managing components deployed to the ESB.
- Fuse ESB can be coupled to other infrastructure services over a variety of transport protocols and message formats.
- Out of the box, the Fuse ESB supports JMS, HTTP HTTPS, FTP XMPP, Web services, and a number of other bindings. In addition, you can easily extend its connectivity options using other components that conform to either the OSGi or JBI specification.
- Fuse ESB employs standards as much as possible to limit dependencies.
In addition, Fuse ESB supports event driven architectures. Services deployed into the Fuse ESB container can be fully decoupled and will simply listen on the bus until an appropriate service request arrives. Fuse ESB also supports events that occur outside of the bus. For example, a JMS service can listen on a topic that is hosted outside of the bus and only act when an appropriate message arrives.
Architecture Overview
Fuse ESB employs a layered architecture comprised of the following:
- Kernel: A lightweight runtime that extends OSGi with powerful features for handling and managing OSGi bundles.
- Technology layer: A layer of component technologies that sits on top of the kernel.
Fuse ESB kernel is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.
The kernel provides the following features:
- Console: Karaf can be administered via an extensible console shell that supports secure, remote access.
- Dynamic logging: A dynamic logging backend provided by Log4J supports different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi).
- Hot deployment: When a JAR file is added to the InstallDir/deploy folder, it is automatically installed inside the runtime.
- Provisioning: Application provisioning through file-drop, Maven repository and remote download.
- Dynamic configuration: Changes to the properties files contained in the InstallDir/etc directory are monitored and propagated to the relevant services.
- Security: Security framework based on Java Authentication and Authorization Service (JAAS).
Whoopee! More fertilizer for my garden!
Found this shared on FB and it was just what I wanted to hear. If I may use the analogy here, I was sinking in a pit full of dung!
UNPLEASANT THINGS, like becoming last in our class, happen in life. They happen to everyone. The only difference between a happy person and one who gets depressed is how they respond to disasters.
Imagine you have just had a wonderful afternoon at the beach with a friend. When you return home, you find a huge truckload of dung has been dumped right in front of your door. There are three things to know about this truckload of dung :
1. You did not order it. It's not your fault.
2. You're stuck with it. No one saw who dumped it, so you cannot call anyone to take it away.
3. It is filthy and offensive, and its stench fills your whole house. It is almost impossible to endure.
In this metaphor, the truckload of dung in front of the house stands for the traumatic experiences that are dumped on us in life. As with the truckload of dung, there are three things to know about tragedy in our life :
1. We did not order it. We say 'Why me?'
2. We're stuck with it. No one, not even our best friends, can take it away (though they may try).
3. It is so awful, such a destroyer of our happiness, and its pain fills our whole life. It is almost impossible to endure.
There are two ways of responding to being stuck with a truckload of dung.
The first way is to carry the dung around with us. We put some in our pockets, some in our bags, and some up our shirts. We even put some down our pants. We find when we carry dung around, we lose a lot of friends! Even best friends don't seem to be around so often."Carrying around the dung" is a metaphor for sinking into depression, negativity, or anger. It is a natural and understandable response to adversity. But we lose a lot of friends, because it is also natural and understandable that our friends don't like being around us when we're so depressed. Moreover, the pile of dung gets no less, but the smell gets worse as it ripens.
Fortunately, there's a second way. When we are dumped with a truckload of dung, we heave a sigh, and then get down to work. Out come the wheelbarrow, the fork, and the spade. We fork the dung into the barrow, wheel it around the back of the house, and dig it into the garden. This is tiring and difficult work, but we know there's no other option.Sometimes, all we can manage is half a barrow a day. We're doing something about the problem, rather than complaining our way into depression. Day after day we dig in the dung. Day after day, the pile gets smaller. Sometimes it takes several years, but the morning does come when we see that the dung in front of our house is all gone.
Furthermore, a miracle has happened in another part of our house. The flowers in our garden are bursting out in a richness of colour all over the place. Their fragrance wafts down the street so that the neighbors, and even passers-by, smile in delight. Then the fruit tree in the corner is nearly falling over, it's so heavy with fruit. And the fruit is so sweet; you can't buy anything like it. There's so much of it that we are able to share it with our neighbors. Even passers-by get a delicious taste of the miracle fruit.
"Digging in the dung" is a metaphor for welcoming the tragedies as fertilizer for life. It is work that we have to do alone: no one can help us here. But by digging it into the garden of our heart, day by day, the pile of pain gets less.It may take us several years, but the morning does come when we see no more pain in our life and, in our heart, a miracle has happened. Flowers of kindness are bursting out all over the place, and the fragrance of love wafts way down our street, to our neighbours, to our relations, and even to passers-by. Then our wisdom tree in the corner is bending down to us, loaded with sweet insights into the nature of life. We share those delicious fruits freely, even with the passers-by, without ever planning to.
When we have known tragic pain, learnt its lesson, and grown our garden, then we can put our arms around another in deep tragedy and say, softly, 'I know.' They realize we do understand. Compassion begins. We show them the wheelbarrow, the fork, and the spade, and boundless encouragement. If we haven't grown our own garden yet, this can't be done.
I have known many monks who are skilled in meditation, who are peaceful, composed and serene in adversity. But only a few have become great teachers. I often wondered why.It seems to me now that those monks who had a relatively easy time of it, who had little dung to dig in, were the ones who didn't become teachers. It was the monks who had the enormous difficulties, dug them in quietly, and came through with a rich garden that became great teachers. They all had wisdom, serenity and compassion; but those with more dung had more to share with the world.
My teacher, Ajahn Chah, who for me was the pinnacle of all teachers, must have had a whole trucking company line up with their dung at his door, in his early life.
Perhaps the moral of this story is that if you want to be of service to the world, if you wish to follow the path of compassion, then the next time a tragedy occurs in your life, you may say,
"Whoopee! More fertilizer for my garden!"
- Opening the Door of Your Heart: And Other Buddhist Tales of Happiness
By AJAHN BRAHM
UNPLEASANT THINGS, like becoming last in our class, happen in life. They happen to everyone. The only difference between a happy person and one who gets depressed is how they respond to disasters.
Imagine you have just had a wonderful afternoon at the beach with a friend. When you return home, you find a huge truckload of dung has been dumped right in front of your door. There are three things to know about this truckload of dung :
1. You did not order it. It's not your fault.
2. You're stuck with it. No one saw who dumped it, so you cannot call anyone to take it away.
3. It is filthy and offensive, and its stench fills your whole house. It is almost impossible to endure.
In this metaphor, the truckload of dung in front of the house stands for the traumatic experiences that are dumped on us in life. As with the truckload of dung, there are three things to know about tragedy in our life :
1. We did not order it. We say 'Why me?'
2. We're stuck with it. No one, not even our best friends, can take it away (though they may try).
3. It is so awful, such a destroyer of our happiness, and its pain fills our whole life. It is almost impossible to endure.
There are two ways of responding to being stuck with a truckload of dung.
The first way is to carry the dung around with us. We put some in our pockets, some in our bags, and some up our shirts. We even put some down our pants. We find when we carry dung around, we lose a lot of friends! Even best friends don't seem to be around so often."Carrying around the dung" is a metaphor for sinking into depression, negativity, or anger. It is a natural and understandable response to adversity. But we lose a lot of friends, because it is also natural and understandable that our friends don't like being around us when we're so depressed. Moreover, the pile of dung gets no less, but the smell gets worse as it ripens.
Fortunately, there's a second way. When we are dumped with a truckload of dung, we heave a sigh, and then get down to work. Out come the wheelbarrow, the fork, and the spade. We fork the dung into the barrow, wheel it around the back of the house, and dig it into the garden. This is tiring and difficult work, but we know there's no other option.Sometimes, all we can manage is half a barrow a day. We're doing something about the problem, rather than complaining our way into depression. Day after day we dig in the dung. Day after day, the pile gets smaller. Sometimes it takes several years, but the morning does come when we see that the dung in front of our house is all gone.
Furthermore, a miracle has happened in another part of our house. The flowers in our garden are bursting out in a richness of colour all over the place. Their fragrance wafts down the street so that the neighbors, and even passers-by, smile in delight. Then the fruit tree in the corner is nearly falling over, it's so heavy with fruit. And the fruit is so sweet; you can't buy anything like it. There's so much of it that we are able to share it with our neighbors. Even passers-by get a delicious taste of the miracle fruit.
"Digging in the dung" is a metaphor for welcoming the tragedies as fertilizer for life. It is work that we have to do alone: no one can help us here. But by digging it into the garden of our heart, day by day, the pile of pain gets less.It may take us several years, but the morning does come when we see no more pain in our life and, in our heart, a miracle has happened. Flowers of kindness are bursting out all over the place, and the fragrance of love wafts way down our street, to our neighbours, to our relations, and even to passers-by. Then our wisdom tree in the corner is bending down to us, loaded with sweet insights into the nature of life. We share those delicious fruits freely, even with the passers-by, without ever planning to.
When we have known tragic pain, learnt its lesson, and grown our garden, then we can put our arms around another in deep tragedy and say, softly, 'I know.' They realize we do understand. Compassion begins. We show them the wheelbarrow, the fork, and the spade, and boundless encouragement. If we haven't grown our own garden yet, this can't be done.
I have known many monks who are skilled in meditation, who are peaceful, composed and serene in adversity. But only a few have become great teachers. I often wondered why.It seems to me now that those monks who had a relatively easy time of it, who had little dung to dig in, were the ones who didn't become teachers. It was the monks who had the enormous difficulties, dug them in quietly, and came through with a rich garden that became great teachers. They all had wisdom, serenity and compassion; but those with more dung had more to share with the world.
My teacher, Ajahn Chah, who for me was the pinnacle of all teachers, must have had a whole trucking company line up with their dung at his door, in his early life.
Perhaps the moral of this story is that if you want to be of service to the world, if you wish to follow the path of compassion, then the next time a tragedy occurs in your life, you may say,
"Whoopee! More fertilizer for my garden!"
- Opening the Door of Your Heart: And Other Buddhist Tales of Happiness
By AJAHN BRAHM
Friday, March 1, 2013
What really is an ESB?
Even-though all of us think we know what an ESB is, it's actually difficult to give a proper and comprehensive answer to the above question. ESB stands for Enterprise Service Bus, yes, but what kind of a beast it it?
The best answer I found so far is the following, from Java SOA Cookbook published by O’Reilly.
There is no specification for ESB. There is no standard that supports the creation of an ESB, or even a precise definition of what an ESB is. While by now the industry generally agrees on what features should be present in a product calling itself an ESB, vendors offer a wide variety of products with features that differ dramatically from one ESB to the next.
How to create a route in Oracle Service Bus is completely different from creating a route in TIBCO ActiveMatrix or a delivery channel in Apache ServiceMix. They don’t all have the same features, and the common features they do have are implemented in very different ways. So the knowledge you would gain about the specifics of one ESB would not be transferable to any other. A deep dive on Mule would offer very little insight for developers who aren’t using Mule, and there are so many ESBs to choose from.
In some cases, vendors, such as Oracle, Software AG, IBM, TIBCO, and others, offer “SOA suites” that comprise a collection of products such as an ESB, an orchestration engine, a SOAP engine, an enterprise registry/repository, a BPEL engine and design- time tools, Business Activity Monitoring and related tools, and more. The features present in these products from vendor to vendor are not consistent. For example, you might have an ESB from one vendor that handles transformations for you, and another ESB product that delegates transformations to an orchestration engine.
It can all get very confusing. You can get a standalone orchestration engine, such as Apache ODE or Active Endpoints VOS, as well as standalone ESBs. Some ESBs run on an application server. Some vendors, such as Oracle, include a “light” subset of orchestration functions directly in their ESB but also sell an orchestration product.
The ESB is capable of connecting a variety of messaging systems without forcing you to create point-to-point channels that are visible to application clients. Clients connect to the bus, which serves as a mediation layer that shields clients from the disparate messaging formats and protocols used in the backend systems. The bus choreographs message interactions with a variety of related SOA technologies, such as rules engines (external or embedded), an orchestration engine (employing BPEL or XPDL), adapters for legacy and packaged applications, and internal routing and transformation mechanisms. This allows all of the nodes of the bus to interact without having to create specific routes to each application, thereby reducing the maintenance overhead. Because the bus abstracts and mediates connected nodes, some flexibility is achieved; if you want to swap out one application for another one, you can do so with minimal disruption to the overall solution. ESBs are the backbone of SOA. They provide the opportunity to really make your entire IT landscape visible, integrated, and ready to participate in new composite applications across EAI, supply chain, B2B, portals, and more.
An ESB is often lightweight, and offers a centralized system for deploying components that can scale independently.
An ESB allows you to send messages between multiple services in a distributed environment, offering a layer of indirection that provides a rich set of mediating features for those messages. An ESB is typically platform-independent in the sense that it will run on a range of operating systems and is often neutral with respect to application server and programming language. The bus allows you to connect native Java applications, .NET applications, object request brokers, and legacy platforms. To achieve this end, most ESBs offer support for invoking web services and other network-ready application nodes, employ adapters to connect with packaged and legacy applications, offer robust routing support for messages, allow orchestration and transformation of message content, and more.
The best answer I found so far is the following, from Java SOA Cookbook published by O’Reilly.
There is no specification for ESB. There is no standard that supports the creation of an ESB, or even a precise definition of what an ESB is. While by now the industry generally agrees on what features should be present in a product calling itself an ESB, vendors offer a wide variety of products with features that differ dramatically from one ESB to the next.
How to create a route in Oracle Service Bus is completely different from creating a route in TIBCO ActiveMatrix or a delivery channel in Apache ServiceMix. They don’t all have the same features, and the common features they do have are implemented in very different ways. So the knowledge you would gain about the specifics of one ESB would not be transferable to any other. A deep dive on Mule would offer very little insight for developers who aren’t using Mule, and there are so many ESBs to choose from.
In some cases, vendors, such as Oracle, Software AG, IBM, TIBCO, and others, offer “SOA suites” that comprise a collection of products such as an ESB, an orchestration engine, a SOAP engine, an enterprise registry/repository, a BPEL engine and design- time tools, Business Activity Monitoring and related tools, and more. The features present in these products from vendor to vendor are not consistent. For example, you might have an ESB from one vendor that handles transformations for you, and another ESB product that delegates transformations to an orchestration engine.
It can all get very confusing. You can get a standalone orchestration engine, such as Apache ODE or Active Endpoints VOS, as well as standalone ESBs. Some ESBs run on an application server. Some vendors, such as Oracle, include a “light” subset of orchestration functions directly in their ESB but also sell an orchestration product.
The ESB is capable of connecting a variety of messaging systems without forcing you to create point-to-point channels that are visible to application clients. Clients connect to the bus, which serves as a mediation layer that shields clients from the disparate messaging formats and protocols used in the backend systems. The bus choreographs message interactions with a variety of related SOA technologies, such as rules engines (external or embedded), an orchestration engine (employing BPEL or XPDL), adapters for legacy and packaged applications, and internal routing and transformation mechanisms. This allows all of the nodes of the bus to interact without having to create specific routes to each application, thereby reducing the maintenance overhead. Because the bus abstracts and mediates connected nodes, some flexibility is achieved; if you want to swap out one application for another one, you can do so with minimal disruption to the overall solution. ESBs are the backbone of SOA. They provide the opportunity to really make your entire IT landscape visible, integrated, and ready to participate in new composite applications across EAI, supply chain, B2B, portals, and more.
An ESB is often lightweight, and offers a centralized system for deploying components that can scale independently.
An ESB allows you to send messages between multiple services in a distributed environment, offering a layer of indirection that provides a rich set of mediating features for those messages. An ESB is typically platform-independent in the sense that it will run on a range of operating systems and is often neutral with respect to application server and programming language. The bus allows you to connect native Java applications, .NET applications, object request brokers, and legacy platforms. To achieve this end, most ESBs offer support for invoking web services and other network-ready application nodes, employ adapters to connect with packaged and legacy applications, offer robust routing support for messages, allow orchestration and transformation of message content, and more.
Subscribe to:
Posts (Atom)