Jakarta XML RPC

For other uses, see Java API for XML (disambiguation).

Java API for XML-based RPC (JAX-RPC) allows a Java application to invoke a Java-based Web Service with a known description while still being consistent with its WSDL description. It can be seen as Java RMIs over Web services. JAX-RPC 2.0 was renamed JAX-WS 2.0 (Java API for XML Web Services). JAX-RPC 1 is deprecated with Java EE 6. The JAX-RPC service utilizes W3C (World Wide Web Consortium) standards like WSDL or Web Service Description Language

It works as follows:

1. A Java program executes a method on a stub (local object representing the remote service)
2. The stub executes routines in the JAX-RPC Runtime System (RS)
3. The RS converts the remote method invocation into a SOAP message
4. The RS transmits the message as an HTTP request

The advantage of such a method is that it allows the Web Service to be implemented at server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web services.

External links

• Official JAX-RPC page
• JAX-RPC 2.0 renamed to JAX-WS 2.0

---

Journal

Service Registry: A Key Piece for Enhancing Reuse in SOA Juan Pablo García-González DATCO Chile S.A. Verónica Gacitúa-Décar Lero (the Irish Software Engineering Research Centre) Dr. Claus Pahl Lero (the Irish Software Engineering Research Centre)

September 2009

Summary: one of the promises of adopting a service-oriented approach in organizations is the potential cost savings that result from the reuse of existing services. A service registry is one of the fundamental pieces of service- oriented architecture (SOA) for achieving reuse. It refers to a place in which service providers can impart information about their offered services and potential clients can search for services. In this article, we provide advice for implementing an enterprise-wide service registry. We also discuss open issues in industry and academia that affect the management of service- repository information.

Introduction The reuse of services greatly depends on the ability to describe and publish the offered functionality of the services to potential consumers (clients). A service registry allows you to organize information about services and provide facilities to publish and discover services.[1] Universal Description Discovery and Integration (UDDI) and the Web Services Description Language (WSDL)—together with SOAP— are standards for describing services and their providers, as well as how services can be consumed: • WSDL[2] provides a model and XML format for describing what a Web service offers. A service description in WSDL separates abstract-service functionality from details such as how and where the service is offered. While the abstract-service description includes types and an abstract interface, concrete details include bindings, a service element that includes all available implementations of the abstract interface at endpoints. • UDDI[3], [4] provides an infrastructure that supports the description, publication, and discovery of service providers; the services that they offer; and the technical details for accessing those services. A core aspect of UDDI is how it organizes information about services and the providers of services. Information entities (UDDI data) are organized in a data model and stored in a UDDI service registry.Inquiring (search and lookup entries) and publication (publish, delete, and update registry–related information) are core APIs. Figure 1 illustrates some relationships between a WSDL service description and information that is stored in a UDDI service registry.

Figure 1. Relationships between WSDL and UDDI (Click on the picture for a larger image)

Originally, UDDI was conceived to cover both publicly exposed services and services that were available within an organization. Currently, most existing implementations are internal to organizations. Service publication, discovery, and (finally) reuse of services is more complicated in an inter-organizational scenario; for example, additional legal and commercial agreements are often needed among parties. Dedicated (public) UDDI service registries were criticized for their limitations (among other reasons) during service inquiry/ discovery. Recently, however, Web search engines—which could be crawling publicly available WSDL documents—have raised promising expectations for discovering publicly available services.[5]

