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.
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
One question that I have long asked myself is in object oriented programming,how should data such as settings and properties be passed around in an object oriented manner?
For example, most programs have options, say you have an option to set the undo level. This must be obtained and then set to a new value. If these settings are saved in an xml file, that section of the application (the option dialog) still needs some kind of xml parser to load the data. In another scenario where you would instead have an object that represents getting and setting settings, each area that needs this would have global access to all settings and a pointer to it would need to be passed around.
In a scenario like Maya or 3DS Max where these use huge gui systems to set object properties, how is this done in a clean and OO manner? The widget, needs to be given the data from the 3D object, and needs to send information to this object. Should a dialog know anything about 3D objects? Probably not. So how is this usually done?
In another scenario, I might need to update a status bar when my frame gets a mousemove. Does that mean my frame should have a pointer to my status bar?
Any abstract examples or readings about this would be appreciated.
Thanks
In a previous job, we had several XML files for our various apps, and much of the configuration was similar, but varied depending on the environment and execution context. Much of this configuration was usernames and password for third party services. When a password would change, we'd have to scour through dozens of XML files and make the changes, then, re-deploy dozens of apps.
I migrated all of the XML configurations to objects using interfaces and a type hierarchy. The interfaces allowed me to code against a common configuration structure, and get compile time support as well as use dependency injection to resolve the run-time instances. The type hierarchy allowed me to define the non-changing configurations once, in a base class, and only override the actual values that differed.
This would be overkill, I think, for a small app, but was imperative in our case.
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.
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.