APUSIC

November 15 ,shang hai jing an district .

IBM WebSphere MQ is a proprietary, asynchronous messaging technology that is available from IBM. WebSphere MQ is middleware technology that is designed for application-to-application communication rather than application-to-user and user interface communication.

WebSphere MQ is available on a large number of platforms and operating systems. It offers a fast, robust, and scalable messaging solution that assures once, and once only, delivery of messages to queue destinations that are hosted by queue managers. This messaging solution has APIs in C, Java, COBOL, and more, which allow applications to construct, send, and receive messages.

With the advent of JMS, generic, portable client applications can be written to interface with proprietary messaging systems such as WebSphere MQ. The integration of WebSphere Application Server with WebSphere MQ over time has been influenced by this dichotomy of generic JMS and proprietary WebSphere MQ access approaches.

For more information about WebSphere MQ, see:

http://www.ibm.com/software/integration/wmq/

Integration with WebSphere Application Server

WebSphere Application Server messaging is a general term for a group of components that provide the messaging functionality for applications. WebSphere MQ and WebSphere Application Server messaging are complementary technologies that are tightly integrated to provide for various messaging topologies.

WebSphere Application Server supports asynchronous messaging based on the Java Message Service (JMS) programming interface and the use of a JMS provider and its related messaging system. JMS providers must conform to the JMS Specification version 1.1.

In WebSphere Application Server V6, you can use the following as JMS

providers:

The default messaging provider

WebSphere MQ

Generic JMS providers

V5 default messaging provider (for migration purposes)

The default messaging provider is the JMS API implementation for messaging

(connection factories, JMS destinations, and so on). The concrete destinations

20 WebSphere Application Server V6.1: Planning and Design

(queues and topic spaces) behind the default messaging provider interface are implemented in a service integration bus. A service integration bus consists of one or more bus members, which can be application servers or clusters. Each bus member will have one (or possibly more in the case of clusters) messaging engine that manages connections to the bus and messages. A service integration bus can connect to other service integration buses and to WebSphere MQ.

Similarly, the WebSphere MQ JMS provider is the JMS API implementation with WebSphere MQ (with queue managers, for example) implementing the real destinations for the JMS interface. WebSphere MQ can coexist on the same host as a WebSphere Application Server V6 messaging engine.

Whether to use the default messaging provider, the direct WebSphere MQ messaging provider, or a combination depends on a number of factors. There is no set of questions that can lead you directly to the decision; however, consider the following guidelines.

In general, the default messaging provider is a good choice if:

You are currently using the WebSphere Application Server V5 embedded messaging provider for intra-WebSphere Application Server messaging.

You require messaging between WebSphere Application Server and an existing WebSphere MQ backbone and its applications.

WebSphere Application Server can support the topology required for scalability.

The WebSphere MQ messaging provider is good choice if:

You are currently using a WebSphere MQ messaging provider and simply want to continue using it.

You require access to heterogeneous, non-JMS EIS systems.

You require access to WebSphere MQ clustering.

Using a topology that combines WebSphere MQ and the default messaging provider gives you the benefit of the tight integration between WebSphere and the default messaging provider (clustering), and the flexibility of WebSphere MQ.

Chapter 2. Integration with other products 21

Connecting WebSphere Application Server to WebSphere MQ

If you decide to use a topology that includes both WebSphere MQ and the default messaging provider, there are two mechanisms to allow interaction between them:

Extend the WebSphere MQ and service integration bus networks by defining a WebSphere MQ link on a messaging engine in a WebSphere Application Server that connects the service integration bus to a WebSphere MQ queue manager.

WebSphere MQ sees the connected service integration bus as a queue manager. The service integration bus sees the WebSphere MQ network as another service integration bus.

WebSphere MQ applications can send messages to queue destinations on the service integration bus and default messaging applications can send messages to WebSphere MQ queues without being aware of the mixed topology. As with WebSphere MQ queue manager networks, this mechanism can be used to send messages from one messaging network to the other; it cannot be used to consume messages from the other messaging network.

Note that:

– WebSphere MQ to service integration bus connections are only supported over TCP/IP.

– A service integration bus cannot be a member of a WebSphere MQ

cluster.

Integrate specific WebSphere MQ resources into a service integration bus for direct, synchronous access from default messaging applications running in WebSphere Application Servers. This is achieved by representing a queue manager or queue sharing group as a WebSphere MQ server in the WebSphere Application Server cell and adding it to a service integration bus as a bus member.

WebSphere MQ queues on queue managers and queue sharing groups running on z/OS can be accessed in this way from any WebSphere Application Server that is a member of the service integration bus. An MQ shared queue group is a collection of queues that can be accessed by one or more queue managers. Each queue manager that is a member of the shared queue group has access to any of the shared queues.

Only WebSphere MQ queue managers and queue sharing groups running on z/OS can be accessed from a service integration bus in this way.

The WebSphere MQ server does not depend on any one designated messaging engine. This type of connectivity to MQ can tolerate the failure of any given message engine as long as another is available in the bus,

22 WebSphere Application Server V6.1: Planning and Design

increasing robustness and availability. This mechanism can be used for both sending and consuming messages from WebSphere MQ queues.

When a default messaging application sends a message to a WebSphere MQ queue, the message is immediately added to that queue; it is not stored by the service integration bus for later transmission to WebSphere MQ in the case when the WebSphere MQ queue manager is not currently available. When a WebSphere Application Server application receives a message from a WebSphere MQ queue, it receives the message directly from the queue.

This section describes IBM Tivoli Directory Server and its integration with

WebSphere Application Server.

Note: IBM SecureWay® Directory Server has been renamed to IBM Tivoli Directory Server in WebSphere Application Server Version 6.1.

For more information about IBM Tivoli Directory Server, see the following Web site:

http://www.ibm.com/software/tivoli/products/directory-server/

2.2.1 The Lightweight Directory Access Protocol (LDAP)

A directory is a data structure that enables the look up of names and associated attributes arranged in a hierarchical tree structure. In the context of enterprise application servers, this enables applications to look up a user principal and determine what attributes the user has and of which groups the user is a member. Decisions about authentication and authorization can then be made using this information.

LDAP is a fast and simple way of looking up user entities in a hierarchical data structure. It has advantages over simply using databases as a user repository in terms of speed, simplicity, and standardized models or schemas for defining data. Standard schemas have standard hierarchies of objects, such as objects that represent a person in an organization. These objects, in turn, have attributes

18 WebSphere Application Server V6.1: Planning and Design

such as a user ID, common name, and so forth. The schema can also have custom objects added to it, which means that your directory is extensible and customizable.

Generally, LDAP is chosen over a custom database repository of users for these reasons. LDAP implementations (such as IBM Tivoli Directory Server) use database engines under the covers, but these engines are optimized for passive lookup performance (through indexing techniques). This is possible because LDAP implementations are based on the assumption that the data changes relatively infrequently and that the directory is primarily for looking up data rather than updating data.

Today, there are many LDAP server implementations. For example, IBM Tivoli Directory Server, iPlanet Directory Server, Open LDAP’s SLAPD server, and Microsoft Active Directory all support the LDAP protocol.

For a list of supported directory servers, see 1.4.4, “Directory servers” on page 11.

2.2.2 Tivoli Directory Server and WebSphere Application Server

When you enable application security in WebSphere Application Server, you must select the user registry to be used (in this case, an LDAP registry). This can be done through the WebSphere administrative console or through the wsadmin command line tool.

Because the LDAP server contains sensitive data in terms of authentication, authorization, and privacy, the LDAP server belongs in the data layer of the network. It is a best practice to enable SSL options in the WebSphere Application Server security configuration so that the data is encrypted between the application server layer and the data layer.

There might be some legal and or regulatory issues that surround storing of certain data types, such as personally identifiable data in the European Union, on IT systems. Ensure that you have consulted your legal department before deploying such information about your systems. These considerations vary by geography and industry, and it is beyond the scope of this book to discuss specific issues. Legal considerations might become even more of an issue when you create custom objects and attributes in the LDAP directory schema that can store further information relating to individuals.

Integration with other products

WebSphere Application Server works closely with other IBM products to provide a fully integrated solution. This chapter introduces some of these products, including those that provide enhanced security and messaging options.

This chapter includes the following sections:

Tivoli Access Manager

Tivoli Directory Server

WebSphere MQ integration

Information Integration

2.1 Tivoli Access Manager

IBM Tivoli Access Manager provides a more holistic security solution at the enterprise level than the standard security providing mechanisms found in WebSphere Application Server. The following sections give an overview of built-in WebSphere Application Server security, how WebSphere Application Server integrates with Tivoli Access Manager, and when and why the two products might be used together.

