Microsoft come out with a new paper of comparing performance of WS in Microsoft platform and on IBM WebSphere.
MS comes out better (the purple bars graph) but then that is not surprising since this is an MS paper :-)

An interesting point is to see the comparison of different WCF configurations. Using NET-TCP gives almost double performance then using HTTP and self hosting http also gives a bit more then IIS hosted services.

Another significant point is that they calculated performance you get for what you pay for it and then MS solutions comes out the better deal by a few scales (the graph with the green bars).

More details in the spec here

I want to recommend you about a great article that was written by a friend of mine - Boaz Davidoff, about duplex web services.

He found a great way for multiple clients to communicate through web services that push events/messages to the client.

I will not get down on details here (this you can read on the article), but this is a great example of server-side multi-threading techniques.

I read some related stuff about this issue on the web and found that Microsoft covered this solution under the WCF environment, but my POC has proven that Boaz's solution is much more easier to understand (if you don't have the minimal knowledge on WCF) and to implement or customize to your own requirements.

So if you have a client application that requires real time information to be pushed from the server, or from other clients, this might be the ticket. 

The article is on the codeproject.com site here.

While search some interesting and innovating technological stuff on the web, I bumped into 2 articles regarding performance comparison between the classic .NET Remoting (published by Microsoft some years ago) and between WCF technology that ships as part of the .NET Framework 3.0.

The first one has being published by Marcin Celej that claims that: "Sending DataSet with .NET Remoting is faster (in any of cases I tested) than sending it with WCF".

On the other hand, MSDN published also a comparison article, and the evidences were other than the above ones: "When migrating distributed applications written with ... .NET Remoting to WCF, the performance is at least comparable to the other existing Microsoft distributed communication technologies ... WCF is ... approximately 25% faster than .NET Remoting".

Graphs and schemes were published to illustrate the great findings by each one of them.

I am a fan of Microsoft technologies - I admit it, but this issue sounds interesting and worth testing not? What do you think about it?

I have a problem (or used to have a problem...). In my working on web 2.0 startup, I bumped in a problem which in first thought looked to me as a simple one but after something like 5 seconds I figured out that it's actually a problem (or something to think about - I like this phrase much better ;)).

So after this introduction, lets introduce the 'something to think about' issue: I had to run each period of time a set of tasks in order to update some database statuses. If my web application was hosted on a dedicated server, this one had be solved very quickly; windows service - I guess you thought about it yourselves...

