In Jini service discovery, you can search for all types of services by providing null for the class[] of service types to discover. My question is what happens if you don't have in your classpath the discovered service interface. For example, in the network there are 2 service with the interfaces IService1 and IService2, both not in my classpath. What would happen when they are discovered? will the code be downloaded to my JVM from the HTTP server (assuming it is configured to point to the HTTP server)?
(yeah, I know Jini is pretty dead :-))
Thanks!
What you probably refer to is service lookup. From the spec: "The lookup service provides a central registry of services available within the djinn. This lookup service is a primary means for programs to find services within the djinn..."
As for disccovery: "Entities that wish to start participating in a distributed system of JiniTM technology-enabled services and/or devices, known as a djinn, must first obtain references to one or more Jini lookup services. The protocols that govern the acquisition of these references are known as the discovery protocols."
I think you have to know your types you want to use. What are you going to do with an interface you know no nothing about?
When you know the interface and what it is good for, you build your program relying on it. What you get in Jini by a service lookup is an implementation of that service interface.
I am aware my answer is sketchy. I would like to direct you to the place where Jini continues its existence: river.apache.org. Jini is live and well! Use the specifications, examples and of course the mailing lists to get an exhaustive answer.
Cheers.
Related
I'd like to be able to do a health check on a deployed Message-Driven Bean in Production. My initial idea was to add a health() method ensuring that the JMS Queue (for reading) and the Database (for writing) are both available, and then expose this health method as a REST API. Unfortunately as a MDB isn't injectable like the other types of EJBs I cannot get a reference to it from my REST controller...
Is there a way to expose a message-driven bean's methods through a REST API ? Or any other way to achieve my initial goal ?
EDIT
A little precision : I don't want to just check that the resources are available, but also that the EJB can communicate with them (by pinging them from inside the EJB instance). This would not only validate that the resources are available (which could indeed be done some other way), but more importantly for me also that the resources bindings are valid and that the resources injection is working.
I think it's not possible the way you want to have it. The reason is, that unlike other EJBs, a MDB solely acts upon arrival of a message and not by any other call to it.
But you may do it the other way round and inject some class into the MDB which you call on any message you receive. That way you'd have a constant "I'm alive" ping, provided that you get messages continuously.
Other than that your only chance is to use the mechanisms of your container which usually can provide some information about its deployed and running components which you may query.
I know typically a process is either a service provider or client over D-Bus, is it practically possible that a process be both a service and client (I think it's okay)? I have such needs in my project, originally there is a service provider and client, some requirements come in, I need the original client to provide service as well. Is there any downside if it's theoretically doable?
Yes, it’s possible, straightforward to do, and there are no downsides as long as it’s a suitable architecture for the problem you’re trying to solve.
Many system services already do just this: they expose a system service on the bus, and also act as a client with other system services which provide information to them.
I m studying Microservices architecture and I m actually wondering something.
I m quite okay with the fact of using (back) service discovery to make request able on REST based microservices. I need to know where's the service (or at least the front of the server cluster) to make requests. So it make sense to be able to discover an ip:port in that case.
But I was wondering what could be the aim of using service registry / discovery when dealing with AMQP (based only, without HTTP possible calls) ?
I mean, using AMQP is just like "I need that, and I expect somebody to answer me", I dont have to know who's the server that sent me back the response.
So what is the aim of using service registry / discovery with AMQP based microservice ?
Thanks for your help
AMQP (any MOM, actually) provides a way for processes to communicate without having to mind about actual IP addresses, communication security, routing, among other concerns. That does not necessarily means that any process can trust or even has any information about the processes it communicates with.
Message queues do solve half of the process: how to reach the remote service. But they do not solve the other half: which service is the right one for me. In other words, which service:
has the resources I need
can be trusted (is hosted on a reliable server, has a satisfactory service implementation, is located in a country where the local laws are compatible with your requirements, etc)
charges what you want to pay (although people rarely discuss cost when it comes to microservices)
will be there during the whole time window needed to process your service -- keep in mind that servers are becoming more and more volatile. Some servers are actually containers that can last for a couple minutes.
Those two problems are almost linearly independent. To solve the second kind of problems, you have resource brokers in Grid computing. There is also resource allocation in order to make sure that the last item above is correctly managed.
There are some alternative strategies such as multicasting the intention to use a service and waiting for replies with offers. You may have reverse auction in such a case, for instance.
In short, the rule of thumb is that if you do not have an a priori knowledge about which service you are going to use (hardcoded or in some configuration file), your agent will have to negotiate, which includes dynamic service discovery.
I get the problem that etcd/consul/$whatever are trying to solve. Service consumers need to talk to service providers, a hugely fluid distributed system needs a mechanism to marry the two.
However, the problem of "where do service consumers go with their requests?" is old and IMO has been solved with MOM -- message oriented middleware.
In MOM, the idea is that service consumers do not care where the service providers live. They simply send a message and have the messaging bus take care of routing the message to the appropriate consumer. There can be multiple providers all doing the same thing (queue-based round-robin) or versioned providers (/v1/request goes to one, /v2/request goes to another).
This is a simple, powerful integration pattern that completely decouples a service interface from its implementation.
And yet I see this bizarre obsession with discovering service providers, which appears to create tight coupling between consumers and providers (in addition to a few other anti-patterns as well.)
So, what am I missing here? TIA.
In MOM, everything flows through the bus, so it might become a bottleneck. With service discovery, a consumer looks up a producer "once" (ok it might have to check back again after a while), and then "directly" (ok could be through a proxy) talks to it.
Or if you prefer catchy phrases: smart endpoints & dumb pipes vs (i guess) dumb endpoints & smart pipes.
Personally I don't see the two as either or for this type of architecture. You could use the service discovery to see what services are available at the moment and subscribe to the MOM for the events you then know will be there. If you can't find services you depend on you can raise an alert. Not all MOM's let you know when there is no publisher for a channel.
You can also combine them in the way that the service discovery is where you find the services you want to contact directly, for example a data store that does no job, and still use the MOM to subscribe to events for changes that other systems do. Not all use cases fit well with job queuing either, as some tasks must be solved synchronously, and then the service discovery is a great way to have a dynamic environment.
I do prefer the asynchronous MQ myself, and I think that if you do it right, with load balancing, redundancy, clustering with separate readers and writers etc you can easily have great stability, scalability and a standardized way for all your components to communicate.
I'm using XMPP to drive a notification system. Basically I will have a set of services, some of which will broadcast to all users and some which are directed to a specific client (full JID).
For a service that broadcasts to all users a PubSub node seems the obvious choice but for a service that targets its messages to a specific client, I'm unsure of the best mechanism to use.
Do I represent these services as other client users and create bespoke implementations for them? The problem I see with this is how will they be discovered? Do I group them into a chat room and discover that. It feels like a bit of a hack. I could also define my own bespoke type of service, but then I have to define my own XML tags and maintain that.
I know there are plenty of standard extensions to XMPP but I cant see anything useful in this case.
Even in the pubsub case, the publisher (i.e. your service) is still a "user", so this configuration will be pretty standard. We simply create service accounts to represent those "users".
I am unsure of what you mean by "how will they be discovered". Why do the services need to be discovered? Your scenario only gives the use case of services sending messages to the users. Assuming the service already knows who the message is to be sent to, then you don't need any other information to send a message.