What is the proper way to make java reusable components that is capable of used in various applications. I mean for example I'm doing a application that has its own user interface and database and etc. If I want to make this app reusable for many other applications as a component of other applications. For example one feature of my first app may needed by other app. So how to make it possible for other apps to use this feature of my app without changing my original code. What are the proper ways to achieve this re usability.
Write something simple which does what it does very well. Document it and unit test it and make it open source.
Have the the reusable components in another project (e.g. "common") and package them as .jar. Then include that jar in the projects where it's needed.
Extracting a separate project might be tricky though. You should observer the following:
the common components should not be dependent on anything in the higher level of abstraction (i.e. you services must not have any UI-related dependencies)
the internals of the components must not be visible to the application using them. I.e. your jar should expose a minimum API.
You have a couple of options for the mechanics of packaging:
simple IDE-dependant packaging - declare a inter-project dependency. On build export the jar and put on the classpath of the client application
Maven/Ivy - install the dependency in a repository (local or remote) and use the dependency resolution mechanisms of maven/ivy
This is a rather broad question. As such, I am offering broad suggestions:
Know your OO basics. Inheritance, encapsulation, polymorphism. It gets crazier from there on out.
Learn about design patterns, start observing them in applications you already use.
Look at popular open libraries to see how they implement patterns and modules.
Try things in sandbox projects. Grow your knowledge in clean environments.
Since you mention Java, check out the Spring Framework.
Hope that helps.
You need code in such a way that your components are loosely coupled. Then the re-usability is very much high. Take a look at this and this.
Sun Microsystems, the creators of the Java language, have at last recognized this need, and have released the Java Beans Component Architecture. Java Beans are, quite simply, reusable controls written in Java, for Java application development.
Beans are "capsules" of code, each designed for a specific purpose. The advantage of Java Beans over standard programming controls is that Beans are independent. They are not specific to operating systems or development environments. A Bean created in one development environment can be easily copied and modified by another. This allows Java Beans greater flexibility in enterprise computing, as components are easily shared between developers.
Related
I'm working on a server engine, and I am not sure in what form to distribute it. It is quite modular and it uses interfaces/abstract classes.
Should it be:
a library (no entry-point, write your own main() and call new Server().setSomeHandler(myHandler).run())
a binary (executable entrypoint with config file where you can inject JAR with handlers)
something else?
Basically, the developer should be able to completely extend or change the way the server works. I don't like the idea of making it a library because it should be a platform by itself, a whole server system.
Providing a programmatic way is more versatile than just an executable. And both ways aren't mutually exclusive. After all, even if a developer provides a handler, internally you probably still need to call something like the setter in your example to actually use that handler. Exposing that API shouldn't be too difficult. You could still provide a small launcher application that loads some config file and wraps it in some API calls, if that is needed.
The more important question would be, are there predefined extension points where developers can plug in their own implementations or is everything completely modular and exchangeable?
For a simple way to provide implementations of predefined interfaces, you can use the ServiceLoader/SPI mechanism. You can built a basic plug-in system with it.
If you want to create a platform, something like OSGi seems more appropriate. Here you could define APIs/SPIs for fine grained components/services. Developers could then provide their own modules that extend the server or even replace your default modules.
In java, I have see so many "container" and it provide "context" to it's client.
Such as EJB container, Web Container, IoC/DI container and "ApplicationContext".
Is this concept a kind of design pattern? I have searched in GoF, and it seems didn't
describe a thing like this.
Not a design pattern, more of a design construct (well, I guess you could argue that the difference is in semantics). A Container would provide an environment (i.e. external code) for your code to run in, and a Context would provide environment settings and additional information for your code.
Instead of 'design pattern' a more suitable concept for 'Container' is Framework.
... a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software platform to develop software applications, products and solutions. ...
In java, I have see so many "container" and it provide "context" to it's client.
'Context' is the environment execution information provided by the Container to the Components that run on it. With the previous definition in mind you can see the 'Context' as one of the generic functionality provided by the Container.
More clear, you have a Container that runs components, each component access the environment information through the Context. Of course this not pretend to be a formal definition, it is just the way I like to think about this concept.
The GoF book is about OO design patterns, it was published in 1995
before all these Java enterprise patterns and servers came up.
It is at the level of classes, methods, etc. i.e. about OO concepts.
You may consider containers and contexts some sort of patterns, yes.
But they are about modules, components, containers, servers, and how
to make these modules and components run into containers and servers.
These are just things from a different time and at a different level.
I'm looking for a tool or set of tools to manage configuration both for our scala application stack and other applications, e.g. lighttpd.
I've been thinking of using Apache Zookeeper, but I haven't found anything that looks like a module for lighttpd (and possibly others). I also considered using for example Puppet, but there doesn't seem to be much of a Zookeeper module for it.
Essentially what I'm trying to achieve is to have one service that keeps configuration & that I can reconfigure dynamically and that would propagate to all services, both on and off the JVM.
Honestly, pick one of the Open Source Configuration Management Systems. One interesting choice that have recently appear and is not listed on Wiki is ANSIBLE.
Also, your problem might be one of orchestration, in which case tools like Chef's Knife, Capistrano, Fabric or MCollective are more adequate.
It might even be you want both, of course.
The best choice would be one written in a language you are familiar with. I don't know of any written in Scala, though this blog post is interesting. For programmers, Chef has great attraction, and handles very dynamic configurations well. I know someone who uses it to create/destroy VM instances on-demand, depending on the application load -- try that with Puppet, and you'll cry.
I like Puppet's declarative configuration style, and in particular the fact that it insulates you a lot from the Operating System differences. To Puppet, a Package is a Package, no matter what operating system you are using.
As for "Zookeeper module"... you might find good recipes/modules for these tools online, but you better be prepared to write your own. Do not chose based on the existence of one particular module -- chose based on how comfortable you feel writing them.
Although I'm a Java developer and this is question concerns OSGi and modularity according to Java, the question really applies for any object-oriented, 3GL.
I'm beginning to grasp the concepts of truly "modular" development and beginning to take a real liking to OSGi. For the first time ever I'm beginning of thinking of deploying jars in very granular, reusable, specialized deployments. However this new mode of thinking has stirred up a few questions.
In pure component-based architectures, does every class get jarred up? If not how granular should components be? Is it possible to make every component reusable?
What are some "rules of thumb" to use when determining how granular a modular component should be? Thanks in advance!
I'm going to answer this mostly from an OSGi perspective.
IMHO it's important to distinguish between components and modules. A component is a programming artefact: something that has behaviour and may offer services to other components. In implementation terms, you program a component using one of OSGi's component models such as Declarative Services. See http://wiki.osgi.org/wiki/Component_Models_Overview
A module is a deployment artefact: it is the packaging of components and/or APIs into an artefact that can be copied around and installed in various runtimes. Therefore implicitly you can package multiple components in one module, OR create one module per component.
The fact is, module contents are quite easy to refactor, so you shouldn't worry too much up front about the granularity: as you get more experience with OSGi you will find the right level for your own needs. However bear in mind the following general advice:
Components packaged together in the same module are (re)deployed together. If one of those components is being released more frequently than the others then you may be creating more work than necessary (e.g., testing by downstream consumers) by repeatedly releasing unchanged components, just because they happen to be in the same module as the changing component.
One cannot deploy half a module. Therefore all the components in a module should be closely related, so you do not make users wish "if only I could deploy just some of the components in this module"...
APIs change very slowly and cautiously, whereas components change frequently. For this and other reasons, APIs are best deployed in their own API bundles. See http://wiki.osgi.org/wiki/Separate_API_from_Implementation
In order to ensure module contents can be refactored without breaking users, always express your dependencies in terms of Import-Package rather than Require-Bundle. See http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle
I intend to develop a system that is entirely based on modules. The system base should have support for finding out about plugins, starting them up and being able to provide ways for those modules to communicate. Ideally, one should be able to put in new modules and yank out unused modules at will, and modules should be able to use each other's funcionality if it is available.
This system should be used as a basis for simulation systems where a lot of stuff happens in different modules, and other modules might want to do something based on that.
The system I intend to develop is going to be in Java. The way I see it, I intend to have a folder with a subfolder for each module that includes a XML that describes the module with information such as name, maybe which events it might raise, stuff like that. I suppose I might need to write a custom ClassLoader to work this stuff out.
The thing is, I don't know if my idea actually holds any water and, of course, I intend on building a working prototype. However, I never worked on a truly modular system before, and I'm not really sure what is the best way to take on this problem.
Where should I start? Are there common problems and pitfalls that are found while developing this kind of system? How do I make the modules talk with each other while maintaining isolation (i.e, you remove a module and another module that was using it stays sane)? Are there any guides, specifications or articles I can read that could give me some ideas on where to start? It would be better if they were based on Java, but this is not a requirement, as what I'm looking for right now are ideas, not code.
Any feedback is appreciated.
You should definitely look at OSGi. It aims at being the component/plugin mechanism for Java. It allows you to modularize your code (in so-called bundles) and update bundles at runtime. You can also completely hide implementation packages from unwanted access by other bundles, eg. only provide the API.
Eclipse was the first major open-source project to implement and use OSGi, but they didn't fully leverage it (no plugin installations/updates without restarts). If you start from scratch though, it will give you a very good framework for a plugin system.
Apache Felix is a complete open-source implementation (and there are others, such as Eclipse Equinox).
Without getting into great detail, you should be looking at Spring and a familiarization with OSGI or the Eclipse RCP frameworks will also give you some fundamental concepts you will need to keep in mind.
Another option is the ServiceLoader added in Java 1.6.
They are many way to do it but something simple can be by using Reflection. You write in your XML file name of file (that would be a class in reallity). You can than check what type is it and create it back with reflection. The class could have a common Interface that will let you find if the external file/class is really one of your module. Here is some information about Reflexion.
You can also use a precoded framework like this SourceForge onelink text that will give you a first good step to create module/plugin.