This invention relates to an implementation system for business applications that can be used to federate the data received from data providers into a common set and process said set in real time.
The first developments of this variety were produced in certain major corporations. They were used during the manufacturing stage to computer process the IT data received from specific businesses by automatically transferring a computer file in so-called neutral format.
The emergence of Intranets and the Internet, and especially the growth in the number of computerized businesses, has led to the need for increased automatic exchanges between those businesses.
International organizations began thinking of SOAs (Service-Oriented Architectures), in which the business applications are based on services instead of coded entities, for the purpose of more effectively gearing the new information technologies towards the company's businesses and introducing a higher degree of flexibility into their working environment.
Services, or functional services, are actually taken to mean functional IT modules, such as functional modules of payroll, invoicing, production management, technical data and client systems, or CAD (Computer-Aided Design) and CAM (Computer-Aided Manufacturing) modules, and so on. The last meaning given will be used in the remainder of this document.
Currently, an approach extending that used for neutral formats involves developing a standard bus capable of supporting computer exchanges between heterogeneous services or businesses. The ESB (Enterprise Service Bus) is one example. Such a solution works all the time that the exchange requirements are low, but beyond that, the solution is not necessarily efficient.
Furthermore, the work performed by standardization groups, such as OMG (Object Management Group), JDO (Java Data Object), JCA (Java Connector Architecture), JMS (Java Messaging Service), EJB (Enterprise JavaBeans) and SOAP (Service-Oriented Architecture Protocol), is common knowledge.
These working groups particularly rely on the capacities of the Java languages (programming language for the Web), as well as the WSDL (Web Service Definition Language) and OWL languages (Web Ontology Language) for developing business applications on the Web.
Work is also focusing on languages for corporate metadata, such as EMD (Enterprise Metadata Discovery), but it is still unfinished or deliberately incomplete.
Obviously, the first step in all this work is to manage to formally describe the most common services and businesses by using data describing the services, known as metadata, but the problem is a difficult one, due to the diversity and complexity.
The diversity is increased even more by the wide range of systems or servers hosting them:                Transaction processing mainframe systems (CICS—Custom Information Control System—or transaction processing monitors for mainframes), middleware, MQSeries (asynchronous message-oriented middleware), ERP (Enterprise Resource Planning), DBMS (Database Management Systems), possibly RDBMS (Relational Database Management Systems) or OODBMS (Object-Oriented Database Management Systems), and the use of query languages, such as SQL (Structured Query Language), and object-oriented languages, such as OOQL (Object-Oriented Query Language)        Systems hosting business applications written in Web language, such as Java, HTML (Hypertext Markup Language) and XML (Extended Markup Language)        
For example, if we consider an application used by a consumer goods company to view its customer invoices on the Web, this Java business application must have access to the data relating to an invoicing service, a customer service and a product service. This data is presumed to reside in memory blocks, but it is not. In the current example, it can only be retrieved by querying an RDBMS and must be translated into XML data. As most of these operations are manual, the invoices cannot be viewed in real time, which means that the system is impracticable.
In brief and to simplify matters, an SQL application cannot be used to query or even call callable services over the Web, and conversely, a Web-based Java application cannot be used to call and query a service related to an RDBMS or a transaction processing system, nor receive data associated with the requested service.
Consequently, even if the data describing the services or businesses in question were available, it would be impossible to create a consistent dataset containing federated data from the Web and from an RDBMS or OODBMS, or in any other system above, and especially process that set in real time.
The applicant has been present in the market for several years via its work in the field of query software for large-capacity databases, such as RDBMS and OODBMS, and other data sources available on the Web, XML and binary files. As part of its wish to extend the scope of its products to SOA service-oriented architectures, the applicant came upon the idea for its invention.
USPTO Backgrounds
USPTO Backgrounds