//Create a Global Assembly
/*Publicly sharing functionality among different application.
*Located in Global Assembly Cache (GAC).
*Identified by globally unique name and version.
*Digital signature to ensure that it can't be tampered.
*Get smaller EXE files.
*Dynamic linking, i.e. loading on demand.
GENERATE KEY FILE: - THE STRONG NAME UTILITY (SN)
A tool is used to generate the key file incorporating a Public/Private Key pair.
We need this key pair to create a hash key for every file. The hash key is called
Public Key Token. This token allows the Common Language Runtime (CLR) to recognise
if a file has been tampered or overwritten. If the token doesn't match anymore the
file was modified.
By the time we pass the public/private key file, the private key is used to create
the public key token by encrypting the assembly name and content. The private key is
our secret and stays with us. The public key token is stored along with the public key
inside the Global Assembly's manifest. This process is called Signing the assembly.
The CLR needs the public key to decrypt the token to verify the file but not other way around.
Only with the private key we are able to create the token and nobody else can create it.
A hash token which encrypts the name and content along with the public key is called a Strong Name.
DotNet> sn -k app.snk
Version Control and Linking
The full version description consists of different parts, e.g.:
1:0:1504:18
1:0 Major and minor version
1504 Build
18 Revision
At the top of a source file we can define attributes for the key file and the version we state:
[assembly:AssemblyKeyFile("app.snk")]
[assembly:AssemblyVersion("1.0.0.0")]
While introducing the sample application we have seen how to compile our assembly to HowDoYouDo.dll.
We are now going to link the DLL with the Assembly Linker (AL) to a Global Assembly incorporating
the key file and version number:
________________
program: ga.cs
________________
using System.Reflection;
[assembly:AssemblyKeyFile("app.snk")]
[assembly:AssemblyVersion("1.0.0.1")]
public class test
{
public static void t1()
{
System.Console.WriteLine("global assembly");
}
}
Dotnet> csc /t:module /out:bin\ga.dll ga.cs
Dotnet> al /t:library /out:bin\myga.dll bin\ga.dll
[OR]
DotNet> al /t:library /keyfile:app.snk /v:1.0.0.0 /out:bin\myga.dll bin\ga.dll
Load into Assembly Cache - The Global Assembly Cache Utility (GACUTIL)
We load the Global Assembly into GAC by the use of the Global Assembly Cache Utility:
Dotnet>gacutil /i bin\myga.dll
Microsoft (R) .NET Global Assembly Cache Utility. Version 1.0.3705.0
Copyright (C) Microsoft Corporation 1998-2001. All rights reserved.
Assembly successfully added to the cache
The /i switch installs an assembly in the global assembly cache by passing the name.
It is also possible to simply copy the file directly into the GAC folder by the use of
Windows Explorer or by a command shell. Open Windows Explorer an go to C:\WINNT\assembly
and you will find the myga entry there.
Tuesday, December 16, 2008
Friday, December 12, 2008
Source Assembly
Assemblies:
• Collection of .dll/ .exe files are called as Assembly.
• Collection of class modules as a single .DLL file.
Module: A single .dll / .exe file
Library: Collection of dll files
Assemblies are loaded on demand.
Types: Private and Global Assembly
Just a Small discussion on Why Assemblies???????
if the programming logic is splitted into different logical units say dll's
and developed in different programming languages vb.net,c#.net,vj#.net,....
you are in need to develop an application which simple want to access many dll's at runtime.
Then every dll you have to refer at runtime. Instead if we first group the necessary dll's that we want
it is easy for us to just refer that single dll file. This process is called as Assembly creation.
PRIVATE ASSEMBLY
Location is specified at compile time and probably in current directory
Identified by name and version
GLOBAL ASSEMBLY
Location is specified at compile time and in GAC. C:/windows/assembly
Identified by globally unique name and version
// some of the command line options while creating assemblies
//*************************************************************
/* /t:module -----> target: is a module file (may be a single dll file)
/t:library -----> target: is a library file (collection of dll files)
/t:exe -----> target: is a executable file
/out:bin\pa.dll --> output: file name pa.dll created in bin directory
/r:bin\pa.dll --> reference: at run time pa.dll used as reference
al --> Assembly Linker
*/////////////////////////////////////////////////////////////////////////
TO DEMONSTRATE THE ASSEMBLY CONCEPT WE ARE TRYING TO CREATE THE FOLLOWING FILES AND
THE STEPS IN BRIEF:
1. Create a class1.vb file (vb.net file)
2. Create a class2.cs file (csharp file)
3. Compile class1.vb and create class1.dll
4. Compile class2.cs and create class2.dll
5. combine class1.dll,class2.dll and create pa.dll using utility al (private assembly)
6. create an application program app.cs (csharp file)
where we are calling
class1.method1
class2.method2
7. Test your app.cs and at runtime use pa.dll as reference
steps in detail: (create a directory in c:\windows\temp\) example==> asm.
***************
1. create a class1.vb file
Public Class class1
Public Shared Sub m1() ////////////////shared means static in vb.net
System.Console.WriteLine("vbmethod")
End Sub
End Class
2. create a class2.cs file
public class class2
{
public static void m2()
{
System.Console.WriteLine("csharp method");
}
}
3. Compile class1.vb and get class1.dll as follows:
******* CREATE A BIN DIRECTORY IN C:\WINDOWS\TEMP\ASM ***********
c:\windows\temp\asm> vbc /t:module /out:bin\class1.dll class1.vb
4. Compile class2.cs and get class2.dll as follows:
c:\windows\temp\asm> csc /t:module /out:bin\class2.dll class2.cs
5. Combile two dll files and create a private assembly named pa.dll
c:\windows\temp\asm> al /t:library /out:bin\pa.dll bin\class1.dll bin\class2.dll
6. Create an application to access your private assembly (app.cs)
class test
{
public static void Main()
{
System.Console.WriteLine("Application Main");
class1.m1(); //static members can be directly accessed by class name
class2.m2(); //.....................................................
}
}
7. To compile your app.cs use pa.dll as your reference
c:\windows\temp\asm>csc /t:exe bin\pa.dll /out:bin\app.exe app.cs
8. Now your app.exe is ready in bin directory
9. you can run simply typing app at
c:\windows\temp\asm\bin> app
10. thus we have created a private assembly successfully and accessed.
Suppose if you didnt create an assembly then you have to do the following:::
>>>>>>> csc /t:exe /out:bin\app.exe /addmodule:bin\class1.dll /addmodule:bin\class2.dll app.cs
Here, you have to add all the modules individually .. which is not advisable if u have huge dll's to refer.
• Collection of .dll/ .exe files are called as Assembly.
• Collection of class modules as a single .DLL file.
Module: A single .dll / .exe file
Library: Collection of dll files
Assemblies are loaded on demand.
Types: Private and Global Assembly
Just a Small discussion on Why Assemblies???????
if the programming logic is splitted into different logical units say dll's
and developed in different programming languages vb.net,c#.net,vj#.net,....
you are in need to develop an application which simple want to access many dll's at runtime.
Then every dll you have to refer at runtime. Instead if we first group the necessary dll's that we want
it is easy for us to just refer that single dll file. This process is called as Assembly creation.
PRIVATE ASSEMBLY
Location is specified at compile time and probably in current directory
Identified by name and version
GLOBAL ASSEMBLY
Location is specified at compile time and in GAC. C:/windows/assembly
Identified by globally unique name and version
// some of the command line options while creating assemblies
//*************************************************************
/* /t:module -----> target: is a module file (may be a single dll file)
/t:library -----> target: is a library file (collection of dll files)
/t:exe -----> target: is a executable file
/out:bin\pa.dll --> output: file name pa.dll created in bin directory
/r:bin\pa.dll --> reference: at run time pa.dll used as reference
al --> Assembly Linker
*/////////////////////////////////////////////////////////////////////////
TO DEMONSTRATE THE ASSEMBLY CONCEPT WE ARE TRYING TO CREATE THE FOLLOWING FILES AND
THE STEPS IN BRIEF:
1. Create a class1.vb file (vb.net file)
2. Create a class2.cs file (csharp file)
3. Compile class1.vb and create class1.dll
4. Compile class2.cs and create class2.dll
5. combine class1.dll,class2.dll and create pa.dll using utility al (private assembly)
6. create an application program app.cs (csharp file)
where we are calling
class1.method1
class2.method2
7. Test your app.cs and at runtime use pa.dll as reference
steps in detail: (create a directory in c:\windows\temp\) example==> asm.
***************
1. create a class1.vb file
Public Class class1
Public Shared Sub m1() ////////////////shared means static in vb.net
System.Console.WriteLine("vbmethod")
End Sub
End Class
2. create a class2.cs file
public class class2
{
public static void m2()
{
System.Console.WriteLine("csharp method");
}
}
3. Compile class1.vb and get class1.dll as follows:
******* CREATE A BIN DIRECTORY IN C:\WINDOWS\TEMP\ASM ***********
c:\windows\temp\asm> vbc /t:module /out:bin\class1.dll class1.vb
4. Compile class2.cs and get class2.dll as follows:
c:\windows\temp\asm> csc /t:module /out:bin\class2.dll class2.cs
5. Combile two dll files and create a private assembly named pa.dll
c:\windows\temp\asm> al /t:library /out:bin\pa.dll bin\class1.dll bin\class2.dll
6. Create an application to access your private assembly (app.cs)
class test
{
public static void Main()
{
System.Console.WriteLine("Application Main");
class1.m1(); //static members can be directly accessed by class name
class2.m2(); //.....................................................
}
}
7. To compile your app.cs use pa.dll as your reference
c:\windows\temp\asm>csc /t:exe bin\pa.dll /out:bin\app.exe app.cs
8. Now your app.exe is ready in bin directory
9. you can run simply typing app at
c:\windows\temp\asm\bin> app
10. thus we have created a private assembly successfully and accessed.
Suppose if you didnt create an assembly then you have to do the following:::
>>>>>>> csc /t:exe /out:bin\app.exe /addmodule:bin\class1.dll /addmodule:bin\class2.dll app.cs
Here, you have to add all the modules individually .. which is not advisable if u have huge dll's to refer.
Wednesday, December 10, 2008
Assemblies
Assembly: Collection of .dll/ .exe files are called as Assembly
you can also say collection of modules as an Assembly.
Module: A single .dll / .exe file
Library: Collection of .dll/ .exe
we discussed that .net overcome the 'dll hell' problem through versioning and signature. Also provides Language Integration.
Assume that we split the program into different logical units say modules developed in different .NET languages C#,VB,VJ#,MC++,Perl.NET,Python.NET,........At runtime how to combine all modules for a particular application.
vb c# vj# PERL.NET Python.NET... SOURCE
| | | | |
.dll.dll.dll .dll .dll ... MODULE
|___|____|______|_________|
|
|
.DLL .. LIBRARY
(ASSEMBLY)
you can also say collection of modules as an Assembly.
Module: A single .dll / .exe file
Library: Collection of .dll/ .exe
we discussed that .net overcome the 'dll hell' problem through versioning and signature. Also provides Language Integration.
Assume that we split the program into different logical units say modules developed in different .NET languages C#,VB,VJ#,MC++,Perl.NET,Python.NET,........At runtime how to combine all modules for a particular application.
vb c# vj# PERL.NET Python.NET... SOURCE
| | | | |
.dll.dll.dll .dll .dll ... MODULE
|___|____|______|_________|
|
|
.DLL .. LIBRARY
(ASSEMBLY)
hello world
Well done, we had a discussion of the architecture of .NET framework,common language runtime and its building blocks, important namespaces in Framework Class Libraries.
Let me discuss to create simple programs to demonstrate the basics of console,windows,web applications & web services.
Program 1: hello.cs
using System;
class test
{
public static void Main()
{
Console.WriteLine("firs console app");
}
}
.net prompt>> csc hello.cs ---------> which creates hello.exe --> is IL file.
to run... >> hello
to view.. >> ildasm hello.exe ------> This shows the contents of meta-data
Program 2: Multiple source files: hello.cs and app.cs
hello.cs
using System.Windows.Forms;
class test
{
public void m1()
{
MessageBox.Show("Windows Application");}}
app.csusing System;
class app
{
public static void Main()
{
Console.WriteLine("Console Application");
test t = new test(); //object of previous program
t.m1(); //call method of class test
}
}
To compile:>>>> csc *.cs --------> will create app.exe
Program 3: Create a Simple Web application
sample.aspx
-------------------------------> default page language VB.NET
<% response.write("First web app..") %> ---> Store in c:/inetpub/wwwroot (IIS)
-----------------------------> Run in Browser.http://localhost/sample.aspx
Program 4: Create a Simple Web Service
firstws.asmx-------------->Store in c:/inetpub/wwwroot (IIS)
<% @ WebService Language="c#" class="abc" %>--> Test in Browser
using System.Web.Services;
public class abc
{
[WebMethod]
public string m1()
{
return "hello First webservice...";
}
}
http://localhost/firstws.asmx
Hope you got some basic idea about how to create simple programs under .NET.
Let me discuss to create simple programs to demonstrate the basics of console,windows,web applications & web services.
Program 1: hello.cs
using System;
class test
{
public static void Main()
{
Console.WriteLine("firs console app");
}
}
.net prompt>> csc hello.cs ---------> which creates hello.exe --> is IL file.
to run... >> hello
to view.. >> ildasm hello.exe ------> This shows the contents of meta-data
Program 2: Multiple source files: hello.cs and app.cs
hello.cs
using System.Windows.Forms;
class test
{
public void m1()
{
MessageBox.Show("Windows Application");}}
app.csusing System;
class app
{
public static void Main()
{
Console.WriteLine("Console Application");
test t = new test(); //object of previous program
t.m1(); //call method of class test
}
}
To compile:>>>> csc *.cs --------> will create app.exe
Program 3: Create a Simple Web application
sample.aspx
-------------------------------> default page language VB.NET
<% response.write("First web app..") %> ---> Store in c:/inetpub/wwwroot (IIS)
-----------------------------> Run in Browser.http://localhost/sample.aspx
Program 4: Create a Simple Web Service
firstws.asmx-------------->Store in c:/inetpub/wwwroot (IIS)
<% @ WebService Language="c#" class="abc" %>--> Test in Browser
using System.Web.Services;
public class abc
{
[WebMethod]
public string m1()
{
return "hello First webservice...";
}
}
http://localhost/firstws.asmx
Hope you got some basic idea about how to create simple programs under .NET.
Monday, December 8, 2008
DOT NET FRAMEWORK
Open Source .NET Distributions:
http://www.mono-project.com [ Linux SUSE, Fedora, MAC OS]
http://www.dotgnu.org [ Win 32, AIX, BeOS, MAC, Solaris, Linux,…]
Microsoft .NET can be considered from different points of view. As a platform, it consists of the following product groups.
1. Development Tools set of languages (>20 languages under one engine CLR)
2. .NET Enterprise Servers(for B2B BizTalk,SQLServer, ExchangeServer...)
3. Web Services (.NET Myservices,Passport,Alerts,...)
4. .NET for devices(Windows ME,Windows CE, Windows Embedded,...)
.NET Framework:
A platform for building, deploying and running web services and applications. Highly productive, standards-based, multi language environment.
Design Goals of .NET framework:
1. Component Infrastructure
2. Language Integration
3. Internet interoperation
4. Simple Development
5. Simple Deployment
6. Reliability
7. Security
1- All classes are ready to be reused at the binary level, similar way to plug-and-play the hardware components.
2- One can’t reuse the COM components written by someone else; you can’t extend a class hosted in the COM component; you can’t catch exception thrown by code in the COM component. Through .NET CTS you can achieve inherit from classes, catch exceptions and take advantage of polymorphism across different languages. These different languages can intermingle with one another.
3- Simple, lightweight protocol for distributed computing. (SOAP=xml+http)
4- .NET provides set of framework classes and lets every language use it. Removes the need of learning a new API each time you switch languages.
5- Overcome DLL hell problem : {Stop working of an application if you update a software, it overwrites the old dll.}If you have two versions of dll, both called abc.dll both of them can live and execute on the same system without causing Dll hell.
6- Exception handling work across all .NET compatible languages. Autmatic Garbage Collection for objects that are no longer needed.
7- Protect access to specific parts of executable code, write code in your method to explicitly cause a security check. Make harder to penetrate your applications and system.
Common Language Runtime:
CLR is a unified environment for all of the languages available for .NET. There is no difference if you write code in VB.NET, C#.NET or Perl.NET – your code will still be run in the same environment and have access to the common subset of classes. We can even mix and match code in different programming languages, including full multilingual object-oriented features, such as inheriting objects, created in one language from the code, written in other language. All of this is made available by Common Language Runtime.
.NET Framework Class Library:
The .NET Framework includes classes, interfaces, and value types that are used in the development process and provide access to system functionality. To facilitate interoperability between languages, the .NET Framework types are Common Language Specification (CLS) compliant and can therefore be used from any programming language where the compiler conforms to the CLS.
The .NET Framework types are the foundation on which .NET applications, components, and controls are built. The .NET Framework includes types that perform the following functions:
• represent base data types and exceptions;
• encapsulate data structures;
• perform I/O operations;
• access information about loaded types via reflections;
• invoke .NET Framework security checks;
• provide data access, rich client-side GUI, and server-controlled, client-side GUI.
http://www.mono-project.com [ Linux SUSE, Fedora, MAC OS]
http://www.dotgnu.org [ Win 32, AIX, BeOS, MAC, Solaris, Linux,…]
Microsoft .NET can be considered from different points of view. As a platform, it consists of the following product groups.
1. Development Tools set of languages (>20 languages under one engine CLR)
2. .NET Enterprise Servers(for B2B BizTalk,SQLServer, ExchangeServer...)
3. Web Services (.NET Myservices,Passport,Alerts,...)
4. .NET for devices(Windows ME,Windows CE, Windows Embedded,...)
.NET Framework:
A platform for building, deploying and running web services and applications. Highly productive, standards-based, multi language environment.
Design Goals of .NET framework:
1. Component Infrastructure
2. Language Integration
3. Internet interoperation
4. Simple Development
5. Simple Deployment
6. Reliability
7. Security
1- All classes are ready to be reused at the binary level, similar way to plug-and-play the hardware components.
2- One can’t reuse the COM components written by someone else; you can’t extend a class hosted in the COM component; you can’t catch exception thrown by code in the COM component. Through .NET CTS you can achieve inherit from classes, catch exceptions and take advantage of polymorphism across different languages. These different languages can intermingle with one another.
3- Simple, lightweight protocol for distributed computing. (SOAP=xml+http)
4- .NET provides set of framework classes and lets every language use it. Removes the need of learning a new API each time you switch languages.
5- Overcome DLL hell problem : {Stop working of an application if you update a software, it overwrites the old dll.}If you have two versions of dll, both called abc.dll both of them can live and execute on the same system without causing Dll hell.
6- Exception handling work across all .NET compatible languages. Autmatic Garbage Collection for objects that are no longer needed.
7- Protect access to specific parts of executable code, write code in your method to explicitly cause a security check. Make harder to penetrate your applications and system.
Common Language Runtime:
CLR is a unified environment for all of the languages available for .NET. There is no difference if you write code in VB.NET, C#.NET or Perl.NET – your code will still be run in the same environment and have access to the common subset of classes. We can even mix and match code in different programming languages, including full multilingual object-oriented features, such as inheriting objects, created in one language from the code, written in other language. All of this is made available by Common Language Runtime.
.NET Framework Class Library:
The .NET Framework includes classes, interfaces, and value types that are used in the development process and provide access to system functionality. To facilitate interoperability between languages, the .NET Framework types are Common Language Specification (CLS) compliant and can therefore be used from any programming language where the compiler conforms to the CLS.
The .NET Framework types are the foundation on which .NET applications, components, and controls are built. The .NET Framework includes types that perform the following functions:
• represent base data types and exceptions;
• encapsulate data structures;
• perform I/O operations;
• access information about loaded types via reflections;
• invoke .NET Framework security checks;
• provide data access, rich client-side GUI, and server-controlled, client-side GUI.
Wednesday, December 3, 2008
SOA Service Oriented Architecture
Web Service Architecture in Realization of the following SOA Architecture:
<--Web Service Triangle: Bind-Publish-Find
Business Activities Outsourcing-->
Service Oriented Architecture:
SOA has emerged as a direct consequence of specific business and technology drivers that have materialized over the past decade. From the business side, major trends such as the outsourcing of noncore operations and the importance of business process reengineering have been key influences driving the surfacing of SOA as an important architectural approach to business information technology (IT) today. From the technology side, the past 15 years have resulted in a realization of the importance of middleware standards and architectures, learning in particular from the successes and failures of distributed object systems and message-oriented middleware.
As an architectural concept, SOA permits multiple approaches for the realization and deployment of an IT system that has been designed and built around its principles. This book focuses on a specific technology that, arguably, has the most significant commercial visibility and traction, and that is Web services. Web services technology is a standards-based, XML-centric realization of an SOA
Business Process Optimization
· The execution of each step or activity within a business process is associated with certain costs, such as people costs that are associated with the activity if human intervention is required, or the cost of computer resources that are required to execute activities within the IT environment. Based on this information, a company can derive the overall cost for performing a business process. For example, if policy associated with a credit allocation process determines that someone must check credits with an amount greater than $1,000, and more customers are asking for credits above this limit, a business could change the policy to set manual intervention at a higher value to reduce the overall costs for running the process.
· Activities have temporal characteristics, such as the average duration for executing an activity or the average time elapsed until an activity is picked up and performed. Based on this information, you can derive the average interval for executing a business process. For example, when you are booking a business trip, you can reserve hotel and flight reservations in parallel, resulting in a shorter execution time for the overall business process relative to its sequential execution.
Collaborations, Mergers, and Acquisitions
The company determines that it is no longer competitive in performing activities A, B, and E. It finds two partners that can run these activities and meet the business goals. Partner 1 runs activities A and B, and Partner 2 runs activity E. The company re-engineered the original process into a new process (P'). In the new process, activity AB kicks off the execution at the first partner (Partner 1), and E' starts the execution at the second partner (Partner 2). The company now has a new process P', which results in increased competitiveness.
The basic principles that underpin SOA are illustrated as follows:
First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them.
Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.
High level Architecture of SOA
The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester's experience with the service is concerned.
Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.
WEB SERVICES:
"Service-Oriented Architectures," SOA represents an abstract architectural concept. It's an approach to building software systems that is based on loosely coupled components (services) that have been described in a uniform way and that can be discovered and composed. Web services represents one important approach to realizing an SOA.
The World Wide Web Consortium (W3C), which has managed the evolution of the SOAP and WSDL specifications, defines Web services as follows:
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
Although Web services technology is not the only approach to realizing an SOA, it is one that the IT industry as a whole has enthusiastically embraced. With Web services, the industry is addressing yet again the fundamental challenge that distributed computing has provided for some considerable time: to provide a uniform way of describing components or services within a network, locating them, and accessing them. The difference between the Web services approach and traditional approaches (for example, distributed object technologies such as the Object Management Group Common Object Request Broker Architecture (OMG CORBA), or Microsoft Distributed Component Object Model (DCOM)) lies in the loose coupling aspects of the architecture. Instead of building applications that result in tightly integrated collections of objects or components, which are well known and understood at development time, the whole approach is much more dynamic and adaptable to change. Another key difference is that through Web services, the IT industry is tackling the problems using technology and specifications that are being developed in an open way, utilizing industry partnerships and broad consortia such as W3C and the Organization for the Advancement of Structured Information Standards (OASIS), and based on standards and technology that are the foundation of the Internet.
Web services had its beginnings in mid to late 2000 with the introduction of the first version of XML messagingSOAP, WSDL 1.1, and an initial version of UDDI as a service registry. This basic set of standards has begun to provide an accepted industry-wide basis for interoperability among software components (Web services) that is independent of network location, in addition to specific implementation details of both the services and their supporting deployment infrastructure. Several key software vendors have provided these implementations, which have already been widely used to address some important business problems.
Although the value of Web services technology has been demonstrated in practice, there is a desire to use the approach to address more difficult problems. Developers are looking for enhancements that raise the level and scope of interoperability beyond the basic message exchange, requiring support for interoperation of higher-level infrastructure services. Most commercial applications today are built assuming a specific programming model. They are deployed on platforms (operating systems and middleware) that provide infrastructure services in support of that programming model, hiding complexity, and simplifying the problems that the solution developer has to deal with. For example, middleware typically provides support for transactions, security, or reliable exchange of messages (such as guaranteed, once-only delivery). On the other hand, there is no universally agreed standard middleware, which makes it difficult to construct applications from components that are built using different programming models (such as Microsoft COM, OMG CORBA, or Java 2 Platform, Enterprise Edition (J2EE) Enterprise Java Beans). They bring with them different assumptions about infrastructure services that are required, such as transactions and security. As a consequence, interoperability across distributed heterogeneous platforms (such as .NET and J2EE) presents a difficult problem.
Transport Services
Web services is basically an interoperable messaging architecture, and message transport technologies form the foundation of this architecture. Web services is inherently transport neutral. Although you can transport Web services messages by using the ubiquitous Web protocols such as HyperText Transport Protocol (HTTP) or Secure HTTP (HTTPS) to give the widest possible coverage in terms of support for the protocols , you can also transport them over any communications protocol, using proprietary ones if appropriate. Although transport protocols are fundamental to Web services and clearly are a defining factor in the scope of interoperability, the details are generally hidden from the design of Web services
Messaging:
The messaging services component of the framework contains the most fundamental Web services specifications and technologies, including eXtensible Markup Language (XML), SOAP, and WS-Addressing. Collectively, these specifications form the basis of interoperable messaging between Web services.
2.1 SOAP
SOAP, one of the significant underpinnings of Web services, provides a simple and relatively lightweight mechanism for exchanging structured and typed information between services. SOAP is designed to reduce the cost and complexity of integrating applications that are built on different platforms. SOAP has undergone revisions since its introduction, and the W3C has standardized the most recent version, SOAP 1.2. SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. SOAP messages are transmitted one way from sender to receiver. However, multiple one-way messages can be combined into more sophisticated message exchange patterns. For instance, a popular pattern is a synchronous request/response pair of messages. Messages can be routed based on the content of the headers and the data inside the message body. You can use tools developed for the XML data model to inspect and construct complete messages. Note that such benefits were not available in architectures such as DCOM, CORBA, and Java Remote Method Invocation (RMI), where protocol headers were infrastructural details that were opaque to the application. Any software agent that sends or receives messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and the ultimate receiver is called an intermediary. Intermediaries model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.
To allow parts of the message path to be identified, each node participates in one or more roles. The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node, other than the sender, belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays, which is typically the application, or in some cases, infrastructure that is performing work on behalf of the application. The body of a SOAP envelope is always targeted at the UltimateReceiver. In contrast, SOAP headers might be targeted at intermediaries or the UltimateReceiver
2.2 WS-Addressing
WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with message exchange. WS-Addressing decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web service message. This specification defines XML elements to identify Web services endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing defines two interoperable constructs that convey information that transport protocols and messaging systems typically provide. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. These two constructs are endpoint references and message information headers.
Description
Service description defines metadata that fully describes the characteristics of services that are deployed on a network. This metadata is important, and it is fundamental to achieving the loose coupling that is associated with an SOA. It provides an abstract definition of the information that is necessary to deploy and interact with a service.
3.1. WSDL
Web Services Description Language (WSDL) is perhaps the most mature of metadata describing Web services. It allows developers to describe the "functional" characteristics of a Web servicewhat actions or functions the service performs in terms of the messages it receives and sends. WSDL offers a standard, language-agnostic view of services it offers to clients. It also provides noninvasive future-proofing for existing applications and services and allows interoperability across the various programming paradigms, including CORBA, J2EE, and .NET.
WSDL is an XML format for describing (network) services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL document has two parts: abstract definitions and concrete descriptions. The abstract section defines SOAP messages in a language- and platform-independent manner. In contrast, the concrete descriptions define site-specific matters such as serialization.
3.2 Policy
As businesses depend more on technology, their ability to control access to resources and enforce their administrative policies become central requirements. In a dynamic distributed environment, this includes the need to manage and distribute these policies only to authorized entities. Recently, government regulations have increased businesses' responsibility to protect consumer information from being distributed to third parties without the individual's consent. This new privacy legislation adds to the existing set of business requirements and introduces access to customer data (and metadata) as part of the information that is critical to the day-to-day management of the business.
In a service-oriented environment, service policies have a fundamental impact on interoperability. It's important to communicate to potential requesters any policies that a service provider enforces when those policies impact the interaction either because they require requesters to follow a specific behavior or a protocol or because they imply service-side behavior that impacts requester requirements or expectations (such as following a particular privacy policy). Service policies become a critical part of service descriptions, augmenting the basic WSDL functional description with a statement of nonfunctional service behaviors. As such, Web service policies support the development of service applications and provide the means to perform both development time and runtime service discovery and selection based on nonfunctional capabilities. For example, a service can be selected from among a list of functionally equivalent services based on its support for a specific privacy policy or the security guarantees it provides.
The first set of Web Services Policy documents [WS-Policy, WS-PolicyAttachment, and WS-PolicyAssertions] was published in 2002.
Discovery Services
The transport, description, and messaging layer are fundamental to allowing Web services to communicate in an interoperable way using messages. However, to facilitate this, it is necessary to collect and store the important metadata that describes these services. The metadata must be in a form that is discoverable and searchable by users who are looking for appropriate services they require to solve some particular business problem. Also, such metadata aggregation and discovery services are a useful repository/registry in which many different organizations might want to publish the services that they host, describe the interfaces to their services, and enable domain-specific taxonomies of services.
4.1. UDDI
The Universal Description and Discovery Interface (UDDI) is a widely acknowledged specification of a Web service registry. It defines a metadata aggregation service and specifies protocols for querying and updating a common repository of Web services information. Solutions developers can query UDDI repositories at well-known locations at design time to ascertain those services that might be compatible with their requirements. After they locate a directory, they can send a series of query requests against the registry to acquire detailed information about Web services (such as who provides them and where they are hosted) and bindings to the implementation. They can then feed this information into an assortment of development time tools to generate the appropriate runtime software and messages required to invoke the required service. Solutions can also query UDDI repositories dynamically at runtime. In this scenario, the software that needs to use a service is told at execution time the type of service or interface it requires. Then it searches a UDDI repository for a service that meets its functional requirements, or a well-known partner provides it. The software then uses this information to dynamically access the service.
UDDI repositories can be provided in one of three ways:
· Public UDDI These are UDDI repositories that can serve as a resource for Internet-based Web services. An example of this is the UDDI Business Registry [UBR]hosted by a group of vendors led by IBM, Microsoft, and SAPthat is replicated across multiple hosting organizations.
· Intra Enterprise UDDI An enterprise has a private internal UDDI repository that provides much more control over which service descriptions are allowed to be placed there and used by application developers within that specific enterprise.
· Inter Enterprise UDDI This basically scopes the content of the UDDI to services that are shareable between specific business partners.
4.2. MetaData Exchange
WS-Policy proposes a framework that extends the service description features that WSDL provides. Having more refined service descriptions, qualified by specific WS-policies, supports much more accurate discovery of services that are compatible with the business application that is to be deployed. In a service registry (such as a UDDI registry), queries of WS-Policy-decorated services enable the retrieval of services that support appropriate policies in addition to the required business interface. For example, a query might request all services that support the creditAuthorization WSDL interface (port type), use Kerberos for authentication, and have an explicitly stated privacy policy. This allows a service requester to select a service provider based on the quality of the interaction that delivers its business contracts.
Although service registries are important components of some Web services environments, it is often necessary to address the request of service information directly to the service itself. The WS-MetaDataExchange specification defines protocols that support the dynamic exchange of WS-Policy and other metadata that is relevant to the service interaction (such as XML Schema and WSDL descriptions) between interacting Web services endpoints. WS-MetadataExchange allows a service requester to ask a service provider directly for all or part of its metadata, without the involvement of a third-party registry. Using the WS-MetadataExchange protocol service, endpoints can exchange policies at runtime and use them to bootstrap their interaction from information about the settings and protocols to be applied. This is especially useful when not all policy information is in a repository or when a requester receives a reference to a service through some mechanism other than a direct query on a registry. This direct dynamic exchange of policies also supports the customization of each interaction based, for example, on the identity of the other endpoint or any other aspect of the context under which the interaction takes place. This flexibility allows Web services to be designed to offer different qualities of service for different targeted audiences.
Quality of Service
Specifications in this domain are related to the quality of the experience associated with interaction with a Web service. The services in this layer specify the requirements that are associated with the overall reliability of Web services. The specific issues involving this layer include security, reliability of message delivery, and support for transactions (guaranteeing and agreeing on the outcome of a business application).
5.1. WS-Security
Security is of fundamental concern in enterprise computing. WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport-level support for security functions (for example, HTTPS and BASIC-Auth authentication). These approaches to security provide a basic minimum for secure communication, and the level of function they provide is significantly less than that provided by existing middleware and distributed environments. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multihop, multiparty Web service computations cannot be secure without WS-Security.
Security relies on predefined trust relationships. Kerberos works because participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. WS-Trust defines an extensible model for setting up and verifying trust relationships. The key concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges, and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they trust, and to rely on these servers.
Some Web service scenarios involve a short sporadic exchange of a few messages. WS-Security readily supports this model. Other scenarios involve long, multimessage conversations between the Web services. WS-Security also supports this model, but the solution is not optimal.
Protocols such as HTTP/S use public keys to perform a simple negotiation that defines conversation-specific keys. This key exchange allows more efficient security implementations and decreases the amount of information encrypted with a specific set of keys. WS-SecureConversation provides similar support for WS-Security. Participants often use WS-Security with public keys to start a conversation or session, and they use WS-SecureConversation to agree on session specific keys for signing and encrypting information.
WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline, and a hotel chain might set up such a federation. An end user who logs into any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies. In addition, customers often have "properties" when they deal with an enterprise, and WS-Federation allows the setting up of a federated property space. This allows each participant to have secure controlled access to each member's property information about the end users.
5.2. Reliable Messaging
In the Internet world, communication channels are typically unreliable. Connections break, messages fail to be delivered or are delivered more than once, and perhaps in a different sequence to that in which they were sent. Communication can become even more of an issue when the exchange of messages spans multiple transport layer connections. Although techniques for ensuring reliable delivery of messages are reasonably well understood and available in some messaging middleware products today (such as IBM WebsphereMQ), messaging reliability is still a problem. If messaging reliability is addressed by Web service developers who are incorporating techniques to deal with this directly into the services they develop, there is no guarantee that developers of different Web services will make the consistent choices about the approach to adopt. The outcome might not guarantee end-to-end reliable interoperable messaging. Even in cases in which the application developers defer dealing with the reliable messaging to messaging middleware, different middleware products from different suppliers do not necessarily offer a consistent approach to dealing with the problem. Again, this might preclude reliable message exchange between applications that are using different message-oriented middleware.
WS-ReliableMessaging addresses these issues and defines protocols that enable Web services to ensure reliable, interoperable exchange of messages with specified delivery assurances. The specification defines three basic assurances:
· In-order delivery The messages are delivered in the same order in which they were sent.
· At least once delivery Each message that is sent is delivered at least one time.
· At most once delivery No duplicate messages are delivered.
5.3. Transactions
Dealing with many of today's business scenarios necessitates the development of applications that consist of multiple Web services exchanging many messages. An example might be a group of financial institutions setting up a financial offering that involves insurance policies, annuities, checking accounts, and brokerage accounts. Such applications can be complex, executing across heterogeneous, loosely coupled distributed systems that are prone to failure, and introducing significant reliability problems. For such applications, you must deal with the failure of any component Web service of the application within the context of the whole application. A coordinated orchestration of the outcome of the participating services that make up the business application is essential so that a coherent outcome of the whole business application can be agreed upon and guaranteed. Therefore, it is important that the Web services involved are able to do the following:
· Start new tasks, the execution and disposition of which are coordinated with other tasks.
· Agree on the outcome of the computation. For example, does everyone agree that the financial packages were set up?
WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are designed specifically to address these requirements.
WS-Coordination is a general mechanism for initiating and agreeing on the outcome of multiparty, multimessage Web service tasks. WS-Coordination has three key elements:
· A coordination context This is a message element that is associated with exchanges during the interaction of Web services. This coordination context contains the WS-Addressing endpoint reference of a coordination service, in addition to the information that identifies the specific task being coordinated.
· A coordinator service This provides a service to start a coordinated task, terminate a coordinated task, allow participants to register in a task, and produce a coordination context that is part of all messages exchanged within a group of participants.
· An interface Participating services can use the interface to inform them of an outcome that all of the participants have agreed upon.
WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to implement the traditional two-phase atomic ACID transaction protocols. However, traditional atomic transactions and the WS-AtomicTransaction protocol are not always suitable. For example, this protocol is generally not appropriate for use with many types of business transactions.
Transaction protocols for business transactions have to deal with long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Therefore, to minimize latency of access by other potential users of the resources being used by Web services participating in the activity, you need to make the results of interim operations visible to others before the overall activity has completed. In light of this, you can introduce mechanisms for fault and compensation handling to reverse the effects of tasks that were completed previously within a business activity (such as compensation or reconciliation). WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model to provide such long-running, compensation-based transaction protocols. For example, although WS-BPEL defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This, again, is an example for the composeability of the Web services specifications.
Components
The existing Web services standards do not provide for the definition of the business semantics of Web services. Today's Web services are isolated and opaque. Overcoming this isolation means connecting Web services and specifying how to jointly use collections (compositions) of Web services to realize much more comprehensive and complex functionalitytypically referred to as a business process. A business process specifies the potential execution order of operations from a collection of Web services, the data that is shared between these composed Web services, which partners are involved, and how they are involved in the business process, joint exception handling for collections of Web services, and so on. This composition especially allows the specification of long-running transactions between composed Web services. Consistency and reliability are increased for Web services applications. Breaking this opaqueness of Web services means specifying usage constraints of operations of a collection of Web services and their joint behavior. This, too, is similar to specifying business processes.
6.1. Composition of Web Services
Business Process Execution Language for Web services (WS-BPEL, often shortened to BPEL) provides a language to specify business processes and process states and how they relate to Web services. This includes specifying how a business process uses Web services to achieve its goal, and it includes specifying Web services that a business process provides. Business processes specified in BPEL are fully executable and are portable between BPEL-conformant tools and environments. A BPEL business process interoperates with the Web services of its partners, whether these Web services are realized based on BPEL or not. Finally, BPEL supports the specification of business protocols between partners and views on complex internal business processes.
Reference Book:
Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More
By Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson
...............................................
Publisher: Prentice Hall PTR
Pub Date: March 22, 2005
Print ISBN: 0-13-148874-0
Pages: 456
SOA has emerged as a direct consequence of specific business and technology drivers that have materialized over the past decade. From the business side, major trends such as the outsourcing of noncore operations and the importance of business process reengineering have been key influences driving the surfacing of SOA as an important architectural approach to business information technology (IT) today. From the technology side, the past 15 years have resulted in a realization of the importance of middleware standards and architectures, learning in particular from the successes and failures of distributed object systems and message-oriented middleware.
As an architectural concept, SOA permits multiple approaches for the realization and deployment of an IT system that has been designed and built around its principles. This book focuses on a specific technology that, arguably, has the most significant commercial visibility and traction, and that is Web services. Web services technology is a standards-based, XML-centric realization of an SOA
Business Process Optimization
· The execution of each step or activity within a business process is associated with certain costs, such as people costs that are associated with the activity if human intervention is required, or the cost of computer resources that are required to execute activities within the IT environment. Based on this information, a company can derive the overall cost for performing a business process. For example, if policy associated with a credit allocation process determines that someone must check credits with an amount greater than $1,000, and more customers are asking for credits above this limit, a business could change the policy to set manual intervention at a higher value to reduce the overall costs for running the process.
· Activities have temporal characteristics, such as the average duration for executing an activity or the average time elapsed until an activity is picked up and performed. Based on this information, you can derive the average interval for executing a business process. For example, when you are booking a business trip, you can reserve hotel and flight reservations in parallel, resulting in a shorter execution time for the overall business process relative to its sequential execution.
Collaborations, Mergers, and Acquisitions
The company determines that it is no longer competitive in performing activities A, B, and E. It finds two partners that can run these activities and meet the business goals. Partner 1 runs activities A and B, and Partner 2 runs activity E. The company re-engineered the original process into a new process (P'). In the new process, activity AB kicks off the execution at the first partner (Partner 1), and E' starts the execution at the second partner (Partner 2). The company now has a new process P', which results in increased competitiveness.
The basic principles that underpin SOA are illustrated as follows:
First, it is necessary to provide an abstract definition of the service, including the details that allow anyone who wants to use the service to bind to it in the appropriate way. Second, those people who are the providers of services need to publish details of their services so that those who want to use them can understand more precisely what they do and can obtain the information necessary to connect to use them.
Third, those who require services need to have some way to find what services are available that meet their needs. Also, to make this bind/publish/find approach work well, standards must be defined to govern what and how to publish, how to find information, and the specific details about how to bind to the service. Web services technology is at the heart of addressing these questions and is the subject of this book. It also forms a basis for the notion of a service bus (infrastructure) that supports SOA.
High level Architecture of SOA
The bottom layer presents its capabilities to cope with various transport protocols to communicate between a service and a requester. The messaging layer on top of the transport layer enables the bus to deal with messages, both XML and non-XML. The latter is important, for example, if a requester and the service needed reside in the same J2EE application server and the bus can simply transport the data in its Java rendering, avoiding unnecessary transformations. The next layer of the bus facilitates and deals with the description of services in terms of functions supported, quality of services of these functions, and supported binding mechanisms. The actual quality of services that the bus enforces based on appropriate parameterization via polices resides in the layer that follows. This layer copes with security aspects such as message integrity, confidentiality, and nonrepudiation, but also with reliable transport of messages and various kinds of transactions. The top layer represents the various kinds of virtual components that Web services represent. This layer has atomic services that are not composed as far as a requester's experience with the service is concerned.
Composed services that the service bus inherently supports are choreographies and societies of services that cooperate following an agreement protocol to decide on the success of the cooperation at the end of the cooperation. Finally, another layer provides features for discovery of services and their descriptions and to agree on a mode of interaction between a requester and a service.
WEB SERVICES:
"Service-Oriented Architectures," SOA represents an abstract architectural concept. It's an approach to building software systems that is based on loosely coupled components (services) that have been described in a uniform way and that can be discovered and composed. Web services represents one important approach to realizing an SOA.
The World Wide Web Consortium (W3C), which has managed the evolution of the SOAP and WSDL specifications, defines Web services as follows:
A software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with XML serialization in conjunction with other Web-related standards.
Although Web services technology is not the only approach to realizing an SOA, it is one that the IT industry as a whole has enthusiastically embraced. With Web services, the industry is addressing yet again the fundamental challenge that distributed computing has provided for some considerable time: to provide a uniform way of describing components or services within a network, locating them, and accessing them. The difference between the Web services approach and traditional approaches (for example, distributed object technologies such as the Object Management Group Common Object Request Broker Architecture (OMG CORBA), or Microsoft Distributed Component Object Model (DCOM)) lies in the loose coupling aspects of the architecture. Instead of building applications that result in tightly integrated collections of objects or components, which are well known and understood at development time, the whole approach is much more dynamic and adaptable to change. Another key difference is that through Web services, the IT industry is tackling the problems using technology and specifications that are being developed in an open way, utilizing industry partnerships and broad consortia such as W3C and the Organization for the Advancement of Structured Information Standards (OASIS), and based on standards and technology that are the foundation of the Internet.
Web services had its beginnings in mid to late 2000 with the introduction of the first version of XML messagingSOAP, WSDL 1.1, and an initial version of UDDI as a service registry. This basic set of standards has begun to provide an accepted industry-wide basis for interoperability among software components (Web services) that is independent of network location, in addition to specific implementation details of both the services and their supporting deployment infrastructure. Several key software vendors have provided these implementations, which have already been widely used to address some important business problems.
Although the value of Web services technology has been demonstrated in practice, there is a desire to use the approach to address more difficult problems. Developers are looking for enhancements that raise the level and scope of interoperability beyond the basic message exchange, requiring support for interoperation of higher-level infrastructure services. Most commercial applications today are built assuming a specific programming model. They are deployed on platforms (operating systems and middleware) that provide infrastructure services in support of that programming model, hiding complexity, and simplifying the problems that the solution developer has to deal with. For example, middleware typically provides support for transactions, security, or reliable exchange of messages (such as guaranteed, once-only delivery). On the other hand, there is no universally agreed standard middleware, which makes it difficult to construct applications from components that are built using different programming models (such as Microsoft COM, OMG CORBA, or Java 2 Platform, Enterprise Edition (J2EE) Enterprise Java Beans). They bring with them different assumptions about infrastructure services that are required, such as transactions and security. As a consequence, interoperability across distributed heterogeneous platforms (such as .NET and J2EE) presents a difficult problem.
Transport Services
Web services is basically an interoperable messaging architecture, and message transport technologies form the foundation of this architecture. Web services is inherently transport neutral. Although you can transport Web services messages by using the ubiquitous Web protocols such as HyperText Transport Protocol (HTTP) or Secure HTTP (HTTPS) to give the widest possible coverage in terms of support for the protocols , you can also transport them over any communications protocol, using proprietary ones if appropriate. Although transport protocols are fundamental to Web services and clearly are a defining factor in the scope of interoperability, the details are generally hidden from the design of Web services
Messaging:
The messaging services component of the framework contains the most fundamental Web services specifications and technologies, including eXtensible Markup Language (XML), SOAP, and WS-Addressing. Collectively, these specifications form the basis of interoperable messaging between Web services.
2.1 SOAP
SOAP, one of the significant underpinnings of Web services, provides a simple and relatively lightweight mechanism for exchanging structured and typed information between services. SOAP is designed to reduce the cost and complexity of integrating applications that are built on different platforms. SOAP has undergone revisions since its introduction, and the W3C has standardized the most recent version, SOAP 1.2. SOAP is defined independently of the underlying messaging transport mechanism in use. It allows the use of many alternative transports for message exchange. SOAP messages are transmitted one way from sender to receiver. However, multiple one-way messages can be combined into more sophisticated message exchange patterns. For instance, a popular pattern is a synchronous request/response pair of messages. Messages can be routed based on the content of the headers and the data inside the message body. You can use tools developed for the XML data model to inspect and construct complete messages. Note that such benefits were not available in architectures such as DCOM, CORBA, and Java Remote Method Invocation (RMI), where protocol headers were infrastructural details that were opaque to the application. Any software agent that sends or receives messages is called a SOAP node. The node that performs the initial transmission of a message is called the original sender. The final node that consumes and processes the message is called the ultimate receiver. Any node that processes the message between the original sender and the ultimate receiver is called an intermediary. Intermediaries model the distributed processing of an individual message. The collection of intermediary nodes traversed by the message and the ultimate receiver are collectively referred to as the message path.
To allow parts of the message path to be identified, each node participates in one or more roles. The base SOAP specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role in that every SOAP node, other than the sender, belongs to the Next role. UltimateReceiver is the role that the terminal node in a message path plays, which is typically the application, or in some cases, infrastructure that is performing work on behalf of the application. The body of a SOAP envelope is always targeted at the UltimateReceiver. In contrast, SOAP headers might be targeted at intermediaries or the UltimateReceiver
2.2 WS-Addressing
WS-Addressing provides an interoperable, transport-independent way of identifying message senders and receivers that are associated with message exchange. WS-Addressing decouples address information from the specific transport used by providing a mechanism to place the target, source, and other important address information directly within the Web service message. This specification defines XML elements to identify Web services endpoints and to secure end-to-end endpoint identification in messages. This specification enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
WS-Addressing defines two interoperable constructs that convey information that transport protocols and messaging systems typically provide. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. These two constructs are endpoint references and message information headers.
Description
Service description defines metadata that fully describes the characteristics of services that are deployed on a network. This metadata is important, and it is fundamental to achieving the loose coupling that is associated with an SOA. It provides an abstract definition of the information that is necessary to deploy and interact with a service.
3.1. WSDL
Web Services Description Language (WSDL) is perhaps the most mature of metadata describing Web services. It allows developers to describe the "functional" characteristics of a Web servicewhat actions or functions the service performs in terms of the messages it receives and sends. WSDL offers a standard, language-agnostic view of services it offers to clients. It also provides noninvasive future-proofing for existing applications and services and allows interoperability across the various programming paradigms, including CORBA, J2EE, and .NET.
WSDL is an XML format for describing (network) services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL document has two parts: abstract definitions and concrete descriptions. The abstract section defines SOAP messages in a language- and platform-independent manner. In contrast, the concrete descriptions define site-specific matters such as serialization.
3.2 Policy
As businesses depend more on technology, their ability to control access to resources and enforce their administrative policies become central requirements. In a dynamic distributed environment, this includes the need to manage and distribute these policies only to authorized entities. Recently, government regulations have increased businesses' responsibility to protect consumer information from being distributed to third parties without the individual's consent. This new privacy legislation adds to the existing set of business requirements and introduces access to customer data (and metadata) as part of the information that is critical to the day-to-day management of the business.
In a service-oriented environment, service policies have a fundamental impact on interoperability. It's important to communicate to potential requesters any policies that a service provider enforces when those policies impact the interaction either because they require requesters to follow a specific behavior or a protocol or because they imply service-side behavior that impacts requester requirements or expectations (such as following a particular privacy policy). Service policies become a critical part of service descriptions, augmenting the basic WSDL functional description with a statement of nonfunctional service behaviors. As such, Web service policies support the development of service applications and provide the means to perform both development time and runtime service discovery and selection based on nonfunctional capabilities. For example, a service can be selected from among a list of functionally equivalent services based on its support for a specific privacy policy or the security guarantees it provides.
The first set of Web Services Policy documents [WS-Policy, WS-PolicyAttachment, and WS-PolicyAssertions] was published in 2002.
Discovery Services
The transport, description, and messaging layer are fundamental to allowing Web services to communicate in an interoperable way using messages. However, to facilitate this, it is necessary to collect and store the important metadata that describes these services. The metadata must be in a form that is discoverable and searchable by users who are looking for appropriate services they require to solve some particular business problem. Also, such metadata aggregation and discovery services are a useful repository/registry in which many different organizations might want to publish the services that they host, describe the interfaces to their services, and enable domain-specific taxonomies of services.
4.1. UDDI
The Universal Description and Discovery Interface (UDDI) is a widely acknowledged specification of a Web service registry. It defines a metadata aggregation service and specifies protocols for querying and updating a common repository of Web services information. Solutions developers can query UDDI repositories at well-known locations at design time to ascertain those services that might be compatible with their requirements. After they locate a directory, they can send a series of query requests against the registry to acquire detailed information about Web services (such as who provides them and where they are hosted) and bindings to the implementation. They can then feed this information into an assortment of development time tools to generate the appropriate runtime software and messages required to invoke the required service. Solutions can also query UDDI repositories dynamically at runtime. In this scenario, the software that needs to use a service is told at execution time the type of service or interface it requires. Then it searches a UDDI repository for a service that meets its functional requirements, or a well-known partner provides it. The software then uses this information to dynamically access the service.
UDDI repositories can be provided in one of three ways:
· Public UDDI These are UDDI repositories that can serve as a resource for Internet-based Web services. An example of this is the UDDI Business Registry [UBR]hosted by a group of vendors led by IBM, Microsoft, and SAPthat is replicated across multiple hosting organizations.
· Intra Enterprise UDDI An enterprise has a private internal UDDI repository that provides much more control over which service descriptions are allowed to be placed there and used by application developers within that specific enterprise.
· Inter Enterprise UDDI This basically scopes the content of the UDDI to services that are shareable between specific business partners.
4.2. MetaData Exchange
WS-Policy proposes a framework that extends the service description features that WSDL provides. Having more refined service descriptions, qualified by specific WS-policies, supports much more accurate discovery of services that are compatible with the business application that is to be deployed. In a service registry (such as a UDDI registry), queries of WS-Policy-decorated services enable the retrieval of services that support appropriate policies in addition to the required business interface. For example, a query might request all services that support the creditAuthorization WSDL interface (port type), use Kerberos for authentication, and have an explicitly stated privacy policy. This allows a service requester to select a service provider based on the quality of the interaction that delivers its business contracts.
Although service registries are important components of some Web services environments, it is often necessary to address the request of service information directly to the service itself. The WS-MetaDataExchange specification defines protocols that support the dynamic exchange of WS-Policy and other metadata that is relevant to the service interaction (such as XML Schema and WSDL descriptions) between interacting Web services endpoints. WS-MetadataExchange allows a service requester to ask a service provider directly for all or part of its metadata, without the involvement of a third-party registry. Using the WS-MetadataExchange protocol service, endpoints can exchange policies at runtime and use them to bootstrap their interaction from information about the settings and protocols to be applied. This is especially useful when not all policy information is in a repository or when a requester receives a reference to a service through some mechanism other than a direct query on a registry. This direct dynamic exchange of policies also supports the customization of each interaction based, for example, on the identity of the other endpoint or any other aspect of the context under which the interaction takes place. This flexibility allows Web services to be designed to offer different qualities of service for different targeted audiences.
Quality of Service
Specifications in this domain are related to the quality of the experience associated with interaction with a Web service. The services in this layer specify the requirements that are associated with the overall reliability of Web services. The specific issues involving this layer include security, reliability of message delivery, and support for transactions (guaranteeing and agreeing on the outcome of a business application).
5.1. WS-Security
Security is of fundamental concern in enterprise computing. WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport-level support for security functions (for example, HTTPS and BASIC-Auth authentication). These approaches to security provide a basic minimum for secure communication, and the level of function they provide is significantly less than that provided by existing middleware and distributed environments. WS-Security uses existing security models (such as Kerberos and X509). The specifications concretely define how to use the existing models in an interoperable way. Multihop, multiparty Web service computations cannot be secure without WS-Security.
Security relies on predefined trust relationships. Kerberos works because participants trust the Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants trust the root certificate authorities. WS-Trust defines an extensible model for setting up and verifying trust relationships. The key concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges, and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they trust, and to rely on these servers.
Some Web service scenarios involve a short sporadic exchange of a few messages. WS-Security readily supports this model. Other scenarios involve long, multimessage conversations between the Web services. WS-Security also supports this model, but the solution is not optimal.
Protocols such as HTTP/S use public keys to perform a simple negotiation that defines conversation-specific keys. This key exchange allows more efficient security implementations and decreases the amount of information encrypted with a specific set of keys. WS-SecureConversation provides similar support for WS-Security. Participants often use WS-Security with public keys to start a conversation or session, and they use WS-SecureConversation to agree on session specific keys for signing and encrypting information.
WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline, and a hotel chain might set up such a federation. An end user who logs into any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies. In addition, customers often have "properties" when they deal with an enterprise, and WS-Federation allows the setting up of a federated property space. This allows each participant to have secure controlled access to each member's property information about the end users.
5.2. Reliable Messaging
In the Internet world, communication channels are typically unreliable. Connections break, messages fail to be delivered or are delivered more than once, and perhaps in a different sequence to that in which they were sent. Communication can become even more of an issue when the exchange of messages spans multiple transport layer connections. Although techniques for ensuring reliable delivery of messages are reasonably well understood and available in some messaging middleware products today (such as IBM WebsphereMQ), messaging reliability is still a problem. If messaging reliability is addressed by Web service developers who are incorporating techniques to deal with this directly into the services they develop, there is no guarantee that developers of different Web services will make the consistent choices about the approach to adopt. The outcome might not guarantee end-to-end reliable interoperable messaging. Even in cases in which the application developers defer dealing with the reliable messaging to messaging middleware, different middleware products from different suppliers do not necessarily offer a consistent approach to dealing with the problem. Again, this might preclude reliable message exchange between applications that are using different message-oriented middleware.
WS-ReliableMessaging addresses these issues and defines protocols that enable Web services to ensure reliable, interoperable exchange of messages with specified delivery assurances. The specification defines three basic assurances:
· In-order delivery The messages are delivered in the same order in which they were sent.
· At least once delivery Each message that is sent is delivered at least one time.
· At most once delivery No duplicate messages are delivered.
5.3. Transactions
Dealing with many of today's business scenarios necessitates the development of applications that consist of multiple Web services exchanging many messages. An example might be a group of financial institutions setting up a financial offering that involves insurance policies, annuities, checking accounts, and brokerage accounts. Such applications can be complex, executing across heterogeneous, loosely coupled distributed systems that are prone to failure, and introducing significant reliability problems. For such applications, you must deal with the failure of any component Web service of the application within the context of the whole application. A coordinated orchestration of the outcome of the participating services that make up the business application is essential so that a coherent outcome of the whole business application can be agreed upon and guaranteed. Therefore, it is important that the Web services involved are able to do the following:
· Start new tasks, the execution and disposition of which are coordinated with other tasks.
· Agree on the outcome of the computation. For example, does everyone agree that the financial packages were set up?
WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are designed specifically to address these requirements.
WS-Coordination is a general mechanism for initiating and agreeing on the outcome of multiparty, multimessage Web service tasks. WS-Coordination has three key elements:
· A coordination context This is a message element that is associated with exchanges during the interaction of Web services. This coordination context contains the WS-Addressing endpoint reference of a coordination service, in addition to the information that identifies the specific task being coordinated.
· A coordinator service This provides a service to start a coordinated task, terminate a coordinated task, allow participants to register in a task, and produce a coordination context that is part of all messages exchanged within a group of participants.
· An interface Participating services can use the interface to inform them of an outcome that all of the participants have agreed upon.
WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to implement the traditional two-phase atomic ACID transaction protocols. However, traditional atomic transactions and the WS-AtomicTransaction protocol are not always suitable. For example, this protocol is generally not appropriate for use with many types of business transactions.
Transaction protocols for business transactions have to deal with long-lived activities. These differ from atomic transactions in that such activities can take much longer to complete. Therefore, to minimize latency of access by other potential users of the resources being used by Web services participating in the activity, you need to make the results of interim operations visible to others before the overall activity has completed. In light of this, you can introduce mechanisms for fault and compensation handling to reverse the effects of tasks that were completed previously within a business activity (such as compensation or reconciliation). WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model to provide such long-running, compensation-based transaction protocols. For example, although WS-BPEL defines a transaction model for business processes, it is WS-BusinessActivity that specifies the corresponding protocol rendering. This, again, is an example for the composeability of the Web services specifications.
Components
The existing Web services standards do not provide for the definition of the business semantics of Web services. Today's Web services are isolated and opaque. Overcoming this isolation means connecting Web services and specifying how to jointly use collections (compositions) of Web services to realize much more comprehensive and complex functionalitytypically referred to as a business process. A business process specifies the potential execution order of operations from a collection of Web services, the data that is shared between these composed Web services, which partners are involved, and how they are involved in the business process, joint exception handling for collections of Web services, and so on. This composition especially allows the specification of long-running transactions between composed Web services. Consistency and reliability are increased for Web services applications. Breaking this opaqueness of Web services means specifying usage constraints of operations of a collection of Web services and their joint behavior. This, too, is similar to specifying business processes.
6.1. Composition of Web Services
Business Process Execution Language for Web services (WS-BPEL, often shortened to BPEL) provides a language to specify business processes and process states and how they relate to Web services. This includes specifying how a business process uses Web services to achieve its goal, and it includes specifying Web services that a business process provides. Business processes specified in BPEL are fully executable and are portable between BPEL-conformant tools and environments. A BPEL business process interoperates with the Web services of its partners, whether these Web services are realized based on BPEL or not. Finally, BPEL supports the specification of business protocols between partners and views on complex internal business processes.
Reference Book:
Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More
By Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, Donald F. Ferguson
...............................................
Publisher: Prentice Hall PTR
Pub Date: March 22, 2005
Print ISBN: 0-13-148874-0
Pages: 456
Tuesday, December 2, 2008
Lecture1 Introduction to Web Services
Welcome all my dear Master of Software Engineers.
Definition:
A Software system designed to support interoperable machine to machine interaction over a network.
We can also say ' standards-based, xml-centric realization of an SOA'
Extending the definiton of web service, we say anything to anything communication. Because normally the web pages viewed by us are very specific means can be only human readable say html,dhtml,server pages etc., But sometimes we would like to automate certain process to improve our business.
So we need programs can be automatically talk to each other without human intervention. Web Services satisfy all these because it uses xml-based communication.
Web Service: API's to the web applications or XML+HTTP API.
which provides platform independent service. As web application access from any browser or Operating System, web service enable you to share code across machines and programming languages.
Gothrough the web page to get more about web services:
http://csis.pace.edu/~lixin/pclc/ws/webServiceConcepts.pdf
Why we need it?:
The Internet is constantly evolving and being used in new and exciting ways every day. In the past, the Internet was used primarily for static HTML brochure sites. Nowadays, as more people, organizations, and businesses are getting on the Internet, users realize that this medium is a great tool for collaborative and distributive applications.
Well, i hope that you have collected some notes about amazon web services
Enjoy Reading..............
Definition:
A Software system designed to support interoperable machine to machine interaction over a network.
We can also say ' standards-based, xml-centric realization of an SOA'
Extending the definiton of web service, we say anything to anything communication. Because normally the web pages viewed by us are very specific means can be only human readable say html,dhtml,server pages etc., But sometimes we would like to automate certain process to improve our business.
So we need programs can be automatically talk to each other without human intervention. Web Services satisfy all these because it uses xml-based communication.
Web Service: API's to the web applications or XML+HTTP API.
which provides platform independent service. As web application access from any browser or Operating System, web service enable you to share code across machines and programming languages.
Gothrough the web page to get more about web services:
http://csis.pace.edu/~lixin/pclc/ws/webServiceConcepts.pdf
Why we need it?:
The Internet is constantly evolving and being used in new and exciting ways every day. In the past, the Internet was used primarily for static HTML brochure sites. Nowadays, as more people, organizations, and businesses are getting on the Internet, users realize that this medium is a great tool for collaborative and distributive applications.
Well, i hope that you have collected some notes about amazon web services
Enjoy Reading..............
Subscribe to:
Posts (Atom)