For each possible implementation, we will do an overview of the flow that the exception does to understand the context of each implementation.

First, let’s do an overview of what is, normally, a basic flow in any Project.

The basic flow of an API Project

The previous Figure shows the basic flow of events inside the IDM project. The API receives an HTTP Request in a certain endpoint. The endpoints of the API are mapped in the controller layer, so when the API receives the HTTP request the controller is the first to interact with that request and sends that request to the respective service that will orchestrate all the necessities of that request. Those necessities could be, for example, retrieve some information from the Database, and that is done in the repository layer. The repository layer is where we map all the interactions with external services(DataBases, API, etc). This is a basic overview of what could be a basic API project.

The Exception Handling Problem

Taking into account the previous overview of the project, we want to make the process of handling exceptions the more clearest and efficient possible in terms of computational needs, but also in terms of code structure. To achieve this purpose we will describe three different ways of handling the exceptions.

Also, in this project, we have 2 different types of exceptions. They are:

• DomainException – This is the type of exception that is thrown when the error that happens is something that the API already expects;
• Exception – This could actually be any type of exception different from DomainException. This occurs when an unexpected error occurs in the API;

Reference to Middleware

In this case, we will use the ExceptionHandler middleware layer. The middleware layer is specific to .NET Core and we will not focus on that here. Take into account that we will use ExceptionHandler in the middleware pipeline to catch all the exceptions that are not treated.

Here is the reference to ASP.NET Core Middleware.

First Approach: Try-Catch on Controller Layer

This approach consists of catching and treating the DomainExceptions that are thrown by any of the layers (Controller, Service, or Repository) of the APIProject in the Controller layers. Take into account that all the unexpected exceptions are always treated in the ExceptionHandler of the Middleware.

Second Approach: Try-Catch in all Layers

This approach consists of all layers of the API Project being capable of catching exceptions and sending again the exception to the upper layers. The Controller layer is where the Domain Exceptions will be treated.

Take into account that in this case, the unexpected exceptions are caught by the layer that throws her and also by the rest of the upper layers. However, it is treated in the ExceptionHandler of the Middleware.

Third Approach: Encapsulate Exception in Response Object

This approach consists, as the name says, in encapsulating the exception in the Response Object. Instead of throwing the exception, we will send the Response object with a Failed message with an instance of the exception in the Response Object as a variable. This means that the system will not need to operate the throws of exceptions for the expected errors. They will be passed in the response object.

Take into account that only the unexpected exceptions are thrown to Middleware – ExceptionHandler to be treated.

Normal Response Object

public class OperationResult
{
        public OperationResult();

        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
}

New Response Object for this approach

public class OperationResult
{
        public OperationResult();
           
        public static OperationResult Success { get; }
        public bool Succeeded { get; protected set; }
        public IEnumerable<OperationError> Errors { get; }

        public static OperationResult Failed(params OperationError[] errors);
        public override string ToString();
        public Exception ExceptionHolder { get; set;} 
}

Fourth Approach: Catch all exceptions in Middleware – Exception Handler

The approach consists of throwing the exceptions whenever they happen and then let them be caught and treated by the middleware – ExceptionHandler. In this approach, we would create a different type of response for each type of exception for the ExceptionHandler send as Response.

This would centralize all the exception handling in one place.

Comparison of Exception Handling approaches

The post How to Handle known Exceptions? appeared first on Blog IT.

The slides include architecture aspects, technical aspects, as well as negotiation and functional hints. It’s not meant to be an absolute best-practices architecture guide, it’s only the result of this very specific project.

You can check/download the deck here.

Special thanks to NetPonto for the invitation, and to the audience for the participation and great feeedback in this LONG session :).

The post «Architecting a Large Software Project – Lessons Learned» @ Netponto 50th Meeting – Lisboa 22/Nov appeared first on Blog IT.

The post Cloud Computing: recommended Reading appeared first on Blog IT.

According to the post, the new features are:

• Alignment with Microsoft BizTalk Server 2009 ( Beta )
• ESB Configuration tool
• Centralized itinerary store
• Itinerary resolver components
• Itinerary forwarder pipeline component
• Itinerary selector pipeline component
• Itinerary designer
• Centralized configuration uses Enterprise Library 4.0 Configuration Block
• Centralized caching uses Enterprise Library 4.0 Caching Block
• Multiple service invocation using both messaging and orchestrations
• Itinerary BAM tracking
• Improved ESB Core engine and itinerary execution

I hope the installation process is improved and that non-US regional settings are supported. Those were a huge barrier to adoption of the ESB Guidance, on my view.

The post ESB Guidance 2.0 (CTP) appeared first on Blog IT.