Designing an Enterprise Service Repository This section proposes some design guidelines to develop an enhanced enterprise service repository. The focus is on improving the reuse of services over time in different IT projects. The aim is to increase service visibility to domain experts (often, this refers to a business-analyst role) and enhance service descriptions with practical information for architects. Business analysts, who have a less technical background but strong knowledge of the business domain, are frequently the early designers of new initiatives for incorporating or modifying the software support at companies; they play a key role with regard to the reuse of services. Enterprise Services Enterprise service–based solutions involve different types of service. Following the separation of concerns that is addressed by the service-virtualization pattern,[6] services can act as an intermediate layer between the client and provider applications of the services. The virtualization pattern focuses on the abstraction of technical details—such as service-endpoint location, policy enforcement, service versioning, and dynamic service-management information from service consumers— which access anintermediate service level. Technical concerns are managed at an implementation level, at which the actual business logic is implemented. Based on SOA initiatives in several companies, we can identify three types of service: • A business service (BS), which client applications use for accessing the functionality that is implemented in provider applications. • An application service (AS), which can be consumed by a BS to access the functionality of the provider applications. • A business-service extension (BSE), which can be consumed by a BS to operate on different AS responses and consolidate a single answer that is sent to a BS. In turn, the BS delivers the consolidated response to the client application. The aggregator pattern[7] is core to the design of a BSE. Figure 2 illustrates the main static relations among elements of an enterprise service–based solution, as well as their relationship to elements from the virtualization pattern. A service registry organizes the description of the three different types of service and their relationships. Client and provider applications interchange messages that are mediated by BS, BSE, and AS. The service registry manages (at the configuration level) the information that relates the different types of service. The information is persisted in a service repository and used at runtime by a BS to answer client requests.

Figure 2. Service-based architecture and its relation to virtualization-pattern roles (Click on the picture for a larger image)

Example 1 Let us consider a simplified BS that is used for calculating the total sales that are related to the life-insurance and group-insurance products of an insurance company. The total sales that are associated with life-insurance products are obtained from a life-insurance legacy application. Analogously, the total sales that are associated with group-insurance products are obtained from the group-insurance legacy application. Each legacy application exposes an AS (lifeInsurance and groupInsurance, respectively) that provides the total sales for each type of insurance product. A BS receives requests from clients who are asking for the total sales; afterwards, it calls the service registry that has the information that is required to enforce specific policies on messages and dependencies to an AS and a BSE. A BSE operates on the answers of an AS and provides a single answer to the BS that contains the total sales of the company. The BS, in turn, delivers this response to the client application. Figure 3 illustrates the described interaction.

Figure 3. Main interaction among elements of the service-based solution from Example 1 (Click on the picture for a larger image)

Enterprise Service Registry The enterprise service registry (ESR) is a core element that organizes service information and supports the interaction among enterprise applications that provide and consume services. Basic functionalities of an UDDI-based ESR can be enhanced by using: • Service-dependencies management. • Runtime-policy enforcement. • Service versioning. • Service-history data (logs) management. A service repository persists the information and documentation that are logically managed by the service registry. Figure 4 illustrates the main information that is organized in an ESR, persisted in a service repository, and provided to end users through a Web-based user interface.

Figure 4. Enterprise service registry (ESR) (Click on the picture for a larger image)

Services Descriptions Services descriptions are core to the service registry. They determine how services can be discovered and subsequently reused: • A BS is described at a high level—often, via textual descriptions in natural language and examples that facilitate understanding by business analysts. • A BSE and an AS contain more technical details. A BS is implemented by at least one AS and also might involve a BSE. To associate a BS to one or more AS(s) and/or BSE(s), a dependency mapping is created and managed by the service registry. Table 1 describes in more detail the information that is managed by the service registry: • The main attributes that describe a BS are shown at the beginning of Table 1. A BSE and an AS share attributes (see middle of Table 1). The end of the table describes binding information that relates a BS to a BSE and an AS. • Information that describes services and is independent of any registry implementation is shown in the Service information column, while information that is managed by the service registry is shown in the Registry information column. If information in the Service information and Registry information columns is the same, an X appears in the Replicated information column. • The remaining columns indicate information that is relevant to different roles.[8] Business analysts and solution architects manage information about business and technical concerns, respectively. Both roles work at a project or business-unit scale. Enterprise and infrastructure architects manage service information from a global (enterprise-wide) perspective. While enterprise architects might be interested in managing (for instance) service versions, infrastructure architects care about providing the required infrastructure support to keep services running with the adequate quality of service (QoS), as defined in service-level agreements (SLAs).

