US20100146396A1 - Systems and methods for web service function, definition, implementation, and/or execution - Google Patents

Systems and methods for web service function, definition, implementation, and/or execution Download PDF

Info

Publication number
US20100146396A1
US20100146396A1 US12/704,124 US70412410A US2010146396A1 US 20100146396 A1 US20100146396 A1 US 20100146396A1 US 70412410 A US70412410 A US 70412410A US 2010146396 A1 US2010146396 A1 US 2010146396A1
Authority
US
United States
Prior art keywords
web service
node
server
application
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/704,124
Inventor
Steve L. Able
Roland S. Martin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GT Software Inc
Original Assignee
GT Software Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GT Software Inc filed Critical GT Software Inc
Priority to US12/704,124 priority Critical patent/US20100146396A1/en
Publication of US20100146396A1 publication Critical patent/US20100146396A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web

Definitions

  • the present application is directed to systems and methods for Web Service function, definition, implementation, and/or execution.
  • the Internet is a global network of connected computer networks. Over the last several years, the Internet has grown in significant measure. A large number of computers on the Internet provide information in various forms. Teen with a computer connected to the Internet can potentially tap into this vast pool of information.
  • the information available via the Internet encompasses information available via a variety of types of application layer information servers such as SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), GOPHER (RFC 1436), WAIS, HTTP (Hypertext Transfer Protocol, RFC 2616) and FTP (File Transfer Protocol, RFC 1123).
  • SMTP Simple Mail Transfer Protocol
  • POP3 Post Office Protocol
  • GOPHER GOPHER
  • WAIS Wireless Fidelity
  • HTTP Hypertext Transfer Protocol
  • FTP File Transfer Protocol
  • the Web consists of a subset of the computers connected to the Internet; the computers in this subset run HTTP servers (“Web servers”).
  • Web servers Several extensions and modifications to HTTP have been proposed including, for example, an extension framework (RFC 2774) and authentication (RFC 2617).
  • Information on the Internet can be accessed through the use of a Uniform Resource Identifier (“URI,” RFC 2396).
  • URI Uniform Resource Identifier
  • a URI uniquely specifies the location of a particular piece of information on the Internet.
  • a URI will typically be composed of several components. The first component typically designates the protocol by which the address piece of information is accessed (e.g., HTTP, GOPHER, etc.).
  • This first component is separated from the remainder of the URI by a colon (‘:’).
  • the remainder of the URI will depend upon the protocol component. Typically, the remainder designates a computer on the Internet by name, or by IP number, as well as a more specific designation of the location of the resource on the designated computer. For instance, a typical URI for an HTTP resource might be:
  • URI Uniform Resource Names
  • Web servers host information in the form of Web pages; collectively the server and the information hosted are referred to as a Web site.
  • a significant number of Web pages are encoded using the Hypertext Markup Language (“HTML”) although other encodings using Standard Generalized Markup Language (“SGML”), eXtensible Markup Language (“XML”), Dynamic HTML (“DHMTL”) (the combination of HTML, style sheets and scripts that allows documents to be animated) or Extensible HyperText Markup Language (“XHTML”) are possible.
  • HTML Hypertext Markup Language
  • SGML Standard Generalized Markup Language
  • XML eXtensible Markup Language
  • DHMTL Dynamic HTML
  • XHTML Extensible HyperText Markup Language
  • Web pages in these formatting languages may include links to other Web pages on the same Web site or another.
  • Web pages may be generated dynamically by a server by integrating a variety of elements into a formatted page prior to transmission to a Web client.
  • Web servers, and information servers of other types, await requests for the information from Internet clients.
  • Client software has evolved that allows users of computers connected to the Internet to access this information.
  • Advanced clients such as Netscape's Navigator and Microsoft's Internet Explorer allow users to access software provided via a variety of information servers in a unified client environment.
  • client software is referred to as browser software.
  • Web services further facilitate access to information on the Internet by computer users.
  • Web services address the need to integrate legacy mainframe applications by acting as platform-independent interfaces that allow communication with other applications using standards-based Internet technologies, such as HTTP and XML.
  • Web services simplify integration by reducing the number of Application Program Interfaces (“API”) to one, Simple Object Access Protocol (“SOAP”) and the number of data formats to one, XML.
  • API Application Program Interfaces
  • SOAP Simple Object Access Protocol
  • SOAP overlays XML and transmits data in a way that can be understood and accepted by Web browsers and servers.
  • the XML is also human readable.
  • Web services allow programmers to make databases and/or other applications available across the Web for other programmers to access them and link the applications together to provide services.
  • Web services using the request and response methods are further described as being a Service Oriented Architecture (“SOA”) approach to integration of electronic business applications or processes.
  • SOA Service Oriented Architecture
  • a service-oriented architecture is essentially a collection of services. These services communicate with each other as described previously. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. The methods of connecting services to each other involve the protocols and transport methods of SOAP.
  • WSDL Web Services Description Language
  • WSDL definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based on some agreed upon XML vocabulary. This agreement could be within an organization or between organizations. Vocabularies within an organization could be designed specifically for that organization. They may or may not be based on some industry-wide vocabulary. If data type and message definitions need to be used between organizations, then most likely an industry-wide vocabulary will be used.
  • WSDL operations are grouped into port types.
  • Port types define a set of operations supported by the Web service.
  • WSDL service bindings connect port types to a port.
  • a port is defined by associating a network address with a port type.
  • a collection of ports defines a service. This binding is commonly created using SOAP protocols and transport methods.
  • IBM created a SOAP interface for CICS (Customer Information Control System) which only supported a one-to-one relationship between the SOAP request and to the application code. This process does not provide automatic parsing and processing between the SOAP XML and the application communication areas. It also fails to provide any method for processing 3270 BMS applications.
  • the IBM process provides neither flow processing nor graphical interface tooling with the SOAP process.
  • a main problem of most computer-based systems is their lack of ability to create composite processing in a Web service environment.
  • a primary aspect of the Web service software described herein is to provide composite-based application processing using existing application software.
  • Present systems lack support for a variety of functionality in the Web service area.
  • Present systems do not support application flow and processing multiple applications via a single SOAP request would provide a much-needed process to the market place.
  • programmers have a significant learning curve to build the required XML and WSDL files required for SOAP processing.
  • Web services are defined with respect to one or more functions available from applications executing on one or more remote systems.
  • definitions are used to generate a programmatic implementation that is communicated to a Web services server executing on, or in communication with, the remote system(s).
  • Web services clients can then use the defined service by posting appropriate requests to the Web services server and receiving back from that server a response encoding the results of performing the requested Web service.
  • the modeling software can also be described as the application flow designer for the patent application.
  • the modeler can preferably be implemented in software executable on a typical computer having a system data store (“SDS”) and a system processor; however, the modeler functionality, or portions thereof, may be implemented in whole, or in part, via hardware.
  • SDS system data store
  • the modeler functionality, or portions thereof can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media.
  • An application for generating a programmatic implementation that is communicated to a Web services server may be referred to herein as a server or rule-based flow engine.
  • the manager can preferably be implemented in software executable on a typical computer having an SDS and a system processor, however, the server functionality, or portions thereof, may be implemented in whole, or in part, via hardware.
  • the server functionality or portions thereof can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media.
  • the server functionality can be standalone, performed within the studio or performed within the server.
  • a Web services server preferably incorporates an SDS, a system processor, and one or more interfaces to one or more communications channels that may include one or more interfaces to user workstations over which electronic communications are transmitted and received.
  • the server functionality, or portions thereof can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media.
  • a Web services client (“Requestor”) executing on a computer communicates a Web service request to the Web services server (“Provider”).
  • the Web services server executes the programmatic implementation of the defined Web service to generate a response.
  • the response is then communicated to the Requestor.
  • the Provider may execute one or more applications on the system execute the server and/or one or more remote systems in order to generate the response.
  • the system processor is in communication with the respective SDS via any suitable communication channel(s); system processor may further be in communication with the one or more communication interfaces via the same, or differing, communication channel(s).
  • Each system processor may include one or more processing elements that provide electronic communication reception, transmission, interrogation, analysis, processing and/or other functionality.
  • the system processor can include local, central and/or peer processing elements depending upon equipment and the configuration thereof.
  • the modeler, manager, server (and client) are summarized above as discrete components; however, these various components all together, or taken in any selected grouping, could be implemented within a single execution environment where a particular system processor and/or SDS could support one or more such components.
  • Each SDS may include multiple physical and/or logical data stores for storing the various types of information. Data storage and retrieval functionality may be provided by either the system processor or data storage processors associated with, or included within, the SDS.
  • the studio provides an automated graphical process of collection of information to define and build the Web service process using an SOA.
  • the studio process provides a graphical flow of the application processes required to build a request and response SOAP-based Web service.
  • the graphical flow or model is then used to create the rules or execution path the server must follow to provide the requested SOAP response.
  • Composite application processing can be provided via the modeling or rules-based process, the designer also provides for external logic processing to control the logic flow through the multiple applications.
  • the manager may optimize its data movement processing and lower storage requirements by only holding data or storage as long as needed.
  • Work meta data fields can be used to dynamically modify control settings at runtime. This process allows the modeler and manager to communicate changes to the flow before runtime that take place at runtime.
  • the manager can allow for called projects, so that an application program can call other application flows at any time based on application or business requirements. This can provide a very powerful way to extend working application flows. An application flow can call other deployed application flows at any time during its processing.
  • a flow processing engine in some implementations that processes movement of data to and from standard application meta data formats to and from the SOAP XML meta data formats. This process reduces the need of the application programmer having to know or understand SOAP and XML processing and having to code additional application program to process SOAP and XML. This can significantly reduce the time to market and the possibility for errors to be introduced into the process.
  • some implementations of the modeler disclosed herein can increase programmer productivity by allowing a drag and drop interface for building application flows and data movements between one or many applications. Development time can be greatly reduced because the need to build routines to parse and move the XML data to/from existing meta data formats is eliminated.
  • a further feature of some implementations includes processing pure SOAP, XML and WSDL creation using a composite application process that allows mapping and data movements without any code to be created and executed.
  • Some such implementations may provide processing via a runtime image that processes the XML rules and instructions for processing the application flow, external logic and data movement processing.
  • FIG. 1 depicts an example graphical user interface for a typical modeler environment.
  • FIG. 2 depicts an exemplary import interface for an example modeler.
  • FIG. 3 depicts an exemplary data movement interface for an exemplary modeler.
  • FIG. 4 depicts an example rule set generated in a typical modeler environment.
  • FIG. 5 depicts a directory listing for a file repository in an exemplary modeler.
  • FIG. 6 provides a sample FTP interface from an exemplary modeler.
  • FIG. 7 is an exemplary Server Administration screen for server configuring and managing.
  • FIG. 8 depicts an exemplary TN3270 Client accessing a TN3270 Server (Emulator).
  • FIG. 9 depicts a potential Integrated Development Environment (IDE) for an exemplary modeler.
  • IDE Integrated Development Environment
  • FIG. 10 is an exemplary FTP interface used in an exemplary modeler.
  • FIG. 11 is a block diagram of various components or functions of an exemplary modeler and server.
  • FIG. 12 is a graphic representation of a potential architecture for an exemplary modeler or server.
  • FIG. 13 is an example screen representing an IDE with MDI, drag and drop and dockable windows as used in some potential implementations.
  • FIG. 14 depicts a potential tool box window of an exemplary modeler.
  • FIG. 15 depicts a potential project explorer window of an exemplary modeler.
  • FIG. 16 depicts a potential property window of an exemplary modeler.
  • FIG. 17 provides a graphical representation of an example graphical diagram window.
  • FIG. 18 represents a browser window within exemplary modeler.
  • FIG. 19 depicts an exemplary test window.
  • FIG. 20 depicts an exemplary SOAP request window as used by the exemplary test window of FIG. 19 .
  • FIG. 21 depicts an exemplary SOAP response window used by the exemplary test window of FIG. 19 .
  • FIG. 22 represents an example output window.
  • FIG. 23 depicts a screen from mainframe sample application.
  • FIG. 24 depicts a sample data input into the example screen in FIG. 23 .
  • FIG. 25 depicts an exemplary modeler project representing a Web service to operate a mainframe application defined through graphical nodes.
  • FIG. 26 demonstrates the relationship between a property window and a node within an graphical diagram window in a particular example modeler.
  • FIG. 27 represents use of a drop-down menu for selecting a data sources for an exemplary node.
  • FIG. 28 represents use of a drop-down menu for selecting a data sources for an exemplary node.
  • FIG. 29 depicts a sample graphical Web service definition accessing a mainframe application.
  • FIG. 30 demonstrates graphical definition of a composite Web service within an exemplary modeler.
  • FIG. 31 depicts a typical deployment architecture for Web services using an exemplary modeler and server.
  • the hardware of a typical execution environment for one or more of the components supporting Web services definition, implementation and/or execution include a system processor potentially including multiple processing elements, that may be distributed across the hardware components, where each processing element may be supported via a general purpose processor such as Intel-compatible processor platforms preferably using at least one PENTIUM class or CELERON class (Intel Corp., Santa Clara, Calif.) processor; alternative processors such as UltraSPARC (Sun Microsystems, Palo Alto, Calif.) and IBM zSeries class processors could be used in other implementations.
  • Web services definition, implementation and/or execution (servicing) functionality may be distributed across multiple processing elements.
  • the term processing element may refer to (1) a process running on a particular piece, or across particular pieces, of hardware, (2) a particular piece of hardware, or either (1) or (2) as the context allows.
  • Some implementations can include one or more limited special purpose processors such as a digital signal processor (DSP), application specific integrated circuits (ASIC) or a field programmable gate arrays (FPGA). Further, some implementations can use combinations of general purpose and special purpose processors.
  • DSP digital signal processor
  • ASIC application specific integrated circuits
  • FPGA field programmable gate arrays
  • the hardware further includes an SDS that could include a variety of primary and secondary storage elements.
  • the SDS would include registers and RAM as part of the primary storage.
  • the primary storage may in some implementations include other forms of memory such as cache memory, non-volatile memory (e.g., FLASH, ROM, EPROM, etc.), etc.
  • the SDS may also include secondary storage including single, multiple and/or varied servers and storage elements.
  • the SDS may use internal storage devices connected to the system processor.
  • a local hard disk drive may serve as the secondary storage of the SDS, and a disk operating system executing on such a single processing element may act as a data server receiving and servicing data requests.
  • the different information used in the systems and methods for Web service function definition, implementation, and/or execution as disclosed herein may be logically or physically segregated within a single device serving as secondary storage for the SDS; multiple related data stores accessible through a unified management system, which together serve as the SDS; or multiple independent data stores individually accessible through disparate management systems, which may in some implementations be collectively viewed as the SDS.
  • the various storage elements that comprise the physical architecture of the SDS may be centrally located or distributed across a variety of diverse locations.
  • database(s) are used to store and manipulate the data; in some such implementations, one or more relational database management systems, such as DB2 (IBM, White Plains, N.Y.), SQL Server (Microsoft, Redmond, Wash.), ACCESS (Microsoft, Redmond, Wash.), ORACLE 8i (Oracle Corp., Redwood Shores, Calif.), Ingres (Computer Associates, Islandia, N.Y.), MySQL (MySQL AB, Sweden) or Adaptive Server Enterprise (Sybase Inc., Emeryville, Calif.), may be used in connection with a variety of storage devices/file servers that may include one or more standard magnetic and/or optical disk drives using any appropriate interface including, without limitation, IDE and SCSI.
  • a tape library such as Exabyte X80 (Exabyte Corporation, Boulder, Colo.), a storage attached network (SAN) solution such as available from (EMC, Inc., Hopkinton, Mass.), a network attached storage (NAS) solution such as a NetApp Filer 740 (Network Appliances, Sunnyvale, Calif.), or combinations thereof may be used.
  • the data store may use database systems with other architectures such as object-oriented, spatial, object-relational or hierarchical.
  • certain implementations may use other storage implementations such as hash tables or flat files or combinations of such architectures.
  • Such files and/or tables could reside in a standard hierarchical file system.
  • Such alternative approaches may use data servers other than database management systems such as a hash table look-up server, procedure and/or process and/or a flat file retrieval server, procedure and/or process.
  • the SDS may use a combination of any of such approaches in organizing its secondary storage architecture.
  • the hardware components may each have an appropriate operating system such as WINDOWS/NT, WINDOWS 2000 or WINDOWS/XP Server (Microsoft, Redmond, Wash.), Solaris (Sun Microsystems, Palo Alto, Calif.), or LINUX (or other UNIX variant).
  • WINDOWS/NT WINDOWS/NT
  • WINDOWS 2000 WINDOWS 2000
  • WINDOWS/XP Server Microsoft, Redmond, Wash.
  • Solaris Sun Microsystems, Palo Alto, Calif.
  • LINUX or other UNIX variant
  • the server or manager executes on a z/OS or VSE/ESA platform and the modeler or studio executes under a WINDOWS 2000 or WINDOWS/XP operating system.
  • the server or manager executes as a rules-based processing application using XML based instructions created by the modeler or studio software.
  • the modeler or studio is a graphical tool for building application flows to allow processing of non-SOAP and SOAP-based applications as SOAP-based composite applications.
  • a graphical user interface allows business analysts and programmers to form a collaboration to build a new business process centered on Web services.
  • users may be business analysts who require a method of interfacing to a mainframe application without an in-depth knowledge of the programming and/or application execution environment.
  • Other users might be application developers or technical support personnel tasked with building SOAP Web services for use by application servers. This aspect can allow a developer to bridge between the application logic and the business process needed to provide a SOAP Web service.
  • a client uses a graphical interface to build a business process by defining inputs and expected outputs and then stepping through the application using graphical icons or nodes for each step.
  • This graphical user interface allows the modeling of a Web service via graphical objects.
  • the graphical objects are connected using connection points to form a flow through the various applications or methods needed to create the single process or composite process web service.
  • the application flow through the various nodes controls the logic processing for several applications which provide the unique function of composite processing.
  • Each of the functions may be represented by a graphical icon or node.
  • the modeler software is resident on the client's workstation and converts the client's input into processing rules in a single format, for example XML.
  • the modeler provides the server with the rules required to navigate or otherwise invoke a business logic process, a transactional or conversational type application or even Web services which exist on the same or external servers.
  • the server or manager is a rules-based engine used to process rules generated as instructions from the modeler.
  • the composite processing of applications provided by the server are a direct result of building the application flow using a graphical design tool. This process provides a simple yet powerful process for building mainframe-based SOAP or SOA applications.
  • the graphical tool serves as one facet of the overall systems and methods described herein. Use of this tool allows no additional programming to be required once the modeler tool has deployed the rules to the server or manager software.
  • the server processes the incoming SOAP request envelope, and then processes the business logic to build the SOAP response envelope for the returned SOAP packet.
  • the server may further allow various processes of additional functions or business logic to form a complete response.
  • Service requestors may communicate with the server to discover the defined Web services and import the WSDL that is created by the modeler to describe and define the processing of the service.
  • the modeler or studio tooling builds the WSDL file automatically for the client or user of the system and removes the need to have the knowledge of building these interface files.
  • the WSDL files can then be used by other third party products such as application design tools to build the interface modules called SOAP clients or proxies to access the applications that are orchestrated by the modeler/studio and server/manager.
  • existing business logic and/or application information can be imported into the systems and methods described herein.
  • Existing business logic and/or application information may be supported through particular formats such as BMS or copybooks.
  • An interface can be provided for such importation such as depicted in FIG. 2 .
  • Imported business logic and/or application information can then be used to build Web services.
  • the importing process provides a way to communicate between various different system types, and the meta data collected through importation allow systems designers to communicate in a known language. Additional meta data may be created and/or renamed, mainly SOAP input and output meta data that is to be exposed by the Web service can be named or described using new meta data names, which can then hide the fact that the back-end system is not a Web service-based application.
  • the imported meta data is preferably normalized into an XML format to allow it to be processed using standard XML parsers instead of having to use a unique parser.
  • the imported data, and/or other meta data can be viewed in a tree fashion using tooling provided by some implementations of the modeler. FIG. 3 depicts such an example.
  • the graphical building of a Web service may use imported information to define communication with business logic and/or application processes.
  • Each node has a unique function and properties that define the Web service and the operations performed by the service.
  • a Start node can describe the Web service and can serve the anchor or parent node for all other operations.
  • a Start node can further represent multiple operations and/or configuration settings. It can, for instance, describe the location (environmental) attributes of the Web service that you are building.
  • Each processing or point node defines the information required to access the target source.
  • the target could be a CICS transaction code, or for a COMMAREA application the target could be a CICS program name. Additional data sources such as DL/I, IMS, DB2, VSAM, could also be used.
  • users build the diagram or model of the Web service they may connect the nodes to form the logic or processing flow. This flow will later be translated into instructions for the rules-based SOAP server process. The syntax of the diagram is verified each time a node connection is attempted to insure a valid logic path and that node connection rules are correct.
  • Each Web Service Operation node defines the expected SOAP input and output for the service operation path.
  • the WSDL is created from the properties entered for each of the nodes. This document is an XML description of the interface methods for the Web service being created.
  • the modeler build process may in some instance provide a verification of the Web service at the same time as it creates the server rules, WSDL and HTML to define the service.
  • the descriptive HTML may be static or converted to a dynamic XSTL template that will build the HTML dynamically based on the XML of the WSDL.
  • the WSDL generated by the modeler build process can now be used, in some implementations, by an execution test and/or debug tool.
  • Such a test and/or debug tool potentially provides for further verification of the service definition and the generated Web service interfaces.
  • These tools can dynamically process the service information (WSDL code) to create the user interface required to verify the deployed Web service.
  • the WSDL definition may serve as the interface point between Java J2EE and .NET processing.
  • the WSDL may be processed by popular Integrated Development Environment (“IDE”) products that supply the capability to automatically build the Java, C# or other language interface code for processing the Web service described by the WSDL.
  • IDE Integrated Development Environment
  • the server side instructions contain a mixture of execution and data flow. These instructions can be represented in XML as a tree structure.
  • the XML tree is derived from the project diagram and its associated settings including data movements and/or properties.
  • the diagram itself is stored as a mostly flat entity (although it may be represented in XML) so the resultant server instructions are not required to have the same appearance as the diagram.
  • the format of rules is preferably set to provide the highest performance, as these rules will be executed for each request of the Web service.
  • the rules may be compressed and/or optimized to improve performance of execution.
  • Each execution node within the server instructions contains children nodes, one of which will receive control once the parent has completed its processing. The choice of the next child to dispatch is determined at runtime by the rules engine, but the rules instructions allow all possible choices to be specified.
  • FIG. 4 depicts a representation of the rules generated by an exemplary modeler in one particular implementation.
  • the model designer has complete control over server processing logic flow. There are no ambiguous execution flows within a Web service operation; the model designer details completely how the server is to operate. Data flow is completely described within the modeling diagram process.
  • the modeler creates the server side instructions via an “n-pass” algorithm applied to the diagram XML based on the number of paths created by the client in the diagram. Server processing is a single pass of the XML server rules instructions tree.
  • the modeler pre-notifies the server, possibly via the rules, of any data movements required to be saved for later usage to optimize the server performance. This design places the complexity burden upon the modeler to be highly optimized in its rule creation resulting in performance benefits in the server rules engine.
  • the server may be a SOAP server based on the HTTP and SOAP protocols.
  • the particular server may support processing standard HTTP and/or secure HTTPS requests.
  • the repository may be a Hierarchical File System based on a CICS standard VSAM KSDS file; this unique function provides support for a UNIX/Windows based file system without the need for Unix System Services on CICS.
  • the file repository may contain a command line processor for management of the file system via a standard CICS transaction. Command examples include, but are not limited to creation of file systems in the repository, directories and data files as depicted in FIG. 5 .
  • the file system repository can also be managed from an FTP server provided such as with the SOAP server and/or via the FTP client supplied with the modeler.
  • FIG. 6 provides an example of screen of management via an FTP server.
  • the HTTP server and FTP server can follow the standard Internet RFCs for those protocols.
  • the server can provide the ability to map transactional 3270 and program-based applications into SOAP methods or objects.
  • the heart of this process is the rules engine that is used to process the output rules instructions from the modeler.
  • the server processes each node starting from the initial start point of the diagram.
  • each diagram contains the Web service name and the operations or methods the service provides.
  • the selected Web Service Operation node becomes the parent node and the logic tree that results will all branch from this common parent.
  • each node of the rule instruction set may cause the server to dispatch the function to handle the node operations.
  • the node operations are optimized into the correct code page for the mainframe session.
  • the HTTP server provides the base protocol support on top of CICS Web Services.
  • This HTTP server provides administrative utilities to manage the SOAP services and FTP servers.
  • An example administrative screen is seen in FIG. 7 . All discoveries of WSDL files and management of the HTML documentation can be stored in a Hierarchical File System (as part of the SDS).
  • Some implementations of the described systems and methods may incorporate a debugger or testing tool to read in the WSDL and extract all the operations that can be performed.
  • the debugger lists the operations in a pull-down list. Once the user selects an operation from the list the input field, meta data will be used to build a tree view of the required input fields.
  • the debugger or test tool may be used to input data for the SOAP Request envelope. For complex arrays the user may first define how many occurrences will be entered, and then the debugger will provide input area in the tree display for the occurrences of the complex type.
  • the debug option may be added to the client modeler application and the server service provider.
  • the debug operations may be a two-way communication path that will allow the client to know what step has been executed on the mainframe.
  • the client notifies the server of the debug request by sending additional headers in the HTTP request to show the debugging client machine.
  • the user may open a TCP/IP socket to listen for requests.
  • As the server starts execution of the rules the server will send status information to the client.
  • the modeler will show the current step in the diagram and will provide for breakpoints and other standard debug commands, such as looking at storage, setting new data values.
  • the emulator can be written in such a way to provide .NET access to the 3270 emulation via browser object tags, the browser may be used as the container for the emulator product. This may also extend beyond the browser into an API that allows programmatic control over the 3270/5250 applications. This will be a pure .NET solution and as such will allow any .NET language on a Microsoft platform be used to build new interfaces.
  • the emulator can take advantage of performance improvements placed into the Windows .NET object used to build applications.
  • the emulator can be installed in classic windows fashion, or via a browser interface.
  • An exemplary emulator screen is seen in FIG. 8 .
  • the modeler process provides for building Web services by importing Basic Mapping Support macros (“BMS”) and building a data structure in XML that matches the Application Data Structure (“ADS”).
  • BMS Basic Mapping Support macros
  • ADS Application Data Structure
  • the model may provide a method for importing the CICS COMMAREA into an XML format much like the BMS macro layout. This provides a common layout and structure for the various application data structures that will be used.
  • a user builds a business process by defining inputs and expected outputs and then stepping through the application using graphical icons for each step.
  • Each of the functions for example business logic functions, starts and stop, logic flow, or XML remap, is represented by an icon.
  • the end result is a graphical design of the application from the Web service inputs to the final Web service response.
  • the graphical models may be self-documenting or may also provide for process documentation to be entered using “sticky notes”.
  • the modeler interfaces with an IDE, which processes the menus and windows for user selections.
  • the general design in a preferred implementation may include dockable and movable windows and the use of Multiple Document Interface (“MDI”). (See FIG. 5 .) Menus and screen literals may optionally be based in resource files to allow for support of languages other than English.
  • FIG. 9 depicts an exemplary screen.
  • the modeler will allow users access to multiple applications in a single Web service by combining application available functions, in contrast to conventional systems that require having to make several calls.
  • all or some files created by the modeler, including the project files can be stored using an XML format.
  • the modeler may incorporate functions to import copybooks that are converted to an easy to understand XML format, which allows for easy expansion of the resulting meta data dictionary.
  • the modeler will also incorporate a BMS macro importer to convert the BMS source into XML format.
  • An FTP client can be provided to pull copybooks and/or BMS macros from the mainframe or other computer.
  • An exemplary interface screen is depicted in FIG. 10 .
  • the FTP client may include a meta data import function. Such a function supports ease of use by clients when importing meta data located on a remote computer system.
  • the modeler provides the server with all the rules engine information needed to process SOAP operations.
  • Manager software for example, mainframe service routines, uses XML data collected via the modeling software to process the business rules defined in the graphical model by the user.
  • Input to the manager will be the processing rules from the modeler and the SOAP packet.
  • the input process will fire the manager, and it will process the business logic building a result for the returned SOAP packet.
  • the server is a rules-based engine that processes the XML server instructions from the modeler.
  • Each node is converted into a set of rules that allow the various processes of a Web service to be applied to information and procedures resident on a server, for example the CICS TS server or on IMS-based server processes.
  • the Start node is the initial setup and logical start of the Web service being created.
  • the Start node defines the name of the Web service and various WSDL options such as the URI to invoke the Web service and the target namespace for the SOAP input/output fields that will be defined.
  • the processing type of RPC (Remote Procedure Call) and Document is requested at this node.
  • the Web Service Operation node provides the logical name for the method or operation and provides the SOAP input and output structures. Each input field and its type is described at the Web Service Operation node. The output structure expected from the Web service is also defined at this node.
  • the LINK Point Node provides the interface point between the server and the Web service being created.
  • the link point defines the name of the program to execute and the location where it should execute. CICS dynamic routing rules may be used when processing.
  • Some implementations may incorporate a 3270 Process node and a Point node.
  • the Process node may cover all the setup information for the transaction code and the information required by CICS to start the 32370 process.
  • the Point node is used to supply the current BMS mapset and map name so that data movements can be created.
  • Data movement nodes provide a tree structure for creation of move rules. Some examples of data movement nodes include Move to LINK, Move to 3270, and Move to Output. The movement process is based on a common code base so that all movement nodes have a similar function.
  • the Move to LINK node may provide the method to set the initial values for the program that will be invoked.
  • the Move to 3270 node may allow for moving data to the BMS map in order to provide input for the 3270 screen operation.
  • the data that could be used for these move operations could be from static values, SOAP input request envelope, and any previously accessed 3270 map or CICS COMMAREA.
  • the Decision nodes provide the ability to add logic that will change the flow through the model. These nodes may be processed by the server and take action on data from any previous point node under the same Web Service Operation node. Complex operations may be defined using the Decision nodes in conjunction with Loop nodes. Decision nodes can target the current point node process for all comparison operations.
  • Loop processing is also used within decision tree processing; a Loop node provides a method for returning to a previous node within the parent Web service operation. At times logic of applications running in CICS will require that they be executed using multiple iterations. The Loop node will allow the logic flow to return to a parent node. For 3270 BMS this might be an operation that is scrolling through several screens. For a COMMAREA application, it might be a program that requires more than one pass to collect all the returned data.
  • the Move to Output node allows for data to be moved from any previous point node with the same parent Web Service Operation node.
  • the target of the movement data will be the SOAP response envelope.
  • the Connector nodes provide a very important process that allows several logic paths to branch out and then return to the main line logic flow.
  • the Operation End node is a logical placeholder to signal that the Web service operation has completed its task. All Web Service Operation node paths can connect to a single Operation End node.
  • a Calculation node will provide for mathematical operations to be added to the logic flow of the modeler. These nodes will process data from the application and will be used to modify the result set returned to the client. For example, the 3270 application may have a total account balance for the persons account. A Calculation node may provide support for the user who desires to process all accounts and return to a single total.
  • a Data Source node provides access to external file systems and database data, for example, DL/I, IMS, DB2, and other ISV databases.
  • Each Data Source node will have unique options for each of the different Data Source databases or file systems supported. These will be added to the product on an as needed or on demand basis.
  • FIG. 11 shows the various functions of the manager/server in one of the variations in which the process can exist.
  • the studio process is the modeler that builds the rules used by the rules processor to orchestrate application flows.
  • the manager/server and modeler/studio architecture is depicted graphically in FIG. 12 .
  • the server process or manager process contains a set of code instructions to manage the various processing engines and may in some implementations automatically switch states between the various processing functions as needed to process an application flow or to orchestrate a composite application consisting of one or more of the application area or processes shown in the example.
  • the SOAP clients can be any .NET, J2EE, standard Java, third party or user created web service functions.
  • the manager/server can itself call another manager/server running the same or different projects to complete a true distributed function. Functions may further be called from user written applications (not shown). During this process the manager or server is acting as an agent of the application and not that of a SOAP request. The processing may occur via API meta data structures instead of SOAP WSDL meta data XML files.
  • the following is a list of functions provided by a typical manager server for processing the application flow rules created by the modeler or studio functions.
  • the modeler or studio function typically includes a high quality graphical display process to achieve the easy graphical building of application flow process. Icons and images are used to associate tasks and functions required to build or orchestrate an application or set of application flows.
  • FIG. 13 depicts a sample screen of one example interface with features as more fully described below.
  • a graphical toolbox of icons may be used to manage the various nodes for building application flows and composite application processes. Such an exemplary interface is depicted in FIG. 14 .
  • 3270 Action Defines the AID operation that is required to continue (move to the next screen).
  • 3270 Point Node Identifies the BMS mapset and map name available to lower level nodes.
  • 3270 Process Defines the data and operations required for a 3270 Bridge process. Server will process the data collected by this node to invoke the 3270 transaction and start the data collection or processing actions that follow.
  • Callable Service Identifies inputs, outputs and work variables for the Callable Operation service.
  • Connector Provides the means to return to the main flow path after branching into multiple paths. The connector eliminates the need for complex or redundant tree structures. Note: Every connection into a Connector must originate from the same nearest parent point node.
  • Move to 3270 Defines the movement of data to the nearest parent 3270 point node (BMS map) from valid data sources, including 3270 field, copybook field, SOAP input, work variable, or static text.
  • Move to Output Defines the movement of data to a SOAP output (defined in the parent Web Service Operation node) from valid data sources, including the nearest parent point node, work variable, or static text.
  • Move to Web Defines the movement of data (defined in the parent Web Service Service Client Operation node) to the SOAP inputs of the Web Service Client Point Node.
  • Move to Work Provides the ability to assign values to work variables that Variable have been defined in the parent Web Service Operation node. This allows you to store information for later use in a Decision node or other movement node.
  • Operation End Signals the end of the Web service operation. Start Marks the beginning of the diagram and identifies the URI of the Web service operation. Sticky Note Allows you to add comments to the diagram to make it more understandable; it does not perform any processing or data collection.
  • Web Service Allows you to browse the Web for a WSDL document, which Client Point Node defines the available services and operations as well as the SOAP inputs and outputs for each operation. After you select a WSDL, you select the Web service and Web service operation you want to call.
  • Web Services Defines a single operation within the Web service. There can be one or more Web service operations connected to the Start node in each Ivory project. This node also defines the SOAP inputs, SOAP outputs, and work variables for this operation.
  • Some implementations may include a project explorer window that may be dockable within an MDI environment.
  • An exemplary project explorer window is depicted in FIG. 15 .
  • Project Explorer may display the contents of the project folder. When a project is created, a folder is specified where the project will reside. This folder may contain files that are not included in the studio project as explained below.
  • Various implementations may further provide a Property interface.
  • One exemplary interface is depicted in FIG. 16 and described further below.
  • the Properties window in such implementations may display the required meta data information for a selected node.
  • the operation of this exemplary interface is outlined as follows:
  • Some implementations may include a Diagram window that may also be referred to as an application flow window. Such a Diagram window may be included as part of an MDI interface. An exemplary diagram window is depicted in FIG. 17 . Such an exemplary interface may include one or more of the following features.
  • Some implementations may include a Browser window. An example of which is presented in FIG. 18 .
  • the Browser window may be included as part of the MDI or be launched separately.
  • the Browser window can display any documents including Internet site and text document.
  • Such an interface may provide one or more of the following features:
  • Some implementations may provide a Test Utility that can allow the unit testing of Web Services which are to be deployed to the manager or server.
  • An exemplary interface is provided in FIG. 19 .
  • Such a test utility window may support one or more of the following features:
  • Some implementations may support an Output window.
  • the Output window may be a dockable window supported in an overall MDI.
  • FIG. 22 depicts an example Output window.
  • An output window may support one or more of the following features:
  • a 3270 CICS application that searches for a name (first and last name) and displays information about the account including the account number, address, status, and account limit is described. Using this information, the 3270 operator, a helpdesk, could raise the account limit if the account status is active,or reopen the account if it is closed.
  • the existing program and business process can be converted to a Web service through a graphical definition, and no changes to the original program are required.
  • An exemplary graphical flow for this process is depicted in FIG. 25 .
  • the graphical diagram defines a Web service which represents the application or business process that the 3270 operator had to perform manually:
  • the WSDL output fields are the typical method to return data to the requesting application. Notice that not all of the information available on the 3270 screen was of interest to the 3270 operator. Therefore, Web service developer provided only the data required by the operation. This reduces the storage requirement during processing and data transfer between machines reducing the network traffic requirements.
  • logic can be added to update or raise the credit limit based on the credit limit by executing additional 3270 BMS transactions.
  • FIG. 29 depicts such an enhanced graphical definition. This new task can reuse the original Web service in a new Web service.
  • this Web service can consume a Web service published by a state agency to validate the driver's license number.
  • the 3270 operator needs to execute a transaction on a Microsoft Windows application which publishes a new credit card after updating a credit limit, it can be automated by adding a Web Service Client Point Node to execute the Microsoft Windows-based Web service from the mainframe. Combining the 3270 operator's tasks to run as a single task can save time and money. This can all be done without writing a single line of mainframe program.
  • a mainframe Web service can be generated through diagraming a business process, such as getting insurance policy information for a user.
  • a mainframe for example, may have a separate application or business process for each type of insurance policy: home, car, and health.
  • the described systems and methods can provide the ability to combine these separate business processes into a single business process implemented as one or more Web services.
  • the described systems and methods can include design and runtime functions.
  • the design component can include a modeler and/or an interface to a mainframe application.
  • the modeler may provide the ability to change logic flow and the path of the original mainframe application.
  • the runtime function component can include a mainframe Web service.
  • the Web service interface is built around mainframe applications that reside on the mainframe. The described systems and methods can verify that the original mainframe application and Web service are in sync.
  • FIG. 30 provides an overview of the modeler and server in some of the systems and methods described herein. These systems and methods improve Web service development along several axis including one or more of the following:

