Remote rs services/references

[Tomáš Fecko]

Hi,

I'm trying remote rs bindings, somehow can't get it working with the dsl.

can anyone provide some short example on that?

dsl specified component with service and dsl specified component with reference...

thanx

[Jim Marino]

Hi Tomas,

The RS binding doesn't work with references - instead you use the JAX-RS client API. The thinking is that if services are using REST there is a need to get close to the transport level so abstracting that away with a business interface for a reference removes that possibility. For example, I'm not sure how HTTP status codes like 404 would be mapped to a Java interface.

On the service side, i.e. exposing a REST resource, we did not create a DSL. Do you need to somehow dynamically change and aspect of a REST service or disable the service in certain environments? If you need to disable the service based on some dynamic criteria such as the environment, I just checked in the ability to define components based on the runtime environment using the "environments" attribute on @Component.

Let me know if I'm misunderstanding your use case or not taking something into consideration.

Jim

  

--
You received this message because you are subscribed to the Google Groups "fabric3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric3+u...@googlegroups.com.
To post to this group, send email to fab...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fabric3/bb2b69a4-3617-42f5-9746-35a2a1a7d2d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tomáš Fecko]

What I'm trying to do, is to access rs services in the same domain, I don't know the host/port though. Jetty on service node is started on some free port, which is unknown to rest client node...

[Tomáš Fecko]

Our use case evolved during time, at the beginning we wanted one domain, multiple zones, cross regions (WAN) - that was hasr to maintain, error prone.

So we placed:

1.) redis pub/sub in the middle

2.) one domain with one zone for GUI and some logic to main region

3.) every executor/worker node with multiple containers contains one domain, with 2 zones, every container contains one node

I tried NATS only on localhost, not in server environment yet. Basicly I believe, it should be a more performant redis replacement, 

the idea behind it is almost the same (channels patterned subscriptions).

What use case arised these days is the following: 

There are cases, where there can be only one connector to external system, which is reused by multiple executors.

But the executors doesn't know about eache other, so the first one, that creates that connector marks that to redis, holding a time evicted lock with it's address and connector identifier.

Other executor first tries to acquire that lock on redis, and if they don't suceed, than they just get the first nodes address and redirect their requests there (sync and async).

Something like rs or ws, looked like a good fit at least for prototyping, although not very performant one. "Patterned channels" was actualy the next logical step we thought of - exactly as you suggested, but with redis (but we will test also NATS).

They require some additional logic to make sync and async over it, and some level of reliability, but it looks like there is no simpler way...

On Thursday, November 26, 2015 at 2:23:22 PM UTC+1, Tomáš Fecko wrote:

Hi Tomas,

With clustered REST services I would use a load balancer with one of the following setups:

1. Static routing

2. Kubernetes which can manage dynamic IP addresses and DNS resolution

It sounds as if static routing won't work for your use case and Kubernetes is too much overhead. Have you had a chance to look at the NATS binding? It's a simple solution since it eliminates the need to manage changing endpoint addresses. Basically you could bring up a single NATs instance or a cluster and clients/services connect to it, which eliminates the need to propagate endpoint routing information to the clients.

Currently the NATS binding supports channels but I can easily added support for request/reply. Would that work for you? Otherwise, we would have to discuss how to propagate REST endpoint which overlaps a lot of the functionality offered by solutions like Kubernetes (and which become complicated in container-based environments).

Jim