ARTICLE

Service-Oriented Architecture and Microsoft .NET

Posted by John Charles Olamendy Articles | Web Services in C# January 21, 2006
This article is intended to provide an overview how Microsoft .NET and related technologies support the goals and principles of Service-Oriented Architecture. The main approach of Microsoft .NET is explained along with the concepts of Service-Oriented Architecture and it fits into this strategy.
Reader Level:

Introduction

To be competitive, companies must be agile; this one has become critical for competitiveness. They constantly have to adapt their organization and environment to more and more frequent technological changes, merges and acquisitions. But technology is often expensive and difficult. To be agile, IT systems must be integrated and reactive, and therefore solutions need a loosely coupled integration, with the possibility to progressively improve legacy applications.

Business process can be extremely complex because of the variety of technologies in the IT infrastructure, such as the operating system, application, and enterprise information systems. Integrating such as heterogeneous technologies is very costly, time-consuming and very complex.

There were no standards for the Enterprise Information System integration, and the solutions were tight coupling, that is, any further changes in business process would involve a large effort to re-engineer the solution, and thus the organization lost the ability to be agile. Business process changes need to be quickly reflected in the systems which support these processes. Nowadays there is a great effort for Enterprise Applications Integration which involves a large number of companies and developers.

Business applications are developed in an organization as a solution to a specific business process. SOA promotes the idea that IT applications are service providers and consumers acting together to support the overall business goals of an organization. This new approach to enterprise architecture is a loosely-coupled solution in which software components are very independently. This is according to how enterprise changes its business because of new contract, services and workflow reengineering.

This paper is intended to provide an overview how .NET supports the goals and principles of SOA. The main approach of .NET is explained along with the concepts of SOA and how .NET and the technologies associated fit into this strategy.

What is Microsoft .NET?

Microsoft.NET applies to various Microsoft technologies. Microsoft initially defined .NET as a platform that is based on Web Services. Unlike other development platforms on which Web Services were an add-on, Web Services are the main technologies in .NET. But it is only one component of the former platform. The main approach to exploit the potential of the Internet and the web-based applications has a great potential to become this framework as a foundation for building powerful yet flexible Internet-centric applications. In these terms, then, .NET can be thought of as a platform that connects information, people, systems, and devices. According to Microsoft, .NET is a "revolutionary new platform, built on open Internet protocols and standards, with tools and services that meld computing and communications in new ways, thus connecting a world of information, people, systems and devices together to radically improve communication and business performance".

.NET consists of:

  • .NET Framework as the core component.

  • Developer Tools, such as Microsoft Visual Studio .NET 2003 which provides an IDE for maximizing productivity.

  • A set of servers, including Microsoft Windows Server 2003, Microsoft SQL Server, and Microsoft BizTalk 2004, etc.
  • Client software, such as Windows XP, Windows CE, and Microsoft Office XP, that helps developers deliver a deep and compelling user experience across a family of devices and existing products.

The .NET Framework is responsible for building and running next generation of software applications, including Web-base applications, XML Web-Services, smart client applications, etc. It is composed by the Common Language Runtime and a unified set of class libraries.

The Common Language Runtime: is the Microsoft.NET Virtual Machine, and it is responsible for running the .NET applications thanks to Microsoft Intermediate Language (MSIL) an internal language for this machine. It also provides additional services such as language integration, security enforcement and memory, process and threat management. In addition, the CLR has a role at development time when features such as life-cycle management, strong type naming, cross-language exception handling, and dynamic binding reduce the amount of code that a developer must write to turn business logic into a reusable component.

Class Libraries: Base classes provide standard functionality such as input/output, string manipulation, security management, network communications; thread management, text management, and user interface design features.

The ADO.NET classes enable developers to interact with data accessed. XML classes enable XML manipulation, searching, and translations. The ASP.NET classes support the development of Web-based applications and Web services. The Windows Forms classes support the development of desktop-based smart client applications. All this classes constitutes the Microsoft.NET API. It is important to remember that this base component can be extended.
 
An important point is that the focus of .NET is on a common object model rather than a particular programming language. For a language to compile and execute within the .NET framework, it must conform to what is known as the Common Type System (CTS). The CTS establishes a framework that helps enable cross-language integration and defines rules that .NET languages must follow. A subset of the CTS is the Common Language Specification (CLS), which enables cross-language interoperability.

From a more developer perspective, the concepts behind Microsoft.NET are:

  • It is a new environment for developing and running applications.

  • It provides the framework for an Internet-centric industry standard that makes it possible to implement a service-oriented architecture by tying together applications, information, and data sources using Web Services.

  • It enables software to become platform- and device-independent.

What is Service-Oriented Architecture?

Service-Oriented Architecture (SOA) is a new way of thinking about enterprise IT Architecture. SOA is about associating business process with IT. SOA represents a natural evolution of proven software architectural principles or design patterns commonly implemented in object-oriented systems.