Abstract

Systems and methods for defining, implementing, deploying and/or executing Web services. A Web service is defined using a graphical interface that allows the application developer to specify the operation of the Web service through inclusion and configuration of graphical nodes representing particular operations and/or functions. The Web service definition can, in some instances, include standard functions and/or previously defined Web services. The environment for definition typically includes a user input device, a graphical display device, a system data store and a system processor. The system processor is in communication with the other elements. The user defines the Web service using an interface provided via the graphical display device. The user interacts with the interface using the user input device. The system processor receives the information from the user input device and updates the provided interface on the graphical display device accordingly. The graphical definition of the Web services is stored at least ephemerally in the system data store, but may, in some instances, be saved to the system data store. Once defined, the graphical definition is converted into a programmatic implementation executable by a Web services server. This programmatic implementation can then be transmitted to an appropriate Web services server accessible by an intended user community.

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • This patent application is a continuation of copending U.S. patent application Ser. No. 11/129,597, filed May 13, 2005, entitled SYSTEMS AND METHODS FOR WEB SERVICE FUNCTION, DEFINITION, IMPLEMENTATION, AND/OR EXECUTION, which claims the benefit of U.S. Provisional Patent Application No. 60/571,652, filed May 14, 2004, the disclosures of which are incorporated herein by reference in their entirety.
  • BACKGROUND
  • The present application is directed to systems and methods for Web Service function, definition, implementation, and/or execution. The Internet is a global network of connected computer networks. Over the last several years, the Internet has grown in significant measure. A large number of computers on the Internet provide information in various forms. Anyone with a computer connected to the Internet can potentially tap into this vast pool of information.
  • The information available via the Internet encompasses information available via a variety of types of application layer information servers such as SMTP (Simple Mail Transfer Protocol), POP3 (Post Office Protocol), GOPHER (RFC 1436), WAIS, HTTP (Hypertext Transfer Protocol, RFC 2616) and FTP (File Transfer Protocol, RFC 1123).
  • One of the most wide spread methods of providing information over the Internet is via the World Wide Web (the Web). The Web consists of a subset of the computers connected to the Internet; the computers in this subset run HTTP servers (“Web servers”). Several extensions and modifications to HTTP have been proposed including, for example, an extension framework (RFC 2774) and authentication (RFC 2617). Information on the Internet can be accessed through the use of a Uniform Resource Identifier (“URI,” RFC 2396). A URI uniquely specifies the location of a particular piece of information on the Internet. A URI will typically be composed of several components. The first component typically designates the protocol by which the address piece of information is accessed (e.g., HTTP, GOPHER, etc.). This first component is separated from the remainder of the URI by a colon (‘:’). The remainder of the URI will depend upon the protocol component. Typically, the remainder designates a computer on the Internet by name, or by IP number, as well as a more specific designation of the location of the resource on the designated computer. For instance, a typical URI for an HTTP resource might be:
  • http://www.server.com/dir1/dir2/resource.htm
  • Where HTTP is the protocol, www.server.com is the designated computer name and /dir1/dir2/resouce.htm designates the location of the resource on the designated computer. The term URI includes Uniform Resource Names (“URNs”) including URNs as defined according to RFC 2141.
  • Web servers host information in the form of Web pages; collectively the server and the information hosted are referred to as a Web site. A significant number of Web pages are encoded using the Hypertext Markup Language (“HTML”) although other encodings using Standard Generalized Markup Language (“SGML”), eXtensible Markup Language (“XML”), Dynamic HTML (“DHMTL”) (the combination of HTML, style sheets and scripts that allows documents to be animated) or Extensible HyperText Markup Language (“XHTML”) are possible. The published specifications for these languages are incorporated by reference herein; such specifications are available from the World Wide Web Consortium and its Web site (http://www.w3.org). Web pages in these formatting languages may include links to other Web pages on the same Web site or another. As will be known to those skilled in the art, Web pages may be generated dynamically by a server by integrating a variety of elements into a formatted page prior to transmission to a Web client. Web servers, and information servers of other types, await requests for the information from Internet clients.
  • Client software has evolved that allows users of computers connected to the Internet to access this information. Advanced clients such as Netscape's Navigator and Microsoft's Internet Explorer allow users to access software provided via a variety of information servers in a unified client environment. Typically, such client software is referred to as browser software.
  • Web services further facilitate access to information on the Internet by computer users. Web services address the need to integrate legacy mainframe applications by acting as platform-independent interfaces that allow communication with other applications using standards-based Internet technologies, such as HTTP and XML. With traditional integration techniques, there are multiple point-to-point communication and data conversions that may change as new applications are integrated or data formats change. Web services simplify integration by reducing the number of Application Program Interfaces (“API”) to one, Simple Object Access Protocol (“SOAP”) and the number of data formats to one, XML. SOAP overlays XML and transmits data in a way that can be understood and accepted by Web browsers and servers. The XML is also human readable. Web services allow programmers to make databases and/or other applications available across the Web for other programmers to access them and link the applications together to provide services.
  • Web services using the request and response methods are further described as being a Service Oriented Architecture (“SOA”) approach to integration of electronic business applications or processes. A service-oriented architecture is essentially a collection of services. These services communicate with each other as described previously. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. The methods of connecting services to each other involve the protocols and transport methods of SOAP.
  • Web Services Description Language (“WSDL”) is a format for describing a Web services interface. It is a way to describe services and how they should be bound to specific network addresses. The WSDL includes three parts: definition, operations and service bindings.
  • WSDL definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based on some agreed upon XML vocabulary. This agreement could be within an organization or between organizations. Vocabularies within an organization could be designed specifically for that organization. They may or may not be based on some industry-wide vocabulary. If data type and message definitions need to be used between organizations, then most likely an industry-wide vocabulary will be used.
  • WSDL operations are grouped into port types. Port types define a set of operations supported by the Web service.
  • WSDL service bindings connect port types to a port. A port is defined by associating a network address with a port type. A collection of ports defines a service. This binding is commonly created using SOAP protocols and transport methods.
  • IBM created a SOAP interface for CICS (Customer Information Control System) which only supported a one-to-one relationship between the SOAP request and to the application code. This process does not provide automatic parsing and processing between the SOAP XML and the application communication areas. It also fails to provide any method for processing 3270 BMS applications. The IBM process provides neither flow processing nor graphical interface tooling with the SOAP process.
  • A main problem of most computer-based systems is their lack of ability to create composite processing in a Web service environment. A primary aspect of the Web service software described herein is to provide composite-based application processing using existing application software. Present systems lack support for a variety of functionality in the Web service area. Present systems do not support application flow and processing multiple applications via a single SOAP request would provide a much-needed process to the market place. Further, programmers have a significant learning curve to build the required XML and WSDL files required for SOAP processing.
  • SUMMARY
  • The present application is directed to systems and methods for Web services function, definition, implementation, and/or execution. In one aspect, Web services are defined with respect to one or more functions available from applications executing on one or more remote systems. In a further aspect, such definitions are used to generate a programmatic implementation that is communicated to a Web services server executing on, or in communication with, the remote system(s). In yet another aspect, Web services clients can then use the defined service by posting appropriate requests to the Web services server and receiving back from that server a response encoding the results of performing the requested Web service.
  • One application for Web service definition and/or development may be referred to herein as the studio or modeling software. The modeling software can also be described as the application flow designer for the patent application. The modeler can preferably be implemented in software executable on a typical computer having a system data store (“SDS”) and a system processor; however, the modeler functionality, or portions thereof, may be implemented in whole, or in part, via hardware. In addition, or instead, the modeler functionality, or portions thereof, can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media.
  • An application for generating a programmatic implementation that is communicated to a Web services server may be referred to herein as a server or rule-based flow engine. The manager can preferably be implemented in software executable on a typical computer having an SDS and a system processor, however, the server functionality, or portions thereof, may be implemented in whole, or in part, via hardware. In addition, or instead the server functionality or portions thereof, can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media. In some implementations the server functionality can be standalone, performed within the studio or performed within the server.
  • A Web services server preferably incorporates an SDS, a system processor, and one or more interfaces to one or more communications channels that may include one or more interfaces to user workstations over which electronic communications are transmitted and received. In addition, or instead, the server functionality, or portions thereof, can be embodied in instructions executable by a computer, where such instructions are stored in and/or on one or more computer readable media.
  • A Web services client (“Requestor”) executing on a computer communicates a Web service request to the Web services server (“Provider”). The Web services server executes the programmatic implementation of the defined Web service to generate a response. The response is then communicated to the Requestor. The Provider may execute one or more applications on the system execute the server and/or one or more remote systems in order to generate the response.
  • In each of the studio and server processes, the system processor is in communication with the respective SDS via any suitable communication channel(s); system processor may further be in communication with the one or more communication interfaces via the same, or differing, communication channel(s). Each system processor may include one or more processing elements that provide electronic communication reception, transmission, interrogation, analysis, processing and/or other functionality. In some implementations, the system processor can include local, central and/or peer processing elements depending upon equipment and the configuration thereof. It should be noted that the modeler, manager, server (and client) are summarized above as discrete components; however, these various components all together, or taken in any selected grouping, could be implemented within a single execution environment where a particular system processor and/or SDS could support one or more such components. Each SDS may include multiple physical and/or logical data stores for storing the various types of information. Data storage and retrieval functionality may be provided by either the system processor or data storage processors associated with, or included within, the SDS.
  • The studio provides an automated graphical process of collection of information to define and build the Web service process using an SOA. The studio process provides a graphical flow of the application processes required to build a request and response SOAP-based Web service. The graphical flow or model is then used to create the rules or execution path the server must follow to provide the requested SOAP response. Composite application processing can be provided via the modeling or rules-based process, the designer also provides for external logic processing to control the logic flow through the multiple applications.
  • The manager may optimize its data movement processing and lower storage requirements by only holding data or storage as long as needed. Work meta data fields can be used to dynamically modify control settings at runtime. This process allows the modeler and manager to communicate changes to the flow before runtime that take place at runtime. The manager can allow for called projects, so that an application program can call other application flows at any time based on application or business requirements. This can provide a very powerful way to extend working application flows. An application flow can call other deployed application flows at any time during its processing.
  • In another aspect, a flow processing engine is disclosed in some implementations that processes movement of data to and from standard application meta data formats to and from the SOAP XML meta data formats. This process reduces the need of the application programmer having to know or understand SOAP and XML processing and having to code additional application program to process SOAP and XML. This can significantly reduce the time to market and the possibility for errors to be introduced into the process. In a further aspect, some implementations of the modeler disclosed herein can increase programmer productivity by allowing a drag and drop interface for building application flows and data movements between one or many applications. Development time can be greatly reduced because the need to build routines to parse and move the XML data to/from existing meta data formats is eliminated.
  • A further feature of some implementations includes processing pure SOAP, XML and WSDL creation using a composite application process that allows mapping and data movements without any code to be created and executed. Some such implementations may provide processing via a runtime image that processes the XML rules and instructions for processing the application flow, external logic and data movement processing.
  • Additional advantages will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the systems and methods described herein. The advantages of the disclosed systems and methods will be realized and attained by means of the elements and combinations particularly pointed out herein. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed below.
  • BRIEF DESCRIPTION OF DRAWINGS
  • The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various aspects of the disclosed systems and methods and together with the description, serve to explain and/or exemplify their principles.
  • FIG. 1 depicts an example graphical user interface for a typical modeler environment.
  • FIG. 2 depicts an exemplary import interface for an example modeler.
  • FIG. 3 depicts an exemplary data movement interface for an exemplary modeler.
  • FIG. 4 depicts an example rule set generated in a typical modeler environment.
  • FIG. 5 depicts a directory listing for a file repository in an exemplary modeler.
  • FIG. 6 provides a sample FTP interface from an exemplary modeler.
  • FIG. 7 is an exemplary Server Administration screen for server configuring and managing.
  • FIG. 8 depicts an exemplary TN3270 Client accessing a TN3270 Server (Emulator).
  • FIG. 9 depicts a potential Integrated Development Environment (IDE) for an exemplary modeler.
  • FIG. 10 is an exemplary FTP interface used in an exemplary modeler.
  • FIG. 11 is a block diagram of various components or functions of an exemplary modeler and server.
  • FIG. 12 is a graphic representation of a potential architecture for an exemplary modeler or server.
  • FIG. 13 is an example screen representing an IDE with MDI, drag and drop and dockable windows as used in some potential implementations.
  • FIG. 14 depicts a potential tool box window of an exemplary modeler.
  • FIG. 15 depicts a potential project explorer window of an exemplary modeler.
  • FIG. 16 depicts a potential property window of an exemplary modeler.
  • FIG. 17 provides a graphical representation of an example graphical diagram window.
  • FIG. 18 represents a browser window within exemplary modeler.
  • FIG. 19 depicts an exemplary test window.
  • FIG. 20 depicts an exemplary SOAP request window as used by the exemplary test window of FIG. 19.
  • FIG. 21 depicts an exemplary SOAP response window used by the exemplary test window of FIG. 19.
  • FIG. 22 represents an example output window.
  • FIG. 23 depicts a screen from mainframe sample application.
  • FIG. 24 depicts a sample data input into the example screen in FIG. 23.
  • FIG. 25 depicts an exemplary modeler project representing a Web service to operate a mainframe application defined through graphical nodes.
  • FIG. 26 demonstrates the relationship between a property window and a node within an graphical diagram window in a particular example modeler.
  • FIG. 27 represents use of a drop-down menu for selecting a data sources for an exemplary node.
  • FIG. 28 represents use of a drop-down menu for selecting a data sources for an exemplary node.
  • FIG. 29 depicts a sample graphical Web service definition accessing a mainframe application.
  • FIG. 30 demonstrates graphical definition of a composite Web service within an exemplary modeler.
  • FIG. 31 depicts a typical deployment architecture for Web services using an exemplary modeler and server.
  • DETAILED DESCRIPTION
  • Exemplary systems and methods are now described in detail. Referring to the drawings, like numbers indicate like parts throughout the views. As used in the description herein, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. Finally, as used in the description herein, the meanings of “and” and “or” include both the conjunctive and disjunctive and may be used interchangeably unless the context clearly dictates otherwise; the phrase “exclusive or” may be used to indicate situation where only the disjunctive meaning may apply.
  • The hardware of a typical execution environment for one or more of the components supporting Web services definition, implementation and/or execution include a system processor potentially including multiple processing elements, that may be distributed across the hardware components, where each processing element may be supported via a general purpose processor such as Intel-compatible processor platforms preferably using at least one PENTIUM class or CELERON class (Intel Corp., Santa Clara, Calif.) processor; alternative processors such as UltraSPARC (Sun Microsystems, Palo Alto, Calif.) and IBM zSeries class processors could be used in other implementations. In some implementations, Web services definition, implementation and/or execution (servicing) functionality, as further described below, may be distributed across multiple processing elements. The term processing element may refer to (1) a process running on a particular piece, or across particular pieces, of hardware, (2) a particular piece of hardware, or either (1) or (2) as the context allows.
  • Some implementations can include one or more limited special purpose processors such as a digital signal processor (DSP), application specific integrated circuits (ASIC) or a field programmable gate arrays (FPGA). Further, some implementations can use combinations of general purpose and special purpose processors.
  • The hardware further includes an SDS that could include a variety of primary and secondary storage elements. In one preferred implementation, the SDS would include registers and RAM as part of the primary storage. The primary storage may in some implementations include other forms of memory such as cache memory, non-volatile memory (e.g., FLASH, ROM, EPROM, etc.), etc.
  • The SDS may also include secondary storage including single, multiple and/or varied servers and storage elements. For example, the SDS may use internal storage devices connected to the system processor. In implementations where a single processing element supports all of the server/manger functionality and/or the modeler functionality a local hard disk drive may serve as the secondary storage of the SDS, and a disk operating system executing on such a single processing element may act as a data server receiving and servicing data requests.
  • It will be understood by those skilled in the art that the different information used in the systems and methods for Web service function definition, implementation, and/or execution as disclosed herein may be logically or physically segregated within a single device serving as secondary storage for the SDS; multiple related data stores accessible through a unified management system, which together serve as the SDS; or multiple independent data stores individually accessible through disparate management systems, which may in some implementations be collectively viewed as the SDS. The various storage elements that comprise the physical architecture of the SDS may be centrally located or distributed across a variety of diverse locations.
  • The architecture of the secondary storage of the system data store may vary significantly in different implementations. In several implementations, database(s) are used to store and manipulate the data; in some such implementations, one or more relational database management systems, such as DB2 (IBM, White Plains, N.Y.), SQL Server (Microsoft, Redmond, Wash.), ACCESS (Microsoft, Redmond, Wash.), ORACLE 8i (Oracle Corp., Redwood Shores, Calif.), Ingres (Computer Associates, Islandia, N.Y.), MySQL (MySQL AB, Sweden) or Adaptive Server Enterprise (Sybase Inc., Emeryville, Calif.), may be used in connection with a variety of storage devices/file servers that may include one or more standard magnetic and/or optical disk drives using any appropriate interface including, without limitation, IDE and SCSI. In some implementations, a tape library such as Exabyte X80 (Exabyte Corporation, Boulder, Colo.), a storage attached network (SAN) solution such as available from (EMC, Inc., Hopkinton, Mass.), a network attached storage (NAS) solution such as a NetApp Filer 740 (Network Appliances, Sunnyvale, Calif.), or combinations thereof may be used. In other implementations, the data store may use database systems with other architectures such as object-oriented, spatial, object-relational or hierarchical.
  • Instead of, or in addition to, those organization approaches discussed above, certain implementations may use other storage implementations such as hash tables or flat files or combinations of such architectures. Such files and/or tables could reside in a standard hierarchical file system. Such alternative approaches may use data servers other than database management systems such as a hash table look-up server, procedure and/or process and/or a flat file retrieval server, procedure and/or process. Further, the SDS may use a combination of any of such approaches in organizing its secondary storage architecture.
  • The hardware components may each have an appropriate operating system such as WINDOWS/NT, WINDOWS 2000 or WINDOWS/XP Server (Microsoft, Redmond, Wash.), Solaris (Sun Microsystems, Palo Alto, Calif.), or LINUX (or other UNIX variant).
  • In one implementation the server or manager executes on a z/OS or VSE/ESA platform and the modeler or studio executes under a WINDOWS 2000 or WINDOWS/XP operating system. The server or manager executes as a rules-based processing application using XML based instructions created by the modeler or studio software. The modeler or studio is a graphical tool for building application flows to allow processing of non-SOAP and SOAP-based applications as SOAP-based composite applications.
  • In some implementations, a graphical user interface is disclosed that allows business analysts and programmers to form a collaboration to build a new business process centered on Web services. For example, users may be business analysts who require a method of interfacing to a mainframe application without an in-depth knowledge of the programming and/or application execution environment. Other users might be application developers or technical support personnel tasked with building SOAP Web services for use by application servers. This aspect can allow a developer to bridge between the application logic and the business process needed to provide a SOAP Web service.
  • In one implementation of the methods and systems described herein, a client uses a graphical interface to build a business process by defining inputs and expected outputs and then stepping through the application using graphical icons or nodes for each step. This graphical user interface allows the modeling of a Web service via graphical objects. The graphical objects are connected using connection points to form a flow through the various applications or methods needed to create the single process or composite process web service. As seen in FIG. 1, the application flow through the various nodes controls the logic processing for several applications which provide the unique function of composite processing.
  • Each of the functions, (for example, business logic functions such as Link Point 3270 process and 3270 Point or Web Service Client point nodes, start and stop, logic flow, input and output movement nodes or XML/data remapping) may be represented by a graphical icon or node. The modeler software is resident on the client's workstation and converts the client's input into processing rules in a single format, for example XML. The modeler provides the server with the rules required to navigate or otherwise invoke a business logic process, a transactional or conversational type application or even Web services which exist on the same or external servers.
  • The server or manager is a rules-based engine used to process rules generated as instructions from the modeler. The composite processing of applications provided by the server are a direct result of building the application flow using a graphical design tool. This process provides a simple yet powerful process for building mainframe-based SOAP or SOA applications. The graphical tool serves as one facet of the overall systems and methods described herein. Use of this tool allows no additional programming to be required once the modeler tool has deployed the rules to the server or manager software. The server processes the incoming SOAP request envelope, and then processes the business logic to build the SOAP response envelope for the returned SOAP packet. The server may further allow various processes of additional functions or business logic to form a complete response. Service requestors may communicate with the server to discover the defined Web services and import the WSDL that is created by the modeler to describe and define the processing of the service. The modeler or studio tooling builds the WSDL file automatically for the client or user of the system and removes the need to have the knowledge of building these interface files. The WSDL files can then be used by other third party products such as application design tools to build the interface modules called SOAP clients or proxies to access the applications that are orchestrated by the modeler/studio and server/manager.
  • In some implementations, existing business logic and/or application information can be imported into the systems and methods described herein. Existing business logic and/or application information may be supported through particular formats such as BMS or copybooks. An interface can be provided for such importation such as depicted in FIG. 2. Imported business logic and/or application information can then be used to build Web services.
  • The importing process provides a way to communicate between various different system types, and the meta data collected through importation allow systems designers to communicate in a known language. Additional meta data may be created and/or renamed, mainly SOAP input and output meta data that is to be exposed by the Web service can be named or described using new meta data names, which can then hide the fact that the back-end system is not a Web service-based application.
  • The imported meta data is preferably normalized into an XML format to allow it to be processed using standard XML parsers instead of having to use a unique parser. The imported data, and/or other meta data, can be viewed in a tree fashion using tooling provided by some implementations of the modeler. FIG. 3 depicts such an example.
  • The graphical building of a Web service may use imported information to define communication with business logic and/or application processes. Each node has a unique function and properties that define the Web service and the operations performed by the service. For example, in a particular implementation, a Start node can describe the Web service and can serve the anchor or parent node for all other operations. A Start node can further represent multiple operations and/or configuration settings. It can, for instance, describe the location (environmental) attributes of the Web service that you are building.
  • Once the Web service operations have been defined the user may select the correct processing or point node. Each processing or point node defines the information required to access the target source. For example, for 3270 interface operations the target could be a CICS transaction code, or for a COMMAREA application the target could be a CICS program name. Additional data sources such as DL/I, IMS, DB2, VSAM, could also be used. As users build the diagram or model of the Web service they may connect the nodes to form the logic or processing flow. This flow will later be translated into instructions for the rules-based SOAP server process. The syntax of the diagram is verified each time a node connection is attempted to insure a valid logic path and that node connection rules are correct. The logic path is traced to insure that the connection operation is to a valid parent and is not crossing Web service operation paths or boundaries. Each Web Service Operation node defines the expected SOAP input and output for the service operation path. The WSDL is created from the properties entered for each of the nodes. This document is an XML description of the interface methods for the Web service being created.
  • The modeler build process may in some instance provide a verification of the Web service at the same time as it creates the server rules, WSDL and HTML to define the service.
  • The descriptive HTML may be static or converted to a dynamic XSTL template that will build the HTML dynamically based on the XML of the WSDL. The WSDL generated by the modeler build process can now be used, in some implementations, by an execution test and/or debug tool. Such a test and/or debug tool potentially provides for further verification of the service definition and the generated Web service interfaces. These tools can dynamically process the service information (WSDL code) to create the user interface required to verify the deployed Web service. In such implementations, the WSDL definition may serve as the interface point between Java J2EE and .NET processing. The WSDL may be processed by popular Integrated Development Environment (“IDE”) products that supply the capability to automatically build the Java, C# or other language interface code for processing the Web service described by the WSDL.
  • The server side instructions (rules) contain a mixture of execution and data flow. These instructions can be represented in XML as a tree structure. The XML tree is derived from the project diagram and its associated settings including data movements and/or properties. The diagram itself is stored as a mostly flat entity (although it may be represented in XML) so the resultant server instructions are not required to have the same appearance as the diagram. The format of rules is preferably set to provide the highest performance, as these rules will be executed for each request of the Web service. The rules may be compressed and/or optimized to improve performance of execution. Each execution node within the server instructions contains children nodes, one of which will receive control once the parent has completed its processing. The choice of the next child to dispatch is determined at runtime by the rules engine, but the rules instructions allow all possible choices to be specified. FIG. 4 depicts a representation of the rules generated by an exemplary modeler in one particular implementation.
  • The model designer has complete control over server processing logic flow. There are no ambiguous execution flows within a Web service operation; the model designer details completely how the server is to operate. Data flow is completely described within the modeling diagram process. The modeler creates the server side instructions via an “n-pass” algorithm applied to the diagram XML based on the number of paths created by the client in the diagram. Server processing is a single pass of the XML server rules instructions tree. The modeler pre-notifies the server, possibly via the rules, of any data movements required to be saved for later usage to optimize the server performance. This design places the complexity burden upon the modeler to be highly optimized in its rule creation resulting in performance benefits in the server rules engine.
  • The server may be a SOAP server based on the HTTP and SOAP protocols. The particular server may support processing standard HTTP and/or secure HTTPS requests. The repository may be a Hierarchical File System based on a CICS standard VSAM KSDS file; this unique function provides support for a UNIX/Windows based file system without the need for Unix System Services on CICS. The file repository may contain a command line processor for management of the file system via a standard CICS transaction. Command examples include, but are not limited to creation of file systems in the repository, directories and data files as depicted in FIG. 5. The file system repository can also be managed from an FTP server provided such as with the SOAP server and/or via the FTP client supplied with the modeler. FIG. 6 provides an example of screen of management via an FTP server. The HTTP server and FTP server can follow the standard Internet RFCs for those protocols.
  • The server can provide the ability to map transactional 3270 and program-based applications into SOAP methods or objects. The heart of this process is the rules engine that is used to process the output rules instructions from the modeler. The server processes each node starting from the initial start point of the diagram. In a preferred implementation, each diagram contains the Web service name and the operations or methods the service provides. Once the method is selected from the SOAP Request envelope, the selected Web Service Operation node becomes the parent node and the logic tree that results will all branch from this common parent. For example, each node of the rule instruction set may cause the server to dispatch the function to handle the node operations. The node operations are optimized into the correct code page for the mainframe session.
  • In a preferred implementation, the HTTP server provides the base protocol support on top of CICS Web Services. This HTTP server provides administrative utilities to manage the SOAP services and FTP servers. An example administrative screen is seen in FIG. 7. All discoveries of WSDL files and management of the HTML documentation can be stored in a Hierarchical File System (as part of the SDS).
  • Some implementations of the described systems and methods may incorporate a debugger or testing tool to read in the WSDL and extract all the operations that can be performed. The debugger lists the operations in a pull-down list. Once the user selects an operation from the list the input field, meta data will be used to build a tree view of the required input fields. The debugger or test tool may be used to input data for the SOAP Request envelope. For complex arrays the user may first define how many occurrences will be entered, and then the debugger will provide input area in the tree display for the occurrences of the complex type. The debug option may be added to the client modeler application and the server service provider. The debug operations may be a two-way communication path that will allow the client to know what step has been executed on the mainframe. The client notifies the server of the debug request by sending additional headers in the HTTP request to show the debugging client machine. The user may open a TCP/IP socket to listen for requests. As the server starts execution of the rules the server will send status information to the client. The modeler will show the current step in the diagram and will provide for breakpoints and other standard debug commands, such as looking at storage, setting new data values.
  • Some implementations of the described methods and systems incorporate an emulator. The emulator can be written in such a way to provide .NET access to the 3270 emulation via browser object tags, the browser may be used as the container for the emulator product. This may also extend beyond the browser into an API that allows programmatic control over the 3270/5250 applications. This will be a pure .NET solution and as such will allow any .NET language on a Microsoft platform be used to build new interfaces. The emulator can take advantage of performance improvements placed into the Windows .NET object used to build applications.
  • The emulator can be installed in classic windows fashion, or via a browser interface. An exemplary emulator screen is seen in FIG. 8.
  • In some preferred implementations, the modeler process provides for building Web services by importing Basic Mapping Support macros (“BMS”) and building a data structure in XML that matches the Application Data Structure (“ADS”). For example, in one implementation the model may provide a method for importing the CICS COMMAREA into an XML format much like the BMS macro layout. This provides a common layout and structure for the various application data structures that will be used.
  • In some preferred implementations, a user builds a business process by defining inputs and expected outputs and then stepping through the application using graphical icons for each step. Each of the functions, for example business logic functions, starts and stop, logic flow, or XML remap, is represented by an icon. The end result is a graphical design of the application from the Web service inputs to the final Web service response. The graphical models may be self-documenting or may also provide for process documentation to be entered using “sticky notes”. The modeler interfaces with an IDE, which processes the menus and windows for user selections. The general design in a preferred implementation may include dockable and movable windows and the use of Multiple Document Interface (“MDI”). (See FIG. 5.) Menus and screen literals may optionally be based in resource files to allow for support of languages other than English. FIG. 9 depicts an exemplary screen.
  • The modeler will allow users access to multiple applications in a single Web service by combining application available functions, in contrast to conventional systems that require having to make several calls. In order to improve compatibility with other systems, all or some files created by the modeler, including the project files, can be stored using an XML format. The modeler may incorporate functions to import copybooks that are converted to an easy to understand XML format, which allows for easy expansion of the resulting meta data dictionary. The modeler will also incorporate a BMS macro importer to convert the BMS source into XML format. An FTP client can be provided to pull copybooks and/or BMS macros from the mainframe or other computer. An exemplary interface screen is depicted in FIG. 10. The FTP client may include a meta data import function. Such a function supports ease of use by clients when importing meta data located on a remote computer system.
  • The modeler provides the server with all the rules engine information needed to process SOAP operations.
  • Manager software, for example, mainframe service routines, uses XML data collected via the modeling software to process the business rules defined in the graphical model by the user. Input to the manager will be the processing rules from the modeler and the SOAP packet. The input process will fire the manager, and it will process the business logic building a result for the returned SOAP packet.
  • In one preferred implementation, the server is a rules-based engine that processes the XML server instructions from the modeler. Each node is converted into a set of rules that allow the various processes of a Web service to be applied to information and procedures resident on a server, for example the CICS TS server or on IMS-based server processes.
  • The Start node is the initial setup and logical start of the Web service being created. The Start node defines the name of the Web service and various WSDL options such as the URI to invoke the Web service and the target namespace for the SOAP input/output fields that will be defined. The processing type of RPC (Remote Procedure Call) and Document is requested at this node.
  • The Web Service Operation node provides the logical name for the method or operation and provides the SOAP input and output structures. Each input field and its type is described at the Web Service Operation node. The output structure expected from the Web service is also defined at this node.
  • The LINK Point Node provides the interface point between the server and the Web service being created. The link point defines the name of the program to execute and the location where it should execute. CICS dynamic routing rules may be used when processing.
  • Some implementations may incorporate a 3270 Process node and a Point node. The Process node may cover all the setup information for the transaction code and the information required by CICS to start the 32370 process. The Point node is used to supply the current BMS mapset and map name so that data movements can be created.
  • Data movement nodes provide a tree structure for creation of move rules. Some examples of data movement nodes include Move to LINK, Move to 3270, and Move to Output. The movement process is based on a common code base so that all movement nodes have a similar function. The Move to LINK node, for example, may provide the method to set the initial values for the program that will be invoked. The Move to 3270 node may allow for moving data to the BMS map in order to provide input for the 3270 screen operation. In one implementation, the data that could be used for these move operations could be from static values, SOAP input request envelope, and any previously accessed 3270 map or CICS COMMAREA.
  • The Decision nodes provide the ability to add logic that will change the flow through the model. These nodes may be processed by the server and take action on data from any previous point node under the same Web Service Operation node. Complex operations may be defined using the Decision nodes in conjunction with Loop nodes. Decision nodes can target the current point node process for all comparison operations.
  • Logic Decision nodes may also be placed in the flow. These nodes allow the data to be examined and the result to modify the flow of the server rules to provide 2 paths for each decision node, so the logic paths or flows increase 2*n where n=the number of decision nodes. These nodes may provide the method for the logic flow to form a tree format. In conjunction with Decision nodes, Connector nodes may be incorporated to allow consolidation of logic paths. The Connector node may provide the method for a branch of logic to return to any logic path under the parent Web Service Operation.
  • Loop processing is also used within decision tree processing; a Loop node provides a method for returning to a previous node within the parent Web service operation. At times logic of applications running in CICS will require that they be executed using multiple iterations. The Loop node will allow the logic flow to return to a parent node. For 3270 BMS this might be an operation that is scrolling through several screens. For a COMMAREA application, it might be a program that requires more than one pass to collect all the returned data.
  • The Move to Output node allows for data to be moved from any previous point node with the same parent Web Service Operation node. The target of the movement data will be the SOAP response envelope.
  • The Connector nodes provide a very important process that allows several logic paths to branch out and then return to the main line logic flow.
  • The Operation End node is a logical placeholder to signal that the Web service operation has completed its task. All Web Service Operation node paths can connect to a single Operation End node.
  • A Calculation node will provide for mathematical operations to be added to the logic flow of the modeler. These nodes will process data from the application and will be used to modify the result set returned to the client. For example, the 3270 application may have a total account balance for the persons account. A Calculation node may provide support for the user who desires to process all accounts and return to a single total.
  • A Data Source node provides access to external file systems and database data, for example, DL/I, IMS, DB2, and other ISV databases. Each Data Source node will have unique options for each of the different Data Source databases or file systems supported. These will be added to the product on an as needed or on demand basis.
  • Exemplary Manager or Server Function
  • The following description lists some general features of an exemplary manager or server function that may be used along with a modeler or studio function to provide application flow processing and orchestration of applications. The manager or server processes all SOAP requests and handle the processing of application flow as described by the rules created by the modeler or studio process. Application orchestration provides a method to modify application flow without the need to modify the existing application code. FIG. 11 shows the various functions of the manager/server in one of the variations in which the process can exist. The studio process is the modeler that builds the rules used by the rules processor to orchestrate application flows. The manager/server and modeler/studio architecture is depicted graphically in FIG. 12.
  • The server process or manager process contains a set of code instructions to manage the various processing engines and may in some implementations automatically switch states between the various processing functions as needed to process an application flow or to orchestrate a composite application consisting of one or more of the application area or processes shown in the example.
  • The SOAP clients can be any .NET, J2EE, standard Java, third party or user created web service functions. The manager/server can itself call another manager/server running the same or different projects to complete a true distributed function. Functions may further be called from user written applications (not shown). During this process the manager or server is acting as an agent of the application and not that of a SOAP request. The processing may occur via API meta data structures instead of SOAP WSDL meta data XML files.
  • The following is a list of functions provided by a typical manager server for processing the application flow rules created by the modeler or studio functions.
    • Rules processing engine for processing execution rules provided by the modeler/studio software for orchestration of application processes along with handling all the dynamic movement of data to and from SOAP XML meta data to application specific meta data layouts. The algorithm used for application flow processing may work in conjunction with the memory management algorithm to insure that only the storage required is saved during the execution orchestration process.
    • HTTP or HTTPS processing of incoming SOAP requests, optionally the requests could be dropped onto an MQSeries queue for processing by the rules engine. This may include the security checking and processing required for verification that the process is valid for the passed security information.
    • The application meta data mapping and data transformation algorithm may be based on the imported meta data information collected from the modeler or studio execution rules instructions. This algorithm includes routines for processing data transformations between the various encoding methods of ASCII to/from EBCDIC. The server/manager may also process all the various COBOL application data types of, but not limited to: COMP, COMP-2 COMP-3, COMP-4 and POINTERS. String and decimal number processing can be processed by the data mapping functions to insure the correct decimal alignment options are processed.
    • Storage processing may be handled by management modules that insure only the data needed to process the movements in the project rules files are saved during the execution of the SOAP or MQSeries request.
    • A URI mapping module may control the processing options and security used for various SOAP requests based on any suitable technique; in one preferred implementation, a pattern matching algorithm is used.
    • The manager may also process WSDL discovery requests as a standard SOAP server using the ?WSDL option, but it processes the documentation of the WSDL into an HTML file that can be served out using the ?INFO request which displays the information collected by the modeler/studio functions into a human readable form of HTML so that other application developers can read and understand the requirements of the WSDL process. This can be advantageous in the debugging and analysis of the Web service.
    • The rules engine may be implemented a single common resource. In some implementations, this rules engine may be completely re-entrant so that it can handle multiple inbound requests.
    • The manager/server may also, in some implementations provide trace functions which create an XML description document that traces the functions of the last SOAP request call. The trace can be used to debug operations or look for problems.
    • The Callable Services Operation (CSO) module may provide an API to an application program which communicates with the CSO module via COMMAREA interface. The CSO module may operate to convert COMMAREA input requests to SOAP requests, execute the requested Web services, and deliver the results in COMMAREA output area.
    Exemplary Modeler or Studio Function
  • The following description lists some general features for an exemplary modeler or studio that may be used along with a manager or server function to provide application flow processing and orchestration of applications. The modeler or studio function typically includes a high quality graphical display process to achieve the easy graphical building of application flow process. Icons and images are used to associate tasks and functions required to build or orchestrate an application or set of application flows. FIG. 13 depicts a sample screen of one example interface with features as more fully described below.
    • Multi-document window interface for controlling several containers of information in a single User Interface (UI).
    • Drag-and-drop dockable windows allow customization of the UI to match the clients or users preferences that support one or more features such as:
      • View or hide a window within UI
      • Resize a window within UI dynamically.
      • Place a window in different location within UI dynamically.
      • Tab between windows.
      • Each window is provided with scroll bars so that the information within the window can be viewed using the scroll bars if needed.
      • Remember the current user preference and configure the windows the same way next application start up.
    • Graphical toolbox of icons used to manage the various nodes required for building application flows and composite application processes.
      • Under certain conditions, the particular nodes made inactive depending on the application types that a developer builds.
      • The nodes will be placed in a logical order that a developer might be using. For an example, all COMMAREA related nodes are grouped together, placed in the order that they are typically used. All 3270 related nodes are grouped and placed in the order that they are typically used. All Web services related nodes are grouped and placed in the order that they are typically used.
    • The toolbar may be fully customizable to allow clients to place important or high use items on toolbars for easy access.
    • Action bar menus may be provided to allow processing of all functions, important or higher usage functions will be represented by icons to allow placement on the toolbar.
    • Import functions may be supported for the following:
      • Copybooks and/or source code to pull in COMMAREA or IMS application layouts
      • BMS macro importer to pull in 3270 meta data information—This may include other 3270 sources in the future.
      • Pull copybooks and/or source code from input source including local computer file system and remote computer file system.
    • Profile dialogs for manager server deployment, UDDI client, FTP client and 3270 client application processing. Profiles include information needed to create and maintain a connection to a host process.
    • Profile dialogs for management of internal/external tooling, namely access to applications created outside the product. For UDDI processing the dialogs may describe the various methods for importing WSDL files created by other functions or by the tool itself.
    • Project Explorer or file management process to show files associated with the project or file member to store all the execution flow processing XML information, may allow double clicking to process options, or right-click to show menu of processing options.
    • The application flow window or diagram window may be part of an MDI interface that provides a customizable grid layout process to allow nodes to be dragged to the diagram processing area and dropped. The dropping or selection process may activate a property window (part of a customizable dockable window interface). Once activated the property window can display the default or saved options for each node depending on the state of activation.
    • Certain nodes may provide collections of information about meta data or data movements. The collections may be accessible via a mouse click or keyboard selection of the collection expansion process. The collections may be presented in tree processing dialogs to allow for ease of processing when selecting or building meta data information.
    • The graphical Diagram window may contain rule processing to allow the flow engine to process correctly. A rigid and expansive set of ruling and verification may take place each time a node or tool is connected or disconnected to reduce errors. The flow processing may require validation in some implementations before a connection is allowed; this provides the client with immediate feedback as to the validity of the diagram, model or application flow. When meta data items are renamed or moved in the collection properties the change should be propagated through all nodes attached to the project.
    • The Properties window may display the required meta data information when a node is selected. When it is required, each meta data may cause additional windows to gather information. As an example, Web Service Client Point Node needs the WSDL location of the Web service. When the WSDL location is clicked, WSDL Discovery window is displayed so that it can gather information about the WSDL and populate the required information on the property window.
    • When the project is deployed to the manager or server, the status of build, verification or processing rules, and the status of upload process of processing rules of application and generated WSDL may be displayed.
    • In addition, some implementations include a build or verification process that can provide a secondary check of the properties and connections between the nodes to insure the flow processing rules are complete and valid before being deployed (uploaded) to the manager/server process.
    • After the completion of the build process, the generated files (e.g., WSDL files, rules processing files, HTML files) describing the application flow are stored. In some implementations, they are stored in the same directory structure of the computer system's file system.
    • A test utility window may contain areas to view and change WSDL location, operation name, URI location, HTTP version, timeout value, user ID, password, SOAP Request parameters, execution of the request, and/or display of the test result /SOAP Response. The interface in some implementations may include one or more of the following features:
      • Remember the current project information from the graphical Diagram window and pre-fill the information including WSDL and URI locations, operation name, and HTTP version.
      • Understand the current project information including the list of operations, the SOAP request and SOAP response parameters.
      • Allow test data to be entered
      • Save test data and reuse the saved test data.
      • View host-generated traces in a window.
    • A full help processing system may be provided in some implementations with the system to provide details on usage and processing of the various functions.
    • The following is a list of potential nodes in this exemplary implementation and a short description of its function:
      • Start—project or flow starting point: contains URI, WSDL location, descriptions and encoding styles and various other information for the rules processing engine. It also defines the name of the Web service.
      • Web Service Operation (WSO)—contains the collections for SOAP input/output and work field processing, defines the operation name for the web service defined in the start node. Allowing multi-operations is a significant feature for the mainframe application based version of the described systems and methods.
      • Callable Service Operation (CSO)—contains the collections for building an API layout to allow client applications to call the server/manager for processing rules based functions via application code instead of via SOAP based calls to activate composite SOAP applications.
      • 3270 Process—defines the 3270 BMS transaction codes and parameters needed to execute a transaction; this may contain processing of any 3270 application screen and need not be restricted to BMS only. After a process node there is normally a 3270 Point node as there is an implied 3270 action after the rules processing of the manager flows through a 3270 Process node.
      • 3270 Point—defines the map information for the 3270 process so that the correct meta data information is used for the following movement processing.
      • Move to 3270—collections of movements of data using meta data information from any previously access information.
      • 3270 Action—the action node defines the 3270 AID or key that should be pressed at the current time. After an action, another 3270 action or a collection of 3270 Point nodes are typically seen. The rules engine internally processes logic flow decisions to select the correct 3270 Point node based on the 3270 image or map that is currently active for the process. After each 3270 action, any number of different screen display options may be provided.
      • LINK Point Node—contains information to process a direct application call via CICS, IMS or other application platforms accessed via call or flat meta data layouts. Another feature is the ability to process several referenced storage areas in addition to just the single flat storage data area. This referenced storage process provides a method to pass very large data areas based on pointer or address reference points, similar to container or channel processing used by CICS TS 3.1. The meta data API area can be one single area or several areas.
      • Move to LINK—this is used as the collection point for movements of meta data from all previously referenced storage to the API area used to communicate to the application. Previous storage could be SOAP input, other applications called via LINK Point, 3270 Point or Web Service Client Point Nodes. The processes described herein may optimize the processing of storage based in part on the rules processor's knowledge at design time of all the data that may be moved or modified.
      • Execute Link Point Node—this node is mainly a marker in the logic flow of the diagram to show when the process is actually called. It allows for easy identification of the application flow being processed.
      • Web Service Client Point Node—identifies the processing of external Web service functions, they could be other Web services created by the present systems and methods or Web services created by other automated or manual methods. The process may provide an import function at this node to collect WSDL files for building the SOAP client needed to access the process. The process may build this dynamically via the modeler and creates a static call in the rules engine on the manager/server that will process the dynamic input and output for the referenced Web service operation. Special usage work variables can be processed as any object property, for example using the @@fieldname; option. This process allows any static option to be modified at runtime by the contents of the named work field.
      • Move to Web Service Client—this movement is like all other movement nodes with the exception that a WSDL is used to define the field names required for the operation.
      • Execute Web Service Client—this node marks when the requested call is placed by the manager/server rules processing engine. The SOAP client is dynamically built at runtime to process the Web service operation.
      • Move to Output—this node may be executed as many times as needed to move the entire SOAP packet to the requestor. The client has control over when and where these are placed in the diagram flow, as stated only one is needed, but as many as required may be coded. Any application data collected in the application flow (continuous connection points) is available to be moved to the SOAP Output, or API communication area depending on the type of service created.
      • Move to Work Variable—as discussed, work variables are meta data fields used to store information that can be used in the product runtime options or as storage for data that may or may not be needed for processing the application, for example switches to modify logic flow in a set of rules in a diagram.
      • Connector—connectors do just what the name implies, as decisions are used to create branches in the logic flow the connector can be used to bring many nodes into a single logic flow again. There are fewer rules about the placement of Connector nodes than any other node. In a preferred implementation, the connector cannot be used to join different operations in a project; it can only connect branches of an operation back to the same operation.
      • Decision—the logic flow modifier, clients can check work fields, SOAP input, application data from any of the various point nodes or for checking the ranges of boundary of arrays. The systems and methods described herein may support an array processor approach that allows for dynamic array processing for SOAP operations. Application arrays are normally static in nature, but can be processed using the same array boundary checking as for SOAP fields.
      • Loop—the rule execution flow processor may have the ability to loop through applications (calling repetitively) to process large amounts of information. The node has controls to limit loop processing to a defined amount or allow for decision processing to control the loop functions. Loops can also be used to process arrays of data in SOAP or application meta data.
      • Operation End—signals to the rules engine that all the processing that has taken place to this point is complete and the response should be returned. If the SOAP Fault option is turned on, the Operation End will create a SOAP fault that will be returned to the calling SOAP client; this is normally used for error processing, but could also signal to the calling application the process completed
      • Sticky Note—used to add documentation to the logic flow diagram, this is only informational data and is not used by the rules engine.
    Tool Box Window of One Exemplary Modeler or Studio Function
  • A graphical toolbox of icons may be used to manage the various nodes for building application flows and composite application processes. Such an exemplary interface is depicted in FIG. 14.
    • When a node is depressed or selected, it can be dragged and dropped on a Diagram window.
    • In some implementations, the graphical toolbox can be context sensitive. Particular node types can be made inactive depending on the application type that a developer builds. As an example, FIG. 14 shows that Callable Service Operation node is made inactive because the developer is not building a Callable service application.
    • The nodes are preferably placed in a logical order.
      • All applications typically start with a Start node followed by one or more Web Services Operation nodes, and end with one or more Stop nodes. Therefore, the Toolbox window may start with the Start node followed by various operational nodes including the Web Services Operation node and Callable Service Operation node.
      • All 3270 related nodes may be placed in a logical order and grouped together. For example, the 3270 Process, 3270 Point Node, Move to 3270, 3270 Action are ordered and grouped accordingly.
      • All LINK related nodes may be ordered logically and grouped together. For example, the LINK Point Node, Move to LINK, and Execute LINK nodes are ordered and grouped accordingly.
      • All Web Services related nodes may be placed in a logical order and grouped together. For example, the Web Service Client Point Node, Move to Web Service Client, and Execute Web Service Client nodes are ordered and grouped accordingly.
      • After executing an operation node (3270 Action, Execute LINK, or Execute Web Service Client), the resultant data from the operation is available. Using the available data, the data can be moved, checked and/or a decision is made to loop or connect to other logical place, and/or loop. Therefore, Move to Output, Move to Work Variable, Connector, Decision, and Loop nodes may be placed after the last execute node and grouped together.
      • Since the last logical operation is typically the Operation End node, it may be listed as the last item of the logical operation node.
      • Since the Sticky Note is typically used as a documentation tool, it may also be placed after the last logical operation node Operation End node.
  • Component Description
    3270 Action Defines the AID operation that is required to continue (move to the
    next screen).
    3270 Point Node Identifies the BMS mapset and map name available to lower level nodes.
    3270 Process Defines the data and operations required for a 3270 Bridge process.
    Server will process the data collected by this node to invoke the
    3270 transaction and start the data collection or processing actions
    that follow.
    Callable Service Identifies inputs, outputs and work variables for the Callable
    Operation service.
    Connector Provides the means to return to the main flow path after branching
    into multiple paths. The connector eliminates the need for complex
    or redundant tree structures.
    Note: Every connection into a Connector must originate from the
    same nearest parent point node.
    Decision Allows you to make comparisons between data values from point
    nodes, SOAP inputs, work variables, or static text.
    Execute LINK Performs the LINK to the program defined in the previous LINK
    Point Node, using the data that has been passed in the
    COMMAREA with one or more Move to LINK nodes.
    Execute Web Calls the Web service operation defined in the Web Service Client
    Service Client Point Node.
    Following this node, you can use the SOAP outputs of the Web
    Service Client Point Node as data sources for any subsequent
    movements or decisions.
    LINK Point Node Defines the CICS application program, as well as the input and
    output copybooks for the current operation.
    Loop Defines a point in the Web service operation where a loop must
    occur to collect all the required information.
    Move to 3270 Defines the movement of data to the nearest parent 3270 point node
    (BMS map) from valid data sources, including 3270 field, copybook
    field, SOAP input, work variable, or static text.
    Move to Defines the movement of data to the COMMAREA associated with
    COMMAREA the input copybook in the nearest parent LINK Point Node from
    valid data sources, including 3270 field, copybook field, SOAP
    input, work variable, or static text.
    Move to Output Defines the movement of data to a SOAP output (defined in the
    parent Web Service Operation node) from valid data sources,
    including the nearest parent point node, work variable, or static text.
    Move to Web Defines the movement of data (defined in the parent Web Service
    Service Client Operation node) to the SOAP inputs of the Web Service Client
    Point Node.
    Move to Work Provides the ability to assign values to work variables that
    Variable have been defined in the parent Web Service Operation node. This
    allows you to store information for later use in a Decision node or
    other movement node.
    Operation End Signals the end of the Web service operation.
    Start Marks the beginning of the diagram and identifies the URI of the
    Web service operation.
    Sticky Note Allows you to add comments to the diagram to make it more
    understandable; it does not perform any processing or data
    collection.
    Web Service Allows you to browse the Web for a WSDL document, which
    Client Point Node defines the available services and operations as well as the SOAP
    inputs and outputs for each operation. After you select a WSDL,
    you select the Web service and Web service operation you want to
    call.
    Web Services Defines a single operation within the Web service. There can be
    one or more Web service operations connected to the Start node in
    each Ivory project. This node also defines the SOAP inputs, SOAP
    outputs, and work variables for this operation.
  • Project Explorer Window of One Exemplary Modeler or Studio Function
  • Some implementations may include a project explorer window that may be dockable within an MDI environment. An exemplary project explorer window is depicted in FIG. 15. Project Explorer may display the contents of the project folder. When a project is created, a folder is specified where the project will reside. This folder may contain files that are not included in the studio project as explained below.
    • In some implementations such as depicted in FIG. 15, files that are included in the project appear in bold type, and files that are not included appear in normal type.
    • When a file is “included” in a studio project, the file is available to be associated with a point node in the diagram. Being included in the project does not necessarily mean that the file is (or will be) used by the project.
    • “Included” files may be used to define project information that is external to modeler or studio, such as BMS mapsets and/or COBOL copybooks. When a developer imports a mapset or copybook, it can be automatically included in the currently open project.
  • Various features of preferred implementations are outlined as follows:
    • Allow manual inclusion of mapset and copybook files that have been copied into the project folder. In some implementations, the interface supports inclusion of a file through a right-click context menu.
    • View the file content by double-clicking in a separate modeler or studio display window.
    • Allow view of the 3270 map image if a map is clicked in a separate modeler or studio 3270 Emulator window.
    Properties Window of One Exemplary Modeler or Studio Function
  • Various implementations may further provide a Property interface. One exemplary interface is depicted in FIG. 16 and described further below.
  • The Properties window in such implementations may display the required meta data information for a selected node. The operation of this exemplary interface is outlined as follows:
    • Once a node is activated, such as from a Diagram window as detailed below, the property window will display the default or saved options for each node depending on the state of activation.
    • The meta data required for the node is displayed. For an example, the Start node will require the node ID, Web services name, URI, WSDL location, encoding style, description, use URI prefix option, and server side tracing option.
    • When a particular meta data item is selected, the help information is displayed so that a developer knows what to do.
    • When required, each meta data may cause additional windows to be displayed to aid gather information. As an example, Web Service Client Point Node needs the WSDL location of the Web service. When the WSDL location is clicked, WSDL Discovery window is displayed so that it can gather information about the WSDL and populate the required information on the property window.
    • When required, each meta data may list the options that a developer can choose from. For an example, in a Start node, the Use URI Prefix During Deploy will list True or False options when selected.
    Diagram Window of One Exemplary Modeler or Studio
  • Some implementations may include a Diagram window that may also be referred to as an application flow window. Such a Diagram window may be included as part of an MDI interface. An exemplary diagram window is depicted in FIG. 17. Such an exemplary interface may include one or more of the following features.
    • A customizable grid layout process to allow nodes to be dragged to the diagram processing area and dropped from the Toolbox window.
    • The dropping or selection process will activate a Properties window. Once activated the properties window will display the default or saved options for each node depending on the state of activation.
    • A grid to allow proper alignment of diagram or graphical representation of a application.
    • A zooming capability to be able to resize the diagrams in 25, 50, 75, 100, and 200% of normal diagram size.
    • A copy and paste function to be able to duplicate the area of logic in other locations in the application flow or to be able to duplicate in other application flow or project.
    • An ability to move a diagram node or group of diagrams to anywhere in a canvas area.
    • An ability to flip connection points when right mouse is clicked on a node and select on the option. For an example, the typical Decision node connections are to have the YES connector on right side of the Decision node and NO connector on the left side of the Decision node. When a decision node is selected and right mouse is clicked, it will display an option to flip nodes. If the flip node is activated, the YES and NO will be reversed.
    • When an application flow or project is saved reopened, the diagrams on the window should displayed as it was when it was saved.
    Browser Window of One Exemplary Modeler or Studio
  • Some implementations may include a Browser window. An example of which is presented in FIG. 18. The Browser window may be included as part of the MDI or be launched separately. The Browser window can display any documents including Internet site and text document. Such an interface may provide one or more of the following features:
    • Go back to display the previously displayed information.
    • Go forward to display the next information (previously displayed information).
    • The same functionality as the commercially available Internet browsers like Microsoft Internet ExplorerBrowser including ability to display any Internet documents.
    • When View Trace is selected from the Test Utility window, display the trace information by downloading trace information from the manager or server.
    Exemplary Test Utility Window
  • Some implementations may provide a Test Utility that can allow the unit testing of Web Services which are to be deployed to the manager or server. An exemplary interface is provided in FIG. 19. Such a test utility window may support one or more of the following features:
    • View and change WSDL location, service name, service operation, HTTP version, URI, and SOAP Action.
      • Remember the current project information from the graphical Diagram window and pre-fill the information including URI.
    • Access the WSDL specified in the WSDL location and populate the information like service name, service operation, HTTP version, URI, and SOAP Action.
    • Select a service operation from list of operations that the WSDL supports.
    • Select an HTTP version from the list of HTTP versions that the WSDL supports.
    • Set Proxy URI.
    • Set Timeout value so that the execution will stop after a certain time.
    • Set user ID and password for security checking if security is activated on the server or manger.
    • Execution of test by sending SOAP request parameters.
    • Save test data and reuse saved test data at a later time.
    • Loading of test data from a local or remote files system to be used in the test.
    • View host generated traces in Browser window.
    • View generated SOAP Request parameters.
      • Access the WSDL and parse the WSDL to find required SOAP Request parameters.
      • Generate and display the SOAP request parameters so that the tester can enter data. An example of these parameters is depicted in FIG. 20.
    • View received SOAP response from the server or manager
      • Parse the WSDL to determine the SOAP Response parameters.
      • Generate and display the SOAP response parameters so that the tester can view returned data. An example of these parameters is depicted in FIG. 21.
    Exemplary Modeler Output Window
  • Some implementations may support an Output window. The Output window may be a dockable window supported in an overall MDI. FIG. 22 depicts an example Output window. An output window may support one or more of the following features:
    • When the project or application flow is built, the status of the build process is displayed. If there is any error during the build process, the error is displayed on this window to allow the debugging of the logic.
    • When the project or application flow is deployed to the manager or server, the status of build, verification or processing rules, and the status of upload process of processing rules of application and generated WSDL to be displayed.
    Example Web Service Development Using One Exemplary Modeler or Studio
  • As an example, the development of a 3270 CICS application that searches for a name (first and last name) and displays information about the account including the account number, address, status, and account limit is described. Using this information, the 3270 operator, a helpdesk, could raise the account limit if the account status is active,or reopen the account if it is closed.
  • Similar programs have existed for decades in the mainframe environment. Those mainframe programs developed over many years cannot be replaced overnight, even though they may be cumbersome to use. For example, the following procedure outlines what a 3270 operator would typically do to find account information using a mainframe application:
    • From a 3270 terminal, the 3270 operator types the transaction code “IVYS” on a blank 3270 screen and presses the Enter key.
    • The program called by the IVYS transaction runs and displays a blank screen such as depicted in FIG. 23.
    • Then the 3270 operator types the last name and first name of an account holder on the screen and presses the Enter key.
    • The program runs and displays account information, such as presented in FIG. 24.
    • The3270 operator reads the displayed information and saves it by either writing notes or printing the screen.
    • The3270 operator studies the displayed information, for example to determine the account status. Based on that information, the 3270 operator performs a different task.
  • This is an example of a simple task, but it requires multiple 3270 operations to accomplish the task. In order to save this information, or to share it with other computer platforms, such as a PC, the saving or sharing must be performed manually. However, if this operation is converted to a Web service, this information can be shared with other platform computers and other applications.
  • In many cases, the people who wrote the decades-old mainframe applications are no longer available. Consequently, it is not easy or cost-effective to alter the original application program.
  • Using the modeler or server, the existing program and business process can be converted to a Web service through a graphical definition, and no changes to the original program are required. An exemplary graphical flow for this process is depicted in FIG. 25.
  • The graphical diagram defines a Web service which represents the application or business process that the 3270 operator had to perform manually:
    • Typing the “IVYS” transaction ID and pressing the Enter key.
    • When a 3270 map is displayed, typing the account holders last name and first name, and pressing the Enter key.
    • When the response is displayed, reviewing the information to determine the next action.
      In order to convert the sample application into a Web service, a developer drags a node from the Toolbox window and drops the node on the Diagram window. When the node is selected on the Diagram window, the Properties window displays current and default information about the node, which is modified by the developer to provide the information needed by the application. An exemplary interface is depicted in FIG. 26.
  • First, describe the Web service environment.
    • The Start node provides the name of the Web service, the location of the WSDL, URI, encoding style and its description.
    • The Web Service Operation node provides the name of the operation, SOAP input and output parameters—and describes the operation or business process that it will perform below this node. It is possible for a single Web service to have multiple Web service operations. Using our example, the SOAP input parameters will be the last name and first name of the account holder. The SOAP output parameters will be the account number and the account status (Active, Closed, Inactive, or unknown).
      Next, the developer begins to diagram the flow of the operation.
    • With the old mainframe application, the 3270 operator typed the “IVYS” transaction code on a 3270 screen and pressed the Enter key to begin. To mimic this action in the Web service, the developer drags a 3270 Process node to the Diagram window. In the Properties window for the node, the developer enters the IVYS initial transaction code and defines “Enter” as the 3270 AID key. This replaces the user action of typing the transaction code and pressing Enter.
    • As a result of pressing the Enter key on the mainframe application, a 3270 screen was displayed. To produce this result, the developer drags a 3270 Point node onto the Diagram window. In the Properties window, the developer identifies the name of the mapset and map that it should expect to receive.
    • When the 3270 mainframe screen was displayed, the 3270 operator would type the last name and first name of the account holder. The developer now drags a Move to 3270 node onto the Diagram window. The Move to 3270 node allows the movement of data from any source that was defined at a higher level than this node. The possible data source is described below. In the example, the developer will use the SOAP input to move the account number, and Static Text to set the “demographic” option. A drop-down menu such as seen in FIG. 27 could be used to specify this.
    • After entering the name, the 3270 operator pressed the Enter key. To duplicate this manual operation, the developer drags a 3270 Action node to the Diagram window.
    • After the 3270 operator pressed the Enter key, the 3270 map with the account number information was displayed. To provide the same function, the developer drags a 3270 Point Node to the Diagram window. The node properties in the Properties window describe the expected 3270 mapset, and map name to receive.
    • When the information was displayed, the 3270 operator had to read the information on the 3270 screen and validate the account number. In the Web service diagram, the developer does the same by dragging a Move to Output node to the Diagram window, saving the account number information. The Move to Output node allows the data movement to SOAP output parameters from any data source that was referenced prior to this node. In this example, the developer will pull the information from the 3270 field and save or move the account number to the SOAP output field. The use of the 3270 field can be selected via a pull-down menu such as presented in FIG. 28.
    • Next, the 3270 operator determines whether the account is Active, Inactive, Closed, or Unknown (error). Based on the status of the account, the 3270 operator will perform different operations. The Web service uses a series of Decision nodes to check the account status. Each Decision node allows checking a value against a data source. Based on the result of the check, it will generate a YES or NO answer. The first Decision node will check whether the account is Active. If the answer is YES, it will move information to the SOAP output area indicating that this account is an active account. If the answer is NO, then the next Decision node is checked for Inactive status, and so on. Typical use of a Decision node is to direct flow of Web service logic and to find errors, end a process, or select the next operation. The Decision node can check whether any data was returned from the name look-up function. Then, based on the reply, it will build a different reply buffer. A Move to Output node is used to define data fields that will be returned in the SOAP response. Any data previously collected can be marked as information to be included in the SOAP reply.
  • The WSDL output fields are the typical method to return data to the requesting application. Notice that not all of the information available on the 3270 screen was of interest to the 3270 operator. Therefore, Web service developer provided only the data required by the operation. This reduces the storage requirement during processing and data transfer between machines reducing the network traffic requirements.
  • The series of manual operations that were required to gather simple account information was automated without writing a single line of code. The automation was done using the graphical representation of the 3270 operator's operations.
  • What if the 3270 operator needed to raise the credit limit, perform other tasks based on the account information. The 3270 operator would have to go through another series of manual operations. This process can also be automated through a Web service developed using the modeler or studio.
  • Continuing with the prior example, logic can be added to update or raise the credit limit based on the credit limit by executing additional 3270 BMS transactions. For example, FIG. 29 depicts such an enhanced graphical definition. This new task can reuse the original Web service in a new Web service.
  • In another example depicted in FIG. 30, the original Web service, account look-up by name, was called as a Web Service Client Point Node and new logic was added to update the credit limit. The ability to consume an internal or external Web Services allows:
    • Simplification of logic.
    • Reuse of an existing Web services.
    • Interaction with a business partner with a different computer system.
    • Reuse of an external machines and programs, such as Windows NT and Unix.
  • If, for example, there is a need to validate a driver's license number, this Web service can consume a Web service published by a state agency to validate the driver's license number.
  • Going back to the original example, if the 3270 operator needs to execute a transaction on a Microsoft Windows application which publishes a new credit card after updating a credit limit, it can be automated by adding a Web Service Client Point Node to execute the Microsoft Windows-based Web service from the mainframe. Combining the 3270 operator's tasks to run as a single task can save time and money. This can all be done without writing a single line of mainframe program.
  • A mainframe Web service can be generated through diagraming a business process, such as getting insurance policy information for a user. A mainframe, for example, may have a separate application or business process for each type of insurance policy: home, car, and health. The described systems and methods can provide the ability to combine these separate business processes into a single business process implemented as one or more Web services.
  • The described systems and methods can include design and runtime functions. The design component can include a modeler and/or an interface to a mainframe application.
  • The modeler may provide the ability to change logic flow and the path of the original mainframe application. The runtime function component can include a mainframe Web service. The Web service interface is built around mainframe applications that reside on the mainframe. The described systems and methods can verify that the original mainframe application and Web service are in sync.
  • To summarize the functions, FIG. 30 provides an overview of the modeler and server in some of the systems and methods described herein. These systems and methods improve Web service development along several axis including one or more of the following:
  • Design Time:
    • Using the modeler/graphical IDE, the application flow and process is defined by dragging components to the Diagram window.
    Deploy Time:
    • After building the Web services with the modeler/studio, instructions for the processing the Web services and the WSDL are uploaded to the server repository.
    Run Time:
    • During the execution time, the server takes in SOAP request from applications written in .NET, J2EE, JAVA, or other programming languages, processes the Web services processing instructions, and returns the results to the application in a SOAP Response.
  • Throughout this application, various publications may have been referenced. The disclosures of these publications in their entireties are hereby incorporated by reference into this application in order to more fully describe the state of the art to which this application pertains.
  • The examples described above are given as illustrative only. It will be readily appreciated by those skilled in the art that many deviations may be made from the specific examples disclosed above without departing from the scope of the inventions set forth in this application and in the claims below.
  • The indentations and/or enumeration of limitations and/or steps in the claims that follow are provided purely for convenience and ease of reading and/or reference. Their usage is not intended to convey any substantive inference as to parsing of limitations and/or steps and/or to convey any substantive ordering of, or relationship between or among, the so indented and/or enumerated limitations and/or steps.

Claims (2)

1. A system to facilitate the definition of web services, the system comprising:
a) a modeler which is operable to interface with a user to enable the user to generate an execution flow via a graphical interface for building one or more flow rules to build composite or single use web services; and
b) a manager that parses the flow rules to generate a programmatic implementation of the web services.
2. A method for graphically defining a web service, the method comprising the steps of:
a) providing an interface with the graphical display device via which the user can graphically define a web service using the user input device;
b) displaying on the graphical display device a graphical representation of at least a portion of a web service definition; and
c) storing in the system data store a digital representation of a graphically defined web service.
US12/704,124 2004-05-14 2010-02-11 Systems and methods for web service function, definition, implementation, and/or execution Abandoned US20100146396A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/704,124 US20100146396A1 (en) 2004-05-14 2010-02-11 Systems and methods for web service function, definition, implementation, and/or execution

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US57165204P 2004-05-14 2004-05-14
US11/129,597 US7665064B2 (en) 2004-05-14 2005-05-13 Systems and methods for web service function, definition, implementation, and/or execution
US12/704,124 US20100146396A1 (en) 2004-05-14 2010-02-11 Systems and methods for web service function, definition, implementation, and/or execution

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/129,597 Continuation US7665064B2 (en) 2004-05-14 2005-05-13 Systems and methods for web service function, definition, implementation, and/or execution

