Component abstraction*

[javabeats]

Hi, everyone!

I have an use case that can have specific behavior depending on the client where the application is deployed. To add such a caracteristic to the code, without having to change it based on each client, I've made pageflow definition and business process definition "scripts", therefore leaving the views involved in the use case much cleaner. To change use case behavior for a certain client, all I have to do is deploy a different process/pageflow definition for him, and the interface behaves according to his needs. Nice.

But what I fail to accomplish now is the same level of abstraction for components. I would like to create, if possible of course, an interface as a component. And use this to control the tasks of my business process. Depending on the implementation of such interface that is deployed, actions would behave differently.

I'm struggling to accomplish this using drools. My architecture is composed of a .EAR file containing ejb-common and web-common projects, for all common artifacts shared between clients. I would like to add new modules representing custom (or specific) interfaces for each client.

So, I came here for suggestions. Do you guys know of any pitfalls of what I'm trying to achieve? (if that's possible at all...)

Thanks in advance!
Rodrigo

[jacob.orshalick]

I would like to create, if possible of course, an interface as a component. And use this to control the tasks of my business process. Depending on the implementation of such interface that is deployed, actions would behave differently.

It is not possible to directly define an interface as a Seam component, but it is possible to have your components implement a common interface and refer to that interface where your component is used. This is definitely recommended to allow differing implementations to be swapped out as you describe.

Thus, if you have a component:

...
@Name("hookComponent")
public class HookComponentImpl implements HookComponent {
...

You tie your use of the component to the interface just like you would when injecting an SFSB:

...
@Name("commonComponent")
public class CommonComponent {
...
@In HookComponent hookComponent;
...

Here Seam will inject an instance of HookComponentImpl as it is the component registered in the context but this could easily be swapped out through a number of approaches (deploying a specific application instance as you describe, install precedence, configuration through components.xml, etc). Hope that helps.

[javabeats]

First off, thanks for your reply ;)

I already knew of such capability - I'm having more trouble with the "implementation swapping" part. Your suggestions are a good set of ideas to start exploring from.. thanks man!

Rodrigo

[gbc1]

Just give your normal classes a lower precedence than the special classes. When two components have same name, higher wins. Look at the docs for more details.

Greetz GHad