SOA defines a paradigm and an architecture in which a group of related software components with an autonomous nature and a high level abstraction that carry out a given business process function, and these components can communicate with each other within the same enterprise, and with other services exposed by other enterprises. SOA is not a replacement for component architecture; rather it neatly complements the component architecture. While component architectures enhance reusability at a finer grain level, SOA can enhance reusability at a coarser grained level. Therefore a given service might very well be developed using well-defined component frameworks such as EJB, CORBA or .NET Remoting.

Service-Oriented Architecture has regained significance at this time because of the emergence of new technologies that are based on open standards that allow disparate systems to communicate in a common fashion.

The principles of SOA require that the services should:

  • Have behavior that is clearly defined by a published interface contract.
  • Have network addressable interfaces or endpoints.
  • Be dynamically discoverable and usable.
  • Emphasize interoperability.

Services are offered at a business level of abstraction which renders the interface as a business interface i.e. a contract. The contract is a mechanism that allows systems to be formalized, that is a set of operations semantically in relationship behind an interface, communication policies, pre-conditions and post-conditions for the collaboration such as security context, transactional behavior, session management, etc, and invariants such as policies for interacting with. Dependencies between services are regarded by the pairing of preconditions and post-conditions, though very loose coupling should minimize these dependencies.

One success factor for SOA is providing well-defined contracts with which other systems or applications can interact and significantly decreases the dependency on coding by eliminating the need to know and write to APIs.

Legacy and new applications are "wrapped" using the contracts, and they become provider of some services. The process of wrapping the legacy application into a service abstracts the complexities of individual applications and allows for what is known as "loose coupling" of services.

A SOAP application called Business Process is an orchestration of services, that is to say, it's an interaction semantically related messages between services, which process, transform and routes them to achieve a business goal. There are languages to specify the former orchestrations, such as Business Process Execution Language (BPEL) and XLANG.

An enterprise approach for SOA will seek to restate all business processes as services that communicate with each other and potentially with services outside of the enterprise. An organization will already have a number of systems already in place to support the business. These legacy systems are often disconnected from each other, or if not, then they are often tightly coupled or require manual intervention when communicating with each other. Legacy systems can be brought into SOA by providing "service wrappers" that would wrap around the system exposing the application functionality as services while allowing the existing technology to be reused. Over time, applications can be replaced or re-architected without affecting the entire enterprise so a long as the interface provided by the service wrapper remains enforced.

SOA deployment. Enterprise Service Bus (ESB)

The deployment of a SOA requires the conversion of existing systems into services. The tasks involved in achieving this can be repeated for each system and a common set of components may be needed to provide additional functionality (such as security and auditing). An Enterprise Service Bus (ESB) is a collection of servers and components that provide these functions and a set of tools to assist in the conversion of existing systems to services. All this must be achieved without conflicting with the principals of SOA.

The steps involved can be grouped into three phases:

  • Exposing the existing systems as core services. 
  • Building business services from these core services. 
  • Using the business services to achieve business process modeling.

Service-Oriented Architecture and Web Services.

Web Services are not inherently service-oriented-they represent a solution to implementing a SOA strategy. Web Services provide a necessary standards-based implementation of SOA wherein services are described using WSDL and accessed via SOAP. So that interoperability across platform, organizational, and network boundaries is feasible. Web Services technologies implemented by the .NET distributed computing model can support such a strategy.

Web Services are logic units that allow programs written in different programming languages and on different platforms to communicate through standard Internet protocols. Microsoft has stated:  "XML Web Services platform will enable developers to create programs that transcend device boundaries and fully harness the connectivity of the Internet."

Web Services allow applications, which may be written in different programming languages or on different platforms, to communicate and share data through standard Internet protocols.

Web Services currently represent the best technology for implementing SOA.

The technology stack used in web services maps onto the principles of SOA formerly explained:

  • WSDL provides a description of service behavior and the interface contract.

  • The HTTP protocol, while not the only protocol available, is the most widely used regardless of the technology platform. It's identified a network service of unique way using the URLs. SOAP provides a platform independent protocol for sending messages across the wire.

  • UDDI provides the means to discover the service both at design time and at run time.

  • XML is the technology that underpins it all. Since XML is text based, it can be read by virtually any machine on any platform giving a high degree of interoperability. WSDL, UDDI and SOAP are all XML based.