Table 1. Main service information at the ESR (Click on the picture for a larger image)

Using the Enterprise Service Registry to Improve Reuse of Services Based on our experience in a range of projects, providing simple descriptions about a BS, facilitating its access, and managing services dependencies have been key to improve reuse. For this purpose, an ESR was a core element. • Business analysts who trigger new requirements for software support can improve their communication with solution and enterprise architects by referring to a BS that is described in the ESR. Based on the descriptions of the BS and its dependencies to an AS and a BSE, domain experts become aware of available functionality at back-end applications. From our experience, this has facilitated a shift from requirements that are specified in a vague manner to initial solution blueprints that comprise orchestrated services (created by business analysts). Long meetings between architects and business analysts can be reduced to short meetings or even telephone calls that refer only to information at the service registry. • Software architects can refine orchestrations that are depicted in the initial blueprints that are made by business analysts. Subsequently, they can agree with enterprise and infrastructure architects on service versions and infrastructure support. Again, information at the ESR was central during the agreement. • Information about service dependencies helped infrastructure architects to analyze the impact of binding new consumers to application services. This is critical for maintaining SLAs. • Runtime policy–enforcement configurations at the service registry allowed specialized treatment for different client-application requests that were associated with a single BS—for example, applying particular validations with regard to formatting, security, and parameterization. • In the case of new requirements triggering modifications to existing services: • Often, extensions or modifications involved changes only at the BSE level. • If an AS or BSE was modified and new versions were deployed, the version of the associated BS remained unchanged. (Service versioning is discussed in more detail in the “Impact of Service Versioning on Service Registries” section.) • Only incompatible changes that modify the business functionality could trigger new BS versions (in general, a BS is designed with forward compatibility in mind). Among the lessons that were learned from different projects, we can emphasize the following: • Decoupling of a BS from an actual implementation (by using AS(es) and a BSE) is an effective way of keeping domain experts separated from technical information, which facilitates service discovery at the business level. • BS discovery support is key to enable the reuse of services beyond a single solution or project—allowing their use across projects and at an enterprise-wide scale. • In practice, when only an AS is presented to domain experts, it remains almost untouched; that is, it is rarely reused in further developments. • Even when new requirements involved modifications to existing service solutions, the reuse of a BS has still been strong. This was facilitated by addressing the required modifications at the BSE level. • During legacy-application migration, client applications kept consuming the same BS. Changes mostly occurred at the AS level. At the ESR, AS descriptions and service dependencies were updated. New projects could reuse a BS independently when a migration had occurred.