BUT, we are not going to host this web 2.0 application in a dedicated server (at least not now) and the scheduled task became a task itself, because (if you are web developers you'd better know) application is lives as long as there is at least one client that consumes it. When the last consumer is going home, also the application in going home to relax...

Now to the main question: how can we keep it alive?

After doing some thinking between me and myself, gathering up some good resolutions and not I thought about good one; in your web application create a web service that most of its job is to expose a KeepAlive web method that will return a dummy value and will keep the web application alive all the time and also will perform the tasks that you to establish for permanent period of time.

In your local PC, create a small desktop application in order to handle the tasks. This application will be a windows service that will run automatically under your machine every X interval and will ping the web service in order to keep the web application alive.

Note: the web service itself will know to execute the specific task itself every predefined period of time.

What about performance? This solution could affect your web application performance (I think that you know the reason why), in this case you can create another wen application that will be placed in the same server and all its job is to be kept alive and perform your tasks.

Any addition will be appreciated... I am going to write this web service now...

Hello and good week to all!

These days I am starting to publish here (in my blog ofcourse) a series of articles that discusses with Web Serivces and the most important issue - Security over Web Services (using Microsoft technology ofcourse), because it is quite simple to write a web service that receives/retrieves data and 'do you thing...', but the complexity comes when you want to secure this data that runs over non-secured protocols or web-lines.

This article assumes that you are familier with web services, its porpuse and its implementation and assimilations, if not, you should read some basic tutorials before you start to read this article. (You can fine general example here).

Introduction
WS-SecurityProtocol defines all web services expansion security topics. Its goal is to let you build and use SOAP messages exchange in secured way. This term is quite flexble and it designed in a specific way in order to constitute the base of building a secured Web Service by the different security models like: SSL, Kerberos, PKI.
WS-SecurityProtocol supplies a full support for large number of security tokens, trusted domains, signature formats and encryption technologies.

This component supplies 3 basic mechanisms: Message Confindentiality, Message Integrity, Security Token Propagation. These mechanisms, each one by it own, doesn't supplies perfect security solution, therefore in actual fact, WS-SecurityProtocol builds a block that uses a combination of all there mechanisms and different enhancements to supply a perfect sucurity solution

Main Facts
Before I start explaining and showing the protocol's structure, I want to stand on the basic definitions and terms this protocol is uses:

• Claim - the client's claim (like: name, identity, key, group, rights and more...)
• Security Token - represent a set of tokens.
• Signed Security Token - this is a claimed and encrypted by a specific authority (like: Kerberos ticket or X.509 certificate) security token.
• Proof-of-possession - information that used by a specific "proof process" in purpose to describe the sender data.
• Integrity - a process that comes to note that the sent data hasn't changed while sending the message.
• Confidentiality - a process that comes to ensure that the data is protected and just specific authorized 'players' are allowed to watch it.
• Digest - an encrypted sum of the data sent stream.
• Signature - this is an encrypted communication between the Proof-of-possession and the digest. This action creates a symetric key and public signatures.
• Attachment - this is the physical data that is transfered using the SOAP messages, but is not a part of the SOAP envelop.

We want to ensure that the SOAP message is encrypted properly to avoid dangers, like:

1. The message could be readen and be changed by malicious user.
2. Malicious user can send fake message through the Web Service and by that to get secret information.

Message Security Model

The WS-SecurityProtocol works under the Message Security Model, that comes to prevent such cases like mentioned above. Its behavior is:

The Security Token declares on Claims and Signatures, this mechanism supplies a proof to the knowledge of the sender (in simple words, the data that the sender holds). In addition, the Signature can bind itself with the Claims in the Security Token (in assumption the token is secured).

Claim can be supported (or not) by "secured authority", which is a set of claims, which encrypted or digitally signed by this authority is usually represented by Signed Security Tokens. An example to Signed Security Token set is X.509Certificate - which by this set of claims, the binding is executed between the client identity and the the public key.
Claim that is not supported by any "secured authority", can be secured only when the connection (binding) between the sender and the receiver is secured (secured line, like SSL etc...), for an example, they can agree on a specific message name that is accepted by both of them and by that only they will know that the message is meant for them (because they are both will look forward to get the same name).

Another type of non-secured claim (which is not supported by any "secured authority") called proof-of-possesion. As I descibed earlier, this term confirms that the user has "pieces" of knowledge that diagnosed by the other 'players' which related to it. For an example, lets take a look of username/password security token, the proof-of-possession here, combines another security token in order to confirm the sender's claim. I need to note here, that Digital integrity (see above if you already forgot) for a message can be used as a proof-of-possession, but in theis case it will not considered as a security token.

Message Protection

Another model that comes to prevent such cases as mentioned above (remember...?).
This model claims that all the messages that are being sent, supposed to be encrypted in order to not be negatively affected by hostile factors. The Integrity based message is supplied by leverage of an XML signature with security tokens, in order to notice that the messages has been sent with no data changes of bad influences. This mechanism supports many signatures and players.

A confidentiality (see above for a definition), based message, uses XML encryption with secutity tokens to ensure that the message's parts will be confidential.

In order to supply the the maximum security to the SOAP message, that we'll want to send, there is a need to build the XML file that includes all the filters and headers definitions.
The structure of the XML file includes the <Security> tag, which symbolizes the security definitions. Under this tag it is possible to define all the information about the message security issue.

An XML file cannot hold more that one security tag, this in purpose to allow that each tag (security XML) will taget to other destination. This tag and all its data under, represents the signature steps and the encryption type that the sender used with to send the message.

A typical WS-SecurityProtocol example:

Line 001 and 002, describes the SOAP envelope. Line 003 opens the headers definitions that describes the message. Line 004 to 008, describes the sending message type, the source and destination.

Line 009, open the Security's filters definitions. This label defines the security definitions that the receiver need to be up to (in order to watch the message ofcourse). This header label is closed in line 029.

Lines 010 to 012, describes the security token that message uses, here the usage is username token. (Here the assumption is that the password is well known by the service, and by that, only username is being sent).

Lines 013 to 028 defines the digital signature. By this example, the signature is based on the key that generated from the sender password. Lines 014 to 021, explains the digital signature. Line 015 defines how to normilize the sent information.

Lines 017 to 020, chooses the elements we want to signature. In this example (by line 017), we can see that the body is digitally signed (<s:Body> label, which you can see in line 031).

Line 022, holds tha signature value that derivated from the encrypted information. Lines 023 to 027, holds an information about the security token location, which combined with the signature. In more explicit, lines 024 - 025, defines that this token is located in a specific URL address.

Line 031 to 033 holds the message body.

That it for now. More tutorials at:

• http://www-128.ibm.com/developerworks/webservices/library/ws-secure/
• http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-securitypolicy.pdf

Comments will be appriciated...

Hi!

In this post, I will examine several different approaches to work properly against web services. I will explain the question (or problem, you can define it however you want) from the real life: You are working on an HR registration application and you want to register a new employee to the system, but the DB that holds all the employees details is located in remoted server. The actions that the application need to do are:

1. Check if the username is already exist in the repository of contents (first WS).
2. Register the user and save her details to the system DB (second WS).
3. Send a registration information to the user that all her details has been feed (third WS).

As we saw, every WS will do a single action, and the last 2 ones are dependent each other.

Now, the question that is being asked is how to handle those actions in exceptions cases, should I want to roll back or to complete the whole bunch of actions.

The approaches are:

1. Repeated requests handling: This way handles the situation that the request is already has been sent to the remote server (by web service ofcourse), and we will want to know if the request handling is over. The way is to attach transaction indetifier to the request. By that, if the server is still busy (while processing the resuest), it will send an appropriate message to the client (status ID). This solution comes to prevent duplicates mesaages requests to the server. One more thing... when implementing this sulotion, you need to consider and to support large number of transcactions (for further cases). By that, the client needs to know the ID of the transaction before sending the request to the server.
2. Two-Phase commit: Before I start speaking the solution, I will explain this term: The two-phase-commit protocol is a distributed algorithm which lets all nodes in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of network failures or node failures. Now, t he common approach, claims that algorithm is not "healthy" to use when working over web services, because if the web service is fails (or shuts down) in a middle of a transcation, there is a chance that the remote server won't know to send a message regarding the transaction state. The solution recommended here is to devide BIG transaction(s) to small transactions, when every small transaction will be handled by one web service. One more important thing is to plan properly the transactions flow, to prevent as much as minimum loss of data (if accured). I recommend to execute each action over one web service, and to call to a transaction manager web service that will be responsable to all the web services actions.
3. Queued Processing: This approach claims that as long as the request is OK (no exception has been received), we will assume that action has been completed properly. To implement this approach you need to create a requests' queue (the requests that we will want to execute). Now, if no exception has been received, the queue will continue executing the further ones. If an exception has been received, the mechanism will roll back the related requests.
4. Transaction Locking: When calling a web service (which is a part of a transaction), all its related resources will be locked in purpose not to allow other users to execute it. Real life example is withdrawaling cash from an ATM. When the user withdrawals the money from the machine, the transaction and his related data in the database is being locked, to prevent mismatch.

In summary, I spread here 4 different approaches to handle transactions over web services. I will be glad to have some comments if you have some.

Wellness untill next time, see you...