I have been learning on building a simple application by replicating the Watson Health Q/A application(https://watsonhealthqa.mybluemix.net/) but the Q/A application seems to have been deprecated and documentation/forums seem to say that I should use the dialog service with the natural language classifier. Any pointers if this is the case. Second, where can I get the template file(dialog xml file with classifier), i.e for the dialog that is based on the already trained health data that previously existed in the Q/A Health application. i.e would need to train the classifier with the same data they used for their Q/A application? Is this now under health services?
#simon's answer is correct and has links to the new services. The older QA service has been deprecated and replaced by other, singularly focused services. The new services are more flexible and more composable.
Side note... I guess I should update my demos (the URL you mention above) b/c those old services are no longer active.
Related
Given that Kubernetes doesn’t offer full visibility into how services interact with each other I want to derive and map services automatically. For eg as shown in the below diagram, how can we derive that the payment service interacts with the cart service and cart service interacts with catalogue and redis.
So far what I had tried is,
kubectl get services command - This command only gives the list of services but does not hint on any communication happening between the services.
Tried Kubeview -> This plots only the deployment architecture and gives a graphical representation but mapping between various services is not derived.
So what is the easiest way to derive information about services interacting with each other and what could be the data source for this information in Kubernetes?
We faced this as well when we were building Otterize -- we needed something to map "who is talking to who" in order to bootstrap our solution, but every tool seemed to be ill suited for the task of simply creating a "network map" without all sorts of stuff we didn't want. We ended up rolling our own, and open sourced it: https://github.com/otterize/network-mapper .
It's based on combining information from DNS queries (actually just query responses) as well as detecting open connections, which gives you an IP-level network map, and then adding a simple resolution heuristic to derive a logical name-level map. You can read more details in this blog post, by one of the guys who built the tool: https://otterize.com/blog/kubernetes-traffic-discovery .
Hope this helps!
You can consider linkerd or other similar tools which offer service Observability
A service mesh like Linkerd is a tool for adding observability, security, and reliability features to “cloud native” applications by transparently inserting this functionality at the platform layer rather than the application layer.
service-mesh
For example, in below screenshot you can see how gate-way service interact with another service
It will also show how the request is going, amount of request with inbound and outbound
So in your case,if payment app is part of mesh you will able to see the inbound and outbound for the service along with requests info.
linkerd-install-helm
Service meshes have three main goals around interservice communication:
Connectivity
Security
Observability
I have several services, each one exposed through REST API with ASP.NET Core Web API. I use Swashbuckle for ASP.NET Core tooling in order to automatically generate from my controllers and DTOs all the necessary documentation and visualize it in SwaggerUI. I found this tooling really great, with little annotations on my models and my controllers already provides many features out of the box, such as a UI client to try out the REST API endpoints.
But with this solution each service has its own dedicated SwaggerUI instance and therefore UI.
I would like to offer to my customers a wiki-like documentation with a navigation menu, where, for instance, they can browse sections regarding all the endpoints exposed by my services and have on each page the same features offered by SwaggerUI.
It can be achieved by creating my own web application but I was wondering whether an out of the box solution or some tool that might ease such integration already exists.
I tried Slate but I felt like I had to re-invent the wheel in order to automate at least the creation of the basic API documentation, namely controller definition, response definition and descriptions. Does anyone have any suggestion?
I faced this very issue recently working in a microservices architecture, you're absolutely right. There is not need to reinvent the wheel.
I really can't recommend redoc by Redocly enough in this case.
Have a look at the multiple-apis example.
I have a requirement to develop a test framework using Cucumber .
Requirements:
There is a Soap WS already developed for an existing project few years ago
There is a new REST ws developed for the same project
I have to validate the responses from the SOAP WS with responses of REST WS and check if both are same or not using a feature file (cucumber)?
basically have to check if fields values in Soap and REST are equal.
how to write the scenario and how to map those fields in SOAP ws with REST ws?
I am very new to BDD and cucumber. elaborate answers are very much appreciated
How to create the scenario
In BDD, we create a scenario with contexts, events and outcomes.
The context is the state in which the scenario starts. So in your case, you have two services, and probably something created in those services that might change the responses. Those become your "Given"s.
Let's say your services are dealing with user details. (Adapt these accordingly for whatever information matters to your scenario.)
Given the REST service has a user 'Chandra Prakash'
And the SOAP service has a user 'Chandra Prakash'
Most of the time in BDD we only have one event happening in each scenario. There can be two events though if there's interaction or something like time passing, and I think this counts too. So we make a call to both services, and the events become your 'When'.
When we ask the REST service for all users with family name 'Prakash'
And we ask the SOAP service for all users with family name 'Prakash'
And the last bit is the outcome, where we look to see if we got the value that's important to us.
Then both services should have found a user 'Chandra Prakash'.
Those lines, together, become the scenario in your feature file.
Rather than just having one scenario to verify that both are the same, I'd look for examples of what the systems do, and use one scenario for each example. But if you want that last call to just check they're both identical, that would be OK.
Wiring up the scenario to automation
Most examples of Cucumber that you find will use something like Selenium to automate over a web page, but you don't have that. Instead of a UI, you have an API. You're coming up with examples of how one system uses another system.
Your automation will be setting up data in the Givens, then calling the REST service or the SOAP service as appropriate in the Whens.
If you work through Cucumber's tutorial, and then use their techniques to wire the scenario up to the two services, you'll get what you're after.
Note that Cucumber has different flavours for different languages, so pick the right flavour for yourself.
Scenarios vs. Acceptance Criteria
In general, I like to ask, "Can you give me an example?" So, can you give me an example of what the REST service and the SOAP service do? If the answer is something of interest to the business and non-technical people, then you can write that example down. Try to use specific details, as I've done here with a user and their name, rather than being generic like
Given the REST service has a user with a particular family name
When we ask the REST service for users with that family name
Then it should retrieve them
This, here, isn't a scenario, even if it's good acceptance criteria. We want our scenarios to be specific and memorable. Try to use realistic data that the business would recognize.
Cucumber vs. plain code
There's one small problem that I can see.
It sounds as if what you're doing might be a technical integration test, rather than an example of the systems' behaviour. If that's the case, and there's no non-technical stakeholder who's interested in the scenario, then Cucumber may be overkill. It's enough to create something in the unit-level framework for your language (so JUnit for Java, etc.). I normally create a little DSL, like this:
GivenThePetshop.IsRunning();
WhenTheAccessories.AreSelected("Rubber bone", "Dog Collar (Large)");
ThenTheBasket.ShouldContain("Rubber bone", 1.50);
ThenTheBasket.ShouldContain("Dog Collar (Large)", 10.00)
ThenTheBasket.ShouldHaveTotal(11.50);
But even that's not needed if you're not reusing the steps anywhere else; you can just put the "Given, When, Then" in comments and call straight to the code.
Here are some arguments I'd use against Cucumber in this instance:
It's harder to refactor plain English than code
It introduces another layer of abstraction, making the code harder to understand
It's another framework for developers to learn
And it takes time to set it up in CI systems etc. too.
If you can't push back, though, using Cucumber won't be the end of the world.
Have some conversations!
The best way to get examples out is to ask someone, "Can you give me an example?" So I'd find the person who knows the business processes best, and ask them.
Please do this even if it's just an integration test, as they'll be able to help you think of other examples in which the systems behave differently. Each of those becomes another scenario.
And there you go! If you do need help that StackOverflow can't provide, there are mailing lists for both BDD and Cucumber, and plenty of examples out there too.
We have Android and iOS (Objective-C) mobile applications.
Our Business Intelligence team is interested in receiving the following parameters with each data event:
the app version
the user session id
We use gRPC for both the mobile-backend communication and also for communicating between the different microservices on the backend.
I am considering sending this information using open tracing spans that are started on the mobile app and pass the app version and session id trough the Baggage.
Can anyone advise if open tracing is suitable for this scenario or if there is a better alternative?
We are also considering using LinkerD on the backend
I'm not sure baggage is really what you want. OpenTracing also offers the possibility of adding tags to a span, which would probably be sufficient for your use-case.
A baggage item is sent downstream along with the span context, whereas a tag is "local" to a span. If you need access to the app version on a span downstream, then you indeed have to use a baggage item, but if all you need is to have the version information within the span, you should just tag it.
About OpenTracing being suitable or not: I'd say that's exactly the purpose of OpenTracing. Not only you'll potentially get "automatic" spans from the frameworks you are using (using the "framework integrations"), but also you can relate that to your business information. We have an example on Hawkular APM where we add both "operational" and "business" data to traces.
Web-applications experienced a great paradigm shift over the last years.
A decade ago (and unfortunately even nowadays), web-applications lived only in heavyweighted servers, processing everything from data to presentation formats and sending to dumb clients which only rendered the output of the server (browsers).
Then AJAX joined the game and web-applications started to turn into something that lived between the server and the browser.
During the climax of AJAX, the web-application logic started to live entirely on the browser. I think this was when HTTP RESTful API's started to emerge. Suddenly every new service had its kind-of RESTful API, and suddenly JavaScript MV* frameworks started popping like popcorns. The use of mobile devices also greatly increased, and REST fits just great for these kind of scenarios. I say "kind-of RESTful" here because almost every API that claims to be REST, isn't. But that's an entirely different story.
In fact, I became a sort of a "REST evangelist".
When I thought that web-applications couldn't evolve much more, a new era seems to be dawning: Stateful persistent connection web-applications.
Meteor is an example of a brilliant framework of that kind of applications. Then I saw this video. In this video Matt Debergalis talks about Meteor and both do a fantastic job!
However he is kind of bringing down REST API's for this kind of purposes in favor of persistent real-time connections.
I would like very much to have real-time model updates, for example, but still having all the REST awesomeness.
Streaming REST API's seem like what I need (firehose.io and Twitter's API, for example), But there is very few info on this new kind of API's.
So my question is:
Is web-based real-time communication incompatible with REST paradigm?
(Sorry for the long introductory text, but I thought that this question would only make sense with some context)
Stateful persistent tcp/ip connections for web-applications are great, as long as you are not moving around.
I have developed a real-time web based framework and in my experience I found that when using a mobile device based web browser, the IP address kept changing as I moved from tower to tower, or, wi-fi to wi-fi.
When IP addresses keep changing, the notion that it is a persistent connection evaporates rather quickly.
The framework for real-time web-app has to be architected with the assumption that connections will be transient and the framework must implement its own notion of a session while the underlying IP connection to the back-end keeps changing.
Once a session has been defined and used in all requests and responses between clients and servers, one essentially has a 'web connection'. And now, one can develop real-time web based apps using the REST paradigm.
The back-end server of the framework has to be intelligent to queue up updates while IP addresses are undergoing transitions and then sync-up when tcp/ip connections has been re-established.
The short answer is, 'Yes, you can do real-time web based app using the REST paradigm'.
If you want to play with one, let me know.
I'm very interested in this subject too. This post has a few links to papers that discuss some of the troubles with poorly-designed RPC:
http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html
I am not saying Meteor is poorly designed, because I do not know much about Meteor.
In any case, I think I want the best of both "world". I want to benefit from REST and all that it affords with the constrained generic interface, addressability, statelessness, etc.
And, I don't want to get left behind in this "real-time" web revolution either! It's definitely very awesome.
I am wondering if there is not a hybrid approach that can work:
RESTful endpoints can allow a client to enter a space, and follow links to related documents as HATEOAS calls for. But, for the "stream of updates" to a resource, perhaps the "subcription name" could itself be a URI, which when browsed to in a point-in-time single request, like through the web browser's address bar or curl, would return either a representation of the "current state", or a list of links with the href for prior states of the resource and/or a way to query the discrete "events" that have occured against the object.
In this way, if you state with the "version 1" of the entity, and then replay each of the events against it, you can mutate it up to its "current state", and this events could be streamed into a client that does not want to get complete representations just because one small part of an entity has changed. This is basically the concept of an "event store", which is covered in lots of the CQRS info out there.
As far as being REST-compatible, I believe this approach has been done (though I'm not sure about the streaming side of this), I cannot remember if it was in this book http://shop.oreilly.com/product/9780596805838.do (REST in Practice), or in a presentation I heard by Vaughn Vernon at this recorded talk in QCon 2010: http://www.infoq.com/presentations/RESTful-SOA-DDD.
He talked about a URI design something like this (I don't remember exactly)
host/entity <-- current version of a resource
host/entity/events <-- list of events that have happened to mutate the object into its current state
Example:
host/entity/events/1 <-- this would correspond to the creation of the entity
host/entity/events/2 <-- this would correspond to the second event ever against the entity
He may have also had something there for history, the complete monent-in-time state, like:
host/entity/version/2 <-- this would be the entire state of the entity after the event 2 above.
Vaughn recently published a book, Implementing Domain-Driven Design, which from the table of contents looks like it covers REST and event-driven architecture: http://www.amazon.com/gp/product/0321834577
I'm the author of http://firehose.io/, a realtime framework based on the premise that Streaming RESTful API's can and should exist. From the project website:
Firehose is a minimally invasive way of building realtime web apps
without complex protocols or rewriting your app from scratch. Its a
dirt simple pub/sub server that keeps client-side Javascript models in
sync with the server code via WebSockets or HTTP long polling. It
fully embraces RESTful design patterns, which means you'll end up with
a nice API after you build your app.
Its my hope that this framework prevents the Internet from going back into the RPC dark ages, but we'll see what happens. We do use Firehose.io in production at Poll Everywhere to push millions of messages per day to people on all sorts of different devices. It works.