Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'd like to use MEF for instantiating the dependencies in an application that has several WCF services hosted in IIS. The different services depend on shared components and I'd like MEF to manage the instantiation and injection of these.
Where should I perform composition? Initially I thought of having a CompositionContainer in an IInstanceProvider but then I realized that that container would only serve a single endpoint and the instances it manages will not be shared with other endpoints. Likewise with having the CompositionContainer in a ServiceHost - That would not be shared across different services.
Am I correct in this analysis? Is the only solution to have the CompositionContainer as a singleton at the application level?
A second question is - When a Service is instantiated by WCF (like when a new user session is started), how can I supply its dependencies? Do I make the CompositionContainer recompose? Wouldn't that affect other already running Service instances?
Might anyone share a code sample for this concept? Many thanks!
You used the term 'injection', and based on your requirements, I would actually suggest taking look at using an IoC container (Spring, Windsor, Unity, etc.) instead as this would provide even greater flexibility. There's also some examples of this already:
http://avingtonsolutions.com/blog/post/2008/08/02/Uisng-Unity-with-a-WCF-Service.aspx
I've encountered the requirement to make WCF service composeable many times, and the approach you identified where you use a custom IInstanceProvider is the way to solve it. Aswell as writing a custom instance provider, you also need a service behaviour, and a custom service host.
In terms of code-samples, I've documented my approach on my blog:
http://www.timjroberts.com/2011/08/wcf-services-with-mef/
Hope this helps.
You can use this nuget package. At project site, you can find couple examples how to use the library in web application or as self hosted service.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
This buzzword is making me pull my hair... I have been asked to create
a microservice using .net core.
Googled a lot, different definitions and samples, but still, I don't know what makes a vs project a microservice / how can I create a microservice in VS. For example, I have asked to create a microservice where a user will input two latitude and longitude values and they will get the distance between them.
Cool, I can do this as a web project in no time. But here I need this as a microservice where the rest of the projects in our firm can use it.
What really makes a VS project into a Microservice or can I convert a project into a micro service? Microservice experts are welcome ...!!! I looking for that step by process in which a microservice is created in .net core.
A microservice is simply a concept. You won't find a "Microservice" template in Visual Studio. Generally, you're going to be implementing a REST API. A microservice doesn't have to be a REST API, but they most normally are.
You also generally won't just be making a microservice, but rather microservices. One of the core tenants of a microservice is that it should deal with just one discrete unit of functionality. Unless your application does just one very boring thing, you'll need multiple microservices. For example, for an ecommerce site, you might have a user service, a cart services, a checkout service, an order service, etc.
To coordinate the efforts of all these microservices, it's also typical to implement an API gateway. The application will work with the gateway only, and the gateway will proxy out the requests to each individual microservice to get the information or do the work that the application requires. In a sense, it acts as a conductor would, coordinating all the individual instruments to create the harmony.
Long and short, most likely what you want is one or likely more ASP.NET Core API project(s). You'll create controllers and actions on those controllers, where the latter of which will effectively become your endpoints, i.e. the functional routes your API exposes to do work. Since a microservice architecture is desired, these API project(s) should remain small and razor-focused, potentially only each working with just one entity class or maybe a very narrow slice of app functionality that involves multiple entities. You should strive to keep them as lightweight as possible, minimizing the amount of middleware and external libraries involved. When it comes to deployment, it's most typical to use containerization - Docker is a popular choice for that.
There's not really a template for creating a microservice in .NET, because any application that is deployable in a standalone way and that is reachable over some form of communication protocol (be it HTTP, message queues, or anything else) to perform some sort of action can be called a microservice.
See also Martin Fowler: Microservices and .NET microservices - Architecture e-book.
So to create your service that will "[accept] two latitude and longitude values and [return] the distance", you can simply create an ASP.NET Core Web API with one action method, and that's your microservice.
Another really good resources aside from what others have mentioned is: https://12factor.net/
It doesn't talk about any implementations (so you wont find references to .NET Core in there) but it does talk about how to design your application so it behaves more like a microservice - including dealing with scaling and processes that are stateless.
And to clarify a point of confusion: there's no special application type for a microservice. If your application behaves like a microservice, it is a microservice!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I created a web service using vb.net in IIS that selects data from database and returns a List of objects with the results.
Is it possible to read that list of objects with a program made in MAC OS X that interacts with the method of the IIS web service?
Another option is use text files, but would be more effective using objects
It's possible, but there is no out-of-the-box solution.
Your options are:
Take a look at Mono project. It's cross-platform .NET framework implementation. You can write program for MAC OS X here and it seems to be the simplest way to go. However I'm unaware of the compatibility between Mono and Microsoft's CLR so you have to check yourself.
You could also possibly run your original service under Mono in which case it would be very simple. The problem is Mono does not cover 100% of the whole .NET framework.
Introduce serialization on service side and deserialization on MAC OS side. For example if you are be able to serialize your objects to strings, you can simply deserialize them on any platform.
Theoretically you could implement your own Object deserializer directly from your existing service. But in practice it would be almost impossible. You would have to handle so many cases, cross-platform issues and much, much, much worse things. I mention this only for completeness of the list. DO NOT go this way.
Appendix:
You must realize, what your service actually sends. It actually sends just some sequence of bits. Computer must correctly parse them to reconstruct original objects. This is tightly related to what Object is in memory. It's memory image depends on the CLR implementation. Without equivalent CLR you won't be able to simply read Object from source CLR.
So your task is to ensure you are able to reconstruct the objects
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am Balu from Hyderabad. I have writing WCF Restful services for our Andriod / Iphone developers()They can use JSON format so that we are choosing REST). Actually we can do Mobile Application only one APP that can runs differnt projects. All the projects are dynamically comes from WEBSERVICE to MobileApp. So we can configure all the dynamic data from Web services only.
Only one App can handle 5 projects having totally 100-150 users. so i can write only one service using Factory Reflection methods to load projects dynamically.
Q) I have doubt that for our projects which WCF instance mode is suitable?
By reading WCF instance mode articles i understand that "percall" instance is suitable for our WCF service. Is my guess correctly or not? Please suggest me.
And i have one more doubt that If we are not specify an attribute as serialize then that object will not go through network properly? i have tried without serialization (i.e not mentioned "datamember" for particular property) its going well to Mobile App.
Please clarify my doubts and tell me whih instance mode i have to use?
Which instance is better?
Which ConcurrencyMode is better?
The PerCall instance mode is preferred when you don't need to maintain state between calls for the same client. In other words, your service is stateless. PerInstance is used when you need to maintain some state between calls for a client. And finally, Singleton is used when you need to reference state between multiple clients. Depending on your binding and security settings, you will default to either PerCall or PerInstance. PerCall is ideal because it's easier for you to scale your service if/when you need to.
For your ConcurrencyMode, the default is single threaded. Since you're asking, I would suggest leaving this as the default (generally). However, take a look at the tricky case I talked about here.
The [DataContract] and [DataMember] attributes are not necessary as of .NET Framework 3.5. Prior to that version, you had to be explicit and specify these attributes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Recently, I have been trying to understand what is the difference between using the Service Locator "anti-pattern" and using the Castle Windsor container. I have found some info here and there on the Internet and I have summarized what I have learned so far in an unfinished blog post.
EDIT: Until now I have been thinking that Dependency Injection is all one would need to guarantee separation. But everywhere I look I see a push in the direction of containers such as Castle Windsor. I would like to clearly understand the reasons.
Please... Explain this to me like I'm a 6 year old :)
Funny you should ask to have it explained like you were six years old; here's an explanation like you were five years old :)
everywhere I look I see a push in the direction of containers such as Castle Windsor
Frankly, I think the reason for that is that most people actually don't understand what Dependency Injection is, which means that instead of grasping the concept of Inversion of Control, they go looking for a replacement for the new keyword they're already used to. Then they find a DI Container and (mis)use it as a Service Locator. Unfortunately, that's very easy to do.
This is the reason why, in my book, I explain all the DI concepts without coupling the explanation to any single DI Container. That's actually the majority of the book.
Service Locator and Dependency Injection are two fundamentally different attempts at achieving loose coupling. Service Locator has many disadvantages, and offers no advantages not also offered by DI. This is why I think it's safe to call Service Locator an anti-pattern.
You don't need a DI Container to use DI; in fact, I would say that unless you take a rather sophisticated approach, it's probably better to avoid one.
Well a service locator may just be a wrapper around a particular inversion of control container such as Castle Windsor. The point is that the only place in which your code should (ideally) reference the container is at your composition root.
Because inversion of control containers support dependency chaining, when you resolve your root type from the container, all of its dependencies will be injected, and any descendent dependencies.
If you then wish to create further types at run time, then you can use factories, which could also have a reference to your container if you wish to take advantage of the dependency chaining offered by the container and the container mappings of interfaces against implementations.
When you use service locator, your code is calling locator for services everywhere. When you use inversion of control, there is only one place (composition root), where you call container. The rest of your app should not be container aware.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am presently designing a message queue system that will be used by various applications and am having a difficult time trying to decide whether to use WCF to provide the services or use a shared class library (DLL) and deploy the DLL with the clients.
For some additional information:
• The queue is stored in a SQL database.
• We expect to have approximately 3-7 different applications/clients using this message queue system.
• The clients/applications may or may not run all on one machine.
• We do not expect a heavy load of messages being queued on a daily basis (approx 1000-10000 per day (gross estimates btw))
• Somewhat “mission critical” – several clients/applications cannot do its job if this service is unavailable.
• Everything operates within the corporate network – no access to Internet required.
I have given some though to the pros and cons for each decision:
WCF Service
Pros:
• Can update the logic in the Queue system without having to update the clients
• Room for scalability – but most likely not going to be an issue.
Cons:
• More difficult to diagnose/debug
• More effort required when deploying
• Queue System unavailable if the service is down (unless we cluster/farm)
Shared Class Library (DLL)
Pros:
• Easier to debug
• Easier development efforts
• Only have to ensure that the DB is available – no dependence on another service/machine.
Cons:
• Deployment headaches when we make updates to the DLL – we may forget to update all the applications that depend on the DLL.
If anyone can provide more arguments for a solution – that would be helpful! If you have an opinion to what you believe is the best direction, please do tell! I’ll appreciate any input that will help make me a decision.
Thanks for your time,
Adrian
You can do both:
Implement a class library that encapsulates all the functionality you wish to expose. Consumers that wish that level of control can reference the library directly.
Develop a WCF service that only acts as a Remote Facade for the class library. It would only expose and translate the class library into DTOs/messages, and contain no logic in itself.
In other words, the class library is your Domain Model, and the service is just a thin Facade in front of that model. That's the way any WCF service should be developed in any case.
That said, I you must choose one or the other, I'll try to add my own thought to yours (which I find most reaonable).
One disadvantage of WCF that you forgot is that it does add some processing overhead because it must serialize and deserialze messages.
Even so, selecting the best model is not only about counting the number of bullets in each pro/con section, as each bullet has different weights.
Without knowing your exact situation and requirements, I would still consider the deployment/versioning issue that relates to direct use of a class library to be a very strong argument against that strategy.
A web service interface will allow you to vary service and each client independently of each other as long as the contract remains stable. That could also be made possible with a class library, but is more difficult.
An interoperable web service interface also gives you a better ability to grow and respond to new business opportunities, as the clients are not constrained to .NET applications. You may have only .NET applications today, but are you sure it will stay that way forever?
If, on the other hand, you decide to go the class library route, make sure to have each client consume abstract base classes, because that will provide you with the most flexible options of changing the implementation without breaking existing clients.
Given the information you provided, I don't think there's a clear-cut winner here. I lean slightly towards WCF despite the added complexity, because I consider the flexibility it provides gives you better options for responding to unforseen changes.