Publications (1)

Publication Number Publication Date
US20100146396A1 true US20100146396A1 (en) 2010-06-10

Family

ID=35429025

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/129,597 Active 2026-01-11 US7665064B2 (en) 2004-05-14 2005-05-13 Systems and methods for web service function, definition, implementation, and/or execution
US12/704,124 Abandoned US20100146396A1 (en) 2004-05-14 2010-02-11 Systems and methods for web service function, definition, implementation, and/or execution

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/129,597 Active 2026-01-11 US7665064B2 (en) 2004-05-14 2005-05-13 Systems and methods for web service function, definition, implementation, and/or execution

Country Status (2)

Country Link
US (2) US7665064B2 (en)
WO (1) WO2005114381A2 (en)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070214419A1 (en) * 2006-03-01 2007-09-13 Ashish Jain Integrated service creation and execution platforms for the converged networks
US20090144305A1 (en) * 2007-11-29 2009-06-04 Mark Cameron Little Dependency management with atomic decay
US20100131854A1 (en) * 2008-11-26 2010-05-27 Mark Cameron Little Graphical user interface for managing services in a distributed computing system
US20100306835A1 (en) * 2009-05-29 2010-12-02 Computer Associates Think, Inc. Communicating security credentials between cics regions
US20110214069A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Presenting messages through a channel of a non-communication productivity application interface
US20110214070A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing access to one or more messages in response to detecting one or more patterns of usage of one or more non-communication productivity applications
US20110213792A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing a modified non-communication application interface for presenting a message
US20110211590A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Presenting messages through a channel of a non-communication productivity application interface
US20110214073A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing a modified Non-Communication application interface for presenting a message
US20110213793A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing access to one or more messages in response to detecting one or more patterns of usage of one or more non-communication productivity applications
US20120210209A1 (en) * 2009-11-06 2012-08-16 Toby Biddle usability testing tool
US20120221998A1 (en) * 2011-02-24 2012-08-30 Active Endpoints, Inc. Screenflow designer with automatically changing view
US20130117728A1 (en) * 2011-10-20 2013-05-09 International Business Machines Corporation Computer program interface
US20130138704A1 (en) * 2010-06-04 2013-05-30 International Business Machines Corporation Managing rule sets as web services
US20130151889A1 (en) * 2011-12-13 2013-06-13 Mircea Markus Disk-free recovery of xa transactions for in-memory data grids
US20130282429A1 (en) * 2011-02-25 2013-10-24 Research & Business Foundation Sungkyunkwan University Apparatus and method for context based activity modeling
US9866455B2 (en) 2007-11-30 2018-01-09 Red Hat, Inc. Using status inquiry and status response messages to exchange management information
US20180270075A1 (en) * 2015-07-03 2018-09-20 Somfy Sas Method for controlling a home-automation facility
US10311024B2 (en) * 2016-08-31 2019-06-04 Ca, Inc. Merging file storage directory structures through user interface visualization of refactoring decisions
US10970050B1 (en) 2019-09-27 2021-04-06 Adp, Llc User interface engine for miniapp development
US20210109894A1 (en) * 2019-10-11 2021-04-15 Ikigai Labs Inc. Automated customized modeling of datasets with intuitive user interfaces
US11070387B2 (en) 2015-07-03 2021-07-20 Somfy Sas Method for recording a central control unit belonging to a home-automation facility
US11095471B2 (en) 2015-07-03 2021-08-17 Somfy Sas Home-automation system and method for constituting the topology of a home-automation system
US20220231921A1 (en) * 2021-01-20 2022-07-21 Vmware, Inc. User interface tools for device-driven management workflows
US11650888B2 (en) 2021-01-21 2023-05-16 Vmware, Inc. Workflow error handling for device driven management
US11665065B2 (en) 2021-01-20 2023-05-30 Vmware, Inc. Network integration and workflow generation tools for device-driven management
US11855833B2 (en) 2021-01-25 2023-12-26 Vmware, Inc. Device-driven management workflow status and impact

