“Oslo” is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road. It’s an incredibly ambitious endeavor by Microsoft to finally tackle the modeling space.
The initiative encompasses an entire group of forthcoming products and technologies that will be released by CSD over time. In order to lay the technical foundation for the “Oslo” modeling platform, CSD will first ship a new version of the .NET Framework and Visual Studio – currently referred to as .NET Framework 4.0 and Visual Studio 2010 – containing some key updates to WCF and WF that make it possible to author declarative workflows and services (think of these as XAML -based “models”).
”Oslo” is the codename for Microsoft’s forthcoming modeling platform. Modeling is used across a wide range of domains and allows more people to participate in application design and allows developers to write applications at a much higher level of abstraction.
“Oslo” consists of:
1. A tool that helps people define and interact with models in a rich and visual manner
2. A language that helps people create and use textual domain-specific languages and data models
3. A relational repository that makes models available to both tools and platform components
ref:
Learn Oslo - http://msdn.microsoft.com/en-us/oslo/cc748651.aspx
Oslo Developer Center - http://msdn.microsoft.com/en-us/oslo/default.aspx
Microsoft 'Oslo' - the vNext SOA Platform -http://geekswithblogs.net/cyoung/articles/116456.aspx
Build Metadata-Based Applications With The “Oslo” Platform - http://msdn.microsoft.com/en-us/magazine/dd419662.aspx
Oslo Videos - http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/41013d24-89f4-4ac2-8ee4-f4b7e75ee5c3
Microsoft SOA Website - http://www.microsoft.com/soa/default.aspx
Microsoft SOA product called OSLO - http://www.microsoft.com/soa/products/oslo.aspx
Oslo May 2009 CTP download - http://www.microsoft.com/downloads/details.aspx?FamilyID=827122a5-3ca0-4389-a79e-87af37cbf60d&displaylang=en
An Introduction To Domain-Driven Design – http://msdn.microsoft.com/en-us/magazine/dd419654.aspx
Microsoft solution Architecture - http://msdn.microsoft.com/en-us/architecture/default.aspx
Microsoft Patterns and Practices - http://msdn.microsoft.com/en-us/practices/default.aspx
Search this Blog:
Microsoft SOA Modeling Platform - Oslo
.NET Data Marshalling & UnMarshalling
Marshaling data => Sending data from .NET to native language
UnMarshaling data => Sending data from Native language to .NET
ref
Introduction to Marshalling - http://msdn.microsoft.com/en-us/library/aa446536.aspx
Call unmanaged DLL functions and control the marshaling of data - http://en.csharp-online.net/Call_unmanaged_DLL_functions_and_control_the_marshaling_of_data
Marshaling Support in the .NET Compact Framework - http://msdn.microsoft.com/en-us/library/8c5xx97k.aspx
Marshal your .NET API - http://pinvoke.net/
Marshal - http://geekswithblogs.net/taylorrich/archive/2006/08/21/88665.aspx
CodeProject - http://www.codeproject.com/KB/cs/C__Poiter.aspx
Passing structures as param - http://www.codeproject.com/KB/vb/Marshaling_Structures.aspx?fid=132433&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=1209742
How to: Marshal Embedded Pointers Using C++ Interop - http://msdn.microsoft.com/en-us/library/3765161x.aspx
How to: Marshal Structures Using C++ Interop - http://msdn.microsoft.com/en-us/library/10d75z29.aspx
Complete Cycle - http://www.developmentnow.com/g/21_2007_2_0_0_913289/How-to-marshal-complex-data-structures.htm
Revisit P/invoke - http://msdn.microsoft.com/en-us/magazine/cc163910.aspx
msdn Links - http://msdn.microsoft.com/en-us/netframework/aa497271.aspx
Interop (.NET 1.1) Performance Guidelines - Marshal.ReleaseComObject - http://www.guidanceshare.com/wiki/Interop_(.NET_1.1)_Performance_Guidelines_-_Marshal.ReleaseComObject
.NET MDAs(Manged debug Assistants) - asserts in the CLR
MDAs are asserts (probes) in the CLR and in the base class libraries (BCL) that can be turned on or off. When enabled, they provide information on the CLR"s current runtime state and on events that you as a developer could not otherwise access. Some even modify runtime behaviors to help expose otherwise very hard to find bugs. The Microsoft® .NET Framework 2.0 includes 42 of these MDAs, some more useful than others, but all of them very powerful debugging aids that can help you track down truly insidious problems at run time
In .NET programming, the ability to see what’s going on at the machine level usually poses a problem only when we’re working with low-level functionality like loading assemblies or interoperating with unmanaged code. This isn’t surprising, as it’s usually the "edges"--the interfaces between components--that usually end up being the problematic parts of any significant program.
.NET 2.0 introduced Managed Debugging Assistants(MDAs) which are probes into the common language runtime (CLR) and base class libraries (BCL). These probes, which you can turn on and off with configuration files, provide information on the CLR’s current state and on events--information that you could not normally access. Some MDAs also modify behavior to help expose bugs that would otherwise be very difficult to isolate.
ref:
Diagnosing Errors with Managed Debugging Assistants -
http://msdn.microsoft.com/en-us/library/d21c150d(VS.80).aspx
Let The CLR Find Bugs For You With Managed Debugging Assistants -
http://msdn.microsoft.com/en-us/magazine/cc163606.aspx
MDA (Manged debug Assistants) - http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=500
Open Source Software in C# - http://csharp-source.net/
Check whether a Dll is Managed Assembly(C#)
.NET environment may contain a mixed DLLs (.net assembly DLLs & native DLLs) on Windows OS. If we have to know programmatically(C#) whether a file (with .dll extension) is a native DLL (or) .NET Assembly DLL, we can use the following function.
ref:
http://stackoverflow.com/questions/367761/how-can-i-prevent-loading-a-native-dll-from-a-net-app
public static bool IsManagedAssembly(string fileName)
{
try {
uint peHeader;
uint peHeaderSignature;
ushort machine;
ushort sections;
uint timestamp;
uint pSymbolTable;
uint noOfSymbol;
ushort optionalHeaderSize;
ushort characteristics;
ushort dataDictionaryStart;
uint[] dataDictionaryRVA = new uint[16];
uint[] dataDictionarySize = new uint[16];
Stream fs = new FileStream(fileName, FileMode.Open, FileAccess.Read);
BinaryReader reader = new BinaryReader(fs);
//PE Header starts @ 0x3C (60). Its a 4 byte header.
fs.Position = 0x3C;
peHeader = reader.ReadUInt32();
//Moving to PE Header start location...
fs.Position = peHeader;
peHeaderSignature = reader.ReadUInt32();
//We can also show all these value, but we will be
//limiting to the CLI header test.
machine = reader.ReadUInt16();
sections = reader.ReadUInt16();
timestamp = reader.ReadUInt32();
pSymbolTable = reader.ReadUInt32();
noOfSymbol = reader.ReadUInt32();
optionalHeaderSize = reader.ReadUInt16();
characteristics = reader.ReadUInt16();
// Now we are at the end of the PE Header and from here, the PE Optional Headers starts... To go directly to the datadictionary, we'll increase the stream’s current position to with 96 (0x60). 96 because, 28 for Standard fields 68 for NT-specific fields From here DataDictionary starts...and its of total 128 bytes. DataDictionay has 16 directories in total, doing simple maths 128/16 = 8. So each directory is of 8 bytes. In this 8 bytes, 4 bytes is of RVA and 4 bytes of Size. btw, the 15th directory consist of CLR header! if its 0, its not a CLR file :)
dataDictionaryStart = Convert.ToUInt16(Convert.ToUInt16(fs.Position) + 0x60);
fs.Position = dataDictionaryStart;
for (int i = 0; i < 15; i++)
{
dataDictionaryRVA[i] = reader.ReadUInt32();
dataDictionarySize[i] = reader.ReadUInt32();
}
fs.Close();
if (dataDictionaryRVA[14] == 0) return false;
else return true;
}
catch(Exception e)
{
// ToDo
}
}
Service Oriented Architecture(SOA) Design Patterns
Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
Why SOA?
The reality in IT enterprises is that infrastructure is heterogeneous across operating systems, applications, system software, and application infrastructure. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.
Service-oriented architectures have the following key characteristics:
1. SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
2. SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
3. SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.
4. Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.
ref:
SOA Introduction
What is SOA - http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html
SOA Overview - http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330269,00.html?offer=briefcase
SOA LifeCycle - http://searchsoa.techtarget.com/guide/allInOne/0,296293,sid26_gci1262598,00.html?offer=briefcase
Principles of Service-Orientation -
http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172714,00.html?offer=briefcase
End-to-end testing for SOA and enterprise transactions -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357238_mem1,00.html
SOA patterns
SOA Patterns - http://www.soapatterns.org/
SOA Design Patterns by Thomas Erl - http://www.soapatterns.com/
SOA Design Patterns (by Arnon Rotem-Gal-Oz) -
http://www.rgoarchitects.com/Files/SoaPatterns.pdf
http://www.rgoarchitects.com/Files/SoaPatterns2.pdf
Best of Udi Dahan's Articles -
http://www.udidahan.com/first-time-here/
SOA Patterns: Implementing an SOA Using an Enterprise Service Bus(IBM Redbook) -
http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf
Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6 - http://www.redbooks.ibm.com/redbooks/pdfs/sg246494.pdf
SOA Anti-Patterns - http://www.infoq.com/articles/SOA-anti-patterns
Service Facade -http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1346145_mem1,00.html
Non-Agnostic Context -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1347582_mem1,00.html
Domain Inventory -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1349152_mem1,00.html
Service Normalization -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1350514,00.html
Service Decomposition -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1352917_mem1,00.html
Miscellaneous
How SAML fits into your SOA security scheme -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1337854_mem1,00.html
Tips for tracing enterprise transactions -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357445_mem1,00.html
Enterprise Architecture in the Agile age - Part 1, Styles of EA -
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357017_mem1,00.html
SOA management vs SOA governance
http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1335764,00.html
Business Process Execution Language (BPEL) Tutorial -
http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330911,00.html
Enterprise Mashups
C++ C# Interoperability
Three complementary technologies enable these managed/unmanaged interactions:
1. Platform Invoke (sometimes referred to as P/Invoke) enables calling any function in any unmanaged language as long as its signature is redeclared in managed source code. This is similar to the functionality that was provided by the Declare statement in Visual Basic® 6.0.
2. COM interop enables calling into COM components in any managed language in a manner similar to using normal managed components, and vice versa. COM interop is comprised of core services provided by the CLR, plus some tools and APIs in the System.Runtime.InteropServices namespace.
3. C++ interop (sometimes referred to as It Just Works (IJW)) is a C++-specific feature, which enables flat APIs and COM APIs to be used directly, as they have always been used. This is more powerful than COM interop, but it requires much more care. Make sure that you check the C++ resources before you use this technology.
Ref:
1. PInvoke Interop Assistant -
Brief: In marshalling, there are a bunch of attributes and rules. Understanding all those attributes and rules seem a bit daunting. In order to make developing work more efficient and easier on those attributes and the rules, P/Invoke Interop Assistant comes out. It is a toolkit that helps developers to efficiently convert from C to managed P/Invoke signatures or verse visa. This is conceptually similar to TlbImp for COM Interop which generates managed proxy entry points based on some formal description of the unmanaged side but it works for P/Invoke. The toolkit was first released on MSDN Magazine website in Jan, 2008.
http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120
2. P/Invoke sample code msi -
http://msdn.microsoft.com/en-us/library/aa719104.aspx
3.CLR INSIDE OUT -
http://msdn.microsoft.com/en-us/magazine/cc164193.aspx
4.NET to C++ Bridge -
http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx5. Interoperability Mini-Guide -
http://tssblog.techtarget.com/index.php/interviews/interoperability-bridging-net-and-java/
6. Calling Win32 DLLs in C# with P/Invoke -
http://msdn2.microsoft.com/en-us/magazine/cc164123.aspx
7. P/Invoke Revisited - http://msdn2.microsoft.com/en-us/magazine/cc163910.aspx
8. Is PInvoke dead - http://weblogs.asp.net/kennykerr/archive/2005/06/20/Is-P_2F00_Invoke-Dead_3F00_.aspx
9. An Overview of Managed/Unmanaged Code Interoperability -
http://msdn2.microsoft.com/en-us/library/ms973872.aspx
10. Chris Green's Unix/Windows and .Net/Java Interoperability Blog - http://blogs.msdn.com/chris.green/
11. Design Guidelines, Managed code and the .NET Framework - http://blogs.msdn.com/brada/articles/361363.aspx
IPC in .NET
.NET Framework provides several good options for inter-process communication (IPC) like -
1. Web services
2. Remoting
3. Remoting with a TCP channel and binary formatter.
4. Named Pipes
...
Ref:
IPC in .NET - http://www.ddj.com/windows/184416711
Using IPC channels and .NET Framework 2.0 to communicate between processes -http://articles.techrepublic.com.com/5100-10878_11-6143016.html
Using Remoting IpcChannel in Framework 2.0 - http://weblogs.asp.net/israelio/archive/2005/01/04/346180.aspx
.NET Remoting Using a New IPC Channel - http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c9251
Using FileMapping on .NET as IPC - http://www.codeproject.com/KB/files/MemMap.aspx
.NET Remoting Using a New IPC Channel - http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c9251
Microsoft Community Blogs (Wonderful site) -http://www.microsoft.com/communities/blogs/PortalHome.mspx
P/Invoke : Calling C++ from C#
P/Invoke is used as a noun when referring to the COM Interop functionality of the CLR and is used as a verb when referring to the use of this feature. Using the P/Invoke service in the .NET Compact Framework includes three primary steps: declaration, invocation, and error handling.
Sample Code:
Let's see how to call the Win32 MessageBeep function whose unmanaged declaration is shown in the following code:
BOOL MessageBeep(
UINT uType // beep type
);
You'll need the following code to add to a class or struct definition in C# in order to call MessageBeep:
[DllImport("User32.dll")]
static extern Boolean MessageBeep(UInt32 beepType);
Surprisingly, this code is all that's required before your managed code can suddenly call the unmanaged MessageBeep API. It's not a method call, but an extern method definition. (Also, it's as close to a straight port from C that C# will allow, so it is a helpful starting point for introducing some concepts.) A possible call from managed code might look like this:
MessageBeep(0);
Now, notice that the MessageBeep method was declared as static. This is a requirement for P/Invoke methods because there is no consistent notion of an instance in the Windows API. Next, notice that the method is marked as extern. This is your hint to the compiler that you mean for the method to be implemented by a function exported from a DLL, and therefore there is no need for you to supply a method body.
Ref:
1. PInvoke Interop Assistant -
Brief: In marshalling, there are a bunch of attributes and rules. Understanding all those attributes and rules seem a bit daunting. In order to make developing work more efficient and easier on those attributes and the rules, P/Invoke Interop Assistant comes out. It is a toolkit that helps developers to efficiently convert from C to managed P/Invoke signatures or verse visa. This is conceptually similar to TlbImp for COM Interop which generates managed proxy entry points based on some formal description of the unmanaged side but it works for P/Invoke. The toolkit was first released on MSDN Magazine website in Jan, 2008.
http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120
2. P/Invoke sample code msi - http://msdn.microsoft.com/en-us/library/aa719104.aspx
3. Calling Win32 DLLs in C# with P/Invoke -
4. P/Invoke Documentation (msdn) - http://msdn.microsoft.com/en-us/library/26thfadc.aspx
5. Interoperating with Unmanaged Code -
6. Using P/Invoke to Call Unmanaged APIs from Your Managed Classes -
http://www.microsoft.com/indonesia/msdn/pinvoke.aspx
7. Managed, Native, and COM Interop Team - http://www.codeplex.com/clrinterop
8. CLR INSIDE OUT - http://msdn.microsoft.com/en-us/magazine/cc164193.aspx
9. Calling Managed .NET Function from Unmanaged Windows Custom DLL -
http://www.codeproject.com/KB/cs/win32_to_net.aspx?display=Print
10. TLBIMP -
TLBIMP is a .NET SDK tool that creates an Interop assembly from a COM type library. This project is a managed code implementation of TLBIMP.
http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=17579
SSCLI(Shared Source Common Language Infrastructure)
The Shared Source Common Language Infrastructure (SSCLI), previously codenamed Rotor, is Microsoft's shared source implementation of the CLI, the core of .NET.
Although the SSCLI is not suitable for commercial use due to its license, it does make it possible for programmersto examine the implementation details of many .NET libraries and to create modified CLI versions. Microsoft provides the Shared Source CLI as a reference CLI implementation suitable for educational use.
The Shared Source CLI was pre-configured to run on Windows, FreeBSD (version 4.7 or newer), and Mac OS X 10.2. It is designed such that the only thing that needs to be customized to port the Shared Source CLI to a different platform should be a thin Platform Abstraction Layer(PAL).
The current version of SSCLI is 2.0, which contains most of the classes and features of version 2.0 of the .NET Framework[1]. Unlike the previous version however, it is only supported on Windows XP SP2.
Ref:
http://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure
