Christian,

I looked at the Jira issue and one of the questions you'd had in there was
about the terminology to use sticky|best, for example.  Perhaps using the
same terminology as DS would be good -  stick vs dynamic.

On Fri, Apr 1, 2016 at 11:34 AM, Brad Johnson <[email protected]>
wrote:

> Thank you.  This is greatly appreciated.  Yes, I'm using it with
> Blueprint.  I've created a Microwebserver that listens for registration
> events to bind SOAP/REST implementations.  In the environment I'm working
> in various organizations are interoperating and have different security and
> data requirements so being able to bootstrap multiple microservers that
> listen for registration events and filter on a service property, inventory,
> invoices, etc. permits me a good way to do general set up of interceptors
> and providers and not have to replicate them.
>
> In order to do fast prototyping of web services I use stub data and
> register via some common OSGi interface like com.foo.InventoryService.
> That also means it is useful when I'm testing the deployments themselves.
> For example, I have a common API bundle and canonical data models.  The
> "front end" registers itself and as picked up by the microsserver and
> exposed as a web service.  It, in turn, picks up a "back end" interface
> that may be a test bundle or it may be the actual connection to some back
> end system (JDEdwards in one case).  The back end does the calls to the
> SOAP services and dozer transforms to canonical models.
>
> What I'd like to be able to do during deployment is install the front end
> with the test bundles.   Obviously the front end only knows it via the OSGi
> registry interface it is looking for and receives that.  That would permit
> me to install my front end with the back end test bundles and run SOAP UI
> tests against everything to verify that everything is working.  Then I want
> to install the higher ranking production bundles and would like those to
> automatically get switched.
>
> Part of the reason for that is that I have one test bundle that exposes
> all the back end services with a ranking of 3 but I have a multitude of
> back end bundles each exposing their own individual services.  For example,
> the test bundle might have invoice, inventory, sales, etc. all exposed as
> services.  But the actual bundle for inventory client services would only
> expose one interface.
>
> I'm also going to use that same architecture to enable remote service
> bundles when I want to do passthroughs.  In other words, I might have a
> front end web service exposed with security, interceptors, etc. in a DMZ
> but when it pulls the service instead of hitting either a test or
> implementation bundle it will hit a passthrough call to another web service
> (I just Camel CXF routes in the bundle).
>
> The microserver works very well and I'm hoping to put it up on Github one
> of these days to make it available to the community.  Many of my clients
> are looking for a more flexible microservices approach and a lot of them
> are Java developers who are not savvy to blueprint, Camel, etc.  I actually
> had one recently who told me that Fuse/Camel/Servicemix isn't really Java.
> Well, they have something of a point, I guess.
>
> The other issue I'd looked at that is a bit of a hold up is the problem of
> not being able to use properties substitutions in filters.  In other words,
> I can't have a cfg file that specifies TEST, PRODUCTION, REMOTE and have
> that used as a filter since that string has to be hard coded.
>
> I'll look at DS and see if it buys me anything in terms of flexibility.
>
> Thanks,
> Brad
>
> On Fri, Apr 1, 2016 at 3:44 AM, David Bosschaert <
> [email protected]> wrote:
>
>> Hi Brad,
>>
>> It depends a little bit on what technology you use to consume the
>> service. I guess you're using Blueprint since this mail is sent to Aries
>> and as Christian mentions there may be some work needed there.
>>
>> If you use Declarative Services you can get a re-binding behaviour by
>> using Dynamic (and/or Greedy) service references, which basically will have
>> the effect that your client is automatically rebound if a new service with
>> a higher ranking becomes available. You can see an example of such a client
>> here:
>> https://github.com/coderthoughts/primes/blob/master/client/src/main/java/org/coderthoughts/primes/client/PrimeClient.java
>> and
>> http://coderthoughts.blogspot.com/2016/02/branch-by-abstraction-and-osgi.html
>>
>> Cheers,
>>
>> David
>>
>> On 1 April 2016 at 06:58, Christian Schneider <[email protected]>
>> wrote:
>>
>>> The current behaviour is required by the spec. We plan to add an option
>>> to configure this https://issues.apache.org/jira/browse/ARIES-1314.
>>> Unfortunately I did not yet have the time to implement this.
>>>
>>> Christian
>>>
>>> 2016-03-31 19:39 GMT+02:00 Brad Johnson <[email protected]>:
>>>
>>>> I've set up separate bundles exposing the same service interface with
>>>> different ranking.  The test stubs are low ranking and the production code
>>>> is higher ranking.
>>>>
>>>> The problem is I'm seeing a first come, first served behavior and not
>>>> selection of service based on ranking. If I stop/uninstall a bundle then
>>>> the other service is immediately picked up as one would expect.  But if I
>>>> restart a bundle, even if it has the highest service ranking, then the
>>>> lower ranking service is bound while the bundle with the higher ranking
>>>> service restarts.  What I'd expected/hoped is that the manager would
>>>> automatically switch the proxy over to the higher ranking service if no
>>>> other filters are specified.  Is there a setting or flag I'm missing that
>>>> would trigger that behavior?
>>>>
>>>> Brad
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>>>
>>
>>
>

Reply via email to