I was trying to have some hold around these WS-* stuff by reading here and there. Microsoft seems to be incorporating all these things into WSE 3.0, which is available as beta right now. Somewhere, I saw IBM's WSTK latest version is already having it in public.
Anyway, I was going through Microsoft's plan of releases, and found some striking points to note:
-- Microsoft's WSE 3.0 will be running on .NET Framework 2.0. Which means, for those running on .NET 1.1, you need to remain happy with WSE 2.0 SP3, whatever you get there.
-- You will need Visual Studio.NET 2005 to develop using WSE 3.0. Which means it would not be easy to make it working with your existing .NET application, unless you decide to port it to new development environment.
So, moving forward quite a few tests are to be done before taking any decision. I can think of a few points right away for me:
-- Currently, my application and web service both running on .NET 1.1. If I migrate the web service to .NET 2.0, will I be able to implement WS-Coordination and WS-Transaction in my web service?
-- Even if I can implement that in my web service, will I be able to keep my application in old .NET 1.1 to realize the full benefit?
-- Will I be able to keep my existing components in .NET1.1 while the new components of the same application will be developed on .NET 2.0? If yes, what would be the key points/limitation I should keep in my mind?
I think I need to wait for some more time till I find good answers to all these.
Friday, September 30, 2005
WS-Coordination
WS-Coordination is a new specification prepared by a group of software product manufacturers. The group includes big names like Microsoft, IBM, BEA, and others. The specification attempts to address the situation where relatively large number of participants get engaged in complete a unit of business processing, which may be composed of serveral long-lived activities at different ends.
WS-Coordination does not address how transaction should be completed, but it sets the stage on which transaction specific activities can be conducted.
The model of this specification is based on three simple services:
1. Activation Service - this allows creation of an instance of a coordinator or creation of a context of a coordinator instance
2. Registration Service - this allows the individual applications to register for coordination
3. A set of coordination protocols - this is an extension provision to allow different protocols for different purposes
So, if we try to look into the specific components within a coordinator, we will see an activation service, a registration service, and one or more protocol services based on how many protocols are in use.
Depending upon how disparate are the applications are, there may be multiple coordinators to facilitate the operations between two applications. One additional namespace has been defined: wscoor.
WS-Coordination does not address how transaction should be completed, but it sets the stage on which transaction specific activities can be conducted.
The model of this specification is based on three simple services:
1. Activation Service - this allows creation of an instance of a coordinator or creation of a context of a coordinator instance
2. Registration Service - this allows the individual applications to register for coordination
3. A set of coordination protocols - this is an extension provision to allow different protocols for different purposes
So, if we try to look into the specific components within a coordinator, we will see an activation service, a registration service, and one or more protocol services based on how many protocols are in use.
Depending upon how disparate are the applications are, there may be multiple coordinators to facilitate the operations between two applications. One additional namespace has been defined: wscoor.
Wednesday, September 28, 2005
Managing Transactions - Revisited
Last year, I have been putting some thoughts into words while blogging about managing transactions. Those who are enthusiastic, can visit this link of my earlier posts on transactions. I have been primarily limited around managing transactions using a transaction coordinator, or more specifically, an application server like COM+. I also explored of having transaction boundaries spread across components and bridged through synchronous events.
Over the period to time, the requirement of having transactions over HTTP is becoming acute. The primary driver to this requirement is the killing success of web services, and its proliferation beyond the traditional boundaries: political, geographical, or organizational.
I am feeling the heat too. Increasingly, I am trying to grapple up with the issues of data inconsistency across the applications that happened due to partial failure of the processes. While defining the business the requirements, these requirements came up as a single unit of work. However, the underlying steps mandate dealing with multiple applications, one being the base application, and the others are dealt via web services. Consuming web services do not remain limited to consuming data, but many times, it means insert/update/delete into the database of other applications. And, the problem starts from there. I am seeing data updated on the base application, but not on the remote application, and vice versa. The users are scared to death when they see their updates are not getting reflected, the operations people are tearing their hairs to correct data/records, and I am sure all are equally angry to see themselves landing into such a trouble.
WS-Transaction specification has come to address some of these problems and to meet the business requirements the way they are getting defined in today's world. In the subsequent BLOGs, we can speak more about this specification and perhaps will try out some sample codes, if possible.
Over the period to time, the requirement of having transactions over HTTP is becoming acute. The primary driver to this requirement is the killing success of web services, and its proliferation beyond the traditional boundaries: political, geographical, or organizational.
I am feeling the heat too. Increasingly, I am trying to grapple up with the issues of data inconsistency across the applications that happened due to partial failure of the processes. While defining the business the requirements, these requirements came up as a single unit of work. However, the underlying steps mandate dealing with multiple applications, one being the base application, and the others are dealt via web services. Consuming web services do not remain limited to consuming data, but many times, it means insert/update/delete into the database of other applications. And, the problem starts from there. I am seeing data updated on the base application, but not on the remote application, and vice versa. The users are scared to death when they see their updates are not getting reflected, the operations people are tearing their hairs to correct data/records, and I am sure all are equally angry to see themselves landing into such a trouble.
WS-Transaction specification has come to address some of these problems and to meet the business requirements the way they are getting defined in today's world. In the subsequent BLOGs, we can speak more about this specification and perhaps will try out some sample codes, if possible.
Tuesday, September 27, 2005
Ignore Extensions and Ignore URLs
These are the two parameters you would be tempted to set while configuring a SiteMinder policy server. The purpose is simple - "Ignore Extensions" will help you to bypass the authentication for the specified file extensions while the "Ignore URL" will make you to bypass authentication for the specified URL. If you put ASP as a value to the "Ignore Extension" parameter, the SiteMinder will not perform the authentication for any HTTP request for any ASP file sitting on the web server. In some cases, the scope of the server includes mutliple websites residing on the same server. Similarly, if you put a URL of a website into "Ignore URL" parameter, all documents within that website will become accessible over HTTP without any authentication.
Looking into these two parameters, my first impression was that these don't meet my practical requirements. As example, I have a website, which I need to keep fully secured so that all pages can be accessed after authentication through the SiteMinder. The only exception would be the login page, which I have designed and developed for the specific application. It means, I needed to open unauthenticated access to one ASP, one JS, one CSS, and a few GIFs. If I put all these as "Ignore Extensions", it would open the full site, literally.
Fortunately, SiteMinder treats the full URL (including directory and file name) as a URL. So, I could use the parameter "Ignore URL" to put the specific file access URLs to make to unprotected. Later, I moved all these files into one sub-directory called "Login" and replace the earlier URLs with a single one: http://myserver/Login/ . As it appears now, the requirement has been met. This has been put into testing now, till then I am keeping my fingures crossed.
Looking into these two parameters, my first impression was that these don't meet my practical requirements. As example, I have a website, which I need to keep fully secured so that all pages can be accessed after authentication through the SiteMinder. The only exception would be the login page, which I have designed and developed for the specific application. It means, I needed to open unauthenticated access to one ASP, one JS, one CSS, and a few GIFs. If I put all these as "Ignore Extensions", it would open the full site, literally.
Fortunately, SiteMinder treats the full URL (including directory and file name) as a URL. So, I could use the parameter "Ignore URL" to put the specific file access URLs to make to unprotected. Later, I moved all these files into one sub-directory called "Login" and replace the earlier URLs with a single one: http://myserver
Starting Over
Before I start blogging on this page, I would like to link up my earlier scribbles I made elsewhere. If you want to have a glimpse of that please click on BLOG: Arijit Chakraborti
As in my previous BLOGs, I will primarily post technology scribbles, but you may find some not-so-techie jots as well. Intermittently, I will also try to re-post some of my earlier BLOGs here.
As in my previous BLOGs, I will primarily post technology scribbles, but you may find some not-so-techie jots as well. Intermittently, I will also try to re-post some of my earlier BLOGs here.
IIS 6.0 Web Service Extensions
This is a new thing that I learned today. To give you a background, we have a running suite of applications on Windows2000 and IIS 5.0. Now, there is a move to upgrade the apps to Win03. After installing IIS, we realized the ASP files are not at all running on the web server while the HTML files are fine. Using the good old experience we thought it must be an installation problem, and the IIS got a faulty setup.
Then we realized the new administrative control came with IIS 6.0. It allows you to enable/disable dynamic content. Referring back to my original problem, the extension ASP was set disabled through this control, perhaps it was a default setting, or may be something really goofed up during the installation steps. But for sure, this was not a old-day's installation glitch, which could be resolved only by uninstallation and reinstallation.
IIS Manager for IIS 6.0 provides interfaces for allowing or prohibiting certain extensions related to dynamic content. You are allowed to allow/prohibit all ISAPI and CGI extensions on a server, but it's not a recommended practice to allow all ISAPI/CGI extensions to prevent the machine being suceptible to computer viruses or worms that use these technologies. So, as a good practice, allow only the required extensions.
You will find more information in the following URL http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a9fc0395-f03b-4213-9c62-1592bcfcf53f.mspx
Then we realized the new administrative control came with IIS 6.0. It allows you to enable/disable dynamic content. Referring back to my original problem, the extension ASP was set disabled through this control, perhaps it was a default setting, or may be something really goofed up during the installation steps. But for sure, this was not a old-day's installation glitch, which could be resolved only by uninstallation and reinstallation.
IIS Manager for IIS 6.0 provides interfaces for allowing or prohibiting certain extensions related to dynamic content. You are allowed to allow/prohibit all ISAPI and CGI extensions on a server, but it's not a recommended practice to allow all ISAPI/CGI extensions to prevent the machine being suceptible to computer viruses or worms that use these technologies. So, as a good practice, allow only the required extensions.
You will find more information in the following URL http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/a9fc0395-f03b-4213-9c62-1592bcfcf53f.mspx
Subscribe to:
Posts (Atom)