Families Citing this family (181)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7114148B2 (en) * 2002-09-30 2006-09-26 Microsoft Corporation Runtime services for network software platform
EP1725922A4 (en) * 2003-10-30 2008-11-12 Lavastorm Technologies Inc Methods and systems for automated data processing
US8225282B1 (en) 2003-11-25 2012-07-17 Nextaxiom Technology, Inc. Semantic-based, service-oriented system and method of developing, programming and managing software modules and software solutions
US7801771B1 (en) 2004-01-27 2010-09-21 Amazon Technologies, Inc. Providing configurable usage models for available services
US8024225B1 (en) 2004-01-27 2011-09-20 Amazon Technologies, Inc. Controlling access to services via usage models
US7797198B1 (en) * 2004-01-27 2010-09-14 Amazon Technologies, Inc. Providing an invocable composite network service based on multiple other invocable constituent network services
US7941543B2 (en) * 2004-08-23 2011-05-10 Neon Systems, Inc. System and method for migrating applications from a legacy system
GB0426202D0 (en) * 2004-11-30 2004-12-29 Ibm A method, system and computer program for addressing a web service
US20080140760A1 (en) * 2005-03-21 2008-06-12 Conner Peter A Service-oriented architecture system and methods supporting dynamic service provider versioning
US7243046B1 (en) * 2005-05-09 2007-07-10 Emc Corporation System and method for preparing trace data for analysis
JP2006338477A (en) * 2005-06-03 2006-12-14 Atrris Corp Information processor and system development method
US20070005158A1 (en) * 2005-06-30 2007-01-04 Kabushiki Kaisha Yaskawa Denki Web based controller
US7590935B2 (en) * 2005-07-08 2009-09-15 Microsoft Corporation Dynamic generation of WSDL documents based on database metadata
US7734515B1 (en) 2005-08-17 2010-06-08 Amazon Technologies, Inc. Generating new invocable composite network services based on multiple other invocable constituent network services
FR2891077B1 (en) * 2005-09-22 2008-12-12 Xcalia Sa SYSTEM FOR IMPLEMENTING A BUSINESS APPLICATION.
CA2527447C (en) 2005-11-18 2015-05-05 Allen Vi Cuong Chan Message oriented construction of web services
US20070156868A1 (en) * 2005-12-29 2007-07-05 Ido Keren Efficient dynamic discovery of web services
US8140987B2 (en) * 2005-12-29 2012-03-20 Sap Ag GUI modeling of web services
US8448137B2 (en) 2005-12-30 2013-05-21 Sap Ag Software model integration scenarios
US8327319B2 (en) 2005-12-30 2012-12-04 Sap Ag Software model process interaction
US8688495B2 (en) 2005-12-30 2014-04-01 Sap Ag Architectural design for time recording application software
US8522194B2 (en) * 2005-12-30 2013-08-27 Sap Ag Software modeling
US8676617B2 (en) 2005-12-30 2014-03-18 Sap Ag Architectural design for self-service procurement application software
US8396731B2 (en) 2005-12-30 2013-03-12 Sap Ag Architectural design for service procurement application software
US8380553B2 (en) 2005-12-30 2013-02-19 Sap Ag Architectural design for plan-driven procurement application software
US8326703B2 (en) 2005-12-30 2012-12-04 Sap Ag Architectural design for product catalog management application software
US8660904B2 (en) 2005-12-30 2014-02-25 Sap Ag Architectural design for service request and order management application software
US8407664B2 (en) * 2005-12-30 2013-03-26 Sap Ag Software model business objects
US8321831B2 (en) 2005-12-30 2012-11-27 Sap Ag Architectural design for internal projects application software
US8316344B2 (en) 2005-12-30 2012-11-20 Sap Ag Software model deployment units
US8402426B2 (en) 2005-12-30 2013-03-19 Sap Ag Architectural design for make to stock application software
US8370794B2 (en) 2005-12-30 2013-02-05 Sap Ag Software model process component
US20080140759A1 (en) * 2006-03-21 2008-06-12 Conner Peter A Dynamic service-oriented architecture system configuration and proxy object generation server architecture and methods
US20080140857A1 (en) * 2006-03-21 2008-06-12 Conner Peter A Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework
WO2007110545A2 (en) * 2006-03-28 2007-10-04 France Telecom Method and system for controlling access to the data in a database
US8396761B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing product catalog software application as enterprise services
US8538864B2 (en) 2006-03-30 2013-09-17 Sap Ag Providing payment software application as enterprise services
US8438119B2 (en) 2006-03-30 2013-05-07 Sap Ag Foundation layer for services based enterprise software architecture
US8442850B2 (en) 2006-03-30 2013-05-14 Sap Ag Providing accounting software application as enterprise services
US8326702B2 (en) 2006-03-30 2012-12-04 Sap Ag Providing supplier relationship management software application as enterprise services
US20070233539A1 (en) * 2006-03-30 2007-10-04 Philipp Suenderhauf Providing human capital management software application as enterprise services
US8396749B2 (en) 2006-03-30 2013-03-12 Sap Ag Providing customer relationship management application as enterprise services
US20070233575A1 (en) * 2006-03-30 2007-10-04 Arthur Berger Architectural design for strategic sourcing application software
US8321832B2 (en) * 2006-03-31 2012-11-27 Sap Ag Composite application modeling
JP2007279838A (en) * 2006-04-03 2007-10-25 Ibm Japan Ltd Information processor, method, and program
US8312416B2 (en) 2006-04-13 2012-11-13 Sap Ag Software model business process variant types
US7590901B2 (en) * 2006-05-19 2009-09-15 International Business Machines Corporation Apparatus, system, and method for dynamic recovery and restoration from design defects in an integrated circuit
US7526486B2 (en) 2006-05-22 2009-04-28 Initiate Systems, Inc. Method and system for indexing information about entities with respect to hierarchies
US8332366B2 (en) 2006-06-02 2012-12-11 International Business Machines Corporation System and method for automatic weight generation for probabilistic matching
US8799797B2 (en) * 2006-07-19 2014-08-05 Red Hat, Inc. Display and management of a service candidate inventory
US8782542B2 (en) * 2006-07-19 2014-07-15 Red Hat, Inc. Display and management of a service composition candidate inventory
US8924919B2 (en) * 2006-07-19 2014-12-30 Red Hat, Inc. Tracking and integrity enforcement of relationships between service and composition candidates in a service model
EP2041654A4 (en) * 2006-07-19 2009-09-02 Red Hat Inc Creation and management of service composition candidates for a service model
US9841951B2 (en) 2006-07-19 2017-12-12 Red Hat, Inc. Management of SOA service model
US20080040418A1 (en) * 2006-08-11 2008-02-14 Risaris Accessing existing data using a service oriented architecture gateway
US8527939B2 (en) * 2006-09-14 2013-09-03 Sap Ag GUI modeling of knowledge base in a modeling environment
US7698268B1 (en) * 2006-09-15 2010-04-13 Initiate Systems, Inc. Method and system for filtering false positives
US8356009B2 (en) * 2006-09-15 2013-01-15 International Business Machines Corporation Implementation defined segments for relational database systems
US7685093B1 (en) 2006-09-15 2010-03-23 Initiate Systems, Inc. Method and system for comparing attributes such as business names
US8176470B2 (en) * 2006-10-13 2012-05-08 International Business Machines Corporation Collaborative derivation of an interface and partial implementation of programming code
US8099710B2 (en) * 2006-12-14 2012-01-17 Microsoft Corporation UI behaviors
US8910119B2 (en) * 2006-12-29 2014-12-09 Sap Ag System and method for displaying component information of a trace
US20080163177A1 (en) * 2006-12-29 2008-07-03 Sap Ag System and method for displaying trace information
US8612996B2 (en) * 2006-12-29 2013-12-17 Sap Ag Technique for integrating a distributed object system component with a service oriented architecture application
US20080168096A1 (en) * 2007-01-08 2008-07-10 Shalom Daskal Extracting business logic from the user interface of service and product oriented computerized systems
US8359339B2 (en) * 2007-02-05 2013-01-22 International Business Machines Corporation Graphical user interface for configuration of an algorithm for the matching of data records
US20080209392A1 (en) * 2007-02-26 2008-08-28 Able Steve L Systems and Methods for Definition and Execution of Batch Processing Services
US8731998B2 (en) * 2007-03-01 2014-05-20 Sap Ag Three dimensional visual representation for identifying problems in monitored model oriented business processes
US8515926B2 (en) 2007-03-22 2013-08-20 International Business Machines Corporation Processing related data from information sources
WO2008121824A1 (en) * 2007-03-29 2008-10-09 Initiate Systems, Inc. Method and system for data exchange among data sources
US8423514B2 (en) * 2007-03-29 2013-04-16 International Business Machines Corporation Service provisioning
WO2008121170A1 (en) 2007-03-29 2008-10-09 Initiate Systems, Inc. Method and system for parsing languages
WO2008121700A1 (en) * 2007-03-29 2008-10-09 Initiate Systems, Inc. Method and system for managing entities
US10313254B1 (en) * 2007-03-30 2019-06-04 Extreme Networks, Inc. Network management interface for a network element with network-wide information
US8370812B2 (en) 2007-04-02 2013-02-05 International Business Machines Corporation Method and system for automatically assembling processing graphs in information processing systems
US8166465B2 (en) * 2007-04-02 2012-04-24 International Business Machines Corporation Method and system for composing stream processing applications according to a semantic description of a processing goal
US7908560B2 (en) * 2007-04-24 2011-03-15 International Business Machines Corporation Method and system for cross-screen component communication in dynamically created composite applications
US8117233B2 (en) * 2007-05-14 2012-02-14 International Business Machines Corporation Method and system for message-oriented semantic web service composition based on artificial intelligence planning
US8549472B1 (en) * 2007-06-12 2013-10-01 Fair Isaac Corporation System and method for web design
US20080313536A1 (en) * 2007-06-14 2008-12-18 Microsoft Corporation Situation Sharing and Viewing
US8683446B2 (en) * 2007-07-09 2014-03-25 International Business Machines Corporation Generation of test cases for functional testing of applications
WO2009042941A1 (en) 2007-09-28 2009-04-02 Initiate Systems, Inc. Method and system for analysis of a system for matching data records
JP5306359B2 (en) * 2007-09-28 2013-10-02 インターナショナル・ビジネス・マシーンズ・コーポレーション Method and system for associating data records in multiple languages
US8713434B2 (en) 2007-09-28 2014-04-29 International Business Machines Corporation Indexing, relating and managing information about entities
US20090165021A1 (en) * 2007-10-23 2009-06-25 Microsoft Corporation Model-Based Composite Application Platform
US8751626B2 (en) * 2007-10-23 2014-06-10 Microsoft Corporation Model-based composite application platform
US8671033B2 (en) 2007-12-31 2014-03-11 Sap Ag Architectural design for personnel events application software
US8671034B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing human capital management software application as enterprise services
US8671032B2 (en) 2007-12-31 2014-03-11 Sap Ag Providing payment software application as enterprise services
US8315900B2 (en) 2007-12-31 2012-11-20 Sap Ag Architectural design for self-service procurement application software
US8447657B2 (en) 2007-12-31 2013-05-21 Sap Ag Architectural design for service procurement application software
US8401936B2 (en) 2007-12-31 2013-03-19 Sap Ag Architectural design for expense reimbursement application software
US8510143B2 (en) 2007-12-31 2013-08-13 Sap Ag Architectural design for ad-hoc goods movement software
US8260821B2 (en) * 2008-02-05 2012-09-04 International Business Machines Corporation Global, dynamic, remote and central system for database driver configuration
US8302017B2 (en) * 2008-03-05 2012-10-30 Microsoft Corporation Definition for service interface
US8745582B2 (en) * 2008-06-13 2014-06-03 Microsoft Corporation Designer for web pages at a local machine
CN101296243B (en) * 2008-06-26 2013-02-20 阿里巴巴集团控股有限公司 Service integration platform system and method for providing internet service
US8413061B2 (en) * 2008-08-05 2013-04-02 Accenture Global Services Limited Synchronous to asynchronous web page conversion
US8627306B2 (en) * 2008-08-06 2014-01-07 Caterpillar Inc. Method and system for updating an information management system configuration
US8291373B2 (en) * 2008-08-13 2012-10-16 Hewlett-Packard Development Company, L.P. Generating LoadRunner scripts
EP2157508A1 (en) * 2008-08-18 2010-02-24 Software AG SOA-registry, method and platform manager for automatic SOA application deployment
US8413115B1 (en) * 2008-08-28 2013-04-02 Raytheon Company Specifying integration points of a system-of-systems
US8401928B2 (en) 2008-09-18 2013-03-19 Sap Ag Providing supplier relationship management software application as enterprise services
US20100070556A1 (en) * 2008-09-18 2010-03-18 Sap Ag Architectural Design for Data Migration Application Software
US8326706B2 (en) 2008-09-18 2012-12-04 Sap Ag Providing logistics execution application as enterprise services
US8352338B2 (en) 2008-09-18 2013-01-08 Sap Ag Architectural design for time recording application software
US8818884B2 (en) 2008-09-18 2014-08-26 Sap Ag Architectural design for customer returns handling application software
US8315926B2 (en) 2008-09-18 2012-11-20 Sap Ag Architectural design for tax declaration application software
US8321250B2 (en) 2008-09-18 2012-11-27 Sap Ag Architectural design for sell from stock application software
US8374896B2 (en) 2008-09-18 2013-02-12 Sap Ag Architectural design for opportunity management application software
US8386325B2 (en) 2008-09-18 2013-02-26 Sap Ag Architectural design for plan-driven procurement application software
US8380549B2 (en) 2008-09-18 2013-02-19 Sap Ag Architectural design for embedded support application software
US8595077B2 (en) 2008-09-18 2013-11-26 Sap Ag Architectural design for service request and order management application software
US8359218B2 (en) 2008-09-18 2013-01-22 Sap Ag Computer readable medium for implementing supply chain control using service-oriented methodology
US7689905B1 (en) * 2008-11-05 2010-03-30 International Business Machines Corporation Containment of terminal application run-time data for viewing when disconnected from a host server
US20100131326A1 (en) * 2008-11-24 2010-05-27 International Business Machines Corporation Identifying a service oriented architecture shared services project
US8099480B1 (en) 2008-11-25 2012-01-17 Google Inc. Scalable workflow design for automated service management
US20100131399A1 (en) * 2008-11-27 2010-05-27 Oracle International Corporation Parser for generating financial manager application rules
US8401908B2 (en) 2008-12-03 2013-03-19 Sap Ag Architectural design for make-to-specification application software
US8738476B2 (en) 2008-12-03 2014-05-27 Sap Ag Architectural design for selling standardized services application software
US8311904B2 (en) 2008-12-03 2012-11-13 Sap Ag Architectural design for intra-company stock transfer application software
US8321308B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for manual invoicing application software
US8321306B2 (en) 2008-12-03 2012-11-27 Sap Ag Architectural design for selling project-based services application software
US8671035B2 (en) 2008-12-11 2014-03-11 Sap Ag Providing payroll software application as enterprise services
US20100211925A1 (en) * 2009-02-19 2010-08-19 Interational Business Machines Corporation Evaluating a service oriented architecture shared services project
US20100217632A1 (en) * 2009-02-24 2010-08-26 International Business Machines Corporation Managing service oriented architecture shared services escalation
US9268532B2 (en) * 2009-02-25 2016-02-23 International Business Machines Corporation Constructing a service oriented architecture shared service
US8935655B2 (en) * 2009-02-25 2015-01-13 International Business Machines Corporation Transitioning to management of a service oriented architecture shared service
US8214389B2 (en) * 2009-04-03 2012-07-03 International Business Machines Corporation Common architecture for administration of client side property settings in a distributed and heterogeneous environment
US8006140B2 (en) * 2009-05-05 2011-08-23 Oracle International Corporation Diagnostic solution for web service process flows
CA2669603A1 (en) * 2009-06-18 2010-12-18 Ibm Canada Limited - Ibm Canada Limitee Graphical modeling tool
US9189244B2 (en) * 2009-08-18 2015-11-17 Adobe Systems Incorporated Methods and systems for managing data service specifications
US8904375B2 (en) * 2009-09-30 2014-12-02 General Electric Company Systems and methods for providing an embedded service-oriented user interface integration bus
US20130031488A1 (en) * 2010-02-26 2013-01-31 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing a modified non-communication application interface for presenting a message
US9710261B2 (en) * 2010-05-06 2017-07-18 Microsoft Technology Licensing, Llc Techniques to enhance software production
US9430222B2 (en) * 2010-05-24 2016-08-30 Oracle International Corporation Controlling a running application for live scene graph editing
US8799177B1 (en) * 2010-07-29 2014-08-05 Intuit Inc. Method and apparatus for building small business graph from electronic business data
US9716632B2 (en) * 2010-08-24 2017-07-25 Hewlett Packard Enterprise Development Lp Interactive layered visualization of a layered software architecture
US9507839B2 (en) * 2010-09-23 2016-11-29 Sap Se Method for determining a supported connectivity between applications
US8489542B2 (en) * 2010-09-23 2013-07-16 Sap Ag Integrated content publishing
CA2732301A1 (en) * 2011-02-18 2012-08-18 Doleweerd Consulting Inc. Browser based mapping region builder
US9600456B2 (en) * 2011-08-30 2017-03-21 Hewlett-Packard Development Company, L.P. Automatically performing a web service operation
US10147123B2 (en) 2011-09-29 2018-12-04 Amazon Technologies, Inc. Electronic marketplace for hosted service images
US8776043B1 (en) 2011-09-29 2014-07-08 Amazon Technologies, Inc. Service image notifications
US9626700B1 (en) 2011-09-29 2017-04-18 Amazon Technologies, Inc. Aggregation of operational data for merchandizing of network accessible services
US9530156B2 (en) * 2011-09-29 2016-12-27 Amazon Technologies, Inc. Customizable uniform control user interface for hosted service images
US8973012B2 (en) 2011-10-25 2015-03-03 International Business Machines Corporation Composing analytic solutions
US9679279B1 (en) 2012-02-27 2017-06-13 Amazon Technologies Inc Managing transfer of hosted service licenses
US9258371B1 (en) 2012-03-23 2016-02-09 Amazon Technologies, Inc. Managing interaction with hosted services
US9397987B1 (en) 2012-03-23 2016-07-19 Amazon Technologies, Inc. Managing interaction with hosted services
CN103631487B (en) * 2012-08-21 2018-09-28 腾讯科技(深圳)有限公司 A kind of method and device of the configuration page
US9104398B2 (en) * 2013-03-13 2015-08-11 Oracle International Corporation Invocation of external web services using dynamically generated composite applications
US9280592B1 (en) * 2013-03-15 2016-03-08 Google Inc. Zombie detector and handler mechanism for accounts, apps, and hardware devices
US9553787B1 (en) 2013-04-29 2017-01-24 Amazon Technologies, Inc. Monitoring hosted service usage
KR20150019795A (en) * 2013-08-16 2015-02-25 엘지전자 주식회사 Mobile terminal and method for controlling the same
EP3095031B1 (en) 2014-01-17 2021-09-15 Fair Isaac Corporation Cloud-based decision management platform
US10831864B2 (en) * 2014-05-12 2020-11-10 International Business Machines Corporation Visual comparison of data clusters
TWI568285B (en) * 2014-10-02 2017-01-21 財團法人資訊工業策進會 Service provider system and service provider method
US11650816B2 (en) 2014-11-11 2023-05-16 Fair Isaac Corporation Workflow templates for configuration packages
US10162630B2 (en) 2014-11-11 2018-12-25 Fair Isaac Corporation Configuration packages for software products
US10223473B2 (en) * 2015-03-31 2019-03-05 International Business Machines Corporation Distribution of metadata for importation
JP6578852B2 (en) * 2015-09-28 2019-09-25 株式会社リコー Information processing system, information processing apparatus, information providing method, and program
US10387209B2 (en) * 2015-09-28 2019-08-20 International Business Machines Corporation Dynamic transparent provisioning of resources for application specific resources
US10063649B2 (en) * 2015-12-29 2018-08-28 Ca, Inc. Data translation using a proxy service
EP3427446A4 (en) * 2016-03-07 2019-09-04 Level 3 Communications, LLC Systems and methods for dynamically connecting network elements to enable a service
US9898384B2 (en) * 2016-03-18 2018-02-20 International Business Machines Corporation Automated problem determination for cooperating web services using debugging technology
US11521137B2 (en) 2016-04-25 2022-12-06 Fair Isaac Corporation Deployment of self-contained decision logic
US10929759B2 (en) * 2017-04-06 2021-02-23 AIBrain Corporation Intelligent robot software platform
US10810371B2 (en) 2017-04-06 2020-10-20 AIBrain Corporation Adaptive, interactive, and cognitive reasoner of an autonomous robotic system
US11151992B2 (en) 2017-04-06 2021-10-19 AIBrain Corporation Context aware interactive robot
US10839017B2 (en) 2017-04-06 2020-11-17 AIBrain Corporation Adaptive, interactive, and cognitive reasoner of an autonomous robotic system utilizing an advanced memory graph structure
US10963493B1 (en) 2017-04-06 2021-03-30 AIBrain Corporation Interactive game with robot system
US10534798B2 (en) * 2017-06-13 2020-01-14 Oracle International Corporation Computer system and method to update data aggregation configurations and control data aggregation
CN109918066A (en) * 2019-02-27 2019-06-21 深圳中砼物联网科技有限公司 A kind of interaction logic configuration method using graphic interface
CN111081356A (en) * 2019-11-07 2020-04-28 福建亿能达信息技术股份有限公司 Method for flow management based on WEB
CN111506359B (en) * 2020-03-26 2024-03-01 深圳市兴海物联科技有限公司 Visual service configuration method, device, equipment and storage medium
CN114691308A (en) * 2020-12-25 2022-07-01 第四范式(北京)技术有限公司 Online task arranging method and online task arranging device
CN113298343B (en) * 2021-03-31 2023-11-14 阿里巴巴新加坡控股有限公司 Task generation method, task execution method and device
CN113254004B (en) * 2021-04-13 2023-02-21 西安热工研究院有限公司 Data statistics platform based on WF4.0 framework
US11829732B2 (en) * 2021-12-14 2023-11-28 Elm Simple object application protocol web service applications
US11886852B1 (en) * 2022-11-29 2024-01-30 Accenture Global Solutions Limited Application composition and deployment

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510468B1 (en) * 1999-01-22 2003-01-21 Micro Focus International Limited Adaptively transforming data from a first computer program for use in a second computer program
US20030115572A1 (en) * 2001-08-28 2003-06-19 Clickmarks, Inc. System, method and computer program product for application development using a visual paradigm to combine existing data and applications
US20040207659A1 (en) * 2003-04-02 2004-10-21 International Business Machines Corporation Program creation by combining web services using graphic user interface controls
US20050086360A1 (en) * 2003-08-27 2005-04-21 Ascential Software Corporation Methods and systems for real time integration services
US6981257B2 (en) * 2001-01-19 2005-12-27 Teubner Russell W System, method and apparatus to allow communication between CICS and non-CICS software applications
US20060106748A1 (en) * 2004-11-12 2006-05-18 International Business Machines Corporation System and method for orchestrating composite web services in constrained data flow environments
US7278134B2 (en) * 2001-04-27 2007-10-02 International Business Machines Corporation Three dimensional framework for information technology solutions
US7370075B2 (en) * 2002-04-25 2008-05-06 Digital Evolution Method and apparatus for managing web services within a computer network system
US8069435B1 (en) * 2003-08-18 2011-11-29 Oracle America, Inc. System and method for integration of web services

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510468B1 (en) * 1999-01-22 2003-01-21 Micro Focus International Limited Adaptively transforming data from a first computer program for use in a second computer program
US6981257B2 (en) * 2001-01-19 2005-12-27 Teubner Russell W System, method and apparatus to allow communication between CICS and non-CICS software applications
US7278134B2 (en) * 2001-04-27 2007-10-02 International Business Machines Corporation Three dimensional framework for information technology solutions
US20030115572A1 (en) * 2001-08-28 2003-06-19 Clickmarks, Inc. System, method and computer program product for application development using a visual paradigm to combine existing data and applications
US7370075B2 (en) * 2002-04-25 2008-05-06 Digital Evolution Method and apparatus for managing web services within a computer network system
US20040207659A1 (en) * 2003-04-02 2004-10-21 International Business Machines Corporation Program creation by combining web services using graphic user interface controls
US8069435B1 (en) * 2003-08-18 2011-11-29 Oracle America, Inc. System and method for integration of web services
US20050086360A1 (en) * 2003-08-27 2005-04-21 Ascential Software Corporation Methods and systems for real time integration services
US20060106748A1 (en) * 2004-11-12 2006-05-18 International Business Machines Corporation System and method for orchestrating composite web services in constrained data flow environments

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070214419A1 (en) * 2006-03-01 2007-09-13 Ashish Jain Integrated service creation and execution platforms for the converged networks
US9621634B2 (en) 2007-11-29 2017-04-11 Red Hat, Inc. Dependency management with atomic decay
US8464270B2 (en) 2007-11-29 2013-06-11 Red Hat, Inc. Dependency management with atomic decay
US20090144305A1 (en) * 2007-11-29 2009-06-04 Mark Cameron Little Dependency management with atomic decay
US9866455B2 (en) 2007-11-30 2018-01-09 Red Hat, Inc. Using status inquiry and status response messages to exchange management information
US10027563B2 (en) 2007-11-30 2018-07-17 Red Hat, Inc. Using status inquiry and status response messages to exchange management information
US20100131854A1 (en) * 2008-11-26 2010-05-27 Mark Cameron Little Graphical user interface for managing services in a distributed computing system
US8645837B2 (en) * 2008-11-26 2014-02-04 Red Hat, Inc. Graphical user interface for managing services in a distributed computing system
US20100306835A1 (en) * 2009-05-29 2010-12-02 Computer Associates Think, Inc. Communicating security credentials between cics regions
US8438634B2 (en) * 2009-05-29 2013-05-07 Ca, Inc. Communicating security credentials between CICS regions
US9058429B2 (en) * 2009-11-06 2015-06-16 Toby Biddle Usability testing tool
US20120210209A1 (en) * 2009-11-06 2012-08-16 Toby Biddle usability testing tool
US9626633B2 (en) 2010-02-26 2017-04-18 Invention Science Fund I, Llc Providing access to one or more messages in response to detecting one or more patterns of usage of one or more non-communication productivity applications
US20110214073A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing a modified Non-Communication application interface for presenting a message
US20110211590A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Presenting messages through a channel of a non-communication productivity application interface
US20110213792A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing a modified non-communication application interface for presenting a message
US20110214070A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing access to one or more messages in response to detecting one or more patterns of usage of one or more non-communication productivity applications
US20110214069A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Presenting messages through a channel of a non-communication productivity application interface
US20110213793A1 (en) * 2010-02-26 2011-09-01 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Providing access to one or more messages in response to detecting one or more patterns of usage of one or more non-communication productivity applications
US8239409B2 (en) 2010-02-26 2012-08-07 The Invention Science Fund I, Llc Providing a modified non-communication application interface for presenting a message
US8918454B2 (en) * 2010-06-04 2014-12-23 International Business Machines Corporation Managing rule sets as web services
US20130138704A1 (en) * 2010-06-04 2013-05-30 International Business Machines Corporation Managing rule sets as web services
US20120221998A1 (en) * 2011-02-24 2012-08-30 Active Endpoints, Inc. Screenflow designer with automatically changing view
US20130282429A1 (en) * 2011-02-25 2013-10-24 Research & Business Foundation Sungkyunkwan University Apparatus and method for context based activity modeling
US10545729B2 (en) * 2011-10-20 2020-01-28 International Business Machines Corporation Computer program interface
CN103890721A (en) * 2011-10-20 2014-06-25 国际商业机器公司 Computer program interface
US20130117728A1 (en) * 2011-10-20 2013-05-09 International Business Machines Corporation Computer program interface
US8738964B2 (en) * 2011-12-13 2014-05-27 Red Hat, Inc. Disk-free recovery of XA transactions for in-memory data grids
US20130151889A1 (en) * 2011-12-13 2013-06-13 Mircea Markus Disk-free recovery of xa transactions for in-memory data grids
US11070387B2 (en) 2015-07-03 2021-07-20 Somfy Sas Method for recording a central control unit belonging to a home-automation facility
US20180270075A1 (en) * 2015-07-03 2018-09-20 Somfy Sas Method for controlling a home-automation facility
US11563594B2 (en) * 2015-07-03 2023-01-24 Somfy Sas Method for controlling a home-automation facility
US11095471B2 (en) 2015-07-03 2021-08-17 Somfy Sas Home-automation system and method for constituting the topology of a home-automation system
US10311024B2 (en) * 2016-08-31 2019-06-04 Ca, Inc. Merging file storage directory structures through user interface visualization of refactoring decisions
US10970050B1 (en) 2019-09-27 2021-04-06 Adp, Llc User interface engine for miniapp development
US20210109894A1 (en) * 2019-10-11 2021-04-15 Ikigai Labs Inc. Automated customized modeling of datasets with intuitive user interfaces
US20220231921A1 (en) * 2021-01-20 2022-07-21 Vmware, Inc. User interface tools for device-driven management workflows
US11665065B2 (en) 2021-01-20 2023-05-30 Vmware, Inc. Network integration and workflow generation tools for device-driven management
US11924056B2 (en) * 2021-01-20 2024-03-05 Vmware, Inc. User interface tools for device-driven management workflows
US11650888B2 (en) 2021-01-21 2023-05-16 Vmware, Inc. Workflow error handling for device driven management
US11855833B2 (en) 2021-01-25 2023-12-26 Vmware, Inc. Device-driven management workflow status and impact

