Hello Mark, On Oct 22, 2012, at 23:42 PM, Mark van Cuijk <[email protected]> wrote:
> On Oct 21, 2012, at 23:08 , Marcel Offermans wrote: > >> Out of curiosity, did you want to exploit the behavior you expected? In >> other words, do you have a use case for it? > > I was indeed working on something and wanted to try whether aspects services > would fit for this use case. > > Basically I defined an interface for a service to retrieve records from a > remote system. Multiple implementation may be registered in a whiteboard > style. Some external systems don't supply values for all fields of a record, > so I used service properties to specify which information is available in the > retrieved records. > > Some fields can be deduced from other fields. For example, I have a service > that is able to map an account ID from the remote system to the account ID in > the internal system. My experiment was to create an aspect service that > consumes the original retriever, wraps the records, such that internal > account IDs are available and could therefore republish the service with a > new set of properties. I also made another aspect service this way to deduce > the value of an enum field using information from other fields. I'm not entirely sure why you'd want to use service properties to describe the fields that a record has. My first instinct would be to have a "getAvailableFields()" method on the Record service. That would then also solve your problem, since then the method invocations for the two aspects would be nicely chained. > Things started to fall apart when I chained those two aspect services. In > short, I expected to find a service when filtering on something like > (&(accountType=INTERNAL)(directionType=*)), both of which were added / > overridden by one of the aspect services. Aspects were designed to provide services that are identical to the "original" service they are an aspect of, so your use case is slightly outside of their intended use. You could also take a look at Adapters, who are designed to adapt a service A into a service B, but those don't necessarily chain, so if you make an A that adapts on B and B that adapts on C and you take away B, you will break the chain. So you're back at my first suggestion. > Anyway, I learned that using aspect services for an interface that is assumed > to be used whiteboard style complicates things a lot. I'm already working out > the solution I was about to use if I didn't want to try out using aspect > services and I just wanted to check on the intended behavior ;-) Well, if you use DM to create your whiteboard listeners, you will find that they "magically" understand aspects, so if you have services S1 and S2, and an aspect on all S'es, you end up with A1 and A2 (and the original S1 and S2 will be hidden from your listener, only to reappear when the aspects go away). Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