Open Issues in Industry and Academia This section discusses a number of observations in industry and academia with regard to enhanced service descriptions, organization of service information in a service registry, and the role of such a registry to enhance the reuse of services. Strategies for Organizing and Finding Services in Registries If service information in an enterprise service registry is difficult to distinguish because of inadequate organization or ineffective search mechanisms, the value of that registry is reduced. Services categorization can help to distinguish services and classify them according to one or more categories. UDDI registries support this through the tModel. The categorization schemas of UDDI refer to taxonomic classifications. Taxonomies organize concepts in a hierarchical structure; multiple taxonomies can apply to a single UDDI entity. Standard classification schemas are suggested, such as the United Nations Standard Products and Services Code (UNSPSC[9]); however, other standards or internally created taxonomies can also be used. The UDDI Inquiry API supports different forms of query, such as browse pattern, drill-down pattern, and invocation pattern. Queries can refer directly to services, as well as to service categories. Similarly to a Web search engine, the browse pattern allows one to find registry elements by matching keywords. Although this mechanism automates part of a service search, the results are limited to the coding system’s value set and direct value matching. Services whose description includes similar or related concepts, but different syntax, cannot be retrieved by using this approach. Also, during use of different categorization schemas, the management of overlapping categories can become expensive.[10] Taxonomy maintenance is an added load that must be considered during the implementation of a service registry. Classification schemas that are not updated can affect the quality of the discovery results.[11] The semantic research community has proposed alternatives to enrich service descriptions semantically and enhance classification schemas in services registries. Basic taxonomies can be enriched or replaced by ontologies. Ontologies structure concepts within a domain and define their meaning. Axioms constrain possible interpretations of concepts and reasoning mechanisms that support inferences from existing data. According to Küster et al.,[12] although semantic enrichment of services descriptions can improve service discovery, several issues still must be addressed, such as reducing the computational cost of reasoning, maintaining the ontologies, and refining search results to improve effectiveness. Impact of Service Versioning on Service Registries When a service has been implemented, changes can occur—from the implementation itself to parts of the service description in a service repository. Changes might aim to improve reuse: • Implemented services that follow a bottom-up approach[13] often fulfill particular project requirements within a domain. When any of these services becomes a candidate for reuse in a different context, it usually requires modifications or extensions. • Analogously, services that follow a top-down approach often must be changed (specialized) to fit in particular contexts. • Different versioning strategies address different requirements. A single solution is not likely to be satisfactory for all situations. WSDL and UDDI do not define guidelines for versioning services. Some authors have proposed strategies for service versioning; most of them relate to backward andforward compatibility:[14] • A backward-compatible version refers to the ability to support consumers of older versions of a service. • A forward-compatible version refers to the ability to adapt to unknown future requests that are intended for newer versions of the service. This type of compatibility involves not only a service-versioning strategy, but also a service-design strategy that is related to changeability. Often, new service versions are replications of a previous version that have additional or modified elements. New versions are named differently (by using some naming convention), and their description is stored in the registry as a new entry. Juric et al.[15] propose extensions to WSDL and UDDI for service versioning. The approach addresses run-time and development-time versioning. Efficiency at the code level is addressed by allowing multiple versions of a service to refer to the same codebase. Additionally, notifications about new and deprecated versions are communicated to consumers. Traceability support is provided to track changes. This academic research promotes the reuse of services and keeps the complexity of a service registry manageable. Service-Usage Information for Enhancing Service Description and Discovery The history of service usage can be an interesting source of information—not only to re-create the actual behavior,[16] but also for service discovery. Stored service usage–history (logs) can help to categorize services according to the user or how services have behaved over time. Let us consider a service description that indicates a specific performance level in its contract; however, the actual measured performance in a given timeframe (extracted from logs) is lower. This information could be used during service discovery; a service that had lower-than-expected performance levels would be discarded from the search. Statistically extracted information about how services behave against historic interactions can help to build less biased rankings and make service discovery more precise; however, an infrastructure for the constant monitoring of services and storing of the history information must be provided. Based on the service history, probabilities can be assigned to quantify uncertainty. Clark et al.[17] consider uncertainty with regard to the configuration of a service- based system, the rate parameters of system components, and the duration of events. An uncertainty model is used to predict system performance under increased demand. This type of analysis is fundamental when one is dimensioning the service support infrastructure. Historical data about individual services helps to predict the performance of an entire system. Offer and demand in an inter- organizational scenario are subject to how much parties trust one another. “Trust in others” is one of several criteria for assigning reputation—witness reputation[18] —to publicly available services. If company X knows that a service is being used or was positively rated for company Y, whom X trusts, the reputation of that service would increase from the point of view of X. One associated problem is the eventual bias for positive ratings, unfair ratings, and the variations of quality between ratings.[19] Sufficiency of WSDL Descriptions to Find Services for Composition Efficiently Services are reused not only by client applications, but also by other services in a service composition. A service composition can provide a more coarse-grained functionality and be closer to a business need. One problem when finding a service (useful in a service composition) is the need to verify if the services that are involved are able to “talk” to one another—that is, if the associated message-interchange protocol among them is compatible. A basic requirement for compatibility is deadlock-freeness. Moreover, the message syntax and semantics should be compatible. Figure 5 illustrates a typical example of incompatibility at the protocol level between two parties. In the figure, a Buyer party offers a buyProduct service, and a Seller party offers a sellProduct service.

