System and method for generating Web Service architectures using a Web Services structured methodology

Abstract

System and method for generating Web Services using a Web Services Structured Methodology. One embodiment may be implemented as a Web Services architecture design mechanism. Lifecycles of the Web Services design process may include vision and strategy, architecture design, development, integration, and deployment. In one embodiment, the Web Services architecture design mechanism may implement a structured methodology design process for Web Services. One embodiment may include a reusable Web Services design pattern catalog and a mechanism for maintaining and updating the catalog and for using the catalog to apply design patterns when designing and implementing Web Services. One embodiment may be used for Enterprise And Cross-Enterprise Integration of Web Services. One embodiment may be used for Legacy Mainframe Integration and Interoperability with Web Services.

Description

CONTINUATION DATA[0001]This application is a continuation-in-part of U.S. patent application Ser. No. 10 / 642,928, titled “Structured Methodology and Design Patterns for Web Services” filed Aug. 18, 2003.BACKGROUND OF THE INVENTION[0002]This invention relates to computer software, and more particularly to Web Services.[0003]2. Description of the Related Art[0004]The term Web Services has quickly become a buzzword in the market. There are true successes, and also much hype about Web Services technology solutions. Much of the market hype focuses on what it can do, rather than on integration. Some generalize that Web Services technology can address all types of business problems. Web Services technologies are a good technology enabler for legacy system integration and cross-platform interoperability, but may not necessarily be the perfect solution to all types of business problems. Such Web Services interest has coincided with the proliferation of XML and Java technology and Business-to...

AI Technical Summary

Benefits of technology

[0019]The Java™ XML Pack (JAX Pack) is an all-in-one download of Java technologies for XML. Java™ XML Pack brings together several of the key industry standards for XML—such as SAX, DOM, XSLT, SOAP, UDDI, ebXML, and WSDL—into one convenient download, thereby giving developers the technologies needed to get started with Web applications and services.

[0036]JAXM refers to the Java technology support for sending and receiving SOAP messages, which is based on the SOAP 1.1 and the SOAP with Attachment specifications. It supports higher level and application-specific protocols built on top of SOAP, including multiple transports such as HTTP, SMTP, and so forth. In addition, JAXM supports both synchronous (request-reply) and asynchronous (one-way) mode. JAXM is preferable to JAX-RPC because of its support for asynchronous messaging, multiparty message routing, and reliable messaging (that is, guaranteed delivery). JAXM is a pluggable provider class for the SOAP server. The provider class supports different data transports, such as HTTP, SMTP, and JMS. For example, if Company X sends a SOAP message using a SOAP provider over HTTP to Company Y, the JAXM provider will create a connection to the specified URL endpoint with Company A's SOAP provider, create a SOAP message instance, and get the SOAP envelope and body. With JAXM, developers can make SOAP messaging reliable with message acknowledgement and guaranteed message delivery using JMS.

[0038]In the JAXB architecture, the utility xjc creates Java source files to bind a DTD or XML Schema to Java data objects. Developers can then add additional program code if necessary and compile the Java source files into Java classes for execution. This can potentially reduce some coding effort and processing time to transcode XML elements in an XML document using JAXP. JAXB version 1.0 supports both DTD and XML Schema. Developers can use the same xjc compiler to generate Java binding files for an XML Schema under Windows or Unix. Using JAXB to bind an XML Schema to the Java data structure, developers can probably write less program code using an XML parser (such as DOM or SAX) to transform XML content into Java data objects. This is a considerable benefit to the productivity.

[0039]JAXR is a standard Java API for accessing diverse and heterogeneous Business Service Registries. It is a unified information model for describing business registry content. It provides multi-layered API abstractions for simple, high-level, business API, and flexible, low-level, generic API. It is the enabling technology for Web Services and peer-to-peer computing in the J2EE™. In the JAXR architecture, a JAXR client is basically a registry client (RC) that is connected to the registry service (RS) via a JAXR pluggable provider. The JAXR provider is able to use any capability-specific interfaces such as ebXML provider or UDDI provider that is specific to a particular Service Registry platform. Developers can also write their own JAXR provider class to accommodate any new Service Registry platform. In this way, the JAXR client only needs to use one single set of program code to access different service registries; it need not be rewritten and recompiled.

[0040]JAX-RPC stands for Java API for XML-based Remote Procedure Calls (RPC). JAX-RPC enables Java technology developers to build Web applications and Web Services incorporating XML-based RPC functionality according to the SOAP 1.1 specification. JAX-RPC allows distributed client / server mode over the Web using the Standard Web Services technologies: SOAP, WSDL, and HTTP. Using the JAX-RPC API and the tools, it simplifies the creation of a Web Service for a Java programmer as it hides all the complexities of generating SOAP and WSDL, but provides tools to generate these using Java Interfaces and some additional configuration information. All the code to map Java data type information to XML / SOAP is generated by the tools “wscompile” and “wsdeploy” from Java Web Services Developer Pack (JWSDP) 1.0.1 (which supersedes the tool “xrpcc” in JWSDP 1.0). The JAX-RPC runtime will take care of the transport. In the JAX-RPC architecture, in order to invoke a remote business service, the client program needs to install a “stub,” which enables it to communicate with the remote application service via the remote “ties.” Both the client and the remote server (services) need to install JAX-RPC runtime, which enables both ends to exchange SOAP messages. This is a typical Remote Procedure Call model.

[0058]Embodiments of a system and method for generating Web Services using a Web Services Structured Methodology are described. Using embodiments, architects are able to derive reference architecture and / or implementation infrastructure for Web Services applications and to implement the Web Services. One embodiment may be implemented as a Web Services architecture design mechanism. In one embodiment, Web Services architecture design mechanism may receive Web Services requirements as input and, using the input, assist a user in generating a Web Services architecture as output.

Problems solved by technology

Web Services technologies are a good technology enabler for legacy system integration and cross-platform interoperability, but may not necessarily be the perfect solution to all types of business problems.

Many systems are deployed without a reliable, scalable architecture and thus suffer from capacity and performance issues.

Many Web Services initiatives begin and end with SOAP-UDDI programming yet lack a framework for reusable components, scalability, and performance management.

Prior art Web Services architectures generally lack structure and guiding principles; a product architecture that lacks structure and guiding principles is not useful for scalable and reliable Web Services.

However, it cannot modify elements of the XML document.

However, the in-memory processing is resource-hungry.

Images