With Respect To an Investment Application

Dear all,

I am working on a banking application, specializing in investment sector. We
have about 14 web modules. All these modules are resting on a common
framework, which does routing, workflow, logging etc. We would like to have
the common framework remain unchanged from application to application, and
country to country. However there is a problem:-

There are two main domain objects, User and Customer. User is the one who is
a typical bank employee and Customer is the one whom the user is serving.
User is part of the common framework, but customer belongs to the customer
module. Hence currently the framework is having dependency on the customer
module, which we do not want. And also, the customer may vary from country
to country. We would like to segregate the dependency. For dependency
segregation, we can use interfaces, but then the interfaces need to be in
the common classpath, which again we dont want.

Not sure, whether I am doing the right option, but because I went through
JMX Microkernal architecture of JBoss, I would like to suggest the following
idea. Let customer be a managed service, which will be started when a
customer is created. Let common framework be a kernal, and let common
framework add/wrap the customer service when needed through JMX. In this
way, the customer service can vary anytime anywhere.

Is there any elegant thoughts ? Is there any better architecture? Please
comment and lets discuss, thanks a lot.

Best regards,
Ravi


.

Relevant Pages

  • Re: Where to stor config file?
    ... tiers. ... They were based off a Common Base Business Framework that kept things common ...
    (microsoft.public.dotnet.general)
  • Re: Where to stor config file?
    ... Now based on those tiers that you have seen, ... They were based off a Common Base Business Framework that kept things common and consistant. ... each application had its own Bussiness Entity library which was derived from the Common Base Business Framework. ...
    (microsoft.public.dotnet.general)
  • Re: Regarding a design issue - in Java
    ... Hence currently the framework is having dependency on the customer ... User-part is tightly coupled with Common framework and ... framework add/wrap the customer service when needed through JMX. ...
    (comp.object)
  • Re: Thread safety
    ... > Image is abstracting you from a bunch of method calls. ... > This generally isn't a huge problem across the framework, but is common ... > API's are created that are wrapping an unmanaged API. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Thread safety
    ... > Image is abstracting you from a bunch of method calls. ... > This generally isn't a huge problem across the framework, but is common ... > API's are created that are wrapping an unmanaged API. ...
    (microsoft.public.dotnet.general)