How to discover the paths of two nodes in an endpoint, preferably the paths of different endpoints. Can sparql be implemented , or is there any other way to do it
Related
I want to create an application that will need several calls to webservices to get data for persons, companies, etc. What is the best practice for that:
Create one SVC file / WCF webservices with several methods
or
Create for each entity (person_webservice.svc / company_webservice.svc) a webservice file with only the methode related to that entity?
If you need to manage the visibility, security, transport or other configurable details for each WCF separately then go for multiple WCF's, if all the services are related, share same server, do not need isolation then managing multiple services will get complicated over time and could end up with duplicate code easily.
WebAPI is the modern version of your split WCF idea, each API controller defines the actions specific to a single entity but all belong to the same 'endpoint' or base url.
Trying to figure out a pattern for how to handle relationships when using a hypermedia based microservices based on Spring Data Rest or HATEOAS.
If you have service A (Instructor) and Service B (Course) each exist as an a stand alone app.
What is the preferred method for establishing a relationship between the two services. In a manner that does not require columns for IDs of the foreign service. It would be possible for each service to have many other services that need to communicate in the same manor.
Possible solution (Not sure a correct path)
Each service has a second table with a OneToMany with the primary entity within the service. The table would have the following fields:
ID, entityID, rel, relatedID
Then in the opposite service using Spring Data Rest setup a find that queries the join table to find records that match.
The primary goal I want to accomplish would be any service can have relationships with any number of other services without having to have knowledge of the other service.
The basic steps are the following ones:
The service needs to discover the resources of the other service.
The service then adds a link to the resources it renders where necessary.
I have a very rudimentary example of these steps in this repository. The example consists of two services: a service to provide geo-spatial searches for stores. The second service is some rudimentary customer management that optionally integrates with store service if it is currently available.
Here's how the steps are implemented:
Resource discovery
In my example the consuming service (i.e. the customer one) uses Spring HATEOAS' Traverson API to traverse a set of link relations until it finds a link named by-location. This is done in StoreIntegration. So all the client service needs to know is the root URI (taken from the environment in my case) and a set of link relations. It periodically checks the link for existence using a HEAD-request.
This of course can be done in a more sophisticated manner: hard-wiring the base URI into the client service might be considered suboptimal but actually works quite well if you're using DNS anyway (so that you can exchange the actual host behind the URI hard-coded). Nonetheless it's a decent pragmatic approach, still rediscovers the other service if it changes URIs, no additional libraries required.
For an even more sophisticated approach have a look at Netflix' Eureka library which is basically a service registry. Also, you might wanna checkout the Spring Cloud integration we have for that.
Augmenting resources with links
Spring HATEOAS provides a ResourceProcessor API that Spring Data REST leverages. It allows you to manipulate the Resource instance about to be rendered and e.g. add links to it. The implementation for the customers service can be found here.
It basically takes the link just discovered in the steps above and expands it using well-known parameters and thus allows clients to trigger a store geo-search by just following the link.
Beyond that
You can find a more sophisticated variant of this example in the examples projects for Spring Cloud. It takes the very same example but switches to Spring Cloud components such as Eureka integration, gathering metrics, adding UI etc.
In my case I can only derive related items from the service itself. My goal is to abstract the related items to the point that any number of services can be related to a service and only need to lookup ID's or links. One thought was an #ElementCollection named related with a join of the entity ID of the service. Then in the #Embedded have a relLink field and a relatedID field. Then in the repository do a findby to find the relLink and relatedID.
The hope is to keep it abstracted enough to essentially mimic a Many to Many setup.
I know it's possible to route a search to a specific shard, but I'm looking to route a search to a specific node. The reason is because some nodes are more powerful than others, and I want to have logic to hit those nodes more than the weaker nodes when conducting a query.
Is this possible? I know, short question but believe me I've done a lot of research and Googling and couldn't find the answer.
If you will set an awareness attribute based on the class of machine, you can use it to automatically route requests within the class. If you are using java-based transport or node clients you can simply assign the same awareness attributes to your clients and they will automatically route request to the nodes with the same set of attributes. If you are using REST clients, you can either connect to machines of desired class or add dedicated client nodes into your cluster, assign them desired awareness attribute and use the to execute queries.
Found the answer:
Just append this in the REST URL when searching "&preference=_primary_first"
I am just trying to get to grips with using WCF, and I am wandering if someone could tell me if I have the right idea with endpoints.
I have been working through the videos on msdn, and now I am wandering about the way to configure WCF Service. The scenario is if I have multiple IServices, e.g. such that I have an IThis and IThat, and the client needs the access both (note: they will be using net.tcp),
IThis handles database querying and,
IThat handles calculations independent of the database,
I assume that I have to define separate Endpoints for IThis and IThat, that are referenced in the client separately. Or would I create an overall IThisAndThat Service that gets referenced in the client and contains the functionality for both??
Or is are the other ways for developing and handling WCF Services with multiple IServices? While I'm asking can you define base address for tcp or only http?
~Thanks all, any help or pointers would be great.
I assume that I have to define
separate Endpoints for IThis and
IThat, that are referenced in the
client separately. Or would I create
an overall IThisAndThat Service that
gets referenced in the client and
contains the functionality for both??
You can do both:
you can create a separate service implementation class - one for IThis, another one for IThat
or you can create a single service implememtation class that implements both IThis and IThat
That choice is entirely up to you.
For every service implementation class that you have, you can define any number of endpoints you wish to have. So if you have an ThisService implementing IThis, you can define a HTTP and a TCP endpoint for that, and you also have a ThatService that implements IThat for which you define a TCP endpoint. That's totally up to you.
BUT: you can only define your endpoints for each service implementation class - if you have a ThisAndThatService implementing both service contracts, you cannot define 3 endpoints for IThis and two different ones for IThat - the endpoints you define are per service implementation class.
While I'm asking can you define base
address for tcp or only http?
Yes, absolutely - you can define a base address for each of the various addressing schemes (http, net.tcp, net.msmq, net.pipe and so forth).
Some basics:
Each service has one or more endpoints. The endpoints are specific to their relevant service, i.e. each endpoint can only belong to one service and cannot be shared between services.
An endpoint defines an entrypoint to the service - it includes an address, binding and contract that can be utilized by a client.
Different endpoints must have different addresses, and can have different bindings and contracts (i.e. they do not have to). Typically, different endpoints have different bindings - that is, transport protocol. They can have different contracts if particular clients are only supposed to have access to certain operations.
Finally, your service must implement all of the contracts that its various endpoints expose.
Here's a very concise and straightforward MSDN page which describes these concepts. http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/9f4391e9-8b9f-4181-a081-860d42b992a9/
There's a lot of information on WCF on the web, and there's a lot to learn. Best to look at some tutorials or guides which focus on what you are trying to do.
I have Modification, Retrieval and Administration operations that are implemented by WCF services. I would like to separate them. The first thing that came to mind was to have three interfaces IRetrieval, IAdministration and IModification and create endpoints based on these interfaces. However, another developer said something about using different bindings or ports. I don't think that's possible - my understanding that WCF binding only defines how the data is treated over the wire and is not fit for logical separation. Am I in the ball park? Are there any other ways to separate the functionality besides the interfaces?
There are only two ways to separate functionalities: separate contracts implemented on the same service or separate contracts implemented on separate services. The difference between these two are more like logical and physical separation. For example default WSDL generation exposes metadata from all implemented contracts in a service. So if you implement all contracts in the single service and expose a metadata endpoint, each client will know an exact description of your administration methods and what security is used.