I am currently working on a .NET Core project where I use the Microsoft.Azure.Servicebus version 1.0 NuGet package found here: https://github.com/Azure/azure-service-bus
The problem I have is that I haven't found any method to get a queue's number of active messages. This used to be pretty easy with .NET framework using the ServicebusNamespace.NamespaceManager, referring to a queue and use the .ActiveMessageCount.
Is this possible in some other way in this library with .NET Core 1.1?
It is now possible using the latest version of the Service Bus library (3.1.1):
using Microsoft.Azure.ServiceBus;
using Microsoft.Azure.ServiceBus.Management;
var client = new ManagementClient(connectionString);
var queue = await client.GetQueueRuntimeInfoAsync(queuePath);
var counts = queue.MessageCountDetails;
var subs = await client.GetSubscriptionRuntimeInfoAsync(topic, subscription);
var countForThisSubscription = subs.MessageCount; //// (Comes back as a Long.)
The .NET Standard client (Microsoft.Azure.ServiceBus) is deliberately not providing management operations. It states that management operations should not be performed at run time. Management operations are extremely slow.
Is this possible in some other way in this library with .NET Core 1.1?
Yes, it is possible.
Instead of the NamespaceManager that was available with the old client (WindowsAzure.ServiceBus), there's a ServiceBus management library (Microsoft.Azure.Management.ServiceBus.Fluent)
You will need to do the following:
Authenticate using ServiceBusManager
Access the namespace you're interested in via ServiceBusManager.Namespaces
Filter out the entity you're interested in by locating it under ServiceBusManager.Namespaces.Queues/ServiceBusManager.Namespaces.Topics. For subscription you'll need to locate one via ITopic object.
Once you've got your entity (IQueue, ITopic, or ISubscription), you'll be able to access the message counts.
I'm not a big fan of this approach. Rather than each developer reinventing this wheel, Azure Service Bus team should have provided a helper library to replace NamespaceManger. You can always raise an issue or vote for an issue that was closed.
Management operations were introduced back in version 3.1.1 with pull request #481.
Related
I'm currently building a Xamarin based mobile application. For that project, I have created a PCL project with framework 4.5. I'm using VS 2013 as the development IDE. Now I want add a WCF service reference to this PCL. While adding service reference to this PCL project, I noticed that generation of asynchronous operation is disabled. Please check the image for more detail.
I added the BCL.Async package via Nuget to the project. But still I can't access the Task based operation from the radiobutton list (its disabled).
So is there any way to generate task based asynchronous operation in service client?
Hate to break it to you but you cannot generate Task based WCF client in Xamarin. The reason is Xamarin or Mono implements the Silverlight set which is a limited WCF implementation. As such you need to use SLSVCUTIL.exe instead(Adding a service reference in Xamarin would use this tool). The silverlight WCF client generated by SLSVCUTIL will be async based only.
All is not lost! You can easily wrap the silverlight async client into a task based client using the Task.FromAsync method.
A sample taken from the Xamarin website:
public async Task<List<TodoItem>> RefreshDataAsync ()
{
...
var todoItems = await Task.Factory.FromAsync <ObservableCollection<TodoWCFService.TodoItem>> (
todoService.BeginGetTodoItems,
todoService.EndGetTodoItems,
null,
TaskCreationOptions.None);
foreach (var item in todoItems) {
Items.Add (FromWCFServiceTodoItem (item));
}
...
}
https://developer.xamarin.com/guides/xamarin-forms/web-services/consuming/wcf/
Now if someone can figure out how to catch an Fault Exception when wrapping in Tasks that would be awesome!
I've not used Xamarin before, but I'll assume APM and maybe Tasks are actually supported in it and this is just a Visual Studio limitation. Try using wsdl.exe manually to generate code. This is the tool Visual Studio calls when you add a service reference.
You'll need to pass either newAsync (Tasks) or oldAsync (APM) through the /parameters switch.
We're currently working on a Worklight project using Dojo (more specifically dojox/app). We managed to create a basic example with a store, model, controller and a view. However, now we want to connect this to our Worklight adapter.
What is the best approach in connecting a Dojox/app application to the backend? We were thinking about feeding our store with the data from the Worklight adapter, however, we need to do all CRUD operations and our data should be in sync with the server because multiple users might be working at the same item.
The best general solution I can think about is using a JsonRest store, but we're using the WL.Client.invokeProcedure function that calls our adapter, so we're not directly using the service.
We found a solution by using the WL.JSONStore from WorkLight. The API of it isn't compatible with the dojo/store API (logically since it wasn't meant to be), but we wrote a dojo/store API based proxy class which does nothing more than translating and forwarding calls to the WL.JSONStore.
I'm working with my team on the "core" domain of our job, we have several DBs, Webservices, importer, etc... We expose the domain services to other teams through a backend WCF webservice. This webservice is cut in several api (or areas).
We deploy this on several production server (~ 80) (1 server <-> 1 customer).
Problem is: Some api goes public and we must maintain the same contract throught many releases. Others team want more flexibility (3 internal api contract version) as they can't follow our delivery rate (longer cycle)
Actually we are only serving this as a whole, and we are using a classic three branch branching (DEV/MAIN/RELEASE'n')
I'm trying to upgrade my TFS Team collection organization to handle a defined version range of each API version:
API Foo v2 (hxxp://-host-/api/foo/v2/...)
API Foo v3 (hxxp://-host-/api/foo/v3/...)
API Bar v1 (hxxp://-host-/api/bar/v1/...)
API Bar v2 (hxxp://-host-/api/bar/v2/...)
Currently we have the following branching schema:
$\MyTeamCollection
|___\DEV {Branch}
|___\Databases
|___\MyDBProj (SSDT)
|___\Documents
|___\MyWebService\MyWebSvc.Usage.docx
|___\Projects
|___\MyWebService.Core
|___\MyWebService.API.Bar
|___\MyWebService.API.Foo
|___\Shared
|___\MyDB\MyDB.DacPac, etc...
|___\MyWebService\MyWebsvc.Bar.Contract.Dll <-- WCF DataContract/ServiceContract
|___\MyWebService\MyWebsvc.Foo.Contract.Dll
|___\MAIN {Branch} <-- This one is what is on the integration server
|___\R1 {Branch} <-- This one went on a production server and is kept aside
|___\R2 {Branch}
|___\Archive
|___\R0 {Branch} <-- This one is obsolete but is archived here
Actually it handles a group of single api versioning. => Each release ship with a set of latest api version (Foo, Bar)
My question is how can I evolve this to handle multiple Api Version in each release (Foo-v1, Foo-v2, bar-v3, bar-v4)
Should i create branch inside branch? Won't this be a nightmare?
Any actual working teamcollection organization on your side?
Thanks,
-Jeremy.
Some additions:
All my clients are .Net, we provide them the assembly named MyWebsvc.Foo.Contract.Dll. This assembly contains:
ServiceContract interface which is implemented by a proxy pattern
[ServiceContract]
public interface IFooService {
Foo Get(int Id);
}
And all data contract needed (DTO + Serialization)
[DataContract]
public class Foo {
// ...
}
On the web service side there is the actual implementation
public class FooServiceImpl : FooApi.IFooService { ... }
For the purpose of this answer, I imagine that you have thoroughly reviewed the abundance of version control branching and merging guidance available online. As such, I suspect that the answer may not be found in “more” version control, but rather in a modest shift in the way features are enabled and available for customer use. Therefore, you may find that implementing a feature toggle solution will reduce the number of release versions that you need to maintain. The following article by Martin Fowler provides a good overview of feature toggles.
http://martinfowler.com/bliki/FeatureToggle.html
Our development team has utilized the concept of feature toggles, in our self-hosted WCF Windows Services, to provide a fully configurable set of endpoints that can be enabled/disabled (and adjusted) via configuration. In such scenarios, we typically utilize the customers’ data repository (database, ldap, etc) to store the configuration values and toggle switches, then when the service runs, it searches the repository for the configuration and then sets up and enables the interfaces in the manner the customer needs/wants.
Hope this helps.
Regards.
Jeremy,
there are a few questions you need to consider.
a) are your clients .Net as well or can they be in any technology? WCF has a really nice "compatible" versioning mechanism, but unfortunately it's non standard and only works with .Net clients
b) do you have the ability to give some guidance as to how the clients consume the services?
The only way to keep this problem under control is to adopt a "compatible" versioning strategy. As you pointed out, you want to have several (max 3) major releases in production and each time you evolve one or more major release you want to create a compatible (minor) version such that there is always one and only one release for each major version of the service running.
From a TFS perspective, I would consider each major version independent from each other, as in essence, they are somewhat independent services. I understand that creates a bit more work since you could have some update that applies to more than one major release, but IMHO, it's not worth the trouble to try to optimize that, unless you are actively working on all major versions simultaneously.
Achieving "compatibility" from one version to the next is not that hard, there are number of guidelines you want to follow both on the service side and the client side. I co-authored this article way back in 2008. http://www.infoq.com/articles/contract-versioning-comp2
I also wrote that blog post recently specifically for HTTP based APIs: http://www.ebpml.org/blog2/index.php/2013/04/13/formalizing-the-api-style
I want to emphasize that it's generally a good idea to use a minor version that is provided by the client to indicate which version of the service was in effect when it was built. The reason for that is that you can handle small breaking changes in a compatible way by knowing which minor version of the service it is compatible with. You still have a single release per major version and the variants are directly handled by the latest (minor) version of the service.
Versioning is key to a healthy API that allows clients to upgrade on their own terms (risk, budget, resources,...) and to the best of my knowledge, a "compatible versioning" strategy is the one that works best.
We were using the System.Data.Services.Client (version 4 I guess) of Microsoft WCF Data Services. When we updated to the version 5.2 (Microsoft.Data.Services.Client dll), it seems that some caching mechanism has been inserted into the new version of WCF Data Services.
Because when we query the data services (OData) through browser, fresh data would be returned, but when we add a service reference to our UI project and use that reference (proxy) to retrieve data, only after 10 minutes or so the fresh data would be shown.
By resetting IIS (iisreset.exe) fresh data would be available, which probably means that somewhere in UI project a caching should be in place.
We don't do something extraordinary in our code, but using OData service reference in its most simple state:
public List<Customer> GetCustomers()
{
CustomersODataModel customersData = new CustomersODataModel("Url");
return customersData.ToList();
}
Consider disabling client side caching in the DataService object and see if that helps. I had the same problem and setting dataService.MergeOption to MergeOption = MergeOption.OverwriteChanges helped keep the data service refreshing the obejct on each change and get.
Desktop clients will be pushing data using WCF to a central server.
When the schema changes etc, say 100 computers have the old version of the desktop client while the rest are using the latest build.
What do I have to do on the server end to handle both versions?
Do I create 2 endpoints in WCF or a single smart endpoint that will figure out the version and act accordingly?
note: i will be passing the version info from the client (if required that is)
You have a choice:
Firstly you should be versioning your service contracts anyway, with their namespaces; eg. http://idunno.org/2008/10/numpty would change to http://idunno.org/2008/11/numpty if the service operations have breaking changes.
Ditto with data contracts; however if all you are doing to the data contract is additive then you can mark the new fields as optional;
[DataMember(IsRequired="false")]
And old clients will work. So this should indicate to you that the parameters into a service and parameters out should also be data contracts; it gives you that flexibility.
MSDN has more