Now, it will be explained some technologies used by Web Services as support:

  • Web Services are invoked using SOAP messages. SOAP, which is defined using XML, is an emerging standard for transmitting messages across the Internet. SOAP facilitates application-to-application interoperation between multiple processing points. SOAP messages contain header information about the communication channel and a body containing the business-oriented content. SOAP messages are often sent within the body of some transport protocol such as HTTP, SMTP or TCP.

  • WSDL is an XML-based grammar used to define a contract provided by the Web.

  • Service. It is used the XML Schema Definition (XSD) standard to describe message structure and data types, WSDL provides a means to describe the basic format of a Web Service request message or invocation and the format of a subsequent response message from the Web Service. The WSDL file gives the developer of a Web Service consuming application all of the information necessary to achieve this programmatic access to another system-that is, to invoke a Web Service.

  • The WSDL gives self-description aspect to the Web Services.

  • The UDDI specification provides directories and descriptions of Web Services so that interested parties can locate these services and interact with them. Specifically, the UDDI standard defines a way to provide a universal database or registry of Web Services and links to their associated WSDL files. A Web Service consumer can use a UDDI registry, whether it be a public registry, or an intranet-based private registry, to discover and reference a Web Service provider.

  • There are standards and specifications that all major software vendors-including Microsoft, IBM, Oracle, BEA Systems, and many others-have agreed upon. So a Web Service endpoint running on Microsoft.NET could be invoked by another application running on, for example, J2EE, and vice versa.

Microsoft.NET and Web Services

Although Web Services can be created on any platform, Microsoft's .NET framework is heavily geared towards the creation of Web Services. It provides a number of tools and features through which a Web Service can be quickly and easily built. A lot of the complexity of generating the necessary SOAP messages, for example, is hidden from developer.

Through the utilization of special attribute tags, a method can be marked as a Web Method, available to be serialized over the wire. The complications of the serialization process are also handled by the Framework. Because the .NET framework offers a high degree of native XML support, it is well suited to building Web Services. The framework will also automatically generate the WSDL required.

Microsoft BizTalk Server

BizTalk Server provides Enterprise Application Integration (EAI) and Business-to- Business (B2B) integration through orchestrations that execute logic and seamlessly integrate disparate systems involved in a business process. BizTalk Orchestrations can be exposed as Web Services and they may also consume internal or external Web Services while executing an orchestration. When exposed as a Web Service, an orchestration receives requests and sends responses via a logical request-reply port that is bound to a physical port when the orchestration is deployed. BizTalk Server orchestrations and related components leverage the .NET framework and are constructed graphically using Visual Studio .NET. With Web Services capabilities and adapters for products such as those from PeopleSoft, SAP, Siebel, and others, BizTalk can support SOA by connecting disparate systems, including those lacking native support for Web Services, into a coherent and maintainable business process.

Web Services Enhancements

Early Web Services standards provided for platform-independent messaging over the Internet using SOAP/XML. These standards alone, however, did not address the problem of transmitting messages in a secure and reliable way. Indeed, businesses do not want to send critical or sensitive data over the public Internet in a way that cannot be secured or where there are no guarantees that requests are completed.

The WS-I Basic Profile addresses this need. The WS-I Basic Profile is published by the Web Services Interoperability (WS-I) organization (www.ws-i.org) which works to establish standard specifications to promote Web Services interoperability across platforms, applications, and programming languages.

The WS-I Basic Profile includes what are known as the WS-Specifications, three of which are implemented in the Web Services Enhancements 2.0 (WSE) which is a .NET class library for building Web Services using the WS-Specifications. WSE implements:

  1. WS-Security: a specification for secure Web Service communication using common security technologies (SSL or TLS), including digital signing and encryption.

  2. WS-Policy: a specification for Web Services to document, for example, their security requirements using meta-data that augments the WSDL file.

  3. WS-Messaging: a specification that defines other means beyond SOAP over HTTP, such as TCP, for communication between Web Service endpoints.

The key benefit of WSE is that it allows the quick implementation of these specifications and relieves the developer from having to code the low-level XML details that would otherwise be required to implement them.

The next iteration of .NET Web Services, code named "Indigo" will provide further enhancements to WSE. Advanced Web services support in Indigo will provide secure, reliable, and transacted messaging along with interoperability. According to Microsoft, Indigo will deliver a programming model and implementation based on service-oriented concepts.

Available Platforms

Sun Microsystems, IBM and Microsoft have all introduced frameworks to support a component-based, Service Oriented Architecture (SOA). Sun's Java2 Enterprise Edition (J2EE) and  Open Net Environment (Sun ONE), IBM's Web Sphere built on J2EE and Microsoft's .Net provide capabilities to achieve this goal but they approach this in different ways. The primary focus of Sun ONE and IBM's Web Sphere is the definition of an underlying architecture through specifications of a standard platform for hosting and delivering J2EE applications built on Java technologies. Microsoft has embraced the SOA by the introduction of their .NET initiative. Microsoft describes .NET as "an open language platform for enterprise and Web development".

Conclusion

SOA is an architecture which evolved from the distributed and the components architectures and has become the new one to solve complex problems around the enterprise environment. Microsoft is entering in this new area and is actively working in specifications, products and interoperability efforts. It is recommended to follow the development in this new approach henceforth.

COMMENT USING
Employers - Post Free Jobs