Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of mark@van-cuijk.nl designates
 79.170.90.37 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Service properties on aspect services in DM
From: Mark van Cuijk <mark@van-cuijk.nl>
In-Reply-To: <E425518E-9506-4F7A-8A9F-A7D25EFE3989@luminis.nl>
Date: Mon, 22 Oct 2012 23:42:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7CF9110-2EBA-4C76-9C3A-D9DA6FB2CA76@van-cuijk.nl>
References: <15B41EE0-D10A-41A8-9C82-0941111F6248@van-cuijk.nl>
 <E425518E-9506-4F7A-8A9F-A7D25EFE3989@luminis.nl>
To: users@felix.apache.org

Hi Marcel,

On Oct 21, 2012, at 23:08 , Marcel Offermans wrote:

> Hello Mark,
>=20
> 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.

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=3DINTERNAL)(directionType=3D*)), both of which were added =
/ overridden by one of the aspect services.

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 ;-)

Thanks,
Mark=

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org