Wrong confirmation ID

Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize… Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

OSGi in the Enterprise: Agility, Modularity, and Architecture's Paradox

by pragkirk on Feb 25, 2010

6,304 views

More…

Less

6 Embeds 1,057

http://techdistrict.kirkk.com	918
http://michaelsheen.sinaapp.com	83
http://www.slideshare.net	48
http://www.schoox.com	6
http://paper.li	1
http://webcache.googleusercontent.com	1

Statistics

Favorites: 23
Downloads: 524
Comments: 2
Embed Views: 1,057
Views on SlideShare: 5,247
Total Views: 6,304

1–2 of 2 previous next

Douglas WANG , Software Architect at Longtop Good OSGi presentation for Software Architect.

I'd like the ppt file converted from keynote too. Could you pls. send it to me?
My email is miqi05 at gmail.com.

Thanks a lot. 1 year ago Reply
Are you sure you want to Yes No
Xeny Maeng Could you please send the ppt file converted from keynote to me ?
My email is winfavor at gmail.com.
Thanks and best regards. 1 year ago Reply
Are you sure you want to Yes No

Hello, and welcome to OSGi in the Enterprise.
Dollo’s Law -> Reversibility -> Defer Commitment and other Lean Principles

There is a law, called Dollo’s Law, that states that evolution is not reversible. As an organism evolves, it cannot evolve into a state formerly realized in it’s ancestors. In other words, evolution is irreversible, and future possibilities can only unfold within the limits of the inherited design. Translated loosely, we are born, grow old, and die; eggs break; wood burns; these are things we accept and view as irreversible. Once done, they cannot be undone. Commonly, we take a similar approach to architecture. In other words, once architectural decisions are made, we feel they cannot be undone. Often times, this is not too far from the truth for two reasons primarily – first, the architecture is not able to accommodate change, second the architect is not willing to accommodate change. As we talk about agile architecture, we’ll try to keep these two themes in mind – the ability of the architecture and the willingness of the architect.

Lehman’s 2nd law - As a system evolves, it’s complexity increases unless work is done to maintain or reduce it.

There is a law, called Dollo’s Law, that states that evolution is not reversible. In other words, as an organism evolves, it cannot evolve into a state formerly realized in it’s ancestors. In other words, evolution is irreversible. Once an organism adopts a particular form, future possibilities can only unfold within the limits of the inherited design. More generally, irreversibility is when a closed system cannot be restored to a previous state without some expenditure of energy. This is because, as evolution progresses, or an irreversible process progresses, entropy increases. That is, the irreversible process itself requires energy that cannot be recovered, and a certain amount of energy is required as the system evolves. In the real world, we often think in terms of thermal efficiency - how much of the energy generated by my furnace is translated to heat that warms my house versus energy that is lost. A certain amount is lost due to dissipation or friction, and this cannot be recovered if we reverse the process. Irreversibility is a process that is one way over time. Translated loosely, we are born, grow old, and die; eggs break; wood burns; these are things we accept and view as irreversible. Once done, they cannot be undone. We accept this one way behavior as a simple truth - time has a certain direction. And this drives us to operate under the common sense conviction that by acting now, we can affect the future but obviously not the past. And so we try to act now.

This story of agile architecture steps beyond the common practices that state that “Avoid ivory tower architecture”, “Architects must write code”, “Perform just-in-time architecture”, “Architect throughout the lifecycle”, “Don’t use a heavyweight UML modeling tool”, “Communicate your architecture”, “Manage change and complexity”, “Deliver working solutions”, or “Prove your architecture early”. I’d like to think we take it a step further by exploring the goals of agile architecture, and then examine how we really realize these goals.

Reference: http://www.isepp.org/Pages/01-02%20Pages/Albert.html

What does this have to do with software architecture? Absolutely nothing...except that a good software architecture is not irreversible, and therefore, we are not required to make all architectural decisions RIGHT NOW!

But what if the system were reversible? What if we were able to apply energy from another external force to reverse the process. We see this today with refrigerators. In thermodynamics, heat always flows from hot to cold, not vice versa. But with a refrigerator, we use an alternative source of energy to reverse the affect.
Today, I’m going to talk about modularity in enterprise software development, and its important contribution in helping us design more flexible, adaptable, and reusable enterprise software. We’ve heard these promises, from other technologies that have come before, but modularity represents an important step in completing the architectural puzzle. Over the past 10 years, and especially that past three or four, the momentum behind modularity has been staggering, and we are on the verge of a disruptive transition that will transform how we think about designing enterprise software. Today, I’m going to tell you the story of why we need modularity in enterprise software development.

OSGi in the Enterprise - Agility, Modularity, and Architecture’s Paradox

Attempts to architect more flexible software often results in the opposite - brittle software fraught with complexity. Something is missing. Complexity is the beast we must tame, and modularity is part of the answer. In this keynote, we’ll examine the challenges of traditional approaches to software architecture, probe the paradox of architecture, and explore the inextricable link between structural and temporal architectural decisions. From the highest level applications and services to the code that exists in the bowels of the system, we expose the advantages of a modular architecture. Come learn new ways that large software systems can be organized to increase flexibility, reusability, adaptability, maintainability, testability, and extensibility. Come discover the importance of OSGi in the Enterprise!

Today, I’m going to tell you why!
I’m going to start by talking about the growing problem of software complexity. It’s quite astounding, actually. Then, we’ll move on into exploring architecture’s role in managing that complexity, from which emerges architecture’s paradox. It’s at this point, that we’ll delve more deeply into the role of modularity, which in conjunction with other paradigms such as OO and SOA, is going to help us overcome the paradox.

Defining Architecture - understanding the goal of architecture and the problems we face in realizing that goal
Modularity - A missing intermediary ingredient surrounding how we solve the problem that help us realize the goal.
Last two sections present some patterns and then a sample case study that applies those systems. The sample is gleaned from a real world project that’s been simplified for purposes of demonstration.

Or think of it this way...The Question...The Problem...The Answer
I’m going to start by talking about the growing problem of software complexity. It’s quite astounding, actually. Then, we’ll move on into exploring architecture’s role in managing that complexity, from which emerges architecture’s paradox. It’s at this point, that we’ll delve more deeply into the role of modularity, which in conjunction with other paradigms such as OO and SOA, is going to help us overcome the paradox.

Defining Architecture - understanding the goal of architecture and the problems we face in realizing that goal
Modularity - A missing intermediary ingredient surrounding how we solve the problem that help us realize the goal.
Last two sections present some patterns and then a sample case study that applies those systems. The sample is gleaned from a real world project that’s been simplified for purposes of demonstration.

Or think of it this way...The Question...The Problem...The Answer
I’m going to start by talking about the growing problem of software complexity. It’s quite astounding, actually. Then, we’ll move on into exploring architecture’s role in managing that complexity, from which emerges architecture’s paradox. It’s at this point, that we’ll delve more deeply into the role of modularity, which in conjunction with other paradigms such as OO and SOA, is going to help us overcome the paradox.

Defining Architecture - understanding the goal of architecture and the problems we face in realizing that goal
Modularity - A missing intermediary ingredient surrounding how we solve the problem that help us realize the goal.
Last two sections present some patterns and then a sample case study that applies those systems. The sample is gleaned from a real world project that’s been simplified for purposes of demonstration.

Or think of it this way...The Question...The Problem...The Answer
I’m going to start by talking about the growing problem of software complexity. It’s quite astounding, actually. Then, we’ll move on into exploring architecture’s role in managing that complexity, from which emerges architecture’s paradox. It’s at this point, that we’ll delve more deeply into the role of modularity, which in conjunction with other paradigms such as OO and SOA, is going to help us overcome the paradox.

Defining Architecture - understanding the goal of architecture and the problems we face in realizing that goal
Modularity - A missing intermediary ingredient surrounding how we solve the problem that help us realize the goal.
Last two sections present some patterns and then a sample case study that applies those systems. The sample is gleaned from a real world project that’s been simplified for purposes of demonstration.

Or think of it this way...The Question...The Problem...The Answer
Modularity - A missing intermediary ingredient surrounding how we solve the problem that help us realize the goal.
Certainly this doesn’t factor density. Dynamic languages will produce less code. But Cobol is about the same as C. http://www.embedded.com/design/210602856

Larger systems are more difficult to understand and maintain.
Writing new software impedes time-to-market. Wouldn’t it be nice to just assemble software?

Can dynamic languages help? Possibly. But they’ll grow in size too.
Certainly this doesn’t factor density. Dynamic languages will produce less code. But Cobol is about the same as C. http://www.embedded.com/design/210602856

Larger systems are more difficult to understand and maintain.
Writing new software impedes time-to-market. Wouldn’t it be nice to just assemble software?

Can dynamic languages help? Possibly. But they’ll grow in size too.
FreeBSD - 2002 at roughly 8 million. 2009 not quite at 16 million.
Linux Kernel - 2004 at 6 million. 2009 at 12 million.
Software growth is a good thing. It means people are using your system and are demanding more from it. They like it and they want to keep using it. Software that
- doesn’t evolve dies and
- cannot evolve dies.
If a software system doubles in size every 7 years, it’s doubtful the original architecture was able to predict all that is yet to come. BAUF cannot predict the architectural shifts that will occur.

Architects architect architecture - social process structure
delineate architecture from design
BAUF cannot work
evolution is critical.

A few preliminary notes before we get started….

Isn’t it amazing that we often try to define a system’s architecture before we have a solid understanding of the business requirements that the architecture must support? Often, we attempt to design a flexible architecture, but fail to design flexibility in the necessary areas.

And what of this? What actually is the difference between architecture and design? Certainly complexity has something to do with this. But complexity can easily derail. And as Gall’s law states…

Again, keep these ideas in mind as we progress throughout the presentation.

BAUF/BDUF cannot work. We design flexibility where is isn’t needed. We cannot predict. Tell story of Java EE patterns (DAO factory to switch db, but not deal with different datastores).
A runtime environment isn’t enough, though. We also need tools that help with the prog. model and well as knowledge surrounding the design paradigm. EJB or OO example from blog.

Enterprise Java Beans (EJB), and especially entity beans, were presented as part of Java EE as a way to componentize business applications. The runtime capabilities of EJB were very alluring - transactions, persistence, security, transparency, etc. - and baked directly into the platform. Unfortunately, there were two glaring problems. The development model was complex and it was not well understood.
It was a number of years ago, but I recall vividly my first experience with EJB. I arrived on the team mid-way through their development effort. At that point, they had more than 100 entity beans, the localhost environment took more than four hours to start-up, and problems were rampant. I stuck around for three weeks before I got the hell out. The project wound up getting cancelled. Developers were able to easily understand the EJB programming model (especially with all the code generation wizards), but lacked the design wisdom to use EJB effectively.
Another tool in our toolbox that help with architecture. Object are too fine grained. Services too coarse. Modularity just right.
While few teams are designing modular software systems, they should be. The goal of architecture necessitates it. So what is this goal of architecture.

Now we’ll explain how modularity increases architectural agility by allowing us to realize these benefits. First, I want to level set on the goal of architecture.
Pretty good reason why we don’t design this way.
What if the platform did support modularity?

As platform support for modularity increases, more teams will want to take advantage of the benefits of modularity. And like we’ve so often seen in the past, teams will struggle to realize these benefits. To understand why, I want to back up, start at the beginning, and talk about software architecture.
Software growth is a good thing. It means our software is surviving. As software grows, its architecture must evolve. Evolution is imperative, implying that we must have an architecture that can adapt. Without it, our systems will die. So how do we create this type of agile architecture? First, let’s look at architecture and examine what it takes to create this type of adaptive architecture.

What do we try to accomplish with architecture? What is it’s goal?
Summary of key phrases -> Components, Significant Decisions, Shared Understanding, Relationships and organization of the system, evolution.
Without question, architectural shifts will occur throughout the course of the project. Sometimes, we anticipate correctly. Sometimes not. Agile architecture is defined by our willingness and ability to embrace architectural change. Yet to embrace architectural change demands that we have an architecture that can accommodate change. Simply because a process is employed that embraces architectural change throughout the software lifecycle does not mean that it’s possible to make that change. Here, the inextricable link between the temporal and structural aspect is established.
Whereas the temporal aspect of agile architecture demands that the architect be flexible, the structural aspect of agile architecture demands that the architecture be flexible so that the team is able to quickly make the change. Agile architecture demands both, and the absence of one precludes the presence of the other.
Modularity is a key ingredient of agile architecture. Modularity ensures that development teams understand architectural dependencies that are going to inhibit or accommodate change. Simply embracing an attitude of change is not enough. We must also be able to accommodate change efficiently. Modularity allows the development team to envision and manage change more easily, meaning they’ll be able to make the change they want to make when they want to make it.
So what makes something significant enough to be deemed architectural? Difficult to change. Why hard to change? Don’t understand, complex, lacks flexibility. Irreversibility. What if we could make them reversible?

The underlying goal of agile architecture is to defer commitment for decisions until we have the knowledge we need to make the decision. At least, this is the case for the irreversible decisions. For reversible decisions, it doesn’t matter because the decision can be changed at any time. Making decisions reversible is the essence of agile architecture.

Well...actually...we need to minimize the impact and cost of change, thereby making change less architecturally significant.

The analogy we draw comparing building and software architecture is flawed. Changing a building is difficult. Adding a new floor in between the 2nd and 3rd floor of a building is always incredibly expensive. However, software can be made easy to change, and the software architecture should strive to make this a goal.

In fact, there is no absolute or theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. And making something easy to change inevitably makes the overall system more complex. And making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. Software is not limited by physics like buildings and bridges are. It is limited only by imagination, design. In other words, it is limited by our abilities, not the properties of the real world. The enemy of software is us.

Yet, the way we minimize the impact and cost of change presents a challenging paradox.
So what makes something significant enough to be deemed architectural? Difficult to change. Why hard to change? Don’t understand, complex, lacks flexibility. Irreversibility. What if we could make them reversible?

The underlying goal of agile architecture is to defer commitment for decisions until we have the knowledge we need to make the decision. At least, this is the case for the irreversible decisions. For reversible decisions, it doesn’t matter because the decision can be changed at any time. Making decisions reversible is the essence of agile architecture.

Well...actually...we need to minimize the impact and cost of change, thereby making change less architecturally significant.

The analogy we draw comparing building and software architecture is flawed. Changing a building is difficult. Adding a new floor in between the 2nd and 3rd floor of a building is always incredibly expensive. However, software can be made easy to change, and the software architecture should strive to make this a goal.

In fact, there is no absolute or theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. And making something easy to change inevitably makes the overall system more complex. And making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. Software is not limited by physics like buildings and bridges are. It is limited only by imagination, design. In other words, it is limited by our abilities, not the properties of the real world. The enemy of software is us.

Yet, the way we minimize the impact and cost of change presents a challenging paradox.
So what makes something significant enough to be deemed architectural? Difficult to change. Why hard to change? Don’t understand, complex, lacks flexibility. Irreversibility. What if we could make them reversible?

The underlying goal of agile architecture is to defer commitment for decisions until we have the knowledge we need to make the decision. At least, this is the case for the irreversible decisions. For reversible decisions, it doesn’t matter because the decision can be changed at any time. Making decisions reversible is the essence of agile architecture.

Well...actually...we need to minimize the impact and cost of change, thereby making change less architecturally significant.

The analogy we draw comparing building and software architecture is flawed. Changing a building is difficult. Adding a new floor in between the 2nd and 3rd floor of a building is always incredibly expensive. However, software can be made easy to change, and the software architecture should strive to make this a goal.

In fact, there is no absolute or theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. And making something easy to change inevitably makes the overall system more complex. And making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. Software is not limited by physics like buildings and bridges are. It is limited only by imagination, design. In other words, it is limited by our abilities, not the properties of the real world. The enemy of software is us.

Yet, the way we minimize the impact and cost of change presents a challenging paradox.
So what makes something significant enough to be deemed architectural? Difficult to change. Why hard to change? Don’t understand, complex, lacks flexibility. Irreversibility. What if we could make them reversible?

The underlying goal of agile architecture is to defer commitment for decisions until we have the knowledge we need to make the decision. At least, this is the case for the irreversible decisions. For reversible decisions, it doesn’t matter because the decision can be changed at any time. Making decisions reversible is the essence of agile architecture.

Well...actually...we need to minimize the impact and cost of change, thereby making change less architecturally significant.

The analogy we draw comparing building and software architecture is flawed. Changing a building is difficult. Adding a new floor in between the 2nd and 3rd floor of a building is always incredibly expensive. However, software can be made easy to change, and the software architecture should strive to make this a goal.

In fact, there is no absolute or theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. And making something easy to change inevitably makes the overall system more complex. And making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. Software is not limited by physics like buildings and bridges are. It is limited only by imagination, design. In other words, it is limited by our abilities, not the properties of the real world. The enemy of software is us.

Yet, the way we minimize the impact and cost of change presents a challenging paradox.
How do we make decisions reversible? We try to design flexible software that can adapt to change. Herein lies the paradox.
We try to reduce the impact and cost of change by designing more flexible systems. How do we design more flexible software systems? Attempt to accommodate variances in behavior given a particular context using a variety of techniques (external configuration, DI, reflection, OO). But this flexibility naturally increases complexity, and herein lies a problem. We attempt to create lightweight cohesive entities at the right level of granularity. They don’t do too much, yet do enough to make them useful - easy to understand, use, and change. But we continue to struggle.

We design flexible systems to the point where we can’t understand it. Massive object models (layers, DI, reflection, etc.). Lots of external configuration. We need something else beyond objects. We must recognize where flexibility is needed. WE NEED MODULARITY.

Once we’ve got this flexible system, with layers, dependency injection, external configurations, reflection, lots of extensibility, we discover that noone can understand it. And as the system grows, the problem is only exacerbated.

A system survives as long as it can evolve. To survive, the architecture must be flexible. Unfortunately, because flexibility increases complexity, the impact and cost of change also increases. And with each change, entropy sets in which further decreases evolvability and survivability.
There is a tension that exists between granularity and weight that makes our entities more reusable, though less useable or more useable, yet less useable. ...
Weight - Dependency on the environment. Granularity - extent to which system is broken into parts. There is tension here. Ex. Should a module pay the bill (dup check, audit, pay, remit) or should each be a separate module?
It also makes the system more difficult to maintain and increases complexity (remember the paradox).
Granularity
Granularity is the extent to which a system is broken down into parts. Coarse-grained components tend to be richer in behavior than fine-grained components. Because coarse-grained components do more, they tend to be bigger than fine-grained components. To maximize reuse, we try composing coarse-grained components from fine-grained components. Of course, this results in a lot of dependencies between components, making them more difficult to use. In general, we can say the following:
Coarse-grained components are easier to use, but fine-grained components are more reusable.
Time for an example. Let’s say we’re creating a component that processes health insurance claims. Let’s keep the business process relatively simple here to maintain our sanity. There are four steps in the process. First, the system is fed the claim information. Second, the system checks to make sure it’s not a duplicate submission. Third, the system reprices the claim based on HMO and PPO agreements. Fourth, the system remits payment. A coarse-grained component would perform all four of these steps.
In doing this, we’ve made it easy to use since we only need to invoke one operation to complete the whole process. But it’s also more difficult to reuse only a portion of this process, such as the remit payment code. The logical solution is to create four fine-grained components (one for each step in the process) and one coarse-grained component composed of the four others that pulls everything together. The fine-grained components make things more reusable, but are also more difficult to use since we have to do more to pull them all together to perform a unit of work.
Weight
Weight is the extent to which a component depends on it’s environment. A heavyweight component depends on it’s operating environment, while a lightweight component avoids these dependencies. When creating a component that runs in multiple environments, we’re forced to move the environment specific dependencies (ie. context dependencies) from code to configuration. This makes the component more reusable, but it’s also a bit more difficult to use since the component must be configured for each environment.
Designing and configuring a lightweight component is more difficult than simply dropping in a component programmed to operate in that environment. In general, we can say the following:
Lightweight components are more reusable, but heavyweight components are easier to use.
Let’s elaborate using the example above, where the solution was to create one coarse-grained component composed of four fine-grained components. If each of these components only needs to run within a single application in a single operating environment, we can encapsulate all of this environmental code into each component, making each heavyweight. But if we want to reuse these components across applications and operating environments, then we have to move this code outside of the component and ensure it can be configured for each environment in which we want it to operate.
There is a tension that exists between granularity and weight that makes our entities more reusable, though less useable or more useable, yet less useable. ...
Weight - Dependency on the environment. Granularity - extent to which system is broken into parts. There is tension here. Ex. Should a module pay the bill (dup check, audit, pay, remit) or should each be a separate module?
It also makes the system more difficult to maintain and increases complexity (remember the paradox).
Granularity
Granularity is the extent to which a system is broken down into parts. Coarse-grained components tend to be richer in behavior than fine-grained components. Because coarse-grained components do more, they tend to be bigger than fine-grained components. To maximize reuse, we try composing coarse-grained components from fine-grained components. Of course, this results in a lot of dependencies between components, making them more difficult to use. In general, we can say the following:
Coarse-grained components are easier to use, but fine-grained components are more reusable.
Time for an example. Let’s say we’re creating a component that processes health insurance claims. Let’s keep the business process relatively simple here to maintain our sanity. There are four steps in the process. First, the system is fed the claim information. Second, the system checks to make sure it’s not a duplicate submission. Third, the system reprices the claim based on HMO and PPO agreements. Fourth, the system remits payment. A coarse-grained component would perform all four of these steps.
In doing this, we’ve made it easy to use since we only need to invoke one operation to complete the whole process. But it’s also more difficult to reuse only a portion of this process, such as the remit payment code. The logical solution is to create four fine-grained components (one for each step in the process) and one coarse-grained component composed of the four others that pulls everything together. The fine-grained components make things more reusable, but are also more difficult to use since we have to do more to pull them all together to perform a unit of work.
Weight
Weight is the extent to which a component depends on it’s environment. A heavyweight component depends on it’s operating environment, while a lightweight component avoids these dependencies. When creating a component that runs in multiple environments, we’re forced to move the environment specific dependencies (ie. context dependencies) from code to configuration. This makes the component more reusable, but it’s also a bit more difficult to use since the component must be configured for each environment.
Designing and configuring a lightweight component is more difficult than simply dropping in a component programmed to operate in that environment. In general, we can say the following:
Lightweight components are more reusable, but heavyweight components are easier to use.
Let’s elaborate using the example above, where the solution was to create one coarse-grained component composed of four fine-grained components. If each of these components only needs to run within a single application in a single operating environment, we can encapsulate all of this environmental code into each component, making each heavyweight. But if we want to reuse these components across applications and operating environments, then we have to move this code outside of the component and ensure it can be configured for each environment in which we want it to operate.
There is a tension that exists between granularity and weight that makes our entities more reusable, though less useable or more useable, yet less useable. ...
Weight - Dependency on the environment. Granularity - extent to which system is broken into parts. There is tension here. Ex. Should a module pay the bill (dup check, audit, pay, remit) or should each be a separate module?
It also makes the system more difficult to maintain and increases complexity (remember the paradox).
Granularity
Granularity is the extent to which a system is broken down into parts. Coarse-grained components tend to be richer in behavior than fine-grained components. Because coarse-grained components do more, they tend to be bigger than fine-grained components. To maximize reuse, we try composing coarse-grained components from fine-grained components. Of course, this results in a lot of dependencies between components, making them more difficult to use. In general, we can say the following:
Coarse-grained components are easier to use, but fine-grained components are more reusable.
Time for an example. Let’s say we’re creating a component that processes health insurance claims. Let’s keep the business process relatively simple here to maintain our sanity. There are four steps in the process. First, the system is fed the claim information. Second, the system checks to make sure it’s not a duplicate submission. Third, the system reprices the claim based on HMO and PPO agreements. Fourth, the system remits payment. A coarse-grained component would perform all four of these steps.
In doing this, we’ve made it easy to use since we only need to invoke one operation to complete the whole process. But it’s also more difficult to reuse only a portion of this process, such as the remit payment code. The logical solution is to create four fine-grained components (one for each step in the process) and one coarse-grained component composed of the four others that pulls everything together. The fine-grained components make things more reusable, but are also more difficult to use since we have to do more to pull them all together to perform a unit of work.
Weight
Weight is the extent to which a component depends on it’s environment. A heavyweight component depends on it’s operating environment, while a lightweight component avoids these dependencies. When creating a component that runs in multiple environments, we’re forced to move the environment specific dependencies (ie. context dependencies) from code to configuration. This makes the component more reusable, but it’s also a bit more difficult to use since the component must be configured for each environment.
Designing and configuring a lightweight component is more difficult than simply dropping in a component programmed to operate in that environment. In general, we can say the following:
Lightweight components are more reusable, but heavyweight components are easier to use.
Let’s elaborate using the example above, where the solution was to create one coarse-grained component composed of four fine-grained components. If each of these components only needs to run within a single application in a single operating environment, we can encapsulate all of this environmental code into each component, making each heavyweight. But if we want to reuse these components across applications and operating environments, then we have to move this code outside of the component and ensure it can be configured for each environment in which we want it to operate.
and we have to be careful in managing complexity by understanding where the complexity is warranted. Sadly, we cannot always do this because of unanticipated change. We have to do our best, by working to accommodate change that causes architecture to shift.

We try to reduce the impact and cost of change by designing more flexible systems. But flexibility naturally increases complexity, and we have to be careful in managing complexity by understanding where the complexity is warranted. Sadly, we cannot always do this because of unanticipated change. We have to do our best, by working to accommodate change that causes architecture to shift.

How do we design more flexible software systems? Small cohesive entities at the right level of granularity. They don’t do too much, yet do enough to make them useful. Attempt to accommodate variances in behavior given a particular context using a variety of techniques (external configuration, DI, reflection, OO). Herein lies a problem. There is a tension that exists between granularity and weight that makes our entities more reusable, though less useable or more useable, yet less useable. ...

We design flexible systems to the point where we can’t understand it. Massive object models (layers, DI, reflection, etc.). Lots of external configuration. We need something else beyond objects. We must recognize where flexibility is needed. WE NEED MODULARITY.

Once we’ve got this flexible system, with layers, dependency injection, external configurations, reflection, lots of extensibility, we discover that noone can understand it. And as the system grows, the problem is only exacerbated.

A system survives as long as it can evolve. To survive, the architecture must be flexible. Unfortunately, because flexibility increases complexity, the impact and cost of change also increases. And with each change, entropy sets in which further decreases evolvability and survivability.
and we have to be careful in managing complexity by understanding where the complexity is warranted. Sadly, we cannot always do this because of unanticipated change. We have to do our best, by working to accommodate change that causes architecture to shift.

We try to reduce the impact and cost of change by designing more flexible systems. But flexibility naturally increases complexity, and we have to be careful in managing complexity by understanding where the complexity is warranted. Sadly, we cannot always do this because of unanticipated change. We have to do our best, by working to accommodate change that causes architecture to shift.

How do we design more flexible software systems? Small cohesive entities at the right level of granularity. They don’t do too much, yet do enough to make them useful. Attempt to accommodate variances in behavior given a particular context using a variety of techniques (external configuration, DI, reflection, OO). Herein lies a problem. There is a tension that exists between granularity and weight that makes our entities more reusable, though less useable or more useable, yet less useable. ...

We design flexible systems to the point where we can’t understand it. Massive object models (layers, DI, reflection, etc.). Lots of external configuration. We need something else beyond objects. We must recognize where flexibility is needed. WE NEED MODULARITY.

Once we’ve got this flexible system, with layers, dependency injection, external configurations, reflection, lots of extensibility, we discover that noone can understand it. And as the system grows, the problem is only exacerbated.

A system survives as long as it can evolve. To survive, the architecture must be flexible. Unfortunately, because flexibility increases complexity, the impact and cost of change also increases. And with each change, entropy sets in which further decreases evolvability and survivability.
What do we try to accomplish with architecture? What is its goal?
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
Architecture all the way down expands our options. It expands our deployment options. It expands our ability to compose new functionality from existing functionality. It expands our reuse options. So here’s an example.

Every major software technology trend of the past two decades cites reuse as a benefit. OO & services are two really good examples. Objects are really fine-grained entities, and compared to objects, services are relatively coarse-grained. So a big problem with reuse is finding something that’s at the right level of granularity for me to use. If a service does too much, I can’t reuse it. And once that happens, I’m forced to look at the objects, which are really hard to understand because there’s nothing bridging services and objects. But with modules, I have that intermediate unit. If a service doesn’t give me what I want, I can look to the finer-grained modules to assemble a new unit that does give me what I want.

BillPay example - pay a bill --> check for dups, audit, pay, remit (service, module, package, or class).
"A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." The scientist gave a superior smile before replying, "What is the tortoise standing on?" "You're very clever, young man, very clever", said the old lady. "But it's turtles all the way down!"
- A Brief History of Time by Stephen Hawking
"A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: "What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise." The scientist gave a superior smile before replying, "What is the tortoise standing on?" "You're very clever, young man, very clever", said the old lady. "But it's turtles all the way down!"
- A Brief History of Time by Stephen Hawking
Architecture all the way down expands our options. It expands our deployment options. It expands our ability to compose new functionality from existing functionality. It expands our reuse options. So here’s an example.

Every major software technology trend of the past two decades cites reuse as a benefit. OO & services are two really good examples. Objects are really fine-grained entities, and compared to objects, services are relatively coarse-grained. So a big problem with reuse is finding something that’s at the right level of granularity for me to use. If a service does too much, I can’t reuse it. And once that happens, I’m forced to look at the objects, which are really hard to understand because there’s nothing bridging services and objects. But with modules, I have that intermediate unit. If a service doesn’t give me what I want, I can look to the finer-grained modules to assemble a new unit that does give me what I want.

BillPay example - pay a bill --> check for dups, audit, pay, remit (service, module, package, or class).
Architecture all the way down expands our options. It expands our deployment options. It expands our ability to compose new functionality from existing functionality. It expands our reuse options. So here’s an example.

Every major software technology trend of the past two decades cites reuse as a benefit. OO & services are two really good examples. Objects are really fine-grained entities, and compared to objects, services are relatively coarse-grained. So a big problem with reuse is finding something that’s at the right level of granularity for me to use. If a service does too much, I can’t reuse it. And once that happens, I’m forced to look at the objects, which are really hard to understand because there’s nothing bridging services and objects. But with modules, I have that intermediate unit. If a service doesn’t give me what I want, I can look to the finer-grained modules to assemble a new unit that does give me what I want.

BillPay example - pay a bill --> check for dups, audit, pay, remit (service, module, package, or class).
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
How does modularity affect how we design? Joints of the system are more architecturally significant. With more flexible joints, we can accommodate shifts.

Maximize flexibility by emphasizing the joints within the system.

Just like TDD drives how we design our classes, modularity drives how we allocated classes to their deployment units.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.
Barbara Liskov OOPSLA 2010 - “It’s more important to make programs easier to read than to write.” In other words, we have to increase understanding. This helps reduce the impact and cost of change.

23 Favorites

anoncow Tags osgi 1 month ago
zhuanggl Tags module osgi 4 months ago
windmove Tags kirkk on modularity 5 months ago
Ray Cheng 6 months ago
pdudits Tags intro osgi 9 months ago
Douglas WANG , Software Architect at Longtop Tags osgi enterprise 1 year ago
declan.cox Tags osgi modularity architecture 1 year ago
tobeand Tags osgi 1 year ago
missedone Tags osgi 1 year ago
bouzonnet Tags osgi modularity 1 year ago

OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox — Presentation Transcript

Kirk Knoernschild Analyst, SDLC and Containers, OSGi in the Enterprise Languages, & Frameworks Burton Group Agility, Modularity, and Architecture’s Paradox www.burtongroup.com kknoernschild@burtongroup.com Blog: http://apsblog.burtongroup.com JAX London & OSGi DevCon Blog: http://techdistrict.kirkk.com Twitter: pragkirk February 23rd, 2010
OSGi in the Enterprise 2 “First they ignore you, then they ridicule you, then they ﬁght you, then you win.” -- Mahatma Gandhi
OSGi in the Enterprise 2 “First they ignore you, then they ridicule you, then they ﬁght you, then you win.” -- Mahatma Gandhi OSGi is a disruptive technology that will transform how enterprise Java applications are designed, developed, and managed!
OSGi in the Enterprise 3 1972
OSGi in the Enterprise 4 Complexity Architectural Agility Paradox Modularity
OSGi in the Enterprise 4 Complexity Architectural Agility Paradox Modularity
OSGi in the Enterprise 5 Complexity Why i What’ s soft st co mpl ware so How d o we mo dul he role of ex? co mpl tame arity? exity?
Complexity 6 Rising Cost of Software Complexity - 120 billion loc in 1990 Source: http://users.jyu.fi/~koskinen/smcosts.htm - 250 billion loc in 2000 - loc doubles every 7 years - 50% of development time spent understanding code - 90% of software cost is maintenance & evolution
Complexity 6 Rising Cost of Software Complexity - 120 billion loc in 1990 Source: http://users.jyu.fi/~koskinen/smcosts.htm - 250 billion loc in 2000 - loc doubles every 7 years - 50% of development time spent understanding code - 90% of software cost is maintenance & evolution Perspective: Not only double the past 7 years, but more than total amount ever written combined!
Complexity 7 Case in Point 2002 2008
Complexity 7 Case in Point 500% 2002 2008
Complexity 8 Reason to Celebrate Lehman’s Law: As a system evolves, its complexity increases unless work is done to maintain or reduce it. www.lumaxart.com/
Complexity 9 BAUF Doesn’t Cut It - BDU F - Exce an d BAUF! s docu m sive en - Resi tation! sting Chang e! We are often asked to design solutions to problems that require knowledge we currently do not possess.
Complexity 9 BAUF Doesn’t Cut It - BDU F - Exce an d BAUF! s docu m sive en - Resi tation! sting Chang e! We are often asked to design solutions to problems that require knowledge we currently do not possess.
Complexity 10 Gall’s Law A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
Complexity 11 Question --------------------------------------------------------------- How do we manage software complexity? Answer --------------------------------------------------------------- Modularity
Complexity 12 Defining Module Hey, it’s a JAR ﬁle! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent A module system provides a runtime environment for modules
Complexity 13 Advantages of Modularity - reus e - re du ce co m - ease ple mainte xity - incr nance ease exten sibility Umm...we can already do this with objects and services!
Complexity 13 Advantages of Modularity - reus - re du e Increases architectural agility! ce co m - ease ple mainte xity - incr nance ease exten sibility Umm...we can already do this with objects and services!
Complexity 14 Module Design Few teams are designing modular software systems today! POLL: Question: Response: ----------------------------------------------------- - How many design class relationships? _____ - How many design package relationships? _____ - How many design service relationships? _____ - How many design module (JAR, Assembly) relationships? _____
Complexity 15 Platform Modularity Why a re design n’t we Platforms discourage modularity! ing mo mo dul re ar sof tware ?
Complexity 16 Platform Modularity - Dyn am - Mult ic deployme ipl nt - Enfo e versions rce depen dencie s
Complexity 16 Platform Modularity - Dyn am - Mult ic deployme This is the next generation application platform! ipl - Enfo e versions nt rce depen dencie s
OSGi in the Enterprise 17 Architectural Agility What What What is arc is is hitect ure? archit the goal of ag ility architectur ecture ? al ?
Architectural Agility 18 What is Architecture? • An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural elements and behavioral elements into progressively larger subsystems, and the architecture style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. Source: Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999
Architectural Agility 19 What is Architecture? • In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers...Architecture is about the important stuff. Whatever that is. Source: Fowler, Martin. IEEE Software, 2003. “Who Needs an Architect?” A quote from Ralph Johnson on the XP mailing list.
Architectural Agility 20 What is Architecture? • The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. Source: ANSI/IEEE Std 1471-2000
Architectural Agility 21 What is Architecture? • A formal description of a system, or a detailed plan of the system at component level to guide its implementation • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. Source: TOGAF - http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html
Architectural Agility 22 What is Architecture? • Architecture embodies the critical design decisions that typify a system. • Relates to cost of change, organizational structure, structure of code, capabilities of a system, etc. • The significance of decisions needs to be understood and assessed • A heavy-weight approach is likely to reduce understanding and our ability to assess Source: QCON London Presentation by James Coplien & Kevlin Henney title Agile Architecture Is not Fragile Architecture - http://www.infoq.com/presentations/Agile- Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
Architectural Agility 23 The Goal of Architecture
Architectural Agility 23 The Goal of Architecture What if we were able to reduce the impact and cost of change?
Architectural Agility 23 The Goal of Architecture What if we were able to reduce the impact and cost of change? We n ee d t elimin o ate archit ectur e!
Architectural Agility 24 Reversibility Rever sible Ir reve can b Decisi rsible e eas o ns are n Decisi ily ch ot ea becau se the ange d becau sily c ons archit se the hange ec expen y are d acco m ture is abl siv to o mo dat e to intens e or reso u e cha ive. rce nge. First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed. -- “Implementing Lean Software Development: From Concept to Cash”
Architectural Agility 24 Reversibility Rever sible Ir reve can b Decisi rsible e eas o ns are n Decisi ily ch ot ea becau se the ange d becau sily c ons archit se the hange ec expen y are d acco m ture is abl siv to o mo dat e to intens e or reso u e cha ive. rce nge. First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed. -- “Implementing Lean Software Development: From Concept to Cash” Irreversible Decisions should be made as late as possible!
Architectural Agility 25 Defeating Complexity
OSGi in the Enterprise 26 Paradox Ho w d How d Are w o we o we ed more de dream realize failure o o me d to ﬂexib sign of reu the ? system le soft se? s? ware
Paradox 27 Architecture Paradox Increa sing e decre vo ases s lvability ur viva bility ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
Paradox 28 Tension Maximizing reuse complicates use
Paradox 28 Tension Maximizing reuse complicates use - SOL ID - Desi gn Pat - Mo d terns ularity Patter ns - SOA Princi ples
Paradox 29 Architecture Paradox Increa sing e decre vo ases s lvability ur viva bility ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
Paradox 29 Architecture Paradox We m Increa ust re sing e decre vo which cogniz e ases s lvability areas ur viva system of the bility deman increa d the se d co that w mplex ill bri ity greate ng r ﬂex ibility! ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
Paradox 30 Increasing Flexibility, Increasing Complexity
OSGi in the Enterprise 31 Modularity Ho w d How d How d oe oe oe help i s mo dularit help u s mo dularit help u s mo dularit ncrea y s real y s o ver y archit se ize re para d co me ectura use? ox? the l ag ilit y?
Modularity 32 Flexibility Where? Here? Which ar system ea of the Here? deman ﬂexib ds mo ility? re Here? Here? Here? Here? Here?
Modularity 33 Something is Missing ?
Modularity 34 Turtles & Architecture What do archit es ecture do w it have t h turt o les? Photo courtesy of: http://www.flickr.com/photos/mybloodyself/1108834349/
Modularity 34 Turtles & Architecture What do archit es ecture do w it have t h turt o les? “ Yo u’r e ver y yo ung clever man, v , clever er y ”, la dy. “ sai d the old But it all th ’s turt e way les down! -- A B ” rief H of Tim istor y e Photo courtesy of: http://www.flickr.com/photos/mybloodyself/1108834349/
Modularity 35 Architecture “all the way down” ? Reuse Release Equivalence: Unit of reuse is the unit of release!
Modularity 35 Architecture “all the way down” Reuse Release Equivalence: Unit of reuse is the unit of release!
Modularity 36 Shared Understanding
Modularity 36 Shared Understanding
Modularity 37 Architectural Joints Here? Which ar system ea of the Here? deman ﬂexib ds mo ility? re Here? Here? Here? Here? Here?
Modularity 37 Architectural Joints Which ar system ea of the deman ﬂexib ds mo ility? re
Modularity 38
Modularity 38 as change occurs
Modularity 38 as change occurs modules and their dependencies
Modularity 38 as change occurs isolate change modules and their dependencies
Modularity 38 as change occurs isolate change modules and their dependencies
Modularity 39 Before and After
Modularity 39 Before and After
Modularity 39 Before and After
Modularity 39 Before and After
Modularity 39 Before and After
Modularity 39 Before and After
Modularity 40 Reuse
Modularity 40 Reuse
Modularity 41 It’s All Good!
Modularity 42 Modular Architecture - Where to Now? Infras Progra Design tructu m m in g Para d - Run re - The Mo del - The igm time p frame techn suppo latfor an d te w o r ks use d t iques rt hel m ch o i den enforc ps that a nolog ies create tify a nd e mo d llow u the ri archit ular create s to of mo ght se ecture mo dul dules t . softw ar are
Modularity 42 Modular Architecture - Where to Now? Infras Progra Design tructu m m in g Para d - Run re - The Mo del - The igm time p frame techn suppo latfor an d te w o r ks use d t iques rt hel m ch o i den enforc ps that a nolog ies create tify a nd e mo d llow u the ri archit ular create s to of mo ght se ecture mo dul dules t . softw ar are The Design Paradigm - What’s the right granularity for a module? - What the right weight for a module?
OSGi in the Enterprise 43 Additional Resources • http://techdistrict.kirkk.com - Kirk’s blog with lots of content on modularity. • Modular Architecture Patterns - Book in Progress • http://modularity.kirkk.com/ • http://www.osgi.org - OSGi HomePage • OSGi in Practice by Neil Bartlett • http://neilbartlett.name/blog/osgibook/ • Modular Java by Craig Walls • OSGi and Equinox: Creating Highly Modular Java Systems by Jeff McAffer, et. al. • Tried to develop a modular architecture without OSGi? • JarAnalyzer - http://code.google.com/p/jaranalyzer/

OSGi in the Enterprise: Agility, Modularity, and Architecture's Paradox

by pragkirk on Feb 25, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 1,057

Statistics

OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox — Presentation Transcript