I have this basic doubt related to osgi. Are all services singleton in osgi? How exactly services different from components? And if services are not singleton, why do we use #reference instead of creating new instance?
Every declarative services component will create at least one OSGi service for the component. For some components you can have more than one configuration. In this case you will have one component and service instance per config.
#Reference will give you the best matching service for the interface or class you inject into.
DS components create services but you can also create OSGi services in other ways. For example using the OSGi API or blueprint.
Related
I want to use background tasks in asp.net core.
I found helpful documentation https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-6.0&tabs=visual-studio
I wonder why their lifetime apparently is scoped: Hosted service that activates a scoped service. The scoped service can use dependency injection (DI).
What is a scope in this context?
For web applications, a scoped lifetime indicates that services are created once per client request (connection). Register scoped services with AddScoped.
In apps that process requests, scoped services are disposed at the end of the request.
While I do understand what that means for e.g a standard http get request to an api,
I do not understand the meaning for a background worker.
Imho it would make more sense to have a singleton backgroundworker. I certainly do not want to have multiple instances running at a time in my application.
Another thing is DI in background workers which apparently differs fron standard services:
To use scoped services within a BackgroundService, create a scope. No scope is created for a hosted service by default.
I cannot confirm that:
services.AddHostedService(x => new DataPersister(x.GetRequiredService<IAsyncDocumentSession>(), x.GetRequiredService<ILogger>()));
seems to work just fine.
You have to read the sentence “Hosted service that activates a scoped service” within its full context:
This article provides three hosted service examples:
Background task that runs on a timer.
Hosted service that activates a scoped service. The scoped service can use dependency injection (DI).
Queued background tasks that run sequentially.
(from “Background tasks with hosted services”, emphasis mine)
So it is not the case that hosted services have a scoped lifetime. All hosted services added using AddHostedService() are actually added with a singleton lifetime, ensuring that there will only ever be a single instance of it.
What the article refers to is the situation when you need to consume a scoped service, like a database connection, within a hosted service. Since you cannot inject scoped dependencies into a singleton service, you will need a different solution there. And the solution usually involves having the singleton service (the hosted service in this case) create a service scope itself from which it can then retrieve the scoped dependency.
I went into more details about the service scopes in this recent answer to a similar question if you are interested.
I would like my ASP.NET Core application to send messages to a Azure Service Bus.
In Microsoft's article Best Practices for performance improvements using Service Bus Messaging they argue that you should re-use instances of clients.
It is recommended that you do not close messaging factories or queue, topic, and subscription clients after you send a message, and then re-create them when you send the next message.
So I take that as I should not instantiate a new instance of the client (TopicClient or QueueClient) inside my controller using the new keyword.
I guess that I should use dependency injection in ASP.NET Core.
Should I directly inject a TopicClient/QueueClient or should I create an own class that wraps an instance of the client and expose a SendAsync method?
When registering the service with dependency injector should I register it as a singleton?
We did it with a wrapper class that is then returning the TopicClient/QueueClient and registered it as a singleton and found no big issues with this approach.
We based our approach on this example provided by Microsoft eshopOnContainers.
The example code for this functionality is found in this file. They than register this class as singleton in Startup.cs in the services where they require ServiceBus.
We have to implement a number of integrations with VSO from different applications using BizTalk Server 2013 R2.
Can someone help me decide which will be the best approach among the below three options:
WCF Service:
We can create a WCF service which will have reference of library provided by VSO and have common methods to interact with VSO. We will use extensible client library for dot net provided by VSO.
Utility Class:
This class will have same methods as in WCF service above, but I guess this will be faster as it will be added inside the BizTalk Solution and will be called from orchestration.
Common BizTalk Orchestration using Web-Http Adapter for calling REST APIs provided by VSO.
Please help me decide among these approaches.
It really depends on your scenario and the need of reuse of VSO functionality within BizTalk or outside BizTalk.
If BizTalk if the only consumer of VSO functionality, then you can directly use .NET library provided by VSO. From design perspective, its a good practice to wrap a third party library within your own .net library with your specific functionality, which will allow you to reuse the functionality across different applications if required.
WCF Service you would only want in case you want to expose this functionality outside BizTalk environment or if you have multiple BizTalk environment in which you want to share the same implementation.
I'm implementing a WCF web service based on WF. This web service consumes other web services which I'm not in charge of. So basically my service workflow contains several Send activities.
I'm following the TDD approach, so the service implementation is to be covered by unit tests. I want to test proper invocation of 3rd party services.
In a non-workflow case I would mock the external services via NMock. But in my case I cannot control the instantiation the workflow instance and I have no idea on how to trick the Send activities to use the mock objects instead of real services endpoints.
Although Unit Testing Workflows And Activities article on MSDN mentions mocks I couldn't find any complete example of mocking the remote end of Send activity.
Any idea on how to do that?
please try Moles framework. http://research.microsoft.com/en-us/projects/pex/
There are samples about how to mock the sharepoint service. I believe the same trick should apply to WF workflow.
I have tried to mock the sqlconnection, Entity framework, web service call, it works very neat. Basically, it can mock almost any .net objects.
Using ServiceAgents wrappers for your web services would be one possible way of doing it.
This is a pattern i have followed in previous projects of mine.
Since they are interface based, you can easily mock out the services.
There are other advantages to this pattern (besides unit testing) including being able to abstract your application from external dependencies to a certain extent. However it does add the overhead of creating another class layer on top of the services.
If I have a client/server type of application built using both Prism and WCF, and I would like on the serverside to have the wcf service to be instatiated per call BUT I would like to use dependency injection (using the UnityContainer in Prism). How could I possibly do this? Should I have a single instance service it would be no problem, but are there any hooks in WCF to allow for a delegate to be called whenever a service is supposed to be instantiated and have this instance returned?
Any ideas?
Cheers!
It is possible! WCF provides a plugin to the WCF responsibility chain called an IInstanceProvider. This allows for you to replace the construction with your own.
Someone has implemented this as a service behavior and is available here:
http://code.msdn.microsoft.com/WCFResources/Release/ProjectReleases.aspx?ReleaseId=1252