Remember the book ” Application Architecture for .NET – Designing Applications and Services “of the patterns & practices, 2002?
Although old, this book is read by many people in the market, providing the basis for several application scenarios that are still operating, firm and strong.
Part of the success is due to layering the book adopts the .NET solutions, when we saw the Business Entity, Business Workflow, Business Components, the interface of dedicated hosting services, among others.
If you became curious, see the diagram below:
Recalled right? Why am I remembering this kind of design? See, it’s been eight years since its publication, even today, we have an organization of components often based on the architecture above. Even at that time, another important design positions the layers of consumption and exports of services, as shown below:
See, people talked about a standard interface via Web services protocols to SOAP / HTTP / WS-I, allowing the import and export data to external application services.
If it already existed 8 years ago, what has changed in the architecture do today? To think about it, see drawing below, I removed the Application Architecture Guide 2.0:
The figure illustrates a service architecture, where we see basically the same layers of 8 years ago.
Interesting or not?
The conclusion is that good architecture patterns are permanent, lasting enough and taste good investment project. Thus, when designing your solution, try to surround some scenarios with good architectural patterns. Certainly, applying good choices, you’re guaranteed a long life for your solution. But look, an anti-pattern is also being excessive in the use of PATTERN’s. Use them sparingly, always!
Some of Microsoft’s platform products are specially dedicated to enterprise scenarios and specific. This is the case of BizTalk Dedicated Server, an application integration engine, which has evolved greatly over the past 10 years.
I have worked with BizTalk from time to time, throughout its various versions. Much has changed since the 2000 and 2002 versions, where neither integration with Visual Studio had. It was a pain!
The list of versions of the platform appears below:
Today, the product is in its 2010 version, complete and well being positioned as a platform for application integration (EAI), providing connectivity to various platforms and market systems, Business Process Management (BPM) capabilities and SOA / ESB . The platform also includes capabilities for integration of climate Business to Business (B2B), adapters, accelerators and full support for RFID scenarios.
Quite a bit! In the Indian market, some companies have found working with versions 2006 and 2006 R2 in solutions integration, orchestration and messaging treatment with great success.
A simplified diagram of the BizTalk messaging model appears below, for those who still do not know:
Above, we see happening via MessageBox messaging, where every message received at the entrance doors are persisted for consolidation, underwriting and processing of pre-defined orchestrations.
Another interesting aspect of an EAI platform is the ability to integrate local services with services published in the public cloud. Whether through a consolidation via a bus service or simply publishing a cloud services, an EAI engine should allow this type of centralization, facilitating the abstraction of the various infrastructures involved in the solution.
I’m doing some projects that are to develop patterns. So, here’s some examples drawn from the WAG:
A typical application containing Web Roles, Worker Roles and communication Queues Azure is shown below:
A simplified version of this pattern with ASP.NET Forms Authentication for Azure Tables see below:
This week we spend enough time talking about the platform of applications and resources. NET 4. But expanding a little more vision, I thought to create a table with the key components for each category of service or application found on a platform.
The result was as follows:
The table above shows a map of the main features present in Microsoft platform and. NET Framework. This map is partial, but highlights the components involved in building applications in desktop scenarios, web, mobile, enterprise, and cloud services.
You may think, ” Wow, big deal, I’ll never know it all! “. But the fact is that you need not know all this while!
The important thing to bear in mind that the Microsoft platform today offers resources for various scenarios, according to his need. Thus, when treating a particular type of application, use this map as initial recognition, to determine which technologies can be applied to each scenario.
This week we begin a mini-series on migration of applications to the Windows Azure platform. How about that?
A recurring question in sessions about cloud computing is just about scenarios in existing on-premise and as we migrate to the cloud services.
What can we migrate? Layers that we enjoy? What is the architecture more indicative? What aspects of connectivity, control, hardware, administration, etc. that will be impacted?
So, I chose some interesting scenarios of migration to be discussed. Among them we will see:
For example, you have COM , COM + or MFC in your solution on-premise? These technologies are not supported on Windows Azure . I had this conversation last week with a company that has a series of old solutions in VB6, COM + and some components in C + + and MFC.
The Windows Azure platform supports standard libraries in C + +, some functions of the Win32 API and all resources of .NET 3.5 SP1, in addition to templates for Web Roles , WCF Web Roles , Worker Roles and Fast CGI . So we’ll see more details of architectural choices throughout the series.
And feel free to suggest new scenarios or actual cases in your company.