Within any organization, communication between the core business operations and the IT group has traditionally been a challenging and adversarial relationship. Most miscommunications between the two groups result from misunderstandings related to software and other issues. Now the gap between the business IT layer is beginning to close.

Since its emergence, Web Service technology has gone a long way towards perfecting itself and finding its right application in the real world. With the maturity of the specifications, Web Service technology, with its power of interoperability, is now the major enabling technology of SOA, which is being adopted by more and more enterprises to build their application integration infrastructure.

Service Oriented Architecture (SOA) is at the heart of many major IT initiatives and vendor offerings. However, while SOA has the potential to deliver business value through streamlined application integration, as well as integration with partners and suppliers, the open nature of SOA has the potential to cause problems with Sarbanes-Oxley compliance. This article will look at compliance issues inherent in developing an SOA. Using a practical example, we'll examine COSO Control Objectives, Risks, and their supporting IT systems from the perspective of Sarbanes-Oxley compliance.

An interesting convergence is taking place in the IT management world, toward Web services-based management protocols. One of the driving factors in this convergence is the effort to improve the agility of enterprise IT, such as HP's Adaptive Enterprise, IBM's On Demand Computing, and Microsoft's DSI.

The fact that you're reading this article means that you are probably planning a service-oriented architecture (SOA) initiative and recognize that some level of governance is required in order to be successful. If you are like most people in this position, you are also somewhat confused as to the meaning of SOA governance. Governance is the current buzzword, and combining governance with SOA creates a phrase that every independent software vendor (ISV) wants a piece of. How do you sort out what is marketing hype from what is truly valuable and relevant to your organization's SOA efforts?

Service-oriented architecture (SOA) and Web services are being critically considered by most organizations today in some form or another. The adoption of SOA and Web services has gained momentum after the standardization of various aspects such as security, business process coordination, transaction management, communication protocol, registration and discovery, etc. However, one notable and practical aspect of designing, implementing, and managing services has not been tackled at a specification level. This aspect is related to the management of change and interface versions.

The world of IT management has changed a great deal since the early days of SNMP and network management. IT organizations today are building and deploying a wide range of systems and applications that must be managed in a consistent and reliable way. Applications are being built from the ground up using service-oriented design principles, and an IT manager can no longer look to a single machine to determine the health and availability of the services being delivered. Resources are much more distributed and interconnected, and they are being deployed at an alarming rate. For IT, this poses additional challenges in having to keep track of changes and to build management solutions that can aid in linking business needs to IT.

Business data is one of the most critical components of the IT portfolio of any enterprise. Most e-business applications are responsible for reading and writing business data in some form or other. Therefore, the efficient storage, retrieval, and management of the data constitute a challenging problem in all organizations.

The article 'Web Service Management - Architecture patterns' (Vol: 5 Iss: 3) that had appeared in Web Services Journal is no longer available from SYS-CON Media, but you can read it as it was originally published in IBM Systems Journal. 'Web Service Management - Architecture patterns' appeared originally as 'Web Services Management Approaches' by Farrell and Kreger, which was published in the IBM Systems Journal (Vol 31, No. 2, 2002) and the article can be viewed at http://researchweb.watson .ibm.com/journal/sj/412/F arrell.pdf.

Organizations looking to reduce integration costs are increasingly adopting a service-oriented architecture (SOA) to maximize their IT investment. The preeminence of Web services as a tool that can support a wide range of dynamic business processes has made it the SOA tool of choice.

Web services are gaining industry-wide acceptance and usage. They are moving from proof-of-concept deployments to actual usage in mission-critical enterprise applications. While Web services allow businesses to connect to partners and customers, the same flexibility and connectivity provide an increased opportunity for errors.

The acclaimed essayist and novelist Nora Ephron once said, 'What my mother believed about cooking is that if you worked hard and prospered, someone else would do it for you.' Nothing could better capture the spirit of service-oriented architectures (SOAs) than this statement from a person who clearly does not consider cooking a core competency. Translated to human terms, an SOA can help make sure that the right person is doing the cooking at the right time.

The more widely service-oriented architectures become incorporated into core business applications and processes, the more critical the ability to easily configure, manage, and monitor the overall infrastructure becomes. By their very nature, service-oriented architectures, or SOAs, are about enabling heterogenous, componentized, and distributed applications to work together seamlessly.

Rather than taking a myopic Web services management approach to realizing the promise of shared services, enterprise architects should focus on building the architecture that controls chaos and enables sharing and reuse.

It's relatively easy to build custom Web services. Customers are finding that it's much more difficult, however, to successfully secure and scale them in production. Six tips from Canada's largest loyalty reward program provider, a global financial services company, and Reactivity, Inc. can help you simplify Web services deployment.

The acclaimed essayist and novelist Nora Ephron once said 'What my mother believed about cooking is that if you worked hard and prospered, someone else would do it for you.' Nothing could better capture the spirit of Service-Oriented Architectures (SOAs) than this statement from a person who clearly does not consider cooking a core competency. Translated to human terms, a SOA can help make sure that the right person is doing the cooking at the right time.

