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...
Tuesday, June 12, 2007
Tuesday, June 5, 2007
.NET 3.5
.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.
Monday, June 4, 2007
Benchmarking with Apache Bench
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.
Saturday, June 2, 2007
Axis2, Middleware for Next Generation Web Services
Published on : IEEE International Conference on Web Services (ICWS'06)- 2006
Abstract:
Full text available at http://grids.ucs.indiana.edu/ptliupages/publications/axis2.pdf
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
Friday, June 1, 2007
Streaming API For XML [StAX]
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.
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.
Thursday, May 31, 2007
SOAP message serialization
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.
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.
Wednesday, May 30, 2007
SOAP message serialization/deserialization
A little bit about how web services work.
.png)
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.
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.
Subscribe to:
Posts (Atom)