How to use a Component based Framework?

Hi,

I am interested how you use a component based framework?

Any hints are welcome .

Regards,
Darya

Assemble the components to your liking.
Use the thinest glue possible.
If the seams are not tight, you may need to thicken
the glue with some of your own code.
If you find yourself thickening the glue too often, consider another framework.

Any more ideas?

The question is a bit too open ended. Do you have such a framework in mind? Did it come with instructions, examples, unit tests?

Think about you write your own enterprise scale framework so that you have a semi-finished product. In my case the enterprise scale framework is based on J2EE.

Once you have this framework up you want to make use of it and create your final (customer or domain specific) product from it. In an OO approach we would go with inheritance, but here we have already lot of components in our framework doing things as we want them, except the domain specific parts. I think starting from the framework domain model adding the domain specific things to it and doing same development as we already did in the framework is a waste of time.

Now, I'm looking for some strategies how one should use such a framework. The whole issue is not related to any particular framework.

Regards,
Darya

Look into the Spring philosophy. One goal was to be non-intrusive, meaning your application code has few (if any) dependencies on the framework. So you avoid extending framework classes or even referencing framework APIs where possible. If that leaves you wondering what it can do and how it can work ... go read up on it. They did a cool thing.

Originally posted by Stan James:
... So you avoid extending framework classes or even referencing framework APIs where possible. If that leaves you wondering what it can do and how it can work ... go read up on it. They did a cool thing.

Sounds interesting. I'm really wondering how you use your framework when not referencing to it in one way or the other.

Do you have a link where I can start reading from?

Regards,
Darya

After reading in Spring's reference documentation I don't see where Spring does help me

Any more hints?

Regards,
Darya

Spring is just the most popular "dependency injection" (used to be called "inversion of control") system.