Figure 5. Example of incompatibility at protocol level between two parties (Click on the picture for a larger image)

To automate a hypothetical sale process, the message-interchange protocol between buyProduct andsellProduct should be compatible. However, Figure 5 illustrates that the Seller expects a payment before sending the product, and the Buyer expects the product before sending the payment. When more and more services are offered and advertised in repositories, there are more chances of satisfying a service demand by composing existing services. However, mediation at the protocol level might be required. Matchmaking conflicts at the message and/or conversation level(s) can be solved—to a certain degree— by a mediator component.[20], [21] However, verifying and solving compatibility among services at the behavioral level is expensive; it involves the (expensive) exploration of possible states of the services during interaction. To increase reuse here, we need efficient mechanisms for finding compatible services. For instance, instead of directly publishing the behavior of a service in a repository, a provider can publish a “summarized description” of the expected behavior of all compatible services to service (compatibility refers to deadlock-freeness). The “summarized description” is called an “operating guideline[22]”and allows the hiding of implementation details, while exposing enough information to find compatible partners. Checking if a service can be composed with others is reduced to checking if a graph-based representation of the potential partner is a subgraph of the “operating guideline,” which is less expensive than exploring all possible states of the services.

Conclusion To improve the reuse of services at the enterprise level, architects must define a strategy for publishing and providing facilities to access services information. For this purpose, an enterprise service registry is a key piece. Information about services can be organized at the registry, and basic functionality can be enhanced—including, for instance, functionality for service versioning, management of service dependencies, and enforcement of runtime policy. In this article, we have provided some design guidelines for enhancing an enterprise service registry to improve the reuse of enterprise services. We have also discussed some open issues in industry and academia with regard to the design and implementation of service registries and associated aspects that are required to describe and organize services information.

CICS Transaction Server for z/OS, Version 4.1 > The CICS Transaction Server library: HTML > Web services The Web services architecture The Web services architecture is based on interactions between three components: a service provider, a service requester, and an optional service registry. The service provider The collection of software that provides a Web service. The Web services provider includes the following: • The application program • The middleware • The platform on which they run The service requester The collection of software that is responsible for requesting a Web service from a service provider. The Web services requester includes the following: • The application program • The middleware • The platform on which they run The service registry The service registry is a central location where service providers can publish their service descriptions and where service requesters can find those service descriptions. The registry is an optional component of the Web services architecture because service requesters and providers can communicate without it in many situations. For example, the organization that provides a service can distribute the service description directly to the users of the service in a number of ways, including offering the service as a download from an FTP site. Using a service registry offers a number of advantages to both the requester and provider; for example, using the IBM® WebSphere® Service Registry and Repository (WSRR) can help the requester to find services more quickly and can help the provider to enforce version control of the services being offered. CICS® provides direct support for implementing service requester and service provider components. However, you will need additional software to deploy a service registry in CICS. If you use the IBM WebSphere Service Registry and Repository (WSRR), CICS provides support for WSRR through the Web services assistant. Alternatively, you can deploy a service registry on another platform. Interactions between a service provider, a service requester, and, a service registry The interactions between the service provider, service requester, and service registry involve the following operations: Publish When a service registry is used, a service provider publishes its service description in a service registry for the service requester to find. Find When a service registry is used, a service requester finds the service description in the registry. Bind The service requester uses the service description to bind with the service provider and interact with the Web service implementation. Figure 1. Web services components and interactions • The Web service description A Web service description is a document by which the service provider communicates the specifications for invoking the Web service to the service requester. Web service descriptions are expressed in the XML application known as Web Service Description Language (WSDL). • Service publication A service description can be published using a number of different mechanisms; each mechanism has different capabilities and is suitable for use in different situations. CICS supports the use of the IBM WebSphere Service Registry and Repository (WSRR) for publishing service descriptions. Alternatively, you can use other methods to publish a service description Java API for XML Messaging From Wikipedia, the free encyclopedia For other uses, see Java API for XML (disambiguation). The Java API for XML Messaging (JAXM) enables distributed software applications to communicate using XML (and SOAP). JAXM supports both asynchronous and synchronous messaging. JAXM is a replacement for SOAP with Attachments API for Java JAXM is one of the Java XML programming APIs Contents

 [hide] 