There are two things that interest me, personally, in these kind of cloud paradigms. First, that there are new application models, new architectures, new colors in the pallete, new tools (modeling is one of them). Just look at all the technologies I mentioned. Most of them are usable to develop enterprise applications, they are not customer-facing new things (Mesh is the partial exception here). The second thing that interests me is precisely the engineering challenge, the new problems we will have to solve in a world where almost nothing can be taken for granted. (Can we communicate at all, if everything is extremely loosely coupled?)

Truth is, however, that I don’t think this will be an easy or widespread shift (regardless of what Nicholas Carr thinks). If you talk to most people working in IT today about “moving to the cloud”, you’ll hear jokes about “fog”, and (legitimate) questions about data ownership, security, trust, cost, SLAs and QoS, etc. These issues will have to be tackled with, or at least enough of them.

Data and Business Logic has been near (“it’s mine, all mine!”) almost since the first days of IT, after all.

… so if you are in Portugal or nearby and want a partner company to explore some new ground using these technologies (or just have interesting discussions), get in touch. 🙂

The post PDC(loud) 2007 appeared first on Blog IT.

Bungee Labs – Next Generation Web Development Platform
an ambitious new on-demand, web-based development environment that enables developers to build and deploy web apps that utilize the large variety of APIs and web services out on the Internet

BungeeConnect
The Bungee Connect Platform-as-a-Service is a single environment for the development, testing, deployment and hosting of amazing web applications. Bungee Connect powers highly interactive user web applications built 80% faster and at a cost tied only to end user adoption

Google App Engine: Cloud Control to Major Tom
Google App Engine is similar to the Amazon Web Services stack, which rolled out at the end of 2006 and has since gone on to be utilised by many startups for their infrastructure needs. But it is not a set of standalone services like Amazon’s – which includes S3 for storage, EC2 for hosting and the SimpleDB database. Google App Engine is an end-to-end service and bundles everything into one package.

Red Dog: Microsoft’s Answer to App Engine and AWS?
Kip Kniskern over at the LiveSide blog spotted a Microsoft job advert that appears to give some insight into a cloud computing platform under development at Redmond that could compete with Google’s just released App Engine or Amazon’s suite of web services. The utility computing platform, codenamed "Red Dog" according to the job ad, is under development at Microsoft’s Cloud Infrastructure Services (CIS) team and aims to see a version one release within the "coming year." What little info is provided by the job posting is rather obscure, but there are a few juicy tidbits to be had.

Google’s App Engine: Aiming At Facebook, Not Amazon
If the Silicon Valley echo chamber wants to make up a competitor for AppEngine, its proper correlate (by a whisker) is Facebook’s F8 platform. If you must cram this new service into a pigeon hole, think of App Engine as the Facebook Platform for the grown-up web.

App Engine: Host Your Apps with Google
It’s about time that developers get access to Google’s platform! We’ve been hearing about Google’s server farms and development tools for years. After Amazon Web Services started doing so well we all knew it was just a matter of time (next will be Microsoft we can can safely assume). Though the obvious comparison is to AWS, they aren’t really the same beast. Amazon has released a set a disparate services that can be used to created a general computing platform. The services, though they work together, do not come bundled.

Linxter Internet Service Bus (ISB)
Linxter is an in-the-cloud, customizable communications infrastructure for distributed applications providing hyperconnective, secure, assured information delivery.

Google AppEngine
Google App Engine enables you to build web applications on the same scalable systems that power Google applications.

Red Dog: Yet another unannounced Microsoft cloud service
I believe Microsoft is working on a hosted app platform for developers, with BizTalk Services and SQL Server Data Services (SSDS) at its heart. In fact, I‘ve heard the codename “Zurich” attached to this Google-App-Engine competitor. But are Red Dog and Zurich one and the same? I think they are different, and all part of the big Microsoft services plan in the sky.

Google unlocks its data centers
Where’s Microsoft?

Food for thought.

The post What’s going on in the web after all? appeared first on Blog IT.

A very simple and very useful technique in this situation, and one I often find is not fully used, is to create a “Wire Tap”. A Wire Tap is an Integration Pattern that allows the inspection of messages that travel across a channel. In BizTalk, this translates to simply creating a (Static, One Way) Send Port that looks for specific messages (using its Filters), and sends them to some destination, typically, a file folder (SMTP email is another frequent choice). This port is not bound to any orchestration, it’s a content-based solution only.

One thing to remember about these Send Ports is that if you have a Send Port that has no filters, it catches nothing. Always remember to set up a filter. The ones I used the most are based on the message type (BTS.MessageType) and the receive port the message came in through (BTS.ReceivePortName).

I actually find that understanding and resorting to this mechanism is frequently a good indicator of the maturity of the BizTalk developer and his understanding of the pub/sub model in BizTalk Server.

The post BizTalk: Wire Tap appeared first on Blog IT.