For more information about Tivoli Access Manager, see:

Tivoli Access Manager for e-business home page

http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/

Tivoli Access Manager Information Center

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?toc

=/com.ibm.itame.doc/toc.xml

2.1.1 WebSphere Application Server security

WebSphere Application Server V6.1 provides its own security infrastructure. This infrastructure is composed of some mechanisms that are specific to WebSphere Application Server but also many that use open standards security technologies. This security technology is widely proven, and the software can integrate with other enterprise technologies easily.

A brief overview of WebSphere security

The rich, standards-based architecture for WebSphere Application Server security offers various configuration options:

At the most basic level, a single server can use the Simple WebSphere Authentication Mechanism (SWAM). However, the SWAM mechanism has been deprecated and will be removed in future versions, so we strongly recommend that you to plan your security to use a different authentication mechanism.

If more than one server is required to share a security mechanism (that is if containers on more than one server need to be able to track user credentials across the servers), you can use Lightweight Third Party Authentication (LTPA). (It can also be used for single servers.) To make this possible, LTPA generates a security token that is passed between servers for authenticated users.

14 WebSphere Application Server V6.1: Planning and Design

Reverse proxy servers (servers that mediate between Web clients and multiple servers behind a firewall) can be integrated with LTPA in WebSphere Application Server to allow for client authentication. A trust association is implemented, which is a contract between the application server and the reverse proxy server. IBM WebSEAL Reverse Proxy is such a reverse proxy product.

An operating system, LDAP or customer user registry is configured to be the user registry for the environment. Only one registry can be configured at any one time. V6.1 introduces a file-based user registry and the ability to federate this registry with other registries. The file-based registry is the default for administrative security enabled out of the box.

WebSphere uses the Java Authentication and Authorization Service (JAAS) API, which enables services to authenticate and to enforce access controls on users.

WebSphere uses a specialized JAAS module to implement the user credentials mapping module in its J2EE Connector Architecture (J2C) implementation that enables WebSphere Application Server to integrate with enterprise information systems.

Java 2 Security can also be enabled. This security mechanism, which is part of the Java runtime, allows or disallows access for Java code to specific system resources based on permissions, which can be specified in a

fine-grained manner. For example, a Java application can be granted permission to access the operating system’s file system for file input and output.

J2EE 1.4 prescribes the use of the JACC API specification. (The relevant Java Community Process Java Specification Request is JSR-115.) JACC allows application servers to interact with third-party authorization providers (such as Tivoli Access Manager) through standard interfaces to make authorization decisions. Previously, proprietary interfaces for third-party authorization providers had to be used.

2.1.2 Tivoli Access Manager and WebSphere Application Server

The WebSphere Application Server security infrastructure is in and of itself adequate for many situations and circumstances. However, integrating WebSphere Application Server with Tivoli Access Manager allows for a far more holistic, end-to-end integration of application security across the entire enterprise.

Chapter 2. Integration with other products 15

The advantages at the enterprise level of using this approach are:

Reduced risk through a consistent services-based security architecture

Lower administration costs through centralized administration and fewer security subsystems

Faster development and deployment

Reduced application development costs because developers do not have to develop bespoke security subsystems

Built-in, centralized, and configurable handling of legislative business concerns such as privacy requirements

Repositories

As with WebSphere Application Server security, Tivoli Access Manager requires a user repository. It supports many different repositories such as Microsoft Active Directory, iPlanet™, and IBM Tivoli Directory Server. Tivoli Access Manager can be configured to use the same user repository as WebSphere Application Server, enabling you to share user identities with both Tivoli Access Manager and WebSphere Application Server.

Tivoli Access Manager policy server

The Tivoli Access Manager policy server maintains the master authorization policy database, which contains the security policy information for all resources and all credentials information of all participants in the secure domain, both users and servers. The authorization database is then replicated across all local authorization servers. IBM WebSEAL Reverse Proxy Server, for example, has its own local authorization server.

Tivoli Access Manager for WebSphere component

The Tivoli Access Manager clients are embedded in WebSphere Application Server. The Tivoli Access Manager client can be configured using the scripting and GUI management facilities of WebSphere Application Server.