Also Published As

Publication number Publication date
WO2005114381A2 (en) 2005-12-01
WO2005114381A3 (en) 2007-11-29
US20050256882A1 (en) 2005-11-17
US7665064B2 (en) 2010-02-16

Similar Documents

Publication Publication Date Title
US7665064B2 (en) Systems and methods for web service function, definition, implementation, and/or execution
US20080209392A1 (en) Systems and Methods for Definition and Execution of Batch Processing Services
US10324690B2 (en) Automated enterprise software development
US9361069B2 (en) Systems and methods for defining a simulated interactive web page
US7620885B2 (en) Automatic generation of documentation for component-based computing solution
US7509649B2 (en) System and method for conversion of generic services' applications into component based applications for devices
US8832181B2 (en) Development and deployment of mobile and desktop applications within a flexible markup-based distributed architecture
US7415715B2 (en) Transaction execution system interface and enterprise system architecture thereof
US7814404B2 (en) System and method for applying workflow of generic services to component based applications for devices
US5758351A (en) System and method for the creation and use of surrogate information system objects
EP2369480A2 (en) Mashup infrastructure with learning mechanism
US7007266B1 (en) Method and software system for modularizing software components for business transaction applications
US20110099466A1 (en) Multiple Bindings in Web Service Data Connection
MXPA05002276A (en) System and method for building wireless applications with intelligent mapping between user interface and data components .
KR20050119645A (en) Program creation by combining web services using graphic user interface controls
US20020066074A1 (en) Method and system for developing and executing software applications at an abstract design level
CA2538561C (en) System and method for conversion of web services applications into component based applications for devices
Varanasi et al. Spring Rest
Kauffman et al. Beginning ASP. NET 2.0 and databases
CA2538531C (en) System and method for applying workflow of generic services to component based applications for devices
Ong UMPJJ-WCS (Wages Claims System) through web/Ong Min Tat
Moroney ASP. NET Web Services
Tiwari et al. Migrating Web 1.0 Interfaces to RIA
Hillier SharePoint and BizTalk Server 2004
Guide TIBCO Business Studio™

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION