Since the inception of the JAR modularity has been a big reason why developers have chosen Java as a development platform. In Java's 20 year history never have there been so many different types of modularity options to choose from. From OSGi, to Docker, to JavaEE Microservices/SOA and finally the upcoming Java 9 release with the promise of Project Jigsaw. This session will discuss the different types of modular architectures available for Java applications as well as the benefits and the tradeoffs for each one. Are you looking for pure speed? Automatic scaling? Programer productivity? Selecting the correct architecture is fundamental in creating technical ecosystems where application development can move quickly and independently.
7. UNIX Rule of Modularity
Developers should build a program out of
simple parts connected by well defined
interfaces, so problems are local, and parts
of the program can be replaced in future
versions to support new features. This rule
aims to save time on debugging code that is
complex, long, and unreadable.
- Eric Raymond
58. References
Parnas, D. L. On the criteria to be used in decomposing systems into modules.
Commun. ACM 15, 12 (December 1972), 1053-1058.
DOI=10.1145/361598.361623 http://doi.acm.org/10.1145/361598.361623
Knoernschild, Kirk. Java Application Architecture: Modularity Patterns with
Examples Using OSGi Addison-Wesley Professional 2012
Brooks, Fred. The Mythical Man-Month: Essays on Software Engineering
Addison-Wesley 1975
Raymond, Eric S. The Art of Unix Programming Addison-Wesley 2003
Perlis, Alan. Epigrams in Programming ACM SIGPLAN Notices 17 (September
1982) http://www.cs.yale.edu/homes/perlis-alan/quotes.html
So today's talk isn't really about anything new and sexy like Microservices or Data Science. However I've found many of the most interesting problems to work with are the ones that we've known about since the dawn of Computer Science and still grapple with today. For example how many people here have been on a project that has fallen behind schedule. Be honest. Ok how many times has the solution been to add more people? An how many of you are still not done?
Well this quote should ring pretty true.
1975 – Mythical Man Month
I use it.
Leads to the next question
It Depends
Can the project actually be broken down
It depends on Modularity
So let talk about what I mean by this.
Here's one definition from the Unix Philosophy.
I think this answers it pretty well for 2 sentences.
But that doesn't really give me enough to work with. Lets go deeper.
Lets talk about what makes a module.
Anyone care to take a stab at this?
Kirk Knoewschild Definition different
Deployable
Manageable
Testable
Natively Reusable
Composable
Stateless
Simple – need to name
Name = purpose
Version – software evolves
Together should be unique
Developer should be able to identify and integrate
Useless if it can only be used in one place
It should also be easily removable from an application.
Protect inner workiings from the public
Sounds bad but helps with refactoring
If exposed people will write code with it
Once that happens Piss community off or dance around the problems
Ever create a admin interface that a client found?
David Parnas – Module design.
We need to think about this
Existing or new we have a tendency towards the ball of mud. (one big class. One big program)
Here are some things he mentions we need to think about in his paper
Hard – Fortune telling
Where do we have questions. Where are we unclear
Good candidate for change
Encapsulate things that might change
Loose coupling. The key to making 9 babies
Separate deployable units
Independent function - Manageable
Cohesion
Understood without the rest of the system
Lets talk about Java…
Java has a number of features that help with modularity ootb
Packages - Groups of classes
Imports – Allow classes from other groups into other classes
Ways of protecting implementation details
Currently packages can't be versioned
Neither can jars
By default classes are public
No good way to restrict people from using them
This is why Java never removes anything
Interfaces and Spring Contexts
We need to go beyond this. DI is only a start not a solution
Still have public classes. No versioning.
No more rt.jar or tools.jar
Is a upcoming new technology based upon a number of older technologies
A lot like virtualization but no hypervisor
Native Libraries
Similar Network ports
Shared file systems
But with this comes added complexity
Discovery
Orchestration
What were code issues are now spread over the whole system