Need for abstract Customer type

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Need for abstract Customer type

grampajohn
Administrator

I've been thinking about the business rules around the interaction of Customers, Tariffs, and Accounting, and I think it would make sense to abstract a set of basic Customer operations into an abstract Customer type that real Customers could extend. Where should that be? I'm not sure. Customer depends on types in common, but I don't think an abstract Customer belongs in common. There is already a Customer type in common that's not a customer, but some sort of customer-attribute summary that might be communicated to brokers. How does this get created? Shouldn't it be called CustomerInfo or something like that? There's also a customer-default plugin, but it's pretty out-of-date and does not do anything interesting. I suppose that could be turned into an abstract customer, or refactored into an abstract customer and a minimal (default) concrete customer.

Here are some examples of common features that could be implemented in an abstract customer:

  • Every individual customer in a customer model must always be subscribed to exactly one tariff for each of its PowerTypes. So customers don't just sign up and withdraw, they switch. There's no obvious place to implement this other than in Customer.
  • When a customer evaluates tariff offerings, it needs to know which of its existing subscriptions can be dropped without penalty, and what the penalty is for dropping the rest. This is a non-trivial query, it should be factored out.
  • Interaction with other server components for meter readings and weather forecasts can be standardized into a simple api.

Please let me know what you think. If there's no objection, I'll create the ticket(s). Thanks. John

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for abstract Customer type

grampajohn
Administrator
A little more exploration shows that there is a Customer interface defined in common, under src/java. Also there are interfaces for a number of other server types, including AccountingService an Auctioneer. Perhaps I'm nit-picking, but these are not types a broker would care about. The server would, but we cannot put them in the server without creating a cycle in the dependency graph. Perhaps we really do need another plugin to hold these server types, along with abstract realizations of at least some of them.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for abstract Customer type

Carsten Block
Administrator
Hi John,

> A little more exploration shows that there is a Customer interface defined in common, under src/java. Also there are interfaces for a number of other server types, including AccountingService an Auctioneer. Perhaps I'm nit-picking, but these are not types a broker would care about. The server would, but we cannot put them in the server without creating a cycle in the dependency graph. Perhaps we really do need another plugin to hold these server types, along with abstract realizations of at least some of them.

One advantage of having all this coupled into a single plugin is that an e.g. a tax authority plugin developer only installs powertac-common and then - in his local plugin development environment - has access to all domain class definitions, all common Constants etc. Also the server can simply search for all classes that implement a certain interface definitions (e.g. to identify all customer implementations).

But that can also work in a setup where we have a lean powertac-common plugin and several mini-plugins that only contain one interface definition each (e.g. tax-authority-interface, auctioneer-interface, etc.). A plugin developer who wants to develop a new tax authority plugin then creates an empty grails plugin, installs tax-authority-interface plugin dependency and probably also powertac-common. This would at least decouple the interface definitions from powertac-common, which, at the moment, is a major holdup for all plugin developers waiting for a new version of powertac-common being released.

Cheers,
Carsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for abstract Customer type

grampajohn
Administrator
On 02/08/2011 04:05 AM, Carsten Block [via Power TAC Developers] wrote:

> Hi John,
>
> ... Perhaps we really do need
> another plugin to hold these server types, along with abstract
> realizations of at least some of them.
>
> One advantage of having all this coupled into a single plugin is that an
> e.g. a tax authority plugin developer only installs powertac-common and
> then - in his local plugin development environment - has access to all
> domain class definitions, all common Constants etc. Also the server can
> simply search for all classes that implement a certain interface
> definitions (e.g. to identify all customer implementations).

This is a somewhat compelling argument, given that a plugin developer is
going to need much of what's in powertac-common in any case. But see
below for an alternative.

>
> But that can also work in a setup where we have a lean powertac-common
> plugin and several mini-plugins that only contain one interface
> definition each (e.g. tax-authority-interface, auctioneer-interface,
> etc.). A plugin developer who wants to develop a new tax authority
> plugin then creates an empty grails plugin, installs
> tax-authority-interface plugin dependency and probably also
> powertac-common. This would at least decouple the interface definitions
> from powertac-common, which, at the moment, is a major holdup for all
> plugin developers waiting for a new version of powertac-common being
> released.

I would not create mini-plugins for each interface; instead, I would
create a single server-interface plugin for all of them. It would in
turn depend on powertac-common, so all you would need to do is make sure
all three packages are available and switch the existing dependency from
powertac-common to server-interface.

There is no need to wait for new versions to be released - you can
easily create dependencies among the source packages from github, as I
described in
http://power-tac-developers.975333.n3.nabble.com/Release-Management-Release-Manager-td2442563.html#a2451811 
(scroll down to the end). By not doing that, we slow down productivity
significantly. I think we should just jettison the version-specific
dependencies until we have a reasonably stable server running.

Cheers -

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Need for abstract Customer type

Carsten Block
Administrator
I would not create mini-plugins for each interface; instead, I would
create a single server-interface plugin for all of them. It would in
turn depend on powertac-common, so all you would need to do is make sure
all three packages are available and switch the existing dependency from
powertac-common to server-interface.

That sounds very good.

There is no need to wait for new versions to be released - you can
easily create dependencies among the source packages from github, as I
described in
http://power-tac-developers.975333.n3.nabble.com/Release-Management-Release-Manager-td2442563.html#a2451811 
(scroll down to the end). By not doing that, we slow down productivity
significantly. I think we should just jettison the version-specific
dependencies until we have a reasonably stable server running. 

I like this approach (and I didn't know about the automatic resolution of local plugins) I always did that manually. Nice learning for me. Thanks!
Loading...