The Tivoli Access Manager server is bundled with WebSphere Application Server Network Deployment. Tivoli Access Manager further integrates with WebSphere Application Server in that it supports the special subjects AllAuthenticated and Everyone.

Note: AllAuthenticated and Everyone are subjects that are specific to WebSphere Application Server. These special categories allow access to a resource to be granted to all those users who have been authenticated regardless of what repository user groups they might belong to and allow access to be granted to all users whether or not they are authenticated.

16 WebSphere Application Server V6.1: Planning and Design

All communication between the Tivoli Access Manager clients and the Tivoli

Access Manager server is done through the JACC API.

Figure 2-1 shows the integration interfaces between WebSphere Application

Server and Tivoli Access Manager.

Further advantages of using Tivoli Access Manager

We already reviewed the enterprise level advantages of using Tivoli Access Manager. Using Tivoli Access Manager at the application server level has the following further advantages:

Supports accounts and password policies.

Supports dynamic changes to the authorization table without having to restart the applications.

Provides tight integration with WebSphere Application Server.

Chapter 2. Integration with other products 17

Security, networking, and topology considerations

Clearly, because the LDAP server contains and the Access Manager server manages sensitive data in terms of authentication, authorization and privacy, the servers belong in the data layer of the network. It is best practice to enable Secure Sockets Layer (SSL) configuration options between the databases so that the data is encrypted.

Legal considerations (privacy and data protection)

You should be aware that there might be some legal and or regulatory issues that surround storing of certain data types, such as personally identifiable data in the European Union, on IT systems. Ensure that you have consulted your legal department before deploying such information about your systems. These considerations vary by geography and industry, and it is beyond the scope of this book to discuss specific issues.

1.4 Supported platforms and software

The following tables illustrate the platforms, software, and versions that WebSphere Application Server V6.1 supports at the time of the writing of this document.

For the most up-to-date operating system levels and requirements, refer to the

WebSphere Application Server system requirements Web page, at:

http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html

1.4.1 Operating systems

Table 1-2 shows the supported operating systems and versions for WebSphere

Application Server V6.1.

Table 1-2 Supported operating systems and versions

Chapter 1. Introduction to WebSphere Application Server V6.1 9

1.4.2 Web servers

All available platforms of WebSphere Application Server V6.1 support the following Web servers:

Apache HTTP Server 2.0.54

IBM HTTP Server for WebSphere Application Server 6.0.2

IBM HTTP Server for WebSphere Application Server 6.1

Internet Information Services 5.0

Internet Information Services 6.0

IBM Lotus® Domino® Enterprise Server 6.5.4 or 7.0

Sun Java™ System Web Server 6.0 SP9

Sun Java System Web Server 6.1 SP3

1.4.3 Database servers

Table 1-3 shows the database servers that WebSphere Application Server V6.1 supports.

Table 1-3 Supported database servers and versions

10 WebSphere Application Server V6.1: Planning and Design

1.4.4 Directory servers

Table 1-4 shows the LDAP servers that WebSphere Application Server V6.1 supports.

Table 1-4 Supported directory servers and versions

1.3 Packaging

Because varying e-business application scenarios require different levels of application server capabilities, WebSphere Application Server is available in multiple packaging options. Although they share a common foundation, each provides unique benefits to meet the needs of applications and the infrastructure that supports them. At least one WebSphere Application Server product fulfills the requirements of any particular project and its supporting infrastructure. As your business grows, the WebSphere Application Server family provides a migration path to more complex configurations.

WebSphere Application Server – Express V6

Note: WebSphere Application Server – Express V6.1 is anticipated to be announced later this year. This book specifically deals with V6.1 of Base and Network Deployment. When you see references to Express, they are specifically referring the V6.0 of Express.

The Express package is geared to those who need to get started quickly with On Demand Business. It is specifically targeted at medium-sized businesses or departments of a large corporation, and is focused on providing ease of use and ease of application development. It contains full J2EE 1.4 support but is limited to a single-server environment.

WebSphere Application Server – Express is unique from the other packages in that it is bundled with an application development tool. Although there are WebSphere Studio and Rational Developer products designed to support each WebSphere Application Server package, normally they are ordered independent of the server. WebSphere Application Server – Express includes the Rational Web Developer application development tool. It provides a development environment geared toward Web developers and includes support for most J2EE

1.4 features with the exception of Enterprise JavaBeans™ (EJB™) and J2EE Connector Architecture (JCA) development environments. However, keep in mind that WebSphere Application Server – Express V6 does contain full support for EJB and JCA, so you can deploy applications that use these technologies.

WebSphere Application Server V6.1

The WebSphere Application Server package is the next level of server infrastructure in the WebSphere Application Server family. Though the WebSphere Application Server is functionally equivalent to that shipped with Express, this package differs slightly in packaging and licensing.

Chapter 1. Introduction to WebSphere Application Server V6.1 5

This package includes two tools for application development and assembly:

The Application Server Toolkit, which has been expanded in V6.1 to include a full set of development tools. The toolkit is suitable for J2EE 1.4 application development, as well as the assembly and deployment of J2EE applications. It also supports Java 5 development.

In addition, the toolkit provides tools for the development, assembly, and deployment of JSR 116 SIP and JSR 168 portlet applications.

This package also includes a trial version of Rational Application Developer, which supports the development, assembly, and deployment of J2EE 1.4 applications.

To avoid confusion with the Express package in this document, we refer to this as the Base package.

WebSphere Application Server Network Deployment V6.1

WebSphere Application Server Network Deployment provides an even higher level of server infrastructure in the WebSphere Application Server family. It extends the WebSphere Application Server base package to include clustering capabilities, Edge components, and high availability for distributed configurations. These features become more important at larger enterprises, where applications tend to service a larger client base, and more elaborate performance and availability requirements are in place.

Application servers in a cluster can reside on the same or multiple machines. A Web server plug-in installed in the Web server can distribute work among clustered application servers. In turn, Web containers running servlets and Java ServerPages (JSPs) can distribute requests for EJBs among EJB containers in a cluster.

The addition of Edge components provides high performance and high availability features. For example:

The Caching Proxy intercepts data requests from a client, retrieves the requested information from the application servers, and delivers that content back to the client. It stores cachable content in a local cache before delivering it to the client. Subsequent requests for the same content are served from the local cache, which is much faster and reduces the network and application server load.

The Load Balancer provides horizontal scalability by dispatching HTTP requests among several, identically configured Web server or application server nodes.

6 WebSphere Application Server V6.1: Planning and Design

WebSphere Application Server V6.1 for z/OS

IBM WebSphere Application Server for z/OS is a full-function version of the Network Deployment product. WebSphere Application Server for z/OS can support On Demand Business on any scale.

Packaging summary

Table 1-1 shows the features included with each WebSphere Application Server packaging option.

Table 1-1 WebSphere Application Server packaging

Chapter 1. Introduction to WebSphere Application Server V6.1 7

a. Express is limited to a maximum of two CPUs.

WebSphere Application Server includes a new tool called Installation Factory for creating customized install packages (CIPs). Consider using Installation Factory to create one or more CIPs and use those CIPs to deploy or update WebSphere throughout your organization.

