Java Web services « SOA Web Services « Java Articles

All the APIs necessary for building and deploying Web services in Java will emerge from the JCP. Launched in December 1998 and revamped in 2000, the JCP is the process by which Java evolves and it will play a significant role in Java's future. However, many question the JCP's efficiency and capability in addressing Web services. Is the JCP adequately preparing Java for Web services? Perhaps a look at its recently released and forthcoming Web services APIs will give us the answer.

If you must consider only interaction between Java programs, you can just use the Java type system or the custom types you defined on top of the basic Java types, such as person. Java Remote Method Invocation (RMI) is a service-oriented framework that relies on the Java type system for service definition: if both programs are written in Java, they can just communicate on the Internet via RMI. XML-based Web services, on the other hand, require that you define a Web service in a type system not tied to any specific programming language; you must map types defined in a programming language to language-neutral types, and vice versa.

An obvious question is, "Why should I care?" For the skeptic, Java SE 6 has improvements across the board, from opening programmatic access to the Java compiler, to system-tray and splash-screen components, to mixing scripting languages with your Java source code (with JavaScript supported out-of-box), to a dapper look and feel in Swing, to XML digital signatures, to the Smart Card I/O API, to JMX monitor threading improvements, to Web services annotations for service providers and simplified client access—to name just a few of the new features coming our way. (The java.net Website provides everything you wanted to know about this new release.)

These standards allow for core application assembly, taking the place of Enterprise JavaBeans (EJB) and other major vendors' competing standards. Chief industry players, including Hewlett-Packard, IBM, Microsoft, and Sun, are currently working to strengthen Web services technology and standards like SOAP and WSDL. Vendor toolkits allow pre-existing JavaBeans to easily adapt to Web services. The Java 2 Platform, Enterprise Edition (J2EE) lets you write the fundamental parts of business applications (for example, connections to databases, transaction handling, and so forth) that will run across different computing systems. Web services for servers will be included in a future J2EE release.

Web Services Business Process Execution Language, WSBPEL, is an XML-based process/workflow-definition execution language. WSBPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web services interfaces. WSBPEL also defines how multiple service interactions with these partners are coordinated to achieve a business goal as well as the state and the logic necessary for this coordination. WSBPEL, previously called Business Process Execution Language for Web Services (BPEL4WS), is often simply referred to as BPEL.

Let's follow our imaginary friend's path in this endeavor. With each step, we will have a set of programs that form the fancied Magellan Travel system. A common thread between these programs is their use of techniques and technologies that together define the term Web services. As a Java developer, you already know quite a bit about Web services, perhaps without realizing it. Thus, the journey will take us through familiar territory, placing that territory in a new context. In one regard, though, Web services aredifferent from anything most Java developers have encountered before. To appreciate that difference, we'll take the elevator up to our friend's office and catch a birds-eye view of what a Web services program looks like.

For a decade, we've understood the benefits of delivering software through the Web: zero installation, platform independence, anywhere/anytime access, continuous improvement. The drawbacks have been equally obvious, or so it has seemed. The browser-based application has not held a candle to conventional software's rich interactivity, split-second responsiveness, and offline-capable local datastore. The resurgence of interest in what is now called AJAX (asynchronous JavaScript and XML), however, has cast doubt on the first two objections. Browser-based software has always been capable of highly dynamic behavior, thanks to DHTML (dynamic HTML). It has also long been capable of interacting autonomously with remote XML services. These two functionalities, recently stabilized as de-facto cross-browser standards, are powering a new generation of Web applications that are richer and more responsive than many thought possible. And although the lack of a model for offline use remains a factor, it reduces in importance as connectivity becomes ever more pervasive.

What do searching for extraterrestrials, curing cancer, and finding big prime numbers all have in common? These problems are all being attacked with grid computing, a a technique of breaking a large problem into small tasks that can be computed independently. While projects like Seti@home and The Greatest Internet Mersenne Prime Search have received plenty of press for using the Internet to distribute tasks to end users around the globe, grid computing also takes place in more controlled environments, such as research and financial settings. But it is by using the power of the Internet and the ability to discover and access idle processes on users' machines that grid computing (once called distributed computing), can access massive numbers of machines and processes.

With Java Web services, the server-side Java developer can build interoperable applications for delivering services to other servers and PC-based or wireless clients. The technology for Java Web services primarily consists of the recently announced Java Web Services Developer Pack (WSDP). This pack consists of the Java API for XML Pack(the so-called JAX Pack), the JSP Standard Tag Libraries (JSTL) API, and the Java Secure Socket Extension (JSSE) API -- along with the Jakarta Tomcat Web container, the Ant build tool, and the UDDI-based registry server.