• 1 Overview • 2 Messages • 3 Connections o 3.1 SOAP Connection o 3.2 Provider Connection • 4 Messaging Providers o 4.1 When to use a Messaging Provider • 5 References • 6 See also

[edit]Overview The Java API for XML Messaging (JAXM) enables developers to use XML messaging using the Java platform. Developers can create and send XML messages over the internet using the JAXM API.[1][2]

The following figure presents a conceptual relationship between JAXM and other architectural elements required in web-based, business-to-business messaging. Also, Java API for XML Messaging has several advantages over Remote Procedure Call such as the following: • One-way (asynchronous) messaging • Routing of a message to more than one party • Reliable messaging with features such as guaranteed delivery The complete JAXM API comes with two packages:[3] • javax.xml.soap: This package contains the API for creating and populating a SOAP message. • javax.xml.messaging: This package allows one to send one-way messages via a messaging provider. [edit]Messages Messages in JAXM are XML messages that follow the prescribed SOAP format and standards. There are two main types of SOAP messages: those that have attachments and those that do not. For example, if you want your message to contain an image, you must send an attachment with the message. The SAAJ API provides the AttachmentPart class for attachments in SOAP messages.[4] [edit]Connections A connection is required to send and receive all SOAP messages. The connection can go to a messaging provider or a particular destination.[5] The JAXM API provides the class and interface to represent two kinds of connections: • javax.xml.soap.SOAPConnection—a connection from the sender directly to the receiver (a point-to-point connection) • javax.xml.messaging.ProviderConnection—a connection to a messaging provider [edit]SOAP Connection A SOAPConnection is a point-to-point connection for sending messages directly to a remote party.[6] A SOAPConnection object, which represents a point-to-point connection, is simple to create and use. You do not have to do any configuration to use a SOAPConnection object because it does not need to run in a servlet container (like Tomcat) or in a J2EE server. It is the only way for a client to have a connection without a service provider.[7] [edit]Provider Connection A ProviderConnection object represents a connection to a messaging provider. (The next section explains more about messaging providers.) When you send a message via a ProviderConnection object, the message goes to the messaging provider. The messaging provider forwards the message, following the message's routing instructions, until the message gets to the ultimate recipient's messaging provider, which in turn forwards the message to the ultimate recipient.[8] [edit]Messaging Providers A messaging provider keeps track of messages and routes them to the correct destination or destinations. It is a service that handles the transmission and routing of messages.[9] [edit]When to use a Messaging Provider A JAXM client may or may not use a messaging provider. Generally, you do not need a messaging provider if you just want to be a consumer of Web services. Some limitations of not using a messaging provider are the following: The client can send only request-response messages The client can act in the client role only Some advantages to not using a messaging provider are the following: • The application can be written using the J2SE platform • The application is not required to be deployed in a servlet container or a J2EE container • No configuration is required Java API for XML-based RPC From Wikipedia, the free encyclopedia For other uses, see Java API for XML (disambiguation). Java API for XML-based RPC (JAX-RPC) allows a Java application to invoke a Java-based Web Service with a known description while still being consistent with its WSDL description. It can be seen as Java RMIs over Web services. JAX-RPC 2.0 was renamed JAX-WS 2.0 (Java API for XML Web Services). JAX-RPC 1 is deprecated with Java EE 6.[1] The JAX-RPC service utilizes W3C (World Wide Web Consortium) standards like WSDL or Web Service Description Language [2] It works as follows: 1. A Java program invokes a method on a stub (local object representing the remote service) 2. The stub invokes routines in the JAX-RPC Runtime System (RS) 3. The RS converts the remote method invocation into a SOAP message 4. The RS transmits the message as an HTTP request The advantage of such a method is that it allows the Web Service to be implemented at server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web services.