WebSphere Application Server also now ships the Update Installer (UPDI) for installing maintenance (fix packs, interim fixes, and so on. In previous versions, these tools were only available as separate Web downloads.

Note: Not all features are available on all platforms. See the system requirements Web page for each WebSphere Application Server package for more information.

WebSphere Application Server provides the environment to run your

Web-enabled On Demand Business applications. An application server functions as Web middleware or a middle tier in a three-tier environment. The first tier is the HTTP server that handles requests from the browser client. The third tier is the business database and the business logic (for example, traditional business applications such as order processing). The middle tier is WebSphere Application Server, which provides a framework for a consistent and architected link between the HTTP requests and the business data and logic.

WebSphere Application Server is available on a wide range of platforms and in multiple packages to meet specific business needs. It also serves as the base for other WebSphere products, such as IBM WebSphere Enterprise Service Bus and WebSphere Process Server, by providing the application server that is required to run these specialized applications.

Figure 1-1 illustrates a product overview of WebSphere Application Server.

The application server is the key component of WebSphere Application Server, providing the runtime environment for applications that conform to the J2EE 1.2,

1.3, and 1.4 specifications. Clients access these applications through standard interfaces and APIs. The applications, in turn, have access to a wide variety of external sources such as back-end systems, databases, Web services, and

Chapter 1. Introduction to WebSphere Application Server V6.1 3

messaging resources that can be used to process the client requests.

Version 6.1 extends the application server to allow it to run JSR 168 compliant portlets and Session Initiation Protocol (SIP) applications written to the JSR 116 specification.

With the Base and Express packages, you are limited to single application server environments. The Network Deployment package enables you to extend this environment to include multiple application servers that are administered from a single point of control and can be clustered to provide scalability and high availability environments.

WebSphere Application Server supports asynchronous messaging through the use of a JMS provider and its related messaging system. WebSphere Application Server includes a fully integrated JMS 1.1 provider called the default messaging provider. This messaging provider complements and extends WebSphere MQ and the application server. It is suitable for messaging among application servers and for providing messaging capability between WebSphere Application Server and an existing WebSphere MQ backbone.

WebSphere Application Server provides authentication and authorization capabilities to secure administrative functions and applications. Your choice of user registries include the operating system user registry, an LDAP registry (for example, IBM Tivoli® Directory Server), custom registries, file-based registries, or federated repositories. In addition to the default authentication and authorization capabilities, you have the option of using an external Java Authorization Contract for Containers (JACC)-compliant authorization provider for application security. The IBM Tivoli Access Manager client embedded in WebSphere Application Server is JACC-compliant and can be used to secure your WebSphere Application Server-managed resources. This client technology is designed to be used with the Tivoli Access Manager server (shipped with Network Deployment).

WebSphere Application Server works with a Web server (such as IBM HTTP Server) to route requests from browsers to the applications that run in WebSphere Application Server. Web server plug-ins are provided for installation with supported Web browsers. The plug-ins direct requests to the appropriate application server and perform workload balancing among servers in a cluster.

WebSphere Application Server Network Deployment includes the Caching Proxy and Load Balancer Edge components for use in highly available, high volume environments. Using Edge components can reduce Web server congestion, increase content availability, and improve Web server performance.

IBM WebSphere is the leading software platform for On Demand Business.
Providing comprehensive leadership, WebSphere is evolving to meet the demands of companies faced with challenging business requirements, such as the need for increasing operational efficiencies, strengthening client loyalty, and integrating disparate systems. WebSphere provides answers in today’s challenging business environments.
IBM WebSphere is architected to enable you to build business-critical
applications for the Web. WebSphere includes a wide range of products that help you develop and serve Web applications. They are designed to make it easier for clients to build, deploy, and manage dynamic Web sites more productively.
In this chapter, we introduce WebSphere Application Server V6.1 for distributed platforms and WebSphere Application Server for z/OS V6.1.

1.1 Product overview
WebSphere is the IBM brand of software products designed to work together to help deliver dynamic On Demand Business quickly. It provides solutions for connecting people, systems, and applications with internal and external resources. WebSphere is based on infrastructure software, or middleware, designed for dynamic On Demand Business. It delivers a proven, secure, and reliable software portfolio that can provide an excellent return on investment.
The technology that powers WebSphere products is Java™. Over the years,many software vendors have collaborated on a set of server-side application programming technologies that help build Web accessible, distributed, platform-neutral applications. These technologies are collectively branded as the Java 2 Platform, Enterprise Edition (J2EE) platform. This contrasts with the  Java 2, Standard Edition (J2SE™) platform, with which most clients are familiar.
J2SE supports the development of client-side applications with rich graphical user interfaces (GUIs). The J2EE platform is built on top of the J2SE platform.
J2EE consists of application technologies for defining business logic and accessing enterprise resources such as databases, enterprise resource planning (ERP) systems, messaging systems, e-mail servers, and so forth.
The potential value of J2EE to clients is tremendous. Among the benefits of J2EE are:
An architecture-driven approach to application development helps reduce maintenance costs and allows for construction of an information technology (IT) infrastructure that can grow to accommodate new services.
Application development is focused on unique business requirements and rules, such as security and transaction support. This improves productivity and shortens development cycles.
Industry standard technologies enable clients to choose among platforms,development tools, and middleware to power their applications. Embedded support for Internet and Web technologies allows for a new breed of applications that can bring services and content to a wider range of customers, suppliers, and others, without creating the need for proprietary integration.
Another exciting opportunity for IT is Web services. Web services allow for the definition of functions or services within an enterprise that can be accessed using industry standard protocols that most businesses already use today, such as HTTP and XML. This allows for easy integration of both intra- and inter-business applications that can lead to increased productivity, expense reduction, and quicker time to market.

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!