This article introduces a new way of building enterprise software by leveraging grid computing concepts implemented by the Globus Toolkit version 4 (GT4). GT4 is an open source implementation of the Open Grid Services Infrastructure (OGSI). The implementation is intended to serve as a proof of concept for OGSI, and to be used as a reference for other implementations. This article addresses only the GT4 Java core services, which provide a run-time environment capable of hosting grid services written in Java. The run-time environment mediates between the application and the underlying network, and transport protocol engines.

Over the last six months, a number of standards have begun to emerge in the areas of Web services' lifecycles, security measures, collaborations, and transactions. JSRs have emerged to begin the process of defining, in a standard way, the different aspects of how Web services might be supported in a J2EE-compliant application server.

There are no clear answers about our technology future. But the issues raised during this keynote, and at JavaOne as a whole are certainly worth thinking about.

Web Services have at their core XML as a mechanism for communication. Ultimately, Web Services are based on three specific technologies: a mechanism to register a service, a mechanism to find a service, and a mechanism for two parties to communicate. Today, developers can use the Java 2 Enterprise Edition APIs and XML to provide Web Services. Such developments leverage existing Web sites and provide simple methods to extend, interconnect and publish existing J2EE-based applications in new and exciting ways.

In part one in this series of book excerpts from Programming .NET Web Services, learn how to write an ASP.NET HelloWorld Web service application.

Interoperability is one of the main promises of Web services. Web services are designed to be independent of the underlying operating system and programming language. In this article we will introduce basic web services interoperability issues. We will focus on the two most popular platforms - Java and Microsoft .NET.

In this article we'll show how to expose J2EE components as Web services and how to use the Java Message Service (JMS) to send SOAP messages reliably. We will mainly speak about Enterprise Java Beans (EJBs), because they are the most widely used J2EE components for business logic implementation, but all demonstrated techniques are also applicable to other J2EE components, such as JDBC data sources and JMS queues.

J2EE has historically been an architecture for building server-side deployments in the Java programming language. It can be used to build traditional web sites, software components, or packaged applications. J2EE has recently been extended to include support for building XML-based web services as well. These web services can interoperate with other web services that may or may not have been written to the J2EE standard.

This chapter from "SOA Using Java Web Services" examines how to build an Ajax front-end to an online shopping application. Through detailed code examples, it walks you through building an Ajax application that consumes RESTful Java Web services endpoints.

This transformation not only serves as a humungous case study for how customers can best use HP products, emulate our processes, and adopt our organizational and financial models, it also establishes the parameters under which HP.com?s architecture must function. How do you cut IT cost while increasing efficiency? Perhaps surprisingly, it all starts with governance.

I'm an advocate for testing XML-based Service-Oriented Architecture (SOA), Enterprise Service Bus (ESB), Web services and Business Integration (BI) based services. Even risky ad-hoc testing is good. (It's risky because most of the time results from ad-hoc tests are misleading). In my experience the business value of running scalability and performance tests comes once an organization formalizes a test method that includes the following:

The purpose of this article is to introduce the basic structure of UDDI, explain how it works and how it might be useful, then explore using a live UDDI registry. We begin by outlining the data model used in a UDDI registry, then describe the UDDI API. Using a publicly available UDDI implementation at freedb.org, along with a Web services runtime server, we'll provide examples of discovering and publishing information. At the end of this article readers should be familiar with the basic concepts of UDDI, and understand how to work with a UDDI registry.

Anybody who thinks that buying an application server (such as WebSphere or WebLogic), combined with a Web Services toolkit (like GLUE, as good as it is in this role), is sufficient for building Web Services is simply not seeing the big picture. The intent of this article is to help you cut through the hype and understand the requirements of real world Web Services by describing the Service Broker, a fundamental new type of Middleware platform that will be used to build enterprise-scale Web Services. A Service Broker is similar to a message broker but is much more flexible. It is used to make a company's services work together and to provide a simplified interface to external systems using a variety of middleware (Corba/IIOP, Messaging, SOAP, Web Services). Companies interested in setting up Web Services will likely use a Service Broker as the backend to their Web Services protocol interfaces (UDDI, SOAP).

.NET, of course, is solely a Microsoft architecture. While it is not impossible for other companies to implement the .NET architecture or at least parts of it, all of the other big players are already committed to Java. Probably one of the main reasons for this is that previously, the Microsoft component architecture was highly integrated with the Windows operating system. Although the .NET framework specification, and more specifically the CLR (Common Language Runtime), improves the possibility of running on other operating systems, there is still far too strong a binding with the Windows architecture to allow easy porting. Microsoft has no form of community process or open source initiative. They have recently announced access to source code for their larger beta test companies, but have also clearly damned open source as being a noose around the neck of innovation. From my perspective, open source does not hinder innovation, but it places a different slant on profitability. IBM now supports Linux along with Java on all of its platforms, and the Apache Web Server as part of WebSphere. This has actually improved IBM's software business and aided in the more rapid development of innovative products.