The way Spring is typically used is to "wire together" regular Java objects (which don't need to know anything about Spring). Spring takes care of creating objects as needed and passes them into appropriate constructors or methods as parameters.

To emphasize the point: your application code does not need to khow that it is running under Spring. Each of your classes just knows that when it needs an instance of another class it is given one.

I wasn't recommending Spring so much as the Dependency Injection approach they took. The approach of building base functionality in framework objects and extending them is quite common and I've done it many times. Google for Template Method or Hollywood Principle to see formal definitions. But it can paint you into corners because "extends" is limiting and tightly coupled.

Techniques to separate the application and the framework include Dependency Inversion and Dependency Injection. (See Google again) Say the application needs a repository service to store and retrieve documents. Make the Repository interface part of the application rather than part of a framework. Now the application can work with any implementation of Repository. The framework might implement the interface, or we might build an Adapter in between them. Now we've inverted the dependencies. Stuff "lower" in the architecture stack depends on interfaces defined "higher" up.

When we go to glue the application together if we make the application reference the adapter or framework class, we've put the old dependency back in. The application should only reference the interface. So we have an application assembler that reads configuration and gives the application a reference to a Repository. That's dependency injection. This gives us neat flexibility to inject a mock or test repository for development and testing.

Spring did a good job of this so you can build lots and lots of code without ever doing an import from Spring. Spring is pretty large now but I think it started with the dependency injection part. Look up dependency inversion and injection and see if they sound worth doing.

Ah, the sound of posts whizzing past each other in the night.

Thanks for the discussion ,

Originally posted by Frank Carver:
... To emphasize the point: your application code does not need to khow that it is running under Spring. ...

Maybe I should explain the framework a bit more. There is one and only one domain model. All framework components are implemented with EJBs and wellknown J2EE design patterns like business delegate, service locator, session facade, services, etc.

So there is no way to bring Spring to the party.

Originally posted by Stan James:
I wasn't recommending Spring so much as the Dependency Injection approach they took ...

Stan, thanks a lot for your great response . I'll have to check how I can bring your ideas together with EJB technology.

Regards,
Darya

The only EJBs in the framework are the session facades. The domain model objects are pure POJOs.

Regards,
Darya

Spring and the whole notion of POJO - Plain Old Java Objects - came about as backlash to the complexity of EJB. You can run Spring in an EJB container and blessedly few if any of your Java objects have any awareness or dependency on EJB.

Another approach ... I work in a vendor framework with exactly one EJB. It's strictly a protocol gateway. We don't have source and have never had any urge to modify it. All calls come through the gateway and it dispatches them out to the appropriate "services".

In other words, there are ways to run inside an EJB container without the downside of being coupled to EJB or having to start a server to test any component. With Spring leading the way, I'd say this is a trend. It's worth studying up a bit before building a framework that ties users forever to EJBs.

Keep in touch ... let us know how this all works out for you!

Originally posted by Stan James:
... I work in a vendor framework with exactly one EJB. It's strictly a protocol gateway. We don't have source and have never had any urge to modify it.

Since I use our company's framework I have the sources. However you can not simply go and extend the framework at your will.

Originally posted by Stan James:
... With Spring leading the way, I'd say this is a trend. It's worth studying up a bit before building a framework that ties users forever to EJBs.

Keep in touch ... let us know how this all works out for you!

Since there already has been lot of investments for the framework, there is no chance to get Spring involved. The framework is already in a stable condition and the only problem for the programmers is to use the framework in a right manner.

Now your ideas of plugging the framework into the final customer (domain) specific application through the Adapter and Template Method GoF Design Patterns seems to me the right way.

I just need to find a nice example to discuss this topic further :roll: .

Regards,
Darya

Let's discuss the topic further with an example framework. I've choosen a scenario which is described in Core J2EE Patterns at page 368 for an order processing system.

View the following class diagram. I want to use this framework in my example application.



I still need to find a little scenario for a customer specific application where I don't change the framework code but add some customer specific stuff. If you in the meantime have some scenario in mind feel free and let us know .

Regards,
Darya
[ January 09, 2007: Message edited by: Darya Akbari ]

The framework class diagram contains a domain model (all POJOs) and one component (all non POJOs). There could be more components but let's keep it simple and only have one component.

Now, having the framework visualized I'm going to use it. There are multiple scenarios thinkable and I start with a first one.

Think about you want to use the framework in your specific application. The only difference is that in your application the Order class needs an addidtional attribute let's say for a priority.

Think about that you can not simply extend the framework Order class and add priority, because that would mean that you can't use the component anymore.

What would be a elegant solution to it. The goal is to reuse the component based framework at best.

Any ideas ?

Regards,
Darya

We need an emoticon for threads risen from the dead.

Think about you want to use the framework in your specific application. The only difference is that in your application the Order class needs an addidtional attribute let's say for a priority.

Think about that you can not simply extend the framework Order class and add priority, because that would mean that you can't use the component anymore.

Now you're ready to talk about dependency injection again. Indeed, if something in your framework says:

we cannot extend order and add new functionality to it. If instead your framework says:

Now we have the chance to INJECT a custom OrderFactory that will return our custom Order. The framework might include an ApplicationAssembler that reads configuration to get the OrderFactory class and calls setOrderFactory. Or we might make the default factory read the Order classname from configuration. Good clean fun, no?

Originally posted by Stan James:
We need an emoticon for threads risen from the dead.

I agree .

I thought it would be a pity not taking this discussion a step further and I am very glad that you are back for it .

Factory pattern sounds very good. You mean Order should be made abstract which in terms of the pattern would be the Product. Hence I see the framework's OrderAppService as the Creator class.

What about the OrderSystemFacade which is an EJB? What if I need more features than the framework's EJB provide?
[ February 17, 2007: Message edited by: Darya Akbari ]

Originally posted by Stan James:
If instead your framework says:

Stan,

So far I would say that the factory itself must be a part of the framework. But doesn't the factory finally has to instantiate my concrete product MyOrder (e.g. MyOrder extends Order)? How does this go when the framework does not know MyOrder in advance ?

Regards,
Darya

Originally posted by Stan James:
The framework might include an ApplicationAssembler that reads configuration to get the OrderFactory class and calls setOrderFactory. Or we might make the default factory read the Order classname from configuration. Good clean fun, no?

Are you telling me to read all specific stuff from a properties file :roll: ?

Regards,
Darya

Are you telling me to read all specific stuff from a properties file

Yes, that's one way. Or a user of your framework could hardcode the injections in his own custom assembler. The assembler might look like either of these:

You could provide a default assembler that reads properties files. Users could build their own assemblers that read XML or a database or hard code class names. I go for configuration without thinking much about it.

Sometimes you need multiple types in one implementation. Maybe you have to use slightly different orders for different products. Configuration might have a map of product code to order class.

Sound fun?