WS-*

SOA and the SO Design Tenets

2007-06-12T22:48:00.000+05:30

SOA is an architectural approach to creating systems built from autonomous services. With SOA, integration becomes forethought rather than afterthought - the end solution is likely to be composed of services developed in different programming languages, hosted on disparate platforms with a variety of security models and business processes. While this concept sounds incredibly complex it is not new – some may argue that SOA evolved out of the experiences associated with designing and developing distributed systems based on previously available technologies. Many of the concepts associated with SOA such as services, discovery and late binding were associated with CORBA and DCOM. Similarly, many service design principles have much in common with earlier OOA/OOD techniques based upon encapsulation, abstraction and clearly defined interfaces.

Read more...

.NET 3.5

2007-06-05T06:21:00.000+05:30

.NET 3.5 is a brand name for a set tools designed to enhance the use of the .NET 3.0 technologies. These include a visual design editor for WPF and WF, Visual Studio project and item templates for WCF, and integration between WCF and WF. In addition, .NET 3.5 includes new language features for both C# and VB.NET, such as extension methods, anonymous types, and query expression. Utilizing these new language features, .NET 3.5 supports Language-Integrated Query (LINQ) – which makes it possible to query objects (LINQ to Objects) and relational data such as XML (LINQ to XML); entities, datasets and SQL (LINQ to ADO.NET). Some of these language features are integrated back into Visual Studio in the form of data source designers and data binding. None of these language features are related to .NET 3.0 (WCF, WPF, WF, CardsSpace). Finally, .NET 3.5 contains framework and tools for ASP.NET AJAX.

Benchmarking with Apache Bench

2007-06-04T13:12:00.000+05:30

A nice article on the above topic : http://www.linux-mag.com/id/1361/. You need to register before accessing the above page & it's totally free.

Axis2, Middleware for Next Generation Web Services

2007-06-02T14:36:00.000+05:30

Published on : IEEE International Conference on Web Services (ICWS'06)- 2006

Abstract:

Axis2, the next generation of Apache Web Services middleware, is an effort to re-architecture Apache Web Service stack to incorporate the changes in Web Services.
Among many improvements, Axis2 provides first class Messaging and SOAP extension supports together with a novel lightweight streaming based XML processing Model. The architecture is build on top of a simple and extensible core that provides the basic abstractions for the rest of the system. We present the design and the thought process behind the key abstractions by breaking down the architecture in to three topics, XML Processing Model, Extensible SOAP processing model and Messaging Framework. This Paper explains the overall architecture while concentrating on the three topics, and demonstrate how they all fit together to yield Axis2.

Full text available at http://grids.ucs.indiana.edu/ptliupages/publications/axis2.pdf

Streaming API For XML [StAX]

2007-06-01T00:01:00.000+05:30

AXIOM stands for AXis Object Model (also known as OM - Object Model) and refers to the XML infoset model that was initially developed for Apache Axis2. XML infoset refers to the information included inside the XML and for programmatical manipulation it is convenient to have a representation of this XML infoset in a language specific manner.

Apache AXIOM is a StAX-based [jsr-173], XML Infoset compliant object model which supports on-demand building of the object tree. It supports a novel "pull-through" model which allows one to turn off the tree building and directly access the underlying pull event stream.

I am not going to duplicate anything here. An Introduction to StAX is a good place to start with, if you are interested in knowing more about StAX.

SOAP message serialization

2007-05-31T00:09:00.000+05:30

The serialization of SOAP calls can be logically seperated into four phases.

1. Traversing the data structures - to impart a corresponding structure to the SOAP XML.
2. Convert machine representation of data to ASCII.
3. Write ASCII to buffer.
4. Initiate network transmission.

It's being found from different researches that the performance of SOAP serialization techniques is not sufficient to scientific computing. SOAP serialization consumes 90% of end-to-end time for a SOAP RPC call. For high performance applications this bottleneck needs to be eliminated.

There have being discussions happening in this area. Differential Serialization and Client side caching are two options being researched. Both techniques are more or less the same. Idea behind the client side caching is to cache web service requests at the client side. So, identical requests need not to go through the message serialization process more than once.

Differential Serialization, has many options. It covers the previous scenario, under the Message Content Match - where two messages need to be identical by both the structure and the content.The other techniques suggested under Differential Serialization are, Perfect Structural Match, Partial Structural Match and First Time Send.

Both of these researches ended up with SOAP implemenatations. And both proved thier respective methods enhanced web service performance by several levels.

SOAP message serialization/deserialization

2007-05-30T15:41:00.000+05:30

A little bit about how web services work.

The following describes the sequence of events that occur when an XML Web service is called:

1. The client creates a new instance of an XML Web service proxy class. This object resides on the same computer as the client.

2. The client invokes a method on the proxy class.

3. The infrastructure on the client computer serializes the arguments of the XML Web service method into a SOAP message and sends it over the network to the XML Web service.

4. The infrastructure receives the SOAP message and deserializes the XML. It creates an instance of the class implementing the XML Web service and invokes the XML Web service method, passing in the deserialized XML as arguments.

5. The XML Web service method executes its code, eventually setting the return value and any out parameters.

6. The infrastructure on the Web server serializes the return value and out parameters into a SOAP message and sends it over the network back to the client.

7. The XML Web service infrastructure, on the client computer, receives the SOAP message, deserializes the XML into the return value and any out parameters, and passes them to the instance of the proxy class.

8. The client receives the return value and any out parameters.

As you carefully go through the above steps you'll notice that there is a huge bottleneck in SOAP message serialization/deserialization process. Also add the number of times this happens in a single web service operation.

Following explains how SOAP Extensions in .NET are used in the SOAP message serialization/deserialization process.

Client Side Prepares a Request Message

1. A client invokes a method on the proxy class.
2. A new instance of the SOAP extension is created on the client.
3. If this is the first time this SOAP extension has executed with this Web service on the client, then the GetInitializer method is invoked on the SOAP extension running on the client.
4. The Initialize method is invoked.
5. The ChainStream method is invoked.
6. The ProcessMessage method is invoked with SoapMessageStage set to BeforeSerialize.
[This is a place which can be used for client side caching]
7. ASP.NET on the client computer serializes the arguments of the Web service method into XML.
8. The ProcessMessage method is invoked with SoapMessageStage set to AfterSerialize.
9. ASP.NET on the client computer sends the SOAP message over the network to the Web server hosting the Web service.

Server Side Receives a Request Message and Prepares a Response

1. ASP.NET on the Web server receives the SOAP message.
2. A new instance of the SOAP extension is created on the Web server.
3. On the Web server, if this is the first time this SOAP extension has executed with this Web service on the server side, the GetInitializer method is invoked on the SOAP extension running on the server.
4. The Initialize method is invoked.
5. The ChainStream method is invoked.
6. The ProcessMessage method is invoked with SoapMessageStage set to BeforeDeserialize.
7. ASP.NET deserializes the arguments within the XML.
8. The ProcessMessage method is invoked with SoapMessageStage set to AfterDeserialize.
9. ASP.NET creates a new instance of the class implementing the Web service and invokes the Web service method, passing in the deserialized arguments. This object resides on the same computer as the Web server.
10.The Web service method executes its code, eventually setting the return value and any out parameters.
11.The ProcessMessage method is invoked with SoapMessageStage set to BeforeSerialize.
12.ASP.NET on the Web server serializes the return value and out parameters into XML.
13.The ProcessMessage method is invoked with SoapMessageStage set to AfterSerialize.
14.ASP.NET sends the SOAP response message over the network back to the Web service client.

Client Side Receives a Response Message

1. ASP.NET on the client computer receives the SOAP message.
2. The ProcessMessage method is invoked with SoapMessageStage set to BeforeDeserialize.
3. ASP.NET deserializes the XML into the return value and any out parameters.
4. The ProcessMessage method is invoked with SoapMessageStage set to AfterDeserialize.
5. ASP.NET passes the return value and any out parameters to the instance of the proxy class.
6. The client receives the return value and any out parameters.

A distributed system defined

2007-05-29T21:40:00.000+05:30

A little bit deviated from the major objective, but very much related.

A distributed system is a complex application designed to run on a network and such a system has multiple processes to do something. Network applications are different from distributed applications. The difference is, in a network application the autonomous computers are explicitly visible and have to be explicitly addressed. That is, you exactly know to which computer you talk to. In a distributed system the existence of multiple autonomous computers is transparent. At the same time a distributed system is spread-out and de-centralized.

Here I quote some of the well-known definitions on distributed systems.

“A system in which hardware and software components located at networked computers communicate and coordinate their actions only by message passing” - Coulouris

“A distributed system is a collection of independent computers that appear to the users of the computer as a single coherent system” – Tanenbaum

“A distributed system is one on which I cannot get any work done because some machine that I have never heard of has crashed” - Lamport

What is AXIS2?

2007-05-28T14:52:00.000+05:30

You wouldn't have come here without knowing the answer. Don't curse me, just for the completion, I'll add few words on this & will give more references - so, the people who are interested in knowing more can go in depth.

If you are new to web services or if this is the first time you hear about web services, please do a Google search to find out some introductory articles on web services. It's not surprising, everybody does not supposed to learn about web services - I've met a lot who have not heard about web services while conducting interviews.

So, please bare with me, I am not going to talk about web services from scratch here. But if you are new to AXIS2 and never used it before, this is the best place to start with.

Web services facilitate inter communication between applications written in different languages. A .NET application can talk to another Java application. In doing so XML is the primary means of communication. To put it in a better way, SOAP is the 'protocol' followed in constructing those XML message. To make it simpler, SOAP defines the schema for a message to be sent via web services. To construct & interpret SOAP messages, we need to have SOAP engine. AXIS2 is, such a SOAP engine - and sometime goes beyond the original definition of a SOAP engine.

AXIS2 enables it's users to carry out following tasks.

1. Send SOAP messages
2. Receive and process SOAP messages
3. Create a Web service out of a plain Java class
4. Create implementation classes for both server and client using WSDL
5. Easily retrieve the WSDL for a service
6. Send and receive SOAP messages with attachments
7. Create or utilize a REST-based Web service
8. Create or utilize services that take advantage of the WS-Security, WS-ReliableMessaging, WS-Addressing, WS-Coordination, and WS-Atomic Transaction recommendations
9. Use Axis2's modular structure to easily add support for new recommendations as they emerge.

Whole set of BUZZ words ah? Nothing to worry about, we'll go through each & every one of them in my future posts. To start with following is a nice tutorial to follow: http://people.apache.org/~thilina/axis2/docs/userguide.html