This white paper takes an in-depth look at the open-source tools that can be used to get started on Web services development. In the application, it is shown how an existing Java asset is exposed as a Web service interface through the entire development lifecycle. The application was developed, deployed, and tested on an HP laptop running on Debian Linux. The MySQL Open Source database and the BEA JRockit Linux JVM were used. The Eclipse environment was used in the creation of the Java components, while Apache Axis and Tomcat were used to develop the Web service. Apache Ant and Eclipse were then used to deploy the Web service, and PushToTest TestMaker was used for testing it.

So, why do you care about these outdated, primitive mainframe systems that are brittle and difficult to work with. You are a Java/J2EE developer using web services, BPEL process managers and ESBs to achieve you job on a daily basis. According to a survey by the Software Development Times ??mainframe applications show up in 47 percent of SOA applications??. This means if you are involved in an SOA project there is almost a fifty percent chance you will have to ?deal with? a legacy mainframe system.

Basic Web Services aren't very difficult to create. To prove this point, we'll show you, in this first article, how to construct a Web Service in about 30 minutes. In subsequent articles we'll delve deeper into Web Services and explain the following topics in detail:

Service Oriented Architecture (SOA) promises to provide us with the ability to assemble complex, distributed systems by selecting and creating compatible parts called services. So far, SOA has delivered a lot of hyperbole to the Web. Gartner recognized it as one of the five hottest IT trends in 2005, claiming that "By 2008, SOA will provide the basis for 80 percent of development projects." At JavaOne 2005, 82 of the 168 technical session PDFs contained "SOA." In July of 2005, there were 1.4 million Google hits for "service oriented architecture." By February, 2006, there were 72 million. SOA is riding a rising tide as the next big thing for enterprise developers.

The Java Web Services Developer Pack (Java WSDP) has evolved into an integrated toolkit for developing, building, testing, and deploying web Services, as well as web and XML-based applications. The current version of Java WSDP, 1.2, contains the latest versions of Java and XML technologies for building reliable and secure web services. It has added new features, fixed bugs from earlier releases, and made developing and deploying web services easier. More importantly, Java WSDP 1.2 is implementing cutting-edge industrial technologies such as the XML Web Services Security (XML Signature) and Web Services Interoperability (WS-I) Basic Profile.

Fast Web Services is an initiative at Sun Microsystems aimed at the identification of performance problems in existing implementations of Web Services standards. Our group has explored several solutions to these problems. This article focuses on a particular solution that delivers maximum performance gains. Fast Web Services explores the use of more efficient binary encodings as an alternative to textual XML representations. In this article, we:

Recently, Sun Microsystems made available through its Early Access Release Program the Java Web Services Developer Pack (WSDP), Early Access Release 1, a package of technologies and tools for building and testing Web services using the Java programming language, and for building and testing Java applications that access Web services.

Java Web Services Developer Pack Java 2 Platform, Enterprise Edition (J2EE) Web Services and Java Technology Web Services Technical Articles on java.sun.com Java API for XML-Based RPC (JAX-RPC) Java API for XML Messaging (JAXM) SOAP with Attachments API for Java (SAAJ) Simple Object Access Protocol (SOAP) 1.1 SOAP Messages With Attachments Web Services Description Language (WSDL) 1.1 ebXML Message Service Specification V1.0 ebXML Transport, Routing & Packaging Version 1.0

The Java Web Services Developer Pack (Java WSDP) has evolved into an integrated toolkit for developing, building, testing, and deploying Web Services, as well as Web and XML-based applications. The current version of Java WSDP, 1.1, has added new features, fixed bugs, and made developing and deploying Web services easier. This article provides a quick overview, describes the technologies that are now part of Java WSDP 1.1, and highlights the new features focusing on the new installer and the Java Architecture for XML Binding (JAXB).

Previously in the Learning Curve Journal, we used JavaFX Script to reproduce the user interface (UI) of an existing Image Search application that searches images on Flickr. The resulting JavaFX Script representation, while not exactly the same as the original, is fairly close. Figure 1 shows the basic UI produced by the JavaFX Script implementation.

With the widespread interest in web services, it's no surprise to learn that the Spring group has an offering called Spring web services. In this article, we'll examine one of the examples that comes as part of the Spring web services distribution. What does Spring do with web services that's a little different; what's the Spring value-add? A few things, actually! One is that users of Spring web services get all the benefits of the Spring approach. (If Spring is new to you, my article "Hit the Ground Running with the Spring Framework" may be of interest.) The benefits of Spring include application contexts, dependency injection, ease of configuration, and so on. Another major benefit of the Spring web services approach is the use of contract-first service design. I'll discuss this in more detail, but for the moment just think of it as a design approach that produces an interface (technically this a WSDL file) before writing the implementation.

