Driven by SaaS market momentum, the growth of large service ecosystems involves radical changes in both enterprise Business Process organization and IT infrastructure to fit interoperability and agility requirements. Many questions associated with the paradigm shift arise: how can we move to a network of services of Internet scale transparently available across the many devices we use to access information?

Web Services are becoming the chosen way of exposing interoperable units of work as services. Today consumers and providers of software services talk different languages, and SOAP makes them understand each other. SOAP can be transported via almost anything, and we sometimes joke that we can even do SOAP over FedEx if necessary.

Next-generation middleware exploits IBM System z specialty engines, redefining mainframe total cost of ownership and spurring expanded legacy participation in Service Oriented Architectures. Of all the wonders Service Oriented Architecture has wrought in the business world, one of the most valuable has been to unlock legacy data, applications, and processing resources for new and profitable use.

If you had to pick a single business benefit that service-oriented architecture (SOA) can provide, it is the ability to respond to change. Change occurs continually in a multitude of places that affect the enterprise: the market, the supply chain, strategic processes, regulations, and so forth. SOA can enable the creation of an agile environment that creates stability in the face of change because it restructures automated functions into reusable pieces that can be quickly reconfigured into new or modified processes.

Traditionally DOM or SAX-based enterprise applications have to repeat CPU-intensive XML parsing when accessing the same documents multiple times. VTD-XML 2.0 introduces a simple general-purpose XML index called VTD+XML (http://vt d-xml.sourceforge.net/per sistence.html) that eliminates the need for repetitive parsing of those applications.

This is the time of year when trend or predication articles start cropping up. Year after year I'm asked if I would be interested in writing about what's to come. You see I have an uncanny ability to pick lottery numbers. Unfortunately my lottery guesses, like most articles that look into the future, aren't right most of the time. So I usually say no, and leave my writing time to topics of here and now.

Service Oriented Architectures are increasingly being used to implement high-performance and real-time systems. Traditional systems operate in 'human real-time,' where human patience is the limit. Increasingly, however, systems operate in 'computer real-time,' where the only limits are imposed by the operational speed of the computers and networks.

Service Oriented Architecture (SOA) has been discussed as an important architectural style for the last few years. Organizations have started to develop service-oriented solutions and many are now leveraging services in their production environments. SOA introduces new technical complexities and challenges and makes testing a critical component of the development lifecycle.

Merger and acquisition expenditures exceeded $2.7 trillion worldwide in 2005 and are expected to grow through 2009. However, according to McKinsey and Company, the big global strategy consultancy, 'Half or more of the big mergers fail to create significant shareholder value.... The sad conclusion is that an average corporate control transaction...delivers little or no value in the return.'

The Web is evolving as an open platform with rich user interface capabilities of desktop clients. This has triggered user-driven management of service consumer ecosystems, expanding the reach of SOA with rich interactive controls and Web 2.0 tools to access the Web content and services. However the usability dimension of these Web 2.0-based service consumer ecosystems is often ignored, leaving doubt about whether present usability testing techniques in Web-based systems are capable enough to guarantee a usable experience in RIA-based service consumer systems.

You are equipped with a technical understanding of Web Services. You are a strong believer in the power of Service Oriented Architecture (SOA). Now you're eager to bring SOA to your enterprise. You want to get maximum benefit from SOA, so you propose to service-enable the key functions of your company's enterprise resource planning (ERP) and customer relationship management (CRM) applications and automate cross-application processes like order-to-cash.

In the telecommunications industry there's a special phrase for that bit of technology that carries data from the last pole or relay box into the customer's home. It's called 'the last mile' and it's often seen as one of the biggest challenges because this last step in the technology chain can be a considerable physical undertaking. In the IT industry we also have our 'last mile': putting the right application in the hands of the end user. Composite applications address this 'last mile', combining a rich user interface with SOA-driven application integration technology.

If Service Oriented Architecture (SOA) is all about business agility, then why does the focus continue to be on how services will be built, deployed, and managed by IT instead of how they'll be consumed by business users? How will SOA services to be rolled out in your organization? Through a Web browser or rich Internet application? Will these Web applications totally replace the applications your business users are currently relying on?

Provisioning is the automation of all the steps required to manage user accounts or system access facilities or data relative to electronically published services. The Provisioning Services Technical Committee (PSTC) at OASIS, the premier standards body for SOA-related standards, defined an XML-based framework named Service Provisioning Markup Language (SPML) for exchanging user information, resource information, and service provisioning information in systems. In this article, we'll explore the role of SPML in managing identity and resource information in SOA environments.

You have purchased applications. You have existing in-house applications. You have applications you are in the process of writing from scratch. Now your CIO wants to know how all these applications are going to start leveraging this 'SOA' that's been in all the papers. Ah yes, S-O-A, the elusive Service Oriented Architecture. You've read the analyst reports. You've watched some online webinars. You even have a fancy poster in your office. It all sounds good, but you're not quite sure how it applies to your environment.

Security has the inherent nature of spanning many different layers of a Web Services system. Web Services vulnerabilities can be present in the operating system, the network, the database, the Web server, the application server, the XML parser, the Web Services implementation stack, the application code, the XML firewall, the Web Service monitoring or management appliance, or just about any other component in your Web Services system.

Patterns emerge as software engineers begin to notice recurring problems. If you design software and you face a situation in which you ask yourself 'Gee, I can't be the first person facing this problem!' your search for a pattern has just begun. Once you find and apply a pattern, your solution will not only benefit from the knowledge gained in the past, but this pattern might also open a door to related patterns.

(Found in a blog, 'Versioning is as inevitable as security.') SOA development practice isn't much different from other software development practices except for design and maintenance. Multiple self-containing and aggregated services that interact with others have their own lifecycle and evolution. The loosely coupling model of SOA services significantly simplifies design but creates additional difficulties in maintenance, especially in the interoperability of different service versions.

One of the challenges IT organizations face is how to propagate identities in complex business processes that are commonly found in Service Oriented Architectures (SOAs). Identities, which are passed from one service invocation to the next in a business process, give the process a user context. Identities can be used to determine access rights to SOA services and for audit and compliance purposes.

With power comes responsibility. The promise of Service Oriented Architecture (SOA) offers significant opportunity for service reuse and the realization of a fully integrated enterprise. But left unchecked, the flexibility enabled by an SOA will result in a Wild Wild West of enterprise IT. To properly harness the power of SOA while delivering value for the enterprise, certain controls are essential. Incorporating service discovery, service security, service management, and policy governance in a ubiquitous and transparent framework is essential to the success of any enterprise SOA deployment.

'Few people know that the first webpage ever created, Tim's home page, was actually a blog,' writes Alex Krupp. 'Blogs are the epitome of Web 1.0. They focus so much on the individual that even Ayn Rand would blush. At their best they can be truly uplifting and inspiring, but on average there are some serious problems with blogs as they exist today. Blogging will be around forever, but I think that personal blogs will be dead in another two or three years.'

Prior to the year 2000, business was a world in love with office spaces and corporate travel. We traveled to work (the office) every day. We traveled away from the office for customer meetings, for internal meetings, for conferences, for awards ceremonies. We traveled because we could and we believed that it was necessary for the competitive advantage. That all changed rather quickly with the economic downturn of the early 2000s and, of course, 9/11. In short order, we relearned how to do business by staying put.

Service-oriented architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers, and service producers can coexist, and still have no dependence on each other. SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets. These software assets, together with the functionality that they provide, are called services in the SOA terminology. By nature, SOAs are complex and are typically applied to solutions with highly volatile requirements.

EII and SOA are two of the newest acronyms bandied about in enterprise IT departments. Application architects are seeking to build loosely coupled applications with Service-Oriented Architecture (SOA). Data architects are trying to make information more widely available with Enterprise Information Integration (EII).

In most software topics, the boundary between theory and practice in software is clearly demarcated: theory is for academics who seldom descend from the ivory tower, practice is for industry professionals who have long forgotten the concepts and application of theory. In concurrency, for example, most developers either know or have programmed semaphores, but few remember the conceptual underpinnings devised by Dijkstra.

The past several years have seen some significant technology trends, such as service-oriented architecture (SOA), enterprise application integration (EAI), business-to-business (B2B), and Web services. These technologies have attempted to address the challenges of improving the results and increasing the value of integrated business processes, and have garnered the widespread attention of IT leaders, vendors, and industry analysts.

Object-oriented technologies are used today in the design and development processes for many computer systems; it is a proven paradigm and has made possible the development of large and complex software systems. Enabling platforms and tools for building and consuming Web services will not be an exception.

Concerns about security are cited as the single largest barrier to rapid Web services adoption. Yet most Web services today are fairly straightforward point-to-point integrations that can be securely implemented using only digital certificates and the Secure Sockets Layer (SSL) protocol.

To RPC, or not to RPC: that is the question. Whether 'tis nobler in the mind to suffer the control and dependency of coupling, or to take arms against a sea of troubles, and by opposing, end them?

The Web services paradigm is poised to become the dominant form of distributed computing this decade and beyond. Indeed, A. T. Kearney, an EDS global consultancy, found that 75% of companies ranging from less than $50 million to more than $1 billion in revenues and across 20 vertical industries have already deployed one or more Web service.

SOAP is at the heart of all Web services as the way to deliver messages between two applications or systems. SOAP in its various versions is well known and often discussed.

UDDI (Universal Description, Discovery and Integration) is a registry for Web services. It provides a mechanism to advertise and discover Web services. Although you don't need to use UDDI to implement a Web services solution, you'll find that a UDDI registry greatly simplifies the management and administration of your services, particularly once they have reached a certain critical mass.

The work being done in WSDM will lay a firm foundation for effective distributed system management, both leveraging the unifying strengths of Web services in the solution itself and addressing the specific requirements for managing what are rapidly becoming the universal glue in enterprise system design.

In the past there seemed to be two more or less exclusive routes to integration: 'roll your own' or buy an EAI product. Typically, developers would choose the first option for maximum flexibility, while project managers preferred the second, for consistency and security.

Web services and service-oriented architectures are transforming application construction. The ubiquity of Web services support by all leading platform venders brings the promise of a flexible application environment with simplified interface techniques, location transparency, and platform-neutral interoperability. This dynamic infrastructure brings about a new implementation approach, the service-oriented architecture.

Web services promise to lower the costs of integration and help legacy applications retain their value. This article explains how you can use them to integrate mainframe CICS applications with other enterprise applications.

Managing change in a software system is a lot like balancing your personal finances. With or without a resource allocation plan, the assets available and the demands placed on them change constantly. Whether it's your code or your checkbook, the result of mismanaging change over time is likely to be the same: disaster.

Over the last few years, there have been significant developments in the Web services world. Many enterprises have embraced Web services to build business-to-business transactions and a uniform communication layer among applications over corporate intranets.

In July 2002, BEA, IBM, and Microsoft released a trio of specifications designed to support business transactions over Web services. These specifications, BPEL4WS, WS-Transaction, and WS-Coordination (see WSJ, Vol. 3, issues 5-7), form the bedrock for reliably choreographing Web services-based applications, providing business process management, transactional integrity, and generic coordination facilities, respectively.

It's easy to develop Web services using Ruby. This article looks at how to develop a Web service client to access the Web services that are hosted in the Internet and how to develop a Web service with simple steps using Ruby.