Thursday, September 29, 2005

DirectX Managed

It's a great pleasure for me to see that David Catuhe from Bewise steel keeps DirectX managed to the top level. I've seen David for the first time at the first North Africa Developers Conefrence in Tunis. His DirectX Managed show was excellent. In one of his recents articles about graphics under .Net (see it here:
he was describing one lack of performance issue Managed DirectX developers have to face, and thus he proposed a way to improve the performance.

Explaining how the using of tables slow down the program because of two phases of unmanaged resources manipulations, he recommanded the usage of GraphicsStream. Moreover he showned a way or using unsafe code so that the execution become four time fast.

Monday, September 19, 2005

ASP.NET authentication modes

Hi all,
Back to basic stuffs, I desire to speak a little about Microsoft ASP.NEt authentication method, taking it from a conceptual level and bring it to the code. It's true that many web sites talk about this subject what what's more interesting that associating concepts coming from theory to real world samples, and that's what we ' are going to do here.

In this article we will see the tree forms of authentication we can use in ASP.NET applications, and we'll make a particular illustration of the Form authentication method. Of course the tree methos are:

  • Windows authentication

  • Forms authentication

  • Passport authentication

Windows authentication

With Windows authentication, ASP.NEt does'nt rely on the application itself but on the operating system to authenticate the user. When the user requests a secure web page from the application, the request goes to Internet Information Services (IIS) . Then IIS compares the user's logon with thoses on the web server or on the domain. If the user's credentials do not match those autorised, IIS rejects the request. The client computer generate a logon dialog box and the user enters the credentials. Again IIS compares the credentials to those authorised and if they're are correct it redirects the request to the correct web page which will be send to the user.

Form authentication

in Form authentication method IIS does not perform the authentication. The IIS security settings for Web applications are set to Allow anonymous acces. When a user request a web page IIS authenticate the user as anonymous user and pass the request to ASP.NET. ASP.NET then, checks for the presence of a specific cookie on the client. If the cookie is not found or is invalid ASP.NET rejects the client and returns a login page. This login page is specified in Web.Config file under the authentication tag. The user supply logon informations on the authentication form and submit the form again. Again IIS authenticate the user as anonymous and pass the request to ASP.NET. This time ASP.NET authenticates the user based on the submitted credentials and it generates a cookie. The requested secured page and the cookie are returned to the client. As long as the cookie remains valid the user can use and view other secured web page with the same credentials.

Monday, September 12, 2005

The role of BPEL in Business Process Integration

The Business Process Execution Language (BPEL) is a vendor-neutral mechanism for describing the behavior of business processes. Originally created by Microsoft, IBM, and others, the latest version of this technology is currently being standardized by a larger group working through OASIS.

The Value of BPEL
BPEL is focused on describing business processes as interactions among web services. Consider a business process spread across multiple execution environments. In this example, the process runs partially on BizTalk Server 2004 and partially on an integration server from another vendor running on Windows or some other platform. The figure below illustrates how BPEL can be used to describe the interaction between the two implementations.
As the figure shows, a BPEL definition can be used first to formalize the public interactions between the two parties participating in this business process, then to generate a baseline implementation of those interactions. Two implementations are generated in this scenario, one targeting BizTalk Server 2004 and a second targeting the other integration server. Each contains the behavior for the system’s appropriate role in the business process. BizTalk Server 2004 might execute the buying half of the process, for example, while the other integration server executes the selling half. The role of BPEL is to define the web service interactions involved in this process. The focus is on the information exchange that must take place to successfully carry out the process.
This example of a business process split between two integration servers illustrates BPEL’s primary value: facilitating interchange[1] of web services-based business processes. While BPEL doesn’t define a complete business process, it does provide a vendor-neutral way to describe interactions of the process with external web services and complementary processes implemented across multiple systems.
Along with the example just described, there are several other scenarios where BPEL can be useful. They include the following:
n A large organization such as a retailer or manufacturer might wish to specify the process its suppliers must implement to sell to it. This kind of hub-and-spoke arrangement, common in business-to-business (B2B) interactions, can be made easier using BPEL. The large buyer at the hub might use BPEL to describe the business process that its suppliers must implement, then distribute this definition to those suppliers. The BPEL definition precisely specifies the required interactions with the hub organization, and so each supplier can use it as a starting point for implementing its side of the process.
n An organization might wish to implement an internal business process that relies on several existing applications, but allow this process to be deployed on any of several different integration servers. To allow this kind of enterprise application integration (EAI), the organization could define the basics of the process in BPEL, then use that common definition as a starting point for implementing the process on servers from one or more vendors.
n Libraries of best-practice business processes can be created, allowing intellectual property to be captured and reused more effectively. For organizations building a process from scratch, standard BPEL solutions like these can be a useful starting point.
n An industry-specific standards organization could provide BPEL templates to its members to help ensure industry-wide support for agreements on how to conduct electronic business.
Microsoft’s support for BPEL is consistent with the other web services standards efforts in which the company participates. All of these standards, including SOAP, the Web Services Description Language (WSDL), and the various WS-* specifications such as WS-Security, are focused on building a common integration fabric across vendor boundaries. None of them, including BPEL, defines an execution environment for implementing applications that use these standards. Instead, this choice is left up to each vendor. For Microsoft, of course, the execution environment is the .NET Framework.
One way to understand BPEL’s usefulness is to view this business process language in much the same light as WSDL. WSDL is useful because it defines an abstract interface to concrete implementations, exposing only what’s necessary for these implementations to interoperate. One implementation might be built in C# on the .NET Framework, while another might be built in Java on a J2EE-based platform, yet interoperability is possible using WSDL and a standard protocol such as SOAP. Similarly, BPEL is useful because it allows an abstract definition of a business process that can be implemented using the .NET Framework, a J2EE-based platform, or something else. By specifying the web services-based interactions the process requires, BPEL effectively aggregates a business process around multiple WSDL endpoints. It makes interworking possible at the business process level rather than just the level of individual web services.
The Foundations of BPEL’s Value
The value of BPEL is based on two fundamental attributes of the technology. First, because BPEL makes no assumptions about the environment in which a business process will execute the technology is completely platform-neutral. The second fundamental attribute that makes BPEL valuable is the language’s complete focus on process-oriented abstractions. Rather than mix these higher-level concerns with the more detailed constructs found in traditional programming languages such as C# and Java, BPEL allows a clean separation between defining the business process itself and implementing the finer-grained business objects (probably written in C#, Java, or a similar language) that this process invokes.
Once these core attributes are clear, it’s obvious why BPEL does not—and should not—provide language bindings for directly invoking .NET or Java objects. Doing this would destroy BPEL’s value by eliminating both of the attributes just described: the language would no longer be platform-neutral, and it would also no longer allow a clean separation between the higher-level abstractions of process modeling and the low-level details of implementing business objects. In fact, BPEL’s creators deliberately omitted these kinds of implementation-oriented capabilities, focusing instead on coordinating service-level interactions using interchangeable XML. While a BPEL definition can specify a business process’s interactions with services and other processes, it provides only a starting point for fully implementing that process.
The truth is that the name “Business Process Execution Language” is something of a misnomer, since BPEL’s primary value lies more in the interactions it defines than in its execution capabilities. Implementations of business processes depend on capabilities that are specific to a particular execution environment. Because of this, implementing complete business processes in a truly portable way is not one of BPEL’s goals. Even if a vendor claims to provide a “BPEL execution engine”, the reality is that proprietary platform-specific extensions are necessary to support full implementation of business processes. Even process implementations created for these BPEL-based systems are not easily portable to other execution environments.
BPEL in BizTalk Server 2004
With the release of BizTalk Server 2004, Microsoft is the first platform vendor to support BPEL in an integration server product. In this new version, customers can import a standard BPEL definition that defines the public aspects of a business process, then use the full power of the BizTalk Server 2004 execution environment built on the .NET Framework to implement and run that process. Similarly, customers can define the web service interaction aspects of their business process in the product’s Orchestration Designer, using just the features found in the BPEL specification, then export this process to standard BPEL. Microsoft adds no proprietary extensions to BPEL.
Given its role as an interchange technology, BPEL will be far more useful when other vendors also support it. In the short run, the initial adoption of BPEL will be slow until these implementations are completed. Yet because of its broad industry backing, other vendors will support the language in the near future. Once this occurs, BPEL is likely to play an important role in implementing business processes that span multiple execution environments.

[1] The term interchange is more appropriate than interoperability when discussing BPEL. As it’s usually used, interoperability implies a protocol, yet BPEL uses industry standard web services and does not define any new protocols. Instead, BPEL determines what gets sent across the wire by specifying the behavior of a business process, thereby defining the interchange between parts of that process.