Thomas Erl is interviewed by Joe McKendrick about service inventories - collections of independently designed and governed services. Thomas discusses the popular Domain Inventory pattern commonly used when enterprise-wide SOA adoption is not possible.

Anish Karmarkar, co-author of the book "Web Service Contract Design and Versioning," offers his insight into standards committees, and describes the fundamental building blocks that contribute to web service interoperability.

The Spring Forum increasingly recommends the use of application contexts for J2EE development. After you master this important area, you're beginning to get a good grasp of the Spring philosophy. Spring technology is not restricted to development of web applications; you can use Spring in any application that supports the use of JAR files.

An organization needs certain core technical competencies if it is to succeed with SOA. Good SOA governance is all about developing these competencies and creating governance mechanisms that ensure the service factory runs as smoothly and as efficiently as possible. The following subsections define these core competencies.

The internationally acclaimed book SOA Design Patterns documents a catalog of 85 patterns that spans nearly 900 pages and over 400 illustrations and is the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl. This book was released in coordination with the launch of www.soapatterns.org, a community site dedicated to the on-going development and expansion of the SOA patterns catalog. The "SOA Pattern of the Week" article series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOA Design Patterns book and the SOAPatterns.org community site. Each article provides a summarized description (600-800 words) of one pattern with some new insights to complement and build upon the content in the book. The series is expected to continue for 85 weeks, into 2010. Note that this book is part of the official curriculum for the SOA Certified Professional (SOACP) program .

Some big players, such as IBM, are pushing the Web Services Distributed Management (WSDM) standard. [1] Others, such as Sun Microsystems, are holding back. Sun recently voted against WSDM becoming an OASIS standard, while IBM voted in favor of standardization—a large majority carried the vote.

It’s clear that in most service-oriented solutions the non-agnostic logic needs to be separated from the agnostic logic, but why does it need to be located in services? The short answer is: “it doesn’t.” You can position this parent logic in a rich client, a monolithic system, or some other software program that is evidently not service-oriented, and the service composition can still be carried out. The Non-Agnostic Context pattern does not require that you create task services, it simply points out that there are benefits to doing so.

Anish Karmarkar, co-author of the book "Web Service Contract Design and Versioning," offers his insight into standards committees, and describes the fundamental building blocks that contribute to web service interoperability.

The SOA Pattern of the Week series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOAPatterns.org community site and the book “SOA Design Patterns” (Erl et al., ISBN: 0136135161, Prentice Hall, 2009), the latest title in the Prentice Hall Service-Oriented Computing Series from Thomas Erl (www.soabooks.com).

The meaning of these items becomes clear from the WSDL document that resulted from running apt on the Web service definition. The generated WSDL is as follows:

Have an opinion about the directions in which JAX-RPC is headed? Discuss this article in the Articles Forum topic, Recent JDK Features Ease Web Service Development.

This article explains how to expose existing POJO-driven J2EE applications as web services using Axis2, while still providing enough room for scalability. It describes leveraging Spring, which already serves as the underlying dependency injection container for many J2EE applications today, to further facilitate the creation and control of these services. Finally, it discusses deployment strategies for Axis2 enterprise web services and lists the specific concerns with certain application servers such as IBM WebSphere.

The technologies that are used to develop Web services are divided into four groups: Core Web Services, Enhanced Web Services, Secure Web Services, and Legacy Web Services. Web services are also used for Systems Management.

This article demonstrates how to create a Web service application from an existing J2EE application using Oracle OC4J J2EE application server and Apache Axis. With downloadable source code, it provides a step-by-step tutorial for building a simple J2EE application and then Web-service enabling it with Axis.

The Hessian binary web service protocol makes web services usable without requiring a large framework, and without learning yet another alphabet soup of protocols. Because it is a binary protocol, it is well-suited to sending binary data without any need to extend the protocol with attachments.

In my previous article (see Resources), I introduced XML-RPC (see Resources) as an easy way to execute functions on remote machines. However, this function alone isn't useful enough to make the protocol worth learning. Instead, we will look at one interesting application of Web services in conjunction with XML-RPC: middleware.

You can implement the FastSOA architecture using Java code and relational database technology. However, I found significant performance and scalability problems when testing service bindings created with Java objects and when persisting XML using relational databases. These problems are significant enough that it makes sense to consider alternatives of XQuery, XSLT, and native XML database technology.

Today the growing popularity of the Internet and its inherent advantages have motivated developers and IT departments to migrate complex C/C++ business and scientific applications to a Web-based environment. Web services such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), and XML remote procedure protocol (XML-RPC) facilitate integration of such legacy applications to the World Wide Web, including XML-RPC as a mechanism to integrate existing C/C++ programs with other client-side technologies. This article will help you determine when to choose XML-RPC versus SOAP and REST. Also, a step-by-step guide and sample code snippets for C++ integration using an open source XML-RPC Library is provided.

Prior to JSR-109, the procedure for deploying a Web service was highly coupled to the destination runtime. Deploying a Web service to Apache Axis is quite different from deploying to Apache SOAP. Organizations that have deployed Web services in the past would require some strong arguments as to why they should switch to the JSR-109 deployment model given their previous investments. The motivation for JSR-109 is to promote the building of interoperable and portable Web services in the J2EE environment. JSR-109 leverages existing J2EE technology and provides industrial standards for Web services deployment. It clearly defines requirements that a Web service for J2EE product provider must support. It allows a J2EE Web service to be configurable via XML-based deployment descriptors and hides the complexity of the system from Web service developers, assemblers and deployers. Knowing how JSR-109 works allows you to configure a J2EE Web service without having to explore and learn the implementation details of the underlying system. Finally, as JSR-109 is adopted by Web server providers, the process of migration and deployment should become a routine procedure.

In the next installment, we'll take a look at how a Web service can advertise itself using UDDI (Universal Description, Discovery and Integration) for use by other Web services. We'll use the newly-released IBM UDDI4J toolkit to publish and bind to Web services in a UDDI repository.

On the Internet, the popularity of J2EE-based Web applications and Web services has pushed the requirement to handle thousands (or more) users simultaneously to the forefront. It is no longer a "future deliverable" luxury in many commercial deployments, but a necessity. In this competitive business environment, an online shop that hangs or crashes when there are too many shoppers simply will not survive. While scalable solutions are widely available for the transaction tier of the J2EE model (for databases, transaction monitors, message queues, and so on), solutions for scaling Web applications or services at the Web tier are still emerging. In this series, we'll take a look at several software technologies that can be applied to scale applications at the Web tier. Each technology takes a different approach and resolves a slightly different set of issues. In this first article, we will examine a popular open source distributed communication substrate called JavaGroups.

Both approaches were "legal SOAP" (although the approach taken by Apache's implementation was admittedly a bit legalistic and inflexible), but they were incompatible with each other. Apache SOAP did not and still doesn't, I might add, understand the Service Description Language used by Microsoft, that has gone through three iterations. First it was the "Service Description Language" or SDL, then as the "Service Contract Language" or SCL, and now as the Web Services Description Language or WSDL.

The input parameters and return values of data types of a Web service operation have a great impact on the interoperability of the Web service. Web services serve as transport for an XML document exchange. When data objects push down into a Web service stack, they serialize into XML data representations. The Web service stack on the other side needs to know exactly how to map those XML data representations to the needs of the environment of the local application (for example, the de-serialization of XML data). The XML Schema definitions are what drives the mappings. The objective of the XSDs is to guarantee that the type sent has a reproducible version on the other end. But due to the implementation difference in the underlying technologies (Java? 2 Platform, Enterprise Edition (J2EE) technology versus Microsoft® .NET), the mappings between XSDs and native data types on those platforms might be different. Some of the differences might result in de-serialization failure, while others might cause information distortion.

This tutorial provides an overview of Amazon Web Services (AWS). AWS exposes raw product information and key parts of Amazon.com technology to third-party developers for use in their applications. After describing how AWS works in general, the tutorial focuses on the main AWS service, called the Amazon E-Commerce Service (ECS). As part of this tutorial, you will develop a small Web application that uses ECS to display book and music information. (Series: Boost application development with Amazon Web Services, Part 1)

I'm not quite sure what happened, but I've always thought the proper use of include and extend associations, as well as uses and extends associations in older versions of the UML, were never described well. As a result, use-case modeling teams had a tendency to argue about the proper application of these associations, wasting an incredible amount of time on an interesting, but minor, portion of the overall modeling technique. I even worked at one organization that went so far as to outlaw the use of the <> and <> stereotypes, an extreme solution that had to be reversed after a few weeks when it was realized that the company still needed these concepts, even though the organization hadn't come to a full agreement as to their proper use.

In both J2EE technology and .NET, it is quite common to share XSD schemas among multiple Web services. In fact, it is one of the best practices to share XML schemas for the sake of modular design and reusability. The XML tag: import and include, are used just for this purpose. For example, you can design a schema for a Product type for a merchandise warehouse, as shown in Listing 5:

In this article, I have explained how to create a system that uses your browser to access an arbitrary Web service. JavaScript code calls a method within an applet, which calls a servlet, which retrieves the remote information. In this way, you bypass restrictions on what an applet can and cannot do.

The Web Services Resource Framework defines a system for creating stateful resources between Web services in terms of an implied resource pattern.

Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. With the Smart SOA approach, you can find value at every stage of the SOA continuum, from departmental projects to enterprise-wide initiatives.

XML-RPC is the granddaddy of XML Web services. It is a simple specification for remote procedure calls (RPC) that uses HTTP as the transport protocol and an XML vocabulary as the message payload. It has become very popular because of its simplicity (the full specification is less than ten printed pages), and most languages now have standard or readily available XML-RPC implementations. This includes Python, which started bundling xmlrpclib, an XML-RPC implementation by Fredrik Lundh, in version 2.2. Joe Johnston's IBM developerWorks article "Using XML-RPC for Web services" (see Resources) covers the basics of XML-RPC in the first three sections. Start there if you need to review the basic technology. In this article, we will focus on using the Python implementation. You must have Python 2.2. to run the examples in this article. Also, in the last article, we looked at the relative performance of XML-RPC, SOAP, and other distributed programming technologies. You may want to read that before making major decisions to deploy XML-RPC.

This is the sort of information defines an API to the XML-RPC listener. Unfortunately, the XML-RPC specification doesn't provide any standard discovery method for listeners to transmit this information. I recommend using a simple Web page that looks like Table 2.

So far your columns have been all about session and entity EJBs for services, which is great for directly connected Java applications, like HttpServlets for Web based clients, or Swing applications for rich (we don't like to say "fat") clients. But we have heard that service-oriented architecture is all about loose coupling. Doesn't that imply using SOAP to provide language neutrality and asynchronous protocols that enable the client and server applications to run independently as much as possible? In other words, why haven't you talked much about JMS and message-driven beans?

A common requirement these days for database application developers is to be able to expose functions that access data on the Web. In this article, we show you how to expose an Informix user-defined routine (UDR) or user-defined datatype (UDT) on the Web as a Web Service, as part of service-oriented architecture. We'll use a JavaBean for interacting with an Informix UDR or UDT, and deploy it as a Web Service using Rational Application Developer (RAD).

The correct handling of API versioning has been one of the most difficult issues faced by developers of distributed systems. Various schemes have been proposed, ranging from the laissez faire approach taken by CORBA to the stricter schemes used in DCOM. With the advent of Web services, there are some new features that you can take advantage of that can help alleviate the problem, but the brutal fact of the matter is that versioning has not been built into the Web services architecture. Current products from IBM and other vendors do not directly address the versioning issue, requiring developers to solve the problem through the application of patterns and best practices.

The following statement may shock you, given that I am the EJB Advocate -- but just because you can code everything on the server side in Java using EJB components doesn't mean that you should. My take is that we are seeing a natural evolution of technology on the sever side similar to that which we saw with Java? servlets on the client side.

Dynamic modeling techniques focus on identifying the behavior within your system, including sequence diagramming and activity diagramming (see "How to draw UML activity diagrams") and UML collaboration diagramming. Meanwhile, static modeling focuses on the static aspects of your system including the classes, their attributes, and the associations between classes. Class models are the main artifact of static modeling as are persistence/data models.

Applying SOA concepts to the user interfaces and delegating common software life cycle functions to a UI container using the portal/portlet architecture can improve time-to-value for a software developer. The WSRP standard, delivering UI components through Web services, offers advantages to both the content provider and the content consumer, enabling a type of application aggregation without programming. Portal frameworks can aggregate portlets into a user interface in a dynamic manner. The participation of users in the SOA can be modelled as a Web service, with human interactions facilitated by the Human Task Manager.

This briefing provides a technical, practical overview of SOA reuse & connectivity offerings, including the benefits and importance of an ESB in creating and maintaining a flexible IT infrastructure.

The power of the RPC/encoded model has enormous appeal to traditional object-oriented programmers who are accustomed to programming within a single organizational domain, such as J2EE technology or .NET. While it provides great ease for the Web services designers and implementers when the scope is limited to a single platform where both the SOAP message writers and readers have a synchronized stub to understand the encoded SOAP messages, it comes at a big price as Web services go global. Its powerful strength turns out to be its weakness in the face of the demand for interoperability across platforms. To illustrate the interoperability problem, examine the WSDL file that Application Developer generated from the previous Web service (see Listing 4 in this sidefile).

Web services versioning barely exists today. Each version is essentially a new Web service with new namespaces. But if you make minor, backward-compatible changes to your service as described in this paper, being careful not to change behavior, then old clients can still talk with your new service. You might even want to design your service from the very beginning to make any future, minor changes, easier.

Backward compatibility refers to a hardware or software system that can use interfaces and data from earlier generation(s) of the system. In the context of Web services, backward compatibility is concerned with how changes to an interface affect existing users (otherwise known as service consumers) of the interface. If existing users are unaffected then the change is backward compatible. If existing users are affected then the change is not backward compatible, and a strategy will be needed to manage the impact of the change.

Virtualization of business functions, a key goal of an SOA, is achieved by isolating service definition and usage from service implementation. Services may be implemented using a wide range of technologies, including IBM WebSphere® MQ, IBM CICS® or IBM IMS?, Java? 2 Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), Java classes, IBM DB2® Queries, Java Message Services (JMS), or Microsoft® .NET. Service requesters dispatch requests to a service provider that offers the capabilities they desire, unaware of its implementation.

When it comes to Web application deployment, we like to keep our options open. If your client has invested in a commercial J2EE implementation such as WebSphere or WebLogic; then they will want to take advantage of that platform. On the other hand, if your client is looking for a lower startup cost, they may want to go with an open source solution such as JBoss or Apache Tomcat. In either case, if you want to make your development efforts as reusable as possible, then you probably can not depend on the vendor-specific IDEs that may be available. Doing your development using an IDE provided by the J2EE application vendor may limit your flexibility when it comes to Java Web services and hide many of the details of deploying a Web service.

Quality of services is an important requirement of business-to-business transactions and thus a necessary element in Web services. The various QoS properties such as availability, accessibility, integrity, performance, reliability, regulatory, and security, need to be addressed in the implementation of Web service applications. The properties become even more complex when you add the need for transactional features to Web services. Some of the limitations of protocols such as HTTP and SOAP may hinder QoS implementation, but there are a number of ways to provide proactive QoS in Web services.

A key challenge for many developers and application architects who are seeking to apply these technologies, however, is the fact that amidst all the hype, there is currently very little direction available on how to best apply new technologies such as SOAP, WSDL, and UDDI within real business scenarios. Recognizing this deficiency, a number of developers and architects from across IBM's Global Services, jStart, and Emerging Technologies Groups have sought to identify and document a collection of best practices for the real-world application of Web service technologies on a scenario-by-scenario basis.

This article demonstrates the simplicity and ease of exposing a pureXML column of a DB2 database through Web service operations, using scripts without launching a separate tool. The installation of the Universal Services can be used to build your own prototypes or applications.

The briefing begins with an overview of the service management lifecycle, and continues with a detailed discussion of the implementation and management of a Service-Oriented Architecture (SOA) solution. It steps through the use of IBM's world-class Rational® and WebSphere® tools for defining, modeling, and implementing new services and managing those services throughout their lifecycle. It also discusses SOA quality management and governance throughout the service lifecycle. The briefing closes with a review of SOA best practices, resources, and calls to action.

The lastest version of WS-Addressing, a key part of the core Web services architecture, has been submitted to the World Wide Web Consortium (W3C) for the standardization process as part of a longer-term effort to provide a standards-based foundation for the development of secure, transacted, asynchronous, and reliable Web services. Read the press release and find links to the submissions on W3C.

The coming year, 2006, is going to be a banner year for Web services in general, and for Java Web services in particular. New third-generation frameworks are being unveiled, which offer much better support for doc/lit SOAP as well as potential performance improvements. At the same time, the froth of WS-* standards is finally starting to settle into a common set of interoperable layers that extend SOAP and WSDL to support core enterprise requirements.

A successful login process fetches the customer profiles, product details, and his previous order details using synchronous RPC to initialize the customer data models. TradingWebServicesMgr is the component that interacts with the manufacturer Web services on behalf of the customer client. The client makes use of a local proxy object and invokes a method on them. This proxy could be a stub in the case of static binding or a dynamic proxy, a class created by the client at runtime. In this application, the manufacturer Web service description document (TradingWebServices.wsdl) that is generated during deployment is available to the customer either directly or through a link in the public registry. Refer to the Resources section for more information on WSDL. The customer application uses this WSDL document to generate a dynamic proxy at run time and invokes calls on this object. The runtime makes use of serializers and de-serializers to transfer Java objects between the client and server. The code snippet from TradingWebServicesMgr.java below shows steps for creating serializers for the Product class and registering with the service.

Web Services Management is what we are going to talk about now. This article analyses the requirements of Web Services Management (referred to as WSM in this article) Platform. To address the functionalities required in WSM, we'll introduce the basic components of WSM. This article, then, aims to develop a basic understanding of the core components of the Web Services Management Platform.

The ExamResultService class contains a method called getResult() that returns multiple values. This may be confusing because the signature of getResult() method shows the return type as String. But here, returning multiple values is achieved by passing a parameter that acts as an input as well as output parameter. Such a parameter is called a IN-OUT parameter.

To describe a multiparty transaction, WSFL uses a new construct: the global model. A global model identifies the set of service instances that participate in the transaction (these are the service providers you saw in the section Flows as Compositions of Web Services) and uses plug links to define the interactions between them.

Now, let us understand the emergence of Web Services as the Internet-based standard to share information among incompatible Enterprise Applications and Information Sources. We will discuss the advantages/limitations of Web Services over other EAI approaches discussed in Part 1.

This article of the series may seem as a diversion from our focus area of Web Services. Nonetheless, as we mentioned in Part 1, Web services uses XML as it's base language. With that large-scale use of XML in Web Services, it would be useful to take a look at some basic and advanced concepts of XML. With this article, we will aim to lay the foundation for a better understanding of what XML is all about.

In a real-world scenario, Web services do not always use primitive data types. The real-world objects may be made of complex, user-defined data types. This article explains in detail the procedure for creating and exposing a Web service with user-defined data types deployed in a Weblogic SOAP container on a BEA Weblogic Server 8.x application server.

The Web Services QoS requirement mainly refers to the quality, both functional as well as non-functional, aspect of a Web Service. This includes performance, reliability, integrity, accessibility, availability, interoperability, and security. In this article, we are trying to cover each of these aspects, with first demystifying that quality aspect, then stating the problems to achieve the same in Web Service, and lastly we propose some of the solutions/best practices to be followed while orchestrating Web Services.

In this article, we will aim to set the overall direction for the rest of the articles in this series. We will cover the architecture of Web services and the technologies used in Web Services. Finally, we will study the steps involved in building a Web Services application.

This article has discussed various exceptions in Web Service and how a user-defined exception could be used for effective error handling in Web Services.

This article is an attempt to highlight the features of JSR 181 specification and show you how easily you can build and deploy JSR 181 Web Services in WebLogic application server.

The Web services QoS requirement mainly refers to the quality, both functional as well as non-functional, aspect of a Web service. This includes performance, reliability, integrity, accessibility, availability, interoperability, and security. In the first part of this article, we covered each of the above QoS aspects from a broad perspective. Now, in each coming article we will look into each of the QoS in detail and will try to come up with solutions and explore best practices to be followed. In this article, we are trying to demystify the "performance" aspect of Web Services.

The use of WebServiceContext API has been deprecated in WebLogic 9.2 onwards and the support for this API may be withdrawn at any time. From version 9.2 onwards, WebLogic has moved towards a Servlets-based JAX-RPC runtime; therefore, support for standard APIs are available now. Another important note is that the Web Service development model has been drastically changed in 9.2 when compared to its previous versions. It has adopted a Web Services annotations model to develop portable Web Services. For more information, please read JSR 181: Web Services Metadata for the JavaTM Platform and JSR 921: Implementing Enterprise Web Services.

With all this sudden awareness about the terms Web Services and ebXML, everyone is bound to get curious and want to know what all this noise is about. Well, we hope that this series of articles, starting from today, and appearing once every fortnight, should clear the curious minds, and put you on a strong footing to tackle the mysterious Web Services with great ease and understanding.

This approach requires the development of an adapter for each application to be integrated. Thus, it is a more useful approach where the number of entities to be integrated is fewer. In today's business, where each application needs to share information with an unpredictable number of entities residing at different locations, the Integration-bus-based EAI approach may not fit.

Most developers equate Web services with SOAP, the Simple Object Access Protocol. SOAP is a new protocol that builds an RPC layer over HTTP and XML. There is little doubt that Web services will use HTTP and XML, but not everybody agrees that SOAP is the ideal implementation.

With the Java XML Pack and Tomcat, you have a set of tools to experiment and develop Web services. There is a bit of learning curve, but given your familiarity with the Java platform, it will not be a big hurdle. Make sure you take advantage of the separate tutorial download as well.

WSCI describes the flow of messages exchanged by a Web service in a particular process, and also describes the collective message exchange among interacting Web services, providing a global view of a complex process involving multiple Web services. Today's service description languages are adequate for simple information retrieval, such as a stock quote, but they do not provide the rich behavioral detail that describes the role the service plays as part of a larger, more comprehensive collaboration. An example of this new method is the exchange between a customer and a travel agent. Now customers can send queries, receive answers, and then respond to those answers instead of starting a new query or request. People can now exchange information back and forth between servers more efficiently.

The Internet has transformed the information age. The Internet Protocol, along with a worldwide communications infrastructure, delivers data communications everywhere at low cost. Today, the bulk of Internet traffic is end-user related, e.g., e-mail and Web browsing. These services will continue to dominate; but in the coming years, we will see more computer-to-computer communications. Information found on the Web is primarily targeted for human consumption; machines have trouble digesting all those font tags and style sheets.

Web Services deployment in enterprises is in vogue. Web services achieve a high level of interoperability among the participating systems due to their use of standard protocols. Managing Web Services is becoming mandatory because of its widespread adoption in huge enterprises. Web Services are becoming pervasive in enterprise computing, thus lowering the maintenance costs and decreasing the system downtime, which is critical for the success of this technology. In this article, we are going to discuss a reference container, which manages and monitors the Web services.

January 9, 2003 - A group of leading IT vendors, consisting of Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems, today announced the publication of the Web Services Reliability (WS-Reliability) specification working draft (see links below). By providing a fundamentally more reliable transport infrastructure, WS-Reliability will help accelerate adoption of Web services, making them relevant for an even wider range of enterprise application and integration challenges.