Pablo M. Cibraro (aka Cibrax)
My thoughts on Web Services and .NET development
-
Pub/Sub in the cloud–A brief comparison between Azure Service Bus and PubNub
Publish/Subscribe in the cloud has became relatively important lately as an integration pattern for business to business scenarios between organizations. The major benefit of using a service hosted in the cloud as intermediary is that publishers and subscribers don’t need to be publicly addressable, be in the same network or be able to talk each other directly. The cloud infrastructure allows this intermediary service to scale correctly as the number of publishers or subscribers increase, and also to act as a firewall for brokering the communication (Publishers or subscribers need explicit permissions to connect, send or receive messages from the intermediary service).
-
Integrating ELMAH with MongoDB
MongoDB is by far one of the most well-known and powerful documental databases created in the open source community. The simplicity that you find in this database is also another factor that help a lot in adoption, as you don’t need to know much to start using it.
-
Extending the SO-Aware repository with custom metadata
One of the main features that SO-Aware provides is the central repository for storing service artifacts (WSLD, schemas, bindings) and configuration that any organization generates. This central repository is completely exposed as an OData service that third party applications and tools can easily consume using Http.
-
Caching strategies for SOAP and REST Services
SOAP services are in nature transport agnostics so they can not rely on specific transport features. Http is a great example where SOAP services make a poor use of Http as application protocol. This means that many of the http constraints are simply ignored, http headers are not used at all, messages are not self descriptive (You can not easily infer what a message does by looking at the content), the uniform interface is not used either as everything goes as a POST to the server and the list keeps growing. This makes impossible to leverage the existing web architecture and use intermediaries for caching results.
-
Don’t use services unless you necessarily need them
There are multiple factors or requirements that might lead you to refactor some functionality into services. Here are some examples,
-
Making the HttpMessageHandlerFactory in WCF Web Apis more DI friendly
The HttpMessageHandlerFactory shipped out of the box in the WCF Web Apis Preview 4 can only construct channels instances with a single argument in the constructor representing the inner channel in the pipeline.
-
We have IQueryable, so why bother with a repository
The repository pattern became popular a couple of years ago by the hand of Eric Evans with the DDD (Domain Driven Design) movement and Martin Fowler with his catalog of Enterprise Application Patterns.
-
Tellago upcoming webinars
We are happy to announce a new program “Technology Updates” as part our plans to help developers and IT people to adopt new technologies.
-
Second round of Web Http Caching
As I discussed in my previous post, web caching relies on specific headers that you need to use correctly on your services. That’s an http application protocol thing, and something that you can easily use in any application framework that treats Http as first citizen. This means that you don’t need to implement anything fancy or exclusively rely on an specific caching technology or components for doing ouput caching (e.g ASP.NET Cache).
-
Implementing caching in your WCF Web Apis
One of the beauties of using Http as application protocol when building Web Apis is that you can reuse all the available infrastructure in the web to make your services scalable to the extreme. Caching is one of the fundamental aspects that makes scalability possible in the web today because it provides the following benefits when it is implemented correctly,