Rather than taking a myopic Web services management approach to realizing the promise of shared services, enterprise architects should focus on building the architecture that controls chaos and enables sharing and reuse.

Web services provide organizations with a flexible, standards-based mechanism for deploying business logic and functionality to distributed consumers. Consumers, whether internal or external, can access necessary components such as account information, credit card validation, and much more. When business functionality is distributed, however, quality management becomes imperative.

When I tell customers that my company does Web services management, the question I often hear is 'so what do you mean by Web services management?' It's no wonder there's so much confusion on this issue, because the term 'management' has been used to mean many different things.

Web services are like your local auto repair shop. You don't want to do business with them until you have a clear idea of the level of service you can expect. Despite the many advantages of these new, standards-based systems, they will not become core business assets without capabilities for gauging and controlling their quality of service (QoS) attributes.

With strict new regulations, such as Sarbanes-Oxley, that include serious penalties for those who do not comply, today's executives face more challenges than before. Lawyers, analysts, auditors, and corporate executives are confronting challenges they have not had to face in the normal span of their work in the wake of compliance regulations.

Application versioning has always been a challenge for the developer community. With the introduction of Web services, this issue becomes even more difficult as developers are dealing with a more distributed set of components that aren't necessarily under their control.

This article makes the case that Web services provide a significant benefit to Sarbanes-Oxley compliance projects, and that they will therefore be used extensively on these projects. We begin with a very brief primer on the Sarbanes-Oxley Act, then describe the connection between SOX and Web services, including an outline of how most Sarbanes-Oxley projects are conducted, and where Web services fit in.

Web services are no longer a collection of buzzwords in the field of e-commerce. Instead, Web services technology enables companies to effectively integrate applications from disparate platforms and partners into a composite application built on business processes.

One day, Snow White decided to deploy a Web service. Her IT dwarves immediately went to work and were pleasantly surprised to find how easy it was to create the Web service using modern development tools. To Snow White's development dwarves, it almost seemed like magic.

Much has happened to the World Wide Web since its start, with continuing and dramatic improvements that have created one of the most powerful information sharing and communications tools worldwide. During the past few years, Web applications and services have burst onto the scene, expanding on the Web's ability to deliver on its original promise of rich functionality, features, and integration.

As Web services move beyond opportunistic implementations and proof-of-concept deployments to support enterprise-wide services in mission-critical applications, the need for Web services management becomes ever more pressing.

If the content of a SOAP message is not understood or the recipient of a message does not know what to do with it when they get it, then using Web services for business, even with extensions for reliable delivery and security, will just not work.

This article outlines a set of best practices for service-oriented integration (SOI) by reviewing the evolution of integration practices, applying those lessons to service-oriented architectures (SOA), and finally analyzing SOA and SOI with the specific technology set of Web services today and into the future.

Web services have become the integration platform of choice for enterprise applications. Those applications by the very nature of their enterprise-scale components can be complex in structure, which is compounded by the need to share common data or context across business processes supported by those applications.

In the first part of this article (WSJ, Vol. 3, issue 9), we examined the need to integrate business transaction management (BTM) software into business process management standards and products. We believe that BTM offers previously inaccessible levels of application coordination and process synchronization, radically simplifying the design and implementation of transactional business processes.

If your company is like most, it is likely that your suppliers, vendors, distributors, and partners have exposed dozens of Web services for your use.

The Internet makes it possible to deliver information almost instantaneously - anytime, anywhere - and is redefining the traditional boundaries around organizations and their IT systems. The Internet has turned buyers into sellers, sellers into buyers, and set new expectations for how services should be delivered. These expectations raise the bar for applications in terms of their need for interconnectivity and responsiveness.

Business transaction management (BTM) is a promising new development in general-purpose enterprise software. Most large companies are devoting significant resources to the problem of reliable, consistent integration of application services.

Portlets are visual components that make up a Web page residing in a Web portal. Typically, when an end user requests a personalized Web page, multiple portlets are invoked when that page is created. An example is a news/financial portal that displays a single page that includes updated financial news, a report on how the stock market is doing, and the latest information on stocks of interest to the end user. Each component consists of one or more portlets.

Web services is now delivering on the promise of interconnecting systems, within and between organizational boundaries. But the benefits of open interoperability of such distributed resources only increase the complexity of the computing environment that has to be managed.

Web services represent a quantum leap forward towards achieving not only interenterprise application integration, but also cross-enterprise application interoperability. These services will enhance operational efficiency and agility, and unlock the intrinsic value of the company's goods and services, thereby creating new market opportunities.

The emergence of Web services is forcing sites to substantially rethink how existing applications can and should work together. Previously, considerations about where certain functions should execute focused principally on the tier.

WSJ readers are already familiar with the concept and promise of Web services. For some time, media and industry analysts have been touting the revolution about to occur in the programming world as a result of universally accessible, reusable code that can be assembled to accomplish any business task.

Many companies are in the initial planning and pilot stages with Web services initiatives and may not think they need to consider management solutions right now. They need to think again.