Abstract:

The object of the present invention is to provide an image forming
apparatus that can transmit and receive data without any process part of
an application corresponding to various communication protocols and
easily add a communication protocol and an application. An image forming
apparatus according to the present invention includes connection request
mediation means for, in response to a connection notice from a plurality
of communication protocol daemons to transmit and receive data in
accordance with respective different communication protocols, mediating
connection instead of the communication protocol daemons by informing the
application that a connection request is provided to the communication
protocol daemons and a shared memory being used for delivery of received
data and transmitted data between the application and the plurality of
communication protocol daemons and being shared by the communication
protocol daemon.

Claims:

1-10. (canceled)

11. An image forming apparatus, comprising:a plurality of method process
means for performing a predefined process in accordance with a method;
anda Web service execution means for, in response to a process request,
executing a Web service by distributing the process request to the method
process means corresponding to the method designated in the process
request.

12. The image forming apparatus as claimed in claim 11, further
comprising:a plurality of Web service applications sharing a process in a
same method and performing a process related to image formation as the
Web service.

13. The image forming apparatus as claimed in claim 11, wherein first
method process means being one of the plurality of method process means
comprise description process means for processing a body part of the
process request described in a predefined description format, and the Web
service application is executed based on a process result provided by the
description process means.

14. The image forming apparatus as claimed in claim 11, wherein the first
method process means being one of the plurality of method process means
comprise:a plurality of process means performing a predefined process
corresponding to a header to designate a description format of the body
part of the process request on the first method to designate the first
method process means; andfirst distribution process means for
distributing the process request to the process means corresponding to a
content type designated in the process request, andwhen the first method
is designated by the process request, the process request is distributed
to the first distribution process means by the Web service execution
means, the process request is distributed to the process means
corresponding to the header, and the Web service application is executed
based on a process result provided by the process means.

15. The image forming apparatus as claimed in claim 11, wherein second
method process means being one of the plurality of method process means
comprise:second distribution process means for distributing the process
request to the Web service application based on identification
information to identify the Web service application on the second method
to designate the second method process means, andwhen the second method
is designated by the process request, the process request is distributed
to the second distribution process means by the Web service execution
means.

16. The image forming apparatus as claimed in claim 12, further
comprising:a Web communication protocol daemon performing communication
control via a Web; andconnection process means being generated through
connection with the Web communication protocol daemon, said connection
process means for controlling reading of received data from a predefined
memory area and writing of transmitted data in the predefined memory area
performed between the Web communication protocol daemon and the Web
service application.

17. The image forming apparatus as claimed in claim 16, further
comprising:a connection notice queue maintaining a connection notice as a
queue;Web connection management means for managing connection between the
Web service execution means and the Web communication protocol daemon by
using the connection notice queue; andconnection request mediation means
for mediating connection instead of the Web communication protocol daemon
by informing the Web connection management means that the connection
notice is provided from the Web communication protocol daemon,wherein the
Web connection management means, in response to a connection request from
the Web service execution means, extract the connection notice from the
connection notice queue and connect to the Web communication protocol
daemon instead of the Web service application.

18. The image forming apparatus as claimed in claim 17, wherein the Web
connection management means, after connection with the Web communication
protocol daemon, generate the connection process means and report
connection management information on the connection to the Web service
execution means, and the Web service execution means, in response to
receipt of the report, distributes the process request to the method
process means corresponding to a method designated in the process
request.

19. The image forming apparatus as claimed in claim 12, further
comprising:a control service managing a plurality of hardware resources
for the image formation and, in response to a use request from the
plurality of Web service applications, controlling use of the plurality
of hardware resources; andan operating system controlling the plurality
of Web service applications and the control service.

20. An image forming method for a computer, the method comprising:a
plurality of method process steps of performing a predefined process in
accordance with a method; anda Web service execution step of, in response
to a process request, executing a Web service by distributing the process
request to the method process steps corresponding to the method
designated in the process request.

21-40. (canceled)

41. The image forming apparatus as claimed in claim 12, wherein first
method process means being one of the plurality of method process means
comprise description process means for processing a body part of the
process request described in a predefined description format, and the Web
service application is executed based on a process result provided by the
description process means.

42. The image forming apparatus as claimed in claim 12, wherein the first
method process means being one of the plurality of method process means
comprise:a plurality of process means performing a predefined process
corresponding to a header to designate a description format of the body
part of the process request on the first method to designate the first
method process means; andfirst distribution process means for
distributing the process request to the process means corresponding to a
content type designated in the process request, andwhen the first method
is designated by the process request, the process request is distributed
to the first distribution process means by the Web service execution
means, the process request is distributed to the process means
corresponding to the header, and the Web service application is executed
based on a process result provided by the process means.

43. The image forming apparatus as claimed in claim 12, wherein second
method process means being one of the plurality of method process means
comprise:second distribution process means for distributing the process
request to the Web service application based on identification
information to identify the Web service application on the second method
to designate the second method process means, andwhen the second method
is designated by the process request, the process request is distributed
to the second distribution process means by the Web service execution
means.

44. The image forming apparatus as claimed in claim 13, wherein second
method process means being one of the plurality of method process means
comprise:second distribution process means for distributing the process
request to the Web service application based on identification
information to identify the Web service application on the second method
to designate the second method process means, andwhen the second method
is designated by the process request, the process request is distributed
to the second distribution process means by the Web service execution
means.

45. The image forming apparatus as claimed in claim 14, wherein second
method process means being one of the plurality of method process means
comprise:second distribution process means for distributing the process
request to the Web service application based on identification
information to identify the Web service application on the second method
to designate the second method process means, andwhen the second method
is designated by the process request, the process request is distributed
to the second distribution process means by the Web service execution
means.

46. The image forming apparatus as claimed in claim 13, further
comprising:a Web communication protocol daemon performing communication
control via a Web; andconnection process means being generated through
connection with the Web communication protocol daemon, said connection
process means for controlling reading of received data from a predefined
memory area and writing of transmitted data in the predefined memory area
performed between the Web communication protocol daemon and the Web
service application.

47. The image forming apparatus as claimed in claim 14, further
comprising:a Web communication protocol daemon performing communication
control via a Web; andconnection process means being generated through
connection with the Web communication protocol daemon, said connection
process means for controlling reading of received data from a predefined
memory area and writing of transmitted data in the predefined memory area
performed between the Web communication protocol daemon and the Web
service application.

48. The image forming apparatus as claimed in claim 15, further
comprising:a Web communication protocol daemon performing communication
control via a Web; andconnection process means being generated through
connection with the Web communication protocol daemon, said connection
process means for controlling reading of received data from a predefined
memory area and writing of transmitted data in the predefined memory area
performed between the Web communication protocol daemon and the Web
service application.

49. The image forming apparatus as claimed in claim 18, further
comprising:a control service managing a plurality of hardware resources
for the image formation and, in response to a use request from the
plurality of Web service applications, controlling use of the plurality
of hardware resources; andan operating system controlling the plurality
of Web service applications and the control service.

Description:

TECHNICAL FIELD

[0001]The present invention relates to an image forming and processing
apparatus having a plurality of communication protocols, and more
particularly, an object of the present invention is to provide an image
forming and processing apparatus that can transmit and receive data even
if an application does not have respective process parts corresponding to
various communication protocols and easily add a communication protocol
and an application. Also, another object of the present invention is to,
provide an image forming apparatus in which an application to provide a
Web service can be easily developed and added. In addition, another
object of the present invention is to provide a program that can
automatically generate a program to convert a description format of
request and response messages of a Web service into a data format
processable for a program of the Web service.

BACKGROUND ART

[0002]Recently, image forming apparatuses, each of which accommodates
respective functions of various devices such as a printer, a copier, a
facsimile and a scanner in one housing thereof, are widely known. Such a
compound type image forming apparatus includes a displaying part, a
printing part and an imaging part in one housing but also respective
applications corresponding to a printer device, a copy device, a scanner
device and a facsimile device, and by switching the applications, the
image forming apparatus can be made to operate as a printer device, a
copy device, a scanner device and a facsimile device.

[0003]However, as the Internet is widely used and a variety of
communication protocols are designed, the market requires that a
conventional compound type image forming apparatus having a printer
function as mentioned above be able to meet printing requests delivered
from various types of interfaces. In such a conventional compound type
image forming apparatus, whenever a new interface is added, the image
forming apparatus is individually capacitated to meet such a market need.
In the case of individual capacitation, it is necessary to modify
installed applications so that these applications can deal with a newly
added interface. On the other hand, if an application is newly developed
and installed, there is a problem that the application has to be
developed to have compatibility with a plurality of interfaces.

[0004]Also, since the recent development and popularization of the
Internet make such a conventional compound type image forming apparatus
having a printer function that can communicate via a network connectable
to other devices via the network, the image forming apparatus is expected
to provide a Web service that can be served under communication control
in accordance with a communication protocol for the Internet, that is,
HTTP (Hypertext Transfer Protocol). In addition to the communication
control in accordance with HTTP, furthermore, it is required to cause
each application of a conventional compound type image forming apparatus
to perform operations caused by differences of methods specified in HTTP
and XML descriptive operations so that the applications to execute image
forming operations can communicate messages under a tendency to widen the
coverage of connected devices by describing a general-purpose description
format such as XML (eXtensible Markup Language) in the body part of HTTP.
Accordingly, developers that develop an application corresponding to a
Web service are required to develop a function-by-function program.

[0005]In the conventional compound type image forming apparatus, if each
application provides an image forming process as a Web service via a
network, it is necessary to modify the installed application so that the
description format of messages communicated in accordance with a network
protocol can be interpreted. Also, in a case where the description format
of the messages is XML (eXtensible Markup Language), if applications
developed in accordance with a conventional development method are
modified corresponding to a Web service or if an application
corresponding to a Web service is newly added to the conventional
compound type image forming apparatus, it is difficult to develop an
application in accordance with a conventional development method because
of requirement of XML knowledge to the developers.

[0006]As mentioned above, since the data format of a message in accordance
with XML is different from the data format processable in a program
language for a Web service function, it is necessary to provide a scheme
to absorb the difference between the two data formats in each Web service
function. In the development of such a scheme to absorb the data format
difference, a large number of simple and similar codes have to be
repeated, and there is a problem in that bugs due to simple errors may be
contained easily.

DISCLOSURE OF INVENTION

[0007]An object of the present invention is to provide an image forming
and processing apparatus having an mediation process part to mediate a
plurality of applications to perform respective different kinds of image
formation with various communication protocols by controlling
transmission and receipt of print data and image data between a device
connected via various types of interfaces that can realize easy addition
of a communication protocol and an application.

[0008]Also, another object of the present invention is to provide an image
forming and processing apparatus configured to include a plurality of
applications for respective different types of image formation and enable
the plurality of applications to share a process part required to provide
a Web service by modularizing the process part in order to easily develop
and add an application to provide the Web service.

[0009]Furthermore, another object of the present invention is to provide
an image forming apparatus in which an application workable as a Web
service can be developed without dependence on description formats of
messages communicated between the image forming apparatus to provide a
plurality of Web services and a device connected to the image forming
apparatus.

[0010]Also, another object of the present invention is to provide a
program that can realize easy program development of a plurality of Web
services without dependence on description formats of messages
communicated between the image forming apparatus to provide the plurality
of Web services and a device connected to the image forming apparatus and
automatically generate a program to convert data formats processable for
development programs of the Web services and the description formats.

[0011]These objects can be solved by the means described below.

[0012]According to the present invention, an image forming apparatus is
configured to include an application executing a process related to image
formation, a plurality of communication protocol daemons transmitting and
receiving data in accordance with respective different communication
protocols, and connection request mediation means for, in response to a
connection notice from each of the communication protocol daemons,
mediating connection instead of the communication protocol daemon by
informing the application that a connection request is provided to the
communication protocol daemon. Also, the image forming apparatus can be
configured to include a shared memory being shared by the plurality of
communication protocol daemons, the shared memory storing received data
and transmitted data and being used for delivery of the received data and
the transmitted data between the application and the plurality of
communication protocol daemons.

[0013]In such an image forming apparatus, a protocol control daemon 9 to
use connection request mediation means (request mediation daemon 7) for
mediating connection between various communication protocols and an
application for executing a process related to image formation control
and a shared memory (99) to control transmission and receipt of data is
configured. As a result, interfaces of the plurality of communication
protocols and each application do not have to be conscious each other.
Thus, it is possible to easily add a communication protocol and an
application to such an image forming apparatus.

[0014]According to the present invention, an image forming apparatus is
configured to include a plurality of method process means for performing
a predefined process in accordance with a method, and a Web service
execution means for, in response to a process request, executing a Web
service by distributing the process request to the method process means
corresponding to the method designated in the process request. In
addition, the image forming apparatus can be configured to include a
plurality of Web service applications sharing a process in a same method
and performing a process related to image formation as the Web service.

[0015]According to such an image forming apparatus, since a process is
modularized for each method, a plurality of Web service applications can
share a process specific to a method.

[0016]According to the present invention, an image forming apparatus is
configured to include Web service process means for executing a process
based on a request message from a device connected via a network and
providing a process result of the process as a Web service and conversion
means for converting the request message received in accordance with a
predefined message communication protocol into a process request
processable by the Web service process means and converting the process
result supplied from the Web service process means into a response
message in accordance with the message communication protocol.

[0017]According to such an image forming apparatus, since a request
message prescribed in a message communication protocol is converted into
a process request processable by the Web service process means and a
process result of the Web service process means is converted into a
response message prescribed in a message communication protocol, it is
possible to develop the Web service process means without knowledge on
such a message communication protocol.

[0018]According to the present invention, a computer readable program is
configured for causing a computer to execute an element tree generation
step of analyzing an interface definition to define an interface of a Web
service and generating a first element tree indicative of an association
between a plurality of elements configuring the interface definition and
a conversion program generation step of generating a conversion program
to perform conversion between a request message and a response message
regarding the Web service described in an input and output data format
processable by a Web service function to execute the Web service and a
predefined description format based on the first element tree.

[0019]In a computer device in which such a program is installed, it is
possible to generate a program (for example, a handler process part in an
embodiment) to perform conversion between request and response messages
in accordance with a predefined description format (such as XML
(eXtensible Markup Language)) and input and output data formats of Web
service functions from interface definitions (such as WSDL (Web Service
Description Language)) to define interfaces of Web services. Thus, since
a large number of simple and similar codes can be generated, it is
possible to eliminate the problem that bugs may be included due to simple
mistakes of developers. Also, since program generation time can be
reduced, it is possible to lessen workloads on developers.

BRIEF DESCRIPTION OF DRAWINGS

[0020]FIG. 1 is a block diagram illustrating a functional structure of a
multifunctional product collectively having various image formation
functions according to one embodiment of the present invention;

[0021]FIG. 2 is a block diagram illustrating a hardware structure of the
multifunctional product shown in FIG. 1;

[0022]FIG. 3 is a diagram illustrating an outline of a process for
mediation between a communication control process and an application;

[0023]FIG. 4 is a diagram illustrating a registration sequence to register
an application;

[0024]FIG. 5 is a diagram illustrating a buffer registration sequence to
register an application buffer;

[0025]FIG. 6 is a diagram illustrating a request report sequence to report
a request to an application;

[0026]FIG. 7 is a diagram illustrating a data transmission and receipt
sequence;

[0027]FIG. 8 is a diagram illustrating a disconnection sequence to
disconnect an application;

[0028]FIG. 9 is a diagram illustrating an exemplary fundamental structure
of a multifunctional product that can develop and add an application
easily;

[0029]FIG. 10 is a diagram illustrating a first exemplary structure of a
multifunctional product that can develop and add an application easily;

[0030]FIG. 11 is a diagram illustrating a process flow of the first
exemplary structure of FIG. 10;

[0031]FIG. 12 is a diagram illustrating a process flow of the first
exemplary structure of FIG. 10;

[0032]FIG. 13 is a diagram illustrating an exemplary thread structure of a
sequence control library;

[0033]FIG. 14 is a diagram illustrating an exemplary thread structure of a
sequence control library;

[0034]FIG. 15 is a diagram illustrating a second exemplary structure of a
multifunctional product that can develop and add an application easily;

[0035]FIG. 16 is a diagram illustrating a third exemplary structure of a
multifunctional product that can develop and add an application easily;

[0036]FIG. 17 is a block diagram illustrating a functional structure of a
handler automatic generation apparatus according to one embodiment of the
present invention;

[0037]FIG. 18 is a block diagram illustrating a hardware structure of a
handler automatic generation apparatus according to one embodiment of the
present invention;

[0038]FIG. 19 is a flowchart to explain an outline of a handler automatic
generation process;

[0039]FIG. 20 is a flowchart to explain a type library generation process;

[0040]FIG. 21 is a diagram to explain a enumeration type definition
generation process in a source code generation process;

[0041]FIG. 22 is a diagram to explain a structure type definition
generation process in a source code generation process;

[0042]FIG. 23 is a diagram to explain an array type definition generation
process in a source code generation process;

[0043]FIG. 24 is a diagram to explain an enumeration type function
declaration process in a source code generation process;

[0044]FIG. 25 is a diagram to explain a structure function declaration
process in a source code generation process;

[0045]FIG. 26 is a diagram to explain an array function declaration
process in a source code generation process;

[0055]FIG. 36 is a diagram illustrating an exemplary structure to
implement a Web service;

[0056]FIG. 37 is a flowchart to explain a Web service providing process in
accordance with SOAP;

[0057]FIG. 38 is a flowchart to explain a Web service providing process in
accordance with SOAP;

[0058]FIG. 39 is a diagram illustrating an exemplary description of an
HTTP request in accordance with SOAP using XML;

[0059]FIG. 40 is a diagram illustrating an exemplary element tree
converted by an XML processor;

[0060]FIG. 41 is a flowchart to explain an element tree analysis process
performed by a print handler;

[0061]FIG. 42 is a diagram illustrating an exemplary setting of an
argument of a function of a Web service function;

[0062]FIG. 43 is a diagram illustrating an exemplary setting of a process
result by the print handler;

[0063]FIG. 44 is a flowchart to explain an element tree generation process
performed by the print handler;

[0064]FIG. 45 is a diagram illustrating an exemplary generated element
tree; and

[0065]FIG. 46 is a diagram illustrating an exemplary description of an
HTTP response in accordance with SOAP using XML converted from an element
tree.

BEST MODE FOR CARRYING OUT THE INVENTION

[0066]In the following, embodiments of the present invention are explained
with reference to the accompanying drawings.

First Embodiment

[0067]An image forming apparatus having various image formation functions
(hereinafter which is referred to as a multifunctional product) according
to the first embodiment of the present invention has a functional
structure, for example, as illustrated in FIG. 1. FIG. 1 is a block
diagram illustrating a functional structure of a multifunctional product
having various image formation functions according to one embodiment of
the present invention.

[0068]In FIG. 1, a multifunctional product 1200 has not only a plotter
1201, a scanner 1202 and other hardware resources 1203 but also a
software set 1210, which is configured from a platform 1220 and an
application 1230, and a multifunctional product activation part 1240.

[0069]When the multifunctional product 1200 is powered ON, the
multifunctional product activation part 1240 is first executed to
activate the platform 1220 and the application 1230.

[0070]The platform 1220 has a control service 1250, which is described
below, to interpret a process request from the application 1230 and issue
an acquisition request for a hardware resource and one or more hardware
resources, a system resource manager (SRM) 1223 to manage one or a
plurality of hardware resources and arbitrate an acquisition request from
the control service 1250, and OS (Operating System) 1221.

[0071]The control service 1250 is configured from a plurality of service
modules, specifically including SCS (System Control Service) 1222, ECS
(Engine Control Service) 1224, MCS (Memory Control Service) 1225, OCS
(Operation panel Control Service) 1226, FCS (FAX Control Service) 1227,
NCS (Network Control Service) 1228 and IMH (Imaging Memory Handler) 1229.
Here, the platform 1220 has an application program interface that enables
a process request to be received from the application in accordance with
a predefined function.

[0072]OS 1221 is an operating system such as UNIX (registered trademark)
and executes individual software items of the platform 1220 and the
application 1230 as respective processes in parallel. When UNIX
(registered trademark), which is an open source, is used, it is possible
to not only ensure security of programs but also obtain source codes
easily because of network availability. In addition, royalty of OS and
TCP/IP is unnecessary, and outsourcing is made easy.

[0073]SRM 1223 together with SCS 1222 is engaged in system control and
resource management, arbitrates hardware resources of an engine part
including a scanner, a plotter and other devices, a memory, a HDD file
and a host I/O (a centronics I/F, a network I/F, an IEEE1394 I/F, an
RS232C I/F and so on) in accordance with requests from an upper layer
that uses the hardware resources, and conducts execution control.

[0074]Specifically, SRM 1223 determines whether a requested hardware
resource is available (whether the requested hardware resource is in
service for other requests), and if the hardware resource is available,
SRM 1223 reports availability of the requested hardware resource to the
upper layer. Also, SRM 1223, in response to a request from the upper
layer, may schedule the hardware resources and directly fulfill request
contents (for example, a paper carry operation and an image forming
operation performed by a printer engine, memory reservation and file
creation).

[0075]SCS 1222 carries out a plurality of functions of application
management (function 1), operation part control (function 2), system
screen displaying (job list screen, a counter display screen and so on)
(function 3), LED displaying (function 4), resource management (function
5), interrupt application control (function 6) and so on. Specifically,
in the application management (function 1), an application is registered
and the information is reported to other applications. In operation part
control (function 2), the right of an application to use the operation
part is exclusively controlled. In the system screen displaying (function
3), in response to request contents from an application having the right
of use to the operation part, an alarm screen is displayed corresponding
to statuses of the engine part. In the LED displaying (function 4),
displaying of a system LED such as an alarm LED and an application key is
controlled. In the resource management (function 5), during job execution
of an application using ECS, exclusive control over the engine resources
(a scanner, a staple and so on) that have to be excluded is served. In
the interrupt application control (function 6), control and service to
preferentially operate a certain application are performed.

[0078]OCS 1226 is a module to control an operation panel as communication
means between an operator and a body control part of the apparatus and
performs operations to inform the body control part that a key
manipulation event is generated by an operator, operations to provide a
library function that each application uses to construct GUI, operations
to manage constructed GUI information with respect to each application,
and display reflection operations on an operation panel.

[0079]FCS 1227 provides an API (Application Program Interface) to perform
facsimile transmission and receipt using a PSTN/ISDN network from each
application layer of a system controller, registration/citation of sorts
of facsimile data managed in BKM (backup SRAM), facsimile reading,
facsimile receiving and printing, and compound transmission and receipt.

[0080]NCS 1228 is a module set to provide a service that applications
requiring a network I/O can commonly use. NCS 1228 distributes data
received from the network side by each protocol to individual
applications and serves as an intermediary, to send data from an
application to the network side.

[0081]In this embodiment, NCS 1228 uses a http (Hypertext Transfer
Protocol) daemon, which is one of a plurality of protocols, to control
data communication to a network device connected via the Internet in
accordance with HTTP (Hypertext Transfer Protocol), starts a plurality of
Web services required for processes designated by an HTTP request header
by calling functions, and reports process results of the plurality of Web
services to the network device as HTTP responses. The Web services are
processed, for example, in accordance with messages described in XML
(eXtensible Markup Language).

[0082]IMH 1229 maps image data from a virtual memory area (user virtual
space) to a physical memory. In response to activation of a process, IMH
1229 calls the system, maps the virtual memory area for a process, and
releases the mapped virtual memory area at process completion time.

[0083]The application 1230 has a printer application 1211 being an
application for a printer having page descriptive language (PDL), PCL and
postscript (PS), a copy application 1212 being an application for
copying, a FAX application 1213 being an application for FAX, a scanner
application 1214 being an application for a scanner, a network file
application 1215 being an application for a network file, a process
examination application 1216 being an application for process
examination, a distribution application 1217 being an application for
distribution, and a Web service application 1218 for providing results of
execution as Web services. Since the individual applications 1211 through
1218 can use processes on the platform 1220 to perform operations, a
screen display control program to conduct screen control, key
manipulation control, job generation and so on plays a main role. Here, a
new application can be installed via a network connected by NCS 1228.
Also, each application can be added or removed per application.

[0084]Here, the Web service application 1218 is an application to execute
a process corresponding to an HTTP request reported by NCS 1228, and the
process result is provided as an HTTP response to the network device that
issues the HTTP request by NCS 1228.

[0086]Next, a hardware configuration of the multifunctional product 1200
is explained. FIG. 2 is a block diagram illustrating a hardware structure
of the multifunctional product shown in FIG. 1. As shown in FIG. 2, the
multifunctional product 1200 is configured by connecting an operation
panel 1310, FCU (FAX Control Unit) 1320, an engine part 1350 composed of
the plotter 1201, the scanner 1202 and other hardware resources, and ASIC
1301 of the controller 1300 via a PCI (Peripheral Component Interconnect)
bus or the like. FCU 1320 has a nonvolatile memory 1321 for storing
received FAX data and RTC (Real Time Clock) 1322 for measuring the time
in FCU 1320. FCU 1320 usually transmits and receives FAX data in
accordance with G3 standard. FCU 1320 may further include both G3
standard and G4 standard.

[0087]In the controller 1300, MEM-C 1302, HDD (Hard Disk Drive) 1303 and
other components are connected to ASIC 1301, and furthermore, ASIC 1301
is connected to CPU 1304 via NB 1305 of the CPU chip set. Since the
interface of CPU 1304 is not disclosed, ASIC 1301 is connected to CPU
1304 via NB 1305 as mentioned above.

[0088]Here, ASIC 1301 is connected to NB 1305 not simply via PCI but via
AGP 1308. The reason that ASIC 1301 is connected to NB 1305 via AGP 1308
in this fashion is why the connection using a low-speed PCI may reduce
the performance because the multifunctional product 1200 controls
execution of a plurality of processes configuring the platform 1220 and
the application 1230.

[0090]NB 1305 is a bridge to connect CPU 1304 to MEM-P 1306, SB 1307 and
ASIC 1301. MEM-P 1306 is a system memory used as a drawing memory of the
multifunctional product. MEM-C 1302 is a local memory used as a copy
image buffer and a code buffer. ASIC 1301 is an image processing specific
IC having an image processing hardware element.

[0091]NB 1305 is connected to SB 1307 via a PCI bus. In addition, NB 1305
is connected to NIC (Network Interface Card) 1311 to control network
communication, USB (Universal Serial Bus) 1312 and IEEE1394 1313 to
enable transmission and receipt of large-sized image data in connection
with a personal computer, and a centronics 1314 connectable via a
parallel cable. SB 1307 is a bridge to connect NB 1305 to ROM, a PCI
device and a peripheral device. SB 1307 has RTC (Real Time Clock) 1323 to
measure time in the controller 1300.

[0092]HDD 1310 is a storage to store image data, programs, font data and
forms. An operation panel 1310 is an operation part to accept input
manipulation from an operator and display messages for an operator.

[0093]Accordingly, a RAM interface for connection with MEM-C 1302 and a
hard disk interface for connection with HDD 1310 are provided to ASIC
1301. When image data are input/output to/from these memory parts, the
input/output destination is switched into the RAM interface or the hard
disk interface.

[0094]AGP 1308 is an interface for a graphic accelerator card presented to
increase the processing speed of a graphic process. By directly accessing
a system memory at a high throughput, it is possible to improve the
processing speed of the graphics accelerator card.

[0095]Next, data transmission and receipt control between the application
1230 and NCS 1228 is described.

[0096]FIG. 3 is a diagram illustrating an outline of an operation of a
process to mediate between a communication control process and an
application. In FIG. 3, only main functional components of the
multifunctional product 1200 are illustrated, and the other functional
components are omitted. In FIG. 3, the multifunctional product 1200 has
the application 1230 to execute various image formation processes, NCS
1228 having a plurality of communication control daemons to control
various communication protocols, and NAI 8 to take an interface between
NCS 1228 and the application 1230. The multifunctional product 1200 is
connected to a network 15. NCS 1228 has a request mediation daemon 7 to
mediate between the daemon 9 and the application 1230, and a protocol
control daemon 9 configured from various communication protocol daemons.
The protocol control daemon 9 has an http daemon 2, an ipp daemon 91, a
ftp daemon 92, a USB daemon 93, an IEEE1394 daemon 94 and a centronics
daemon 95.

[0097]The http daemon 2 controls communication, for example, in accordance
with HTTP (Hypertext Transfer Protocol). The http daemon 2 sets a
network, monitors for a status of the device, transmits and receives a
device control command in XML in cooperation with an application. The ipp
daemon 91 controls receipt of print data in accordance with IPP (Internet
Printing Protocol) being an HTTP-based printing protocol. The ftp daemon
92 controls to provide a service in accordance with FTP (File Transfer
Protocol).

[0100]From the above description, it will be understood that NCS 1228
differs from other services of the control service 1250 in that
communication takes place through two processes of the protocol control
daemon 9 and the protocol control daemon 9.

[0101]NCS 1228 uses a shared memory as means for communicating a large
amount of data between processes. The shared memory is a memory area to
which a plurality of different processes are allowed to access. NCS 1228
is a standard function provided to NetBSD (registered trademark). In
order to exclusively access the shared memory from a plurality of
processes, it is necessary to communicate information on reading and
writing of data each other.

[0102]A detailed description is given, with reference to FIG. 4 through
FIG. 8, of a sequence to communicate a large amount of data between NCS
1228 and the application 1230 in the process outline shown in FIG. 3.

[0103]FIG. 4 is a diagram illustrating a registration sequence to register
an application. Referring to FIG. 4, the application 1230 makes an
inquiry to the request mediation daemon 7 (step S101). In response to
receipt of a report on supported services from the request mediation
daemon 7 (step S102), the application 1230 registers an application to
the request mediation daemon 7 by reporting service contents of the
application 1230 (step S103). For example, the application, a spool
function (not available), a job function (not available) and so on are
registered.

[0104]This registration makes it possible for the request mediation daemon
7 to obtain information to indicate which application the request
mediation daemon 7, in response to receipt of a connection notice from
the protocol control daemon 9, should mediate to connect to which
communication protocol daemon.

[0105]FIG. 5 is a diagram illustrating a buffer registration sequence to
register an application buffer. Referring to FIG. 5, the application 1230
executes a transmission and receipt buffer acquisition process. The
application 1230 registers a plurality of transmission and receipt
buffers for the application 1230 to the request mediation daemon 7 (step
S111). In addition, the application 1230 opens the registered
transmission and receipt buffers (step S112) and obtains transmission and
receipt buffer management information from the request mediation daemon 7
(step S113). At this time, the application 1230 reserves a plurality of
transmission and receipt buffers for itself in the shared memory.

[0106]FIG. 6 is a diagram illustrating a request report sequence to report
a request to an application. Referring to FIG. 6, in response to receipt
of a connection notice via the network 15 (step S11), the protocol
control daemon 9 reports the connection notice to the request mediation
daemon 7 (step S12). In response to receipt of the connection notice from
the protocol control daemon 9, the request mediation daemon 7 assigns one
of the plurality of the transmission and receipt buffers that the
application 1230 has registered and then informs the protocol control
daemon 9 (step S13).

[0107]In addition, the request mediation daemon 7 provides a connection
notice to the application 1230 to report a connection destination (step
S14). In response to the connection notice, the application 1230 provides
a connection permission to the request mediation daemon 7 (step S15).
Then, the application 1230 establishes a connection with the protocol
control daemon 9 (step S16). The protocol control daemon 9 connected to
the application 1230 is one of daemons 2 and 91 through 95 as shown in
FIG. 3. In addition, the application 1230 sets report timing to the
protocol control daemon 9 (step S17) and requests the protocol control
daemon 9 to start data receipt from the connection destination (step
S18).

[0108]FIG. 7 is a diagram illustrating a data transmission and receipt
sequence. Referring to FIG. 7, when the protocol control daemon 9 of NCS
1230 writes received data in a receipt buffer 97 in a shared memory 99
(step S21), the protocol control daemon 9 shifts a write pointer by the
amount of received data (step S22). The protocol control daemon 9 informs
the application 1230 that the data have been written in the receipt
buffer (step S23). Through the report, a start pointer at which the
writing is started and an end pointer at which the writing is ended are
reported.

[0109]In response to receipt of the notice from the protocol control
daemon 9, the application 1230 reads the received data from the shared
memory 99 (step S24) and shifts the read pointer by the amount of the
received data (step S25). Then, the application 1230 informs the protocol
control daemon 9 that the received data have been read from the receipt
buffer (step S26).

[0110]A description is given of a case where data are transmitted from the
application 1230 to the network 15. When the application 1230 writes
transmitted data in a transmission buffer 98 in the shared memory 99
(step S27), the application 1230 shifts the write pointer by the amount
of the transmitted data (step S27-2). The application 1230 informs the
protocol control daemon 9 that the transmitted data have been written in
the transmission buffer (step S28). Through this report, a start pointer
at which the writing is started and an end pointer at which the writing
is ended are reported.

[0111]In response to receipt of the report from the application 1230, the
protocol control daemon 9 reads the transmitted data from the shared
memory 99 and transmits the read data to the connection destination (step
S29). Then, the protocol control daemon 9 shifts the read pointer (step
S30). The protocol control daemon 9 informs the application 1230 that the
data have been read from the transmission buffer (step S30-2).

[0112]In description with reference to FIG. 7, for convenience, the
reading is performed after received data have been written. However, the
reading and the writing may be performed simultaneously. The writing and
the reading of transmitted data may be also similarly performed.

[0113]FIG. 8 is a diagram illustrating a disconnection sequence to
disconnect an application. Referring to FIG. 8, the protocol control
daemon 9 informs the application 1230 that data have been received (step
S31). This notice is provided, for example, when the network is
disconnected. In response to receipt of the notice, the application 1230
determines the current status as a disconnection status and requests the
protocol control daemon 9 to break the connection with the daemon that
has received the data (step S32). The protocol control daemon 9 performs
a termination process and reports the termination to the request
mediation daemon 7 (step S33).

[0114]In this fashion, it is possible to exclusively access the shared
memory 99 from a plurality of processes through mutual communication of
information on writing and reading of data between the application 1230
and the protocol control daemon 9.

[0115]In this fashion, according to the present invention, by controlling
transmission and receipt of print data and image data between devices
connected via various interfaces, the protocol control daemon 9 of the
multifunctional product 1200 can be configured to use the request
mediation daemon 7 and the shared memory to mediate connection between
various communication protocols and a plurality of applications for
different types of image processing to control data transmission and
receipt. As a result, interfaces of the communication protocols and the
individual applications do not have to be considered each other. Thus, it
is possible to easily add a communication protocol and an application to
the multifunctional product 1200.

[0116]As described in the first embodiment, according to the present
invention, since a mediation processing part to mediate between various
communication protocols and a plurality of applications to perform
distinct image formation processes is provided in an image forming
apparatus by controlling transmission and receipt of print data and image
data between devices connected via various interfaces, the interfaces of
the communication protocols and the individual applications do not have
to be considered each other. As a result, it is possible to easily add a
communication protocol and an application to an image forming apparatus
according to the present invention.

[0117]In the present invention, connection request mediation means for
mediating connection between various communication protocols and
applications to execute operations related to image formation can be
configured to have registration means for, in response to a registration
request from an application, registering the application and buffer
registration means for, in response to a registration request of a
transmission and receipt buffer from the application, registering a
receipt buffer and a transmission buffer specific to the application to
make the receipt buffer and the transmission buffer available.

[0118]Also, the connection request mediation means can be configured to
have transmission and receipt buffer allocation means for, in response to
receipt of a connection notice from the communication protocol daemons,
allocating a receipt buffer and a transmission buffer, which are used
during connection, in the shared memory and informing the communication
protocol daemon.

[0119]In addition, the application 1230 can be configured to have
connection process means for, in response to receipt of a connection
notice from the connection request mediation means, reporting connection
permission to the connection request mediation means and establishing
connection with the communication protocol daemon and data receipt start
request means for requesting the communication protocol daemon to start
data receipt.

[0120]In addition, each communication protocol daemon can be configured to
have received data write means for writing data received by the
communication protocol daemon in the receipt buffer allocated by the
transmission and receipt buffer allocation means and shifting the write
start position by the length of the data and receipt write report means
for informing the application that the received data have been written in
the receipt buffer and reporting writing of the received data in
designated write start position and write end position.

[0121]In addition, the application 1230 can be configured to have received
data read means for, in response to receipt of a write notice of the
received data from the communication protocol daemon, reading the
received data from a range between the write start position and the write
end position, which are designated in the write notice, in the receipt
buffer and shifting the read start position to the write end position and
receipt read report means for informing the communication protocol daemon
that the received data have been read from the receipt buffer.

[0122]In addition, the application 1230 can be configured to have
transmitted data write means for writing transmitted data in the
transmission buffer registered by the buffer registration means and
shifting the write start position by the length of the data and
transmission write report means for informing the communication protocol
daemon that the transmitted data have been written in the transmission
buffer and reporting that the transmitted data have been written in
designated write start position and write end position.

[0123]In addition, each communication protocol daemon can be configured to
have transmitted data read means for, in response to receipt of a write
notice to write the transmitted data from the application, reading the
transmitted data from a range between the write start position and the
write end position, which are designated in the write notice, in the
transmission buffer and causing the communication protocol daemon
connected to the application to transmit the transmitted data, start read
position shift means for shifting the read start position to the write
end position and transmission read report means for informing the
application that the transmitted data have been read from the
transmission buffer.

Second Embodiment

[0124]The multifunctional product 1200 according to a second embodiment of
the present invention has the same functional structure and hardware
configuration as those of the multifunctional product 1200 according to
the first embodiment, and the description thereof is omitted.

[0125]In addition to the functional structure and hardware configuration
according to the first embodiment, furthermore, since operations on data
transmission and receipt between NCS 1228 and the application 1230 are
unified as a sequence control library and similar processes are performed
for implementation of Web service functions, a method of modularizing and
unifying such similar processes can be considered.

[0126]A description is given, with reference to FIG. 9, of a fundamental
structure of the multifunctional product 1200 in the case where such
similar processes are unified as a sequence control library. FIG. 9 is a
diagram illustrating an exemplary fundamental structure of a
multifunctional product whereby an application can be developed and added
easily. In FIG. 9, only main functional components of the multifunctional
product 1200 are illustrated, and the description of the other functional
components is omitted. Referring to FIG. 9, the application 1230 and NCS
1228 communicate received data and transmitted data to each other via a
sequence control library 100 as an intermediate layer. Here, case where
an HTTP daemon 2 controls the communication is described. The sequence
control library 100 is used also in cases where other daemons control the
communication.

[0127]The application 1230 has a process part for each method to designate
a data transmission manner. For example, the application 1230 has a POST
method process part 103 operating in POST method, a GET method process
part 104 operating in GET method, and other method process part 199
operating in a method other than the POST method and the GET method. Each
of the process parts 103, 104 and 199 not only performs an analysis
process specific to respective methods but also executes an operation in
accordance with a process request and provides the process result as a
Web service.

[0128]The sequence control library 100 has an HTTP connection management
part 101 to manage connection in accordance with HTTP and an HTTP service
execution part 102 to execute a service by transmitting and receiving
data in accordance with HTTP.

[0129]Since connection is established for each request of an HTTP service,
a plurality of the HTTP execution parts 102 are generated as threads (or
processes). The HTTP service execution part 102 distributes processes to
the GET method process part 104, the POST method process part 103 and the
other method process part 199 in accordance with a method to designate
data transmission manner designated in an HTTP header.

[0130]NCS 1228 has an HTTP daemon 2 to control communication for data
transmission and receipt via the network 15 in accordance with HTTP and a
request mediation daemon 7, in response to a connection or disconnection
notice from the HTTP daemon 2, to establish and break connection with the
HTTP connection management part 101.

[0131]In response to receipt of the first connection notice from the
request mediation daemon 7, the HTTP connection management part 101
initializes the shared memory 99 and registers a connectable number of
the receipt buffers 97 and the transmission buffers 98 so that data can
be transmitted and received. Also, this initialization allows a plurality
of connection requests to be accepted. For each connection, the HTTP
service execution part 102 is generated as a thread. Then, an HTTP
service can be provided for each connection.

[0132]For example, it is supposed that the HTTP daemon 2 can accept at
most three connection requests simultaneously. In this case, it is
possible to improve the process performance in all time presence of three
threads. On the other hand, one thread may be generated for each
connection, and the thread may be terminated at time of the process
completion.

[0133]Each of the process parts 103, 104 and 199 of the application 1230
does not communicate data with the HTTP daemon 2 and the request
mediation daemon 7 directly. Each process part, in response to receipt of
a process request from the HTTP service execution part 102, reports the
process result to the HTTP service execution part 102 via the shared
buffer 99.

[0134]Each of the process parts 103, 104 and 199, for example, after
receipt of a process request from the HTTP service execution part 102,
reads print data to be processed (MB-order data) from the shared buffer
99, writes the execution result of the process corresponding to the
process request on the print data in the shared buffer 99, provides the
process result as a Web service to the request source via the HTTP
service execution part 102. The process result is image data (MB-order
data) generated by performing an image formation operation on the print
data or status information indicative of a status on the image formation
operation, for example.

[0135]Thus, each of the process parts 103, 104 and 199 of the application
1230 has only to be a process part to which the HTTP service execution
part 102 can distribute process requests.

[0136]Similarly, it is also possible to easily add various applications,
that is, to add a process part corresponding to a method to the
multifunctional product 1200.

[0137]The exemplary fundamental structure that can easily add a process
part for each method to provide a Web service has been described with
reference to FIG. 9. In such a method-by-method process part, however, if
different Web services are provided in one method, process specific to
the method necessary prior to execution of a process to provide a Web
service has to be provided for each Web service. It is considered to
unify such processes specific to a method.

[0138]A description is given, with reference to FIG. 10, of a case where
processes on data transmission and receipt between NCS 1228 and the
application 1230 are unified as a sequence control library and further
processes specific to each method are unified. In addition, the process
flow is described in detail with reference to FIG. 11 and FIG. 12.

[0139]FIG. 10 is a diagram illustrating a first exemplary structure of a
multifunctional product that can make the development and addition of an
application easy. In FIG. 10, only main functional components of the
multifunctional product shown in FIG. 1 are illustrated, and the other
functional components are omitted. In FIG. 10, the same process parts as
those in FIG. 9 are designated by the same reference numerals, and the
description thereof is omitted.

[0140]The fundamental structure shown in FIG. 10 differs from that shown
in FIG. 9 in that in the POST method process part 103 of the application
1230, Web service applications 1218-1 and 1218-2 share an XML process
part 103-2 to analyze XML messages specific to the POST method and
generate messages in accordance with XML and an XML analysis part 103-3
having parts required to analyze and generate XML.

[0141]When the HTTP service execution part 102 distributes a process to
the POST method process part 103, the POST method process part 103, in a
case where a process request is described in an XML message, causes the
XML process part 103-2 to uniformly analyze the XML message and describe
a response from the Web service applications 1218-1 and 1218-2, which
actually perform a process corresponding to the request as a Web service,
in form of an XML message. The XML process part 103-2 operates the XML
analysis part 103-3 as needed and analyzes and generates XML messages.

[0142]In the first exemplary structure, since each of the Web service
applications 1218-1 and 1218-2 does not have to analyze and generate any
XML message, developers have to develop only a process part to actually
provide a Web service in the POST method. As a result, it is possible to
easily add a new Web service application to the multifunctional product
1200.

[0143]A description is given, with reference to FIG. 11 and FIG. 12, of a
process flow between execution of the Web service application 1218 as a
Web service and notification of the process result to the HTTP daemon 2
in the first exemplary structure shown in FIG. 10. FIG. 11 and FIG. 12
are diagrams illustrating a process flow in the first exemplary structure
shown in FIG. 10. Referring to FIG. 11, when the request mediation daemon
7 reports a connection notice to the HTTP connection management part 101
(step S40), the HTTP connection management part 101 adds the notice to a
connection notice queue 105 (step S41). The HTTP service execution part
102 requests the HTTP connection management part 101 to acquire
connection (step S42). In response to the request, the HTTP connection
management part 101 requests the connection notice queue 105 to acquire
the notice (step S43) and acquires a connection notice from the
connection notice queue 105 (step S44).

[0144]Based on the connection notice acquired from the connection notice
queue 105, the HTTP connection management part 101 establishes connection
with the HTTP daemon 2. Also, the HTTP connection management part 101
generates connection management information and stores the connection
management information in a connection process part 89 (step S46). The
connection process part 89 is apart of processes performed in the HTTP
service execution part 102. On the other hand, in response to connection
from the HTTP connection management part 101, the HTTP daemon 2 stores
HTTP header information in the connection process part 89 (step S47).

[0145]The HTTP connection management part 101 informs the HTTP service
execution part 102 of the connection management information (step S48).
If the connection management information designates the POST method, the
HTTP service execution part 102 requests the POST method process part 103
to perform a process (step S49). The POST method process part 103, if
"text/xml" is designated as "Content-Type", requests the XML process part
103-2 to analyze an XML message (step S50).

[0146]The XML process part 103-2 requests the connection process part 89
to read data (step S51). The HTTP daemon 2 informs the connection process
part 89 that received data have been written in the receipt buffer 97
(step S52). The connection process part 89 reports the received data to
the XML process part 103-2 (step S53).

[0147]The XML process part 103-2 requests the XML analysis part 103-3 to
analyze an XML message portion of the received data (step S54). Then,
when the XML process part 103-2 requests the XML analysis part 103-3 to
acquire the result, the XML analysis part 103-3 informs the XML process
part 103-2 of an element tree as the result of syntax analysis on the XML
message (step S56).

[0148]The XML process part 103-2 requests the Web service application 1218
to perform a process corresponding to the element tree reported from the
XML analysis part 103-3 (step S57). Depending on the request, the Web
service application 1218 executes the process and informs the XML process
part 103-2 of the process result by using an element tree (step S58).

[0149]Based on the reported element tree, the XML process part 103-2
generates an XML message by writing the process result of the Web service
application 1218 in the connection management part 87 in accordance with
XML (step S59). Then, the connection process part 89 writes the XML
message in the transmission buffer 98 and informs the HTTP daemon 2 that
the message has been written in the transmission buffer 98 (step S60).

[0150]Also, the XML process part 103-2 provides a termination notice to
the connection process part 89 (step S61). In response to the termination
notice, the connection process part 89 disconnects to the HTTP daemon 2
(step S62). Furthermore, the XML process part 103-2 informs the
connection process part 89 that the process has been completed (step
S63). The connection process part 89 informs the HTTP service execution
part 102 that the process has been completed (step S64). Then, the HTTP
service execution part 102 informs the HTTP connection management part
101 that the process has been completed (step S65).

[0151]In the above-mentioned process flow, the Web service application
1218 performs the process mutually with only the XML process part 103-2
at steps S57 and S58. In this fashion, it is possible to make the
development of a Web service application in accordance with new POST
method by using the sequence control library 100 and the process part
modularized and unified process part composed of the XML process part
103-2 and the XML analysis part 103-3 in the POST method process part 103
of the application 1230.

[0152]A further description is given, with reference to FIG. 13 and FIG.
14, of a thread structure generated by a sequence control library that
implements communication of transmitted and received data using the
shared memory 99. FIG. 13 and FIG. 14 are diagrams illustrating an
exemplary thread of a sequence control library.

[0153]Referring to FIG. 13, an initialization thread 191, which is
generated in response to activation of the multifunctional product 1200,
generates a mediation daemon client thread 192 (step S61). The mediation
daemon client thread 192 is a process unit of the HTTP connection
management part 101 and works as the HTTP connection management part 101.
Then, the initialization thread 191 registers an application in the
request mediation daemon 7 (step S62). In addition, the initialization
thread 191 generates at least one HTTP service execution thread 193 (step
S63). The HTTP service execution thread 193 is a unit of the HTTP service
execution part 102 and works as the HTTP service execution part 102.

[0154]In response to a connection notice from the request mediation daemon
7 (step S64), the mediation daemon client thread 192 adds the connection
notice to the connection notice queue 105 and reports connection to one
of the HTTP service execution threads 193 (step S65). In response to
receipt of the connection notice, the HTTP service execution thread 193
generates an HTTP daemon client thread 194 (step S66). The HTTP service
execution thread 193 is connected to the HTTP daemon 2 (step S67).

[0155]The request mediation daemon 7 informs the HTTP daemon client thread
194 that received data have been written in the receipt buffer 97 (step
S68). Then, the HTTP daemon client thread 194 informs the HTTP service
execution thread 193 that the received data have been written (step S69).
The HTTP service execution thread 193 reads the received data, which have
been written by the request mediation daemon 7, from the receipt buffer
97 (step S70).

[0157]Through the thread process in the sequence control library 100, a
large amount of data can be accessed by using the shared memory 99. In
addition, the thread process can be realized as a process separate from
the Web service application 1218 actually executing a Web service
function implemented in the application 1230. Also, the above description
holds for a Web service application actually executing a Web service
function in the GET method process part 104 and the other method process
part 199 shown in FIG. 10. As a result, developers of a Web service
function can develop a Web service function without knowledge on the
process flow of data transmission and receipt between NCS 1228 and the
application 1230.

[0158]In the first exemplary structure shown in FIG. 10, the case where
XML messages are used for process requests and responses in accordance
with the POST method has been described. However, the POST method
includes various process types depending on content types. A description
is given, with reference to FIG. 15, of a case where process parts are
integrated for each process type in the POST method. FIG. 15 is a diagram
illustrating the second exemplary structure of a multifunctional product
that makes the development and addition of an application easy. In FIG.
15, the same process parts as those in FIG. 10 are designated by the same
reference numerals, and the description thereof is omitted.

[0159]Referring to FIG. 15, the POST method process part 103 has, in
addition to the process parts 103-2, 103-3 and 1218-4 corresponding to
the process parts 103-2, 103-3 and 1218-1 and 1218-2, respectively, as
unified process parts, a content type distribution process part 113-1 to
distribute processes based on content types, a FORM data analysis part
113-2 to analyze such a process request that FORM is designated in the
content type, and a multipart analysis part 113-4 to analyze such a
process request that a multipart is designated in the content type. In
addition, the POST method process part 103 has as process parts to
provide a Web service a Web service application 1218-3 to actually
process data set in FORM and a Web service application 1218-5 to perform
a process to upload a data file designated by the multipart.

[0160]The content type distribution process part 113-1, if
"application/x-www-form-urlencoded" is designated as the content type,
assigns a process request to the FORM data analysis part 113-2. Also, the
content type distribution process part 113-1, if "multipart/form-data" is
designated as the content type, assigns a process request to the
multipart analysis part 113-4. Also, the content type distribution
process part 113-1, if "text/xml" is designated as the content type,
assigns a process request to the XML process part 103-2.

[0161]In response to receipt of process requests, the FORM data analysis
part 113-2, the multipart analysis part 113-4 and the XML process part
103-2 perform respective analysis processes and then cause the Web
service applications 1218-3, 1218-5 and 1218-4 to perform processes
corresponding to the process requests.

[0162]In this fashion, by sharing predefined analysis processes
corresponding to content types handled in the POST method, a developer
can develop a new Web service application 1218 without knowledge on the
predefined analysis processes and also easily adds such a new Web service
application 1218 to the multifunctional product 1200.

[0163]A description is given, with reference to FIG. 16, of a structure to
share processes specific to the GET method in the GET method process part
104. FIG. 16 is a diagram illustrating the third exemplary structure of a
multifunctional product that makes the development and addition of an
application easy. In FIG. 16, the same process parts as those in FIG. 9
are designated by the same reference numerals, and the description
thereof is omitted.

[0164]Referring to FIG. 16, the GET method process part 104 has a URL
distribution process part 104-1 to distribute process requests based on
URLs (Uniform Resource Locator) to identify Web services as a unified
process part and a plurality of Web service applications 1218-6 through
1218-8 corresponding to the URLs as process parts to provide Web
services.

[0165]In this fashion, by sharing predefined analysis processes of URLs
handled in the GET method, a developer can develop a new Web service
application without knowledge on the predefined analysis processes of
URLs and also easily add such a new Web service application to the
multifunctional product 1200.

[0166]In addition, when the multifunctional product 1200 is configured to
have the POST method process part 103 as shown in FIG. 15 and the GET
method process part 104 as illustrated in FIG. 16, it is possible to
easily develop and add a Web service application 1218 even in either of
the POST method and the GET method.

[0167]According to the present invention, the multifunctional product 1200
can be configured to modularize process parts necessary to provide Web
services and share the process parts in a plurality of applications. As a
result, since similar functions necessary to provide Web services are
collectively modularized and the modularized functions (process parts)
can be reused by implementation applications, it is possible to easily
develop an application and add the application to the multifunctional
product 1200.

[0168]As mentioned in the second embodiment, according to the present
invention, since an image forming apparatus has such a structure that
process parts necessary to provide Web services are modularized and the
modularized process parts are shared in a plurality of applications, it
is possible to provide the image forming apparatus whereby an application
to provide a Web service can be easily developed.

[0169]In the present invention, connection process means for generating
the connection management information and performing a connection
process, in response to receipt of a process notice from the method
process part to which the process request is assigned, can be configured
to break connection with the Web communication protocol daemon.

[0170]Also, the connection process means inform the Web service execution
means that a process corresponding to the process request has been
completed and can be configured to report the process completion to the
Web connection management means.

[0171]In addition, a program can be configured to have a method process
step of processing a plurality of methods to perform predefined processes
in accordance with methods and a Web service execution step of, in
response to a process request, executing Web services by distributing the
process request to the method process step corresponding to the method
designated by the process request.

Third Embodiment

[0172]A handler automatic generation apparatus according to one embodiment
of the present invention has a functional structure as illustrated in
FIG. 17. FIG. 17 is a block diagram illustrating a functional structure
of a handler automatic generation apparatus according to one embodiment
of the present invention. Referring to FIG. 17, a handler automatic
generation apparatus 500, which is a computer device, has a recording
medium (for example, a hard disk drive (HDD)) for storing a handler
automatic generation part 510 to generate a program for absorbing a
difference between data format of a message and data format processable
in a program language of a Web service function, an interface definition
521 in accordance with WSDL (Web Service Description Language), and a
source code 531 required to execute a handler.

[0173]The handler automatic generation part 510 is a process part to input
the interface definition 521 in accordance with WSDL (Web Service
Description Language), generate an element tree through analysis of the
syntax of a request message described in XML (eXtensible Markup
Language), set an argument for function call of a Web service function
(WSF) based on the element tree, and generate and output a source code of
the handler process part to generate an element tree to describe an XML
response message including a return value from the Web service function.

[0174]The handler automatic generation part 510 has an XML analysis part
511, a type library generation part 512, a handler source code generation
part 513, an XML schema analysis part 514, a type element analysis part
515, a message element analysis part 516, an operation element analysis
part 517, a file input part 520 to input the interface definition 521,
and a file output part 530 to output the source code 531.

[0175]The interface definition 521 defines what interface makes it
possible to provide a Web service. The interface definition 521 is
configured from an interface definition file 522 in accordance with WSDL
and a type definition file 523 fetched through import from the interface
definition file 522. If the type definition file 523 is not fetched in
the interface definition file 522 through import, the type definition
file 523 does not exist.

[0176]The source code 531 is, for example, a C language source code. The
source code 531 is configured from a handler source code 532 composed of
a header file and a program file of the handler process part and a type
library 533 referred to by the handler source code 532. The type library
533 is configured from a header file and a program file.

[0177]The file input part 520 supplies the interface definition 521
designated by a user to the handler automatic creation part 510 (step
S81) and informs the XML analysis part 511 (step S82). The XML analysis
part 511 generates an element tree through analysis on the XML syntax
based on the interface definition 521 received from the file input part
520. Then, the XML analysis part 511 reports the element tree to the type
element analysis part 515 (step S83-1), the message element analysis part
516 (step S83-2) and further the operation element analysis part 517
(step S83-3).

[0178]The type element analysis part 515, which is a process part to
analyze a types element in an element tree for the purpose of generating
a type library, detects a types element indicative of a type definition
through analysis of an element tree and causes the XML schema analysis
part 514 to analyze the detected types element (step S84-1). Then, the
type element analysis part 515 informs the type library generation part
512 of the analysis result of the XML schema analysis part 514 (step
S85-1).

[0179]The message element analysis part 516, which is a process part to
analyze a message element in an element tree for the purpose of
generating a handler source code, reports the analysis result to the
handler source code generation part 513 (step S85-2). The operation
element analysis part 517, which is a process part to analyze an
operation element in an element tree for the purpose of generating a
handler source code, reports the analysis result to the handler source
code generation part 513 (step S85-3).

[0180]The type library generation part 512 is a process part to generate a
type library based on the analysis result reported from the type element
analysis part 515, and the generated type library is reported to the file
output part 530 (step S86-1). The handler source code generation part 513
generates a source code based on the analysis result reported from the
message element analysis part 516 and the operation element analysis part
517, and reports the generated source code to the file output part (step
S86-2). The file output part 530 outputs the source code 531 by
considering the source code reported from the handler source code
generation part 513 as a handler source code 532 and the type library
reported from the type library generation part 512 as the type library
533 (step S87).

[0181]In this fashion, the handler automatic generation apparatus 500,
when the interface definition 521 to define a Web service is input, can
automatically output the source code 531 of the handler process part.

[0182]Such a handler automatic generation apparatus 500 has a hardware
structure as illustrated in FIG. 18. FIG. 18 is a block diagram
illustrating a hardware structure of a handler automatic generation
apparatus according to one embodiment of the present invention.

[0183]Referring to FIG. 18, a handler automatic generation apparatus 500,
which is an apparatus to execute the handler automatic generation part
510 under control of a computer, has a CPU (Central Processing Unit) 551,
a memory unit 552, a display unit 553, an input unit 554, a storage
device 556 and a driver 557, and is connected to a system bus B.

[0184]CPU 551 controls the handler automatic generation apparatus 500 in
accordance with programs stored in the memory unit 552. The memory unit
552, which is configured as RAM, ROM and so on, stores programs executed
by CPU 551, data necessary for processes in CPU 551, and data obtained in
processes of CPU 551. In addition, a partial area of the memory unit 552
is allocated as a work area used for processes in CPU 551.

[0185]The display unit 553 displays various kinds of necessary information
under control of CPU 551. The input unit 554, which includes a mouse, a
keyboard and so on, is used to enable a user to input various kinds of
information necessary for the handler automatic generation apparatus 500
to perform processes. The storage device 556, for example, which is
configured in a hard disk unit, stores the interface definition 521 and
the source code 531, which are illustrated in FIG. 17, and data required
to generate the handler process part.

[0186]A program to implement an automatic generation process of the
handler automatic generation part 510 in the handler automatic generation
apparatus 500 is provided to the handler automatic generation apparatus
500, for example, through a recording medium 558 such as CD-ROM.
Specifically, when the recording medium 558 having the program is set in
the driver 557, the driver 557 reads the program from the recording
medium 558, and the read program is installed in a recording device 556
via the system bus B. Then, in response to activation of the program, CPU
551 starts a process in accordance with the program installed in the
recording device 556. Here, such a medium for storing the program is not
limited to CD-ROM, and may be any medium as long as the medium can be
read by a computer.

[0187]A description is given of an outline of a handler automatic
generation process executed by the handler automatic generation part 510.
FIG. 19 is a flowchart to explain the outline of the handler automatic
generation process. Referring to FIG. 19, the file input part 520 reads
the interface definition file 521 (step S501), and the XML analysis part
511 generates an element tree through analysis of an XML description
(step S502).

[0188]The handler automatic generation part 510 determines whether the
analysis is successful (step S503). If the analysis fails, an error is
displayed on the display unit 553 (step S504) and the handler generation
process is terminated. If the analysis is successful, the type library
generation part 512 generates a type library (step S505). Also, the
handler source code generation part 513 generates a handler source code
(step S506), and the handler generation process is terminated.

[0189]A detailed description is given of a type library generation process
(step S505) performed by the type library generation part 512. FIG. 20 is
a flowchart to explain a type library generation process. Referring to
FIG. 20, the type element analysis part 515 detects a types element from
an element tree reported from the XML analysis part 511 (step S511).

[0190]The type element analysis part 515 determines whether a types
element has been detected (step S512). If no types element is detected,
the type library generation process is terminated. On the other hand, if
a types element is detected, it is determined whether the types element
is an empty element (step S513). If the detected types element is an
empty element, the type library generation process is terminated. On the
other hand, if the detected types is not an empty element, it is
determined whether an external file has been imported (step S514). In
other words, it is determined whether the interface definition file 522
imports the type definition file 523 in FIG. 17. If no external file
(type definition file 523) is imported, the process control proceeds to
step S516. On the other hand, if an external file (type definition file
523) is imported, a schema definition file (type definition file 523) is
read (step S515).

[0191]The XML schema analysis part 514 analyzes XML schema of the
interface definition file 522 (step S516) and generates a source code
(step S517). Then, the file output part 530 outputs a type library 533
having a header file and a program file.

[0192]A description is given, with reference to FIG. 21 through FIG. 27,
of the source code generation process at step S517. First, a case where
the data type in a types element is defined as an enumeration type is
described. FIG. 21 is a diagram to explain an enumeration type definition
generation process in the source code generation process.

[0193]Referring to FIG. 21, an XML schema 601 is an exemplary XML
description of which data type is defined as an enumeration type. In a
tag simpleType description 602, the XML schema 601 is defined as a simple
data type having the name "SomeValueEnum". Furthermore, in a tag
restriction description 603, a description 604 is limited such that the
base type thereof is a string by "string" designated in base. In the
description 604, for example, three values "VALUE1", "VALUE2" and
"VALUE3" are listed as the string by an enumeration tag. In this case, it
is defined that the data type of the name "SomeValueEnum" has the three
strings.

[0194]A C code 701 is a C language source code generated from the XML
schema 601 to define a data type in the enumeration type. In the C code
701, a description 702 defines that "_SomeValueEnum" belongs to the
enumeration type based on the description 602, and a description 704 is
generated based on the descriptions 603 and 604. A description 704, in
which "SomeValueEnum_VALUE1", "SomeValueEnum_VALUE2" and
"SomeValueEnum_VALUE3" are listed, defines that the three strings are
included. Then, a description 705 defines that "SomeValueEnum" has the
same data type as "enum_SomeValueEnum".

[0195]In this fashion, the C code 701 can be generated from the XML schema
601 in which the enumeration type is described in a types element.

[0196]Next, a case where the data type in a types element is defined as a
structure is described. FIG. 22 is a diagram to explain a structure type
definition generation process in a source code generation process.

[0197]Referring to FIG. 22, the XML schema 611 is an exemplary XML
description whose data type is defined in a structure. The XML schema 611
is defined to be a compound data type having the name "SomeStruct" in a
tag complexType description 612. In a tag sequence description 613, the
order of data is prescribed. A tag element description 614 defines that
the structure member "strParam" is a string, and a tag element
description 615 defines that the structure member "intParam" is an
integer.

[0198]A C code 711 is a C language source code generated from the XML
schema 611 in which the data type is defined in form of structure. In the
C code 711, a description 712 defines that "_SomeStruct" is a structure
based on the description 612, and "char *strParam" in a description 714
and "int intParam" in a description 715 are generated based on the
descriptions 614 and 615. Then, a description 715 indicates that
"SomeStruct" defines the same data type as "struc_SomeStruct".

[0199]In this fashion, the C code 711 is generated from the XML schema 611
in which the structure is described in a types element.

[0200]Next, a case where the data type in a types element is defined in an
array is described. FIG. 23 is a diagram to explain an array type
definition generation process in a source code generation process.

[0201]Referring to FIG. 23, an XML schema 621 is an exemplary XML
description whose data type is defined in an array form. According to a
description 622 defined by a tag "complexType", the XML schema 621 is
defined as a compound data type having the name "ArrayOfString".
Furthermore, according to a description 624 defined by a tag
"restriction", "soapEnc:Array" designated in base limits the array to an
array in accordance with SOAP encoding. Also, according to a description
625 defined by a tag "sequence", the order of data in the description 626
is prescribed. According to a description defined by a tag "element", it
is defined that "item" is a string, can be omitted and has no upper bound
of the number of occurrence times. According to a description 627 defined
by a tag "attribute", "soapEnv:arrayType" is referred to, and an
attribute is defined such that the array type is an array of strings
according to "wsdl:arrayType="xs:string[ ]".

[0202]A C code 721 is a C language source code generated from the XML
schema 621 whose data type is defined in an array form. In the C code
721, a description 722 defines that "_ArrayOfString" is a structure based
on the description 622, and "int length;" indicative of the number of
elements in the descriptions 723 and 724 and "char **array;" being the
pointer of the array of "char*" in the description 715 are generated.
Then, a description 725 indicates that "ArrayOfString" defines the same
data type as "struct_ArrayOfString".

[0203]A description is given, with reference to FIG. 24 through FIG. 26,
of examples in which C language function declarations are generated based
on definitions of "simpleType" and "complexType" of a types element. In
FIG. 24 through FIG. 26, "Document" and "Element" in C language codes are
configured by mapping types defined in DOM (Document Object Model) to C
language structures. In FIG. 24 through FIG. 26, a serializer and a
deserializer are programs executed for conversion between an element tree
and structure data corresponding to each type. The serializer is a
program to convert structure data into an element tree, and the
deserializer is a program to convert an element tree into structure data.
Also, a constructor and a destructor are programs executed for generation
of structure data, and the destructor is a program to release structure
data.

[0204]FIG. 24 is a diagram to explain an enumeration type function
declaration process in a source code generation process. Referring to
FIG. 24, a serializer 801, which is indicated as "Element
*SomeValueEnum_serialize(Document *doc, char *tagName, SomeValueEnum
value);", receives an enumeration value "SomeValueEnum value" as an input
and generates and outputs an element (Element) whose tag name is
"tagname" in "char *tagname". Also, a deserializer 811, which is
indicated as "SomeValueEnum SomeValueEnum_deserialize(Element
*element);", receives an element (Element), analyzes the element, and
outputs an enumeration value.

[0205]The serializer 801 and the deserializer 811 are generated from the
XML schema 601.

[0206]FIG. 25 is a diagram to explain a structure function declaration
process in a source code generation process. Referring to FIG. 25, a
constructor 821, which is represented as "SomeStruct
*SomeStruct_create(char *strParam, int intParam);" receives a structure
member value as an input and generates and outputs a structure. A
destructor 831, which is represented as "viod SomeStruct_free(SomeStruct
*st);", receives a structure as an input and releases the used memory
area. Also, the destructor 831 recursively releases a memory area used by
a structure member. A serializer, which is represented as "Element
*SomeStruct_serialize(Document *doc, char *tagName, SomeStruct *st);",
receives a structure through "SomeStruct *st" as an input and generates
and outputs an element (Element) whose tag name is "tagname" through
"char *tagname". Also, a deserializer 851, which is represented as
"SomeStruct *SomeStruct_deserialize(Element *element);", receives an
element (Element) as an input, analyzes the element, and generates and
outputs a structure.

[0207]As a result, it is possible to set an input value in a structure
that a Web service function can process by using the deserializer 851 and
the constructor 821 on an element indicative of the input value described
in XML. Also, it is possible to set a process result corresponding to an
element described in XML by using the serializer 841 on a return value
from a Web service function (an output value as a process result).

[0208]The constructor 821, the destructor 831, the serializer 841 and the
deserializer 851 are generated from the XML schema 611.

[0209]FIG. 26 is a diagram to explain an array function declaration
process in a source code generation process. Referring to FIG. 26, a
constructor 861, which is represented as "ArrayOfString
*ArrayOfString_create(int length, char **array);", receives an array and
the size of the array as inputs and generates and outputs a structure
holding the array. A destructor 871, which is represented as "void
ArrayOfString_free(ArrayOfString st);", receives a structure holding an
array as an input and releases the used memory area. Also, the destructor
871 recursively releases a memory area that an array member uses. A
serializer 881, which is represented as "Element
*ArrayOfString_serialize(Document *doc, char *tagName, ArrayOfString
*st);", receives a structure holding an array through "ArrayOfString *st"
as an input and generates and outputs an element (Element) whose tag name
is "tagName" through "char *tagname". Also, a deserializer 891, which is
represented as "SomeStruct *SomeStruct_deserialize(Element *element);",
receives an element (Element) as an input, analyzes the element,
generates and outputs a structure holding an array.

[0210]Thus, it is possible to set an input value in an array that a Web
service function can process by using the deserializer 891 and the
constructor 861 on an element indicative of an input value described in
XML. Also, it is possible to set a process result corresponding to an
element described in XML by using the serializer 881 on a return value
from a Web service function (an output value as a process result).

[0211]The constructor 861, the destructor 871, the serializer 881 and the
deserializer 891 are generated from the XML schema 621.

[0212]Such a generated C language function declaration is supplied to a
header file of the type library 533. Also, each function process is
output to a program file.

[0213]A description is given, with reference to FIG. 27 and FIG. 28, of a
handler generation process of the handler automatic generation part 510.
FIG. 27 and FIG. 28 are flowcharts to explain a handler generation
process. Referring to FIG. 27, the handler automatic generation part 510
obtains a service name from a name attribute of a service element (step
S521). Then, a service element, a binding element and a porttype element
are accessed in that order to detect respective element (step S522).

[0214]An operation element, which is a child of the porttype element, is
searched for, and an operation name is obtained from the name attribute
(step S523). An input element, which is a child of the operation element,
is searched for, and an input message name is obtained from the name
attribute (step S524). An output element, which is a child of the
operation element, is searched for, and an output message name is
obtained from the name attribute (step S525). Then, a function
declaration of the handler process part and a Web service function (WSF)
is generated (step S526).

[0215]A message element of an input message is searched for (step S527). A
part element, which is a child of the message element, is searched for,
and a parameter name and a type are obtained from the name attribute and
the type attribute, respectively (step S528). Then, the type is mapped to
a C language type (step S529). It is determined whether there is another
part element (step S530). If there is another part element, the process
control returns to step S528, and the above process is repeated. On the
other hand, if there is no part element, the mapping of the input message
to a C language type is finished and an output message is mapped to a C
language type.

[0216]A message element of the output message is searched for (step S531).
A part element, which is a child of the message element, is searched for,
and a parameter name and a type are obtained from the name attribute and
the types attribute, respectively (step S532). Then, the type is mapped
to a C language type (step S533). It is determined whether there is
another part element (step S534). If there is another part element, the
process control proceeds to step S532 and the above process is repeated.
On the other hand, if there is no more part element, the mapping of an
output message to a C language type is finished.

[0217]Then, a structure definition of an input message is generated (step
S535). Also, a structure definition of an output message is generated
(step S536). A program of the handler process part is generated (step
S537). The structure definitions of the input message and the output
message are output to a header file, and the program of the handler
process part is output to a program file (step S538). Then, it is
determined whether there is another operation element (step S539). If
there is another operation element, the process control proceeds to step
S523, and the above process is repeated. If there is no more operation
element, the handler generation process is terminated.

[0218]A description is given, with reference to FIG. 29 and FIG. 30, of
exemplary descriptions of an interface definition file supplied to the
handler automatic generation part 510. FIG. 29 and FIG. 30 are diagrams
illustrating exemplary descriptions of an interface definition in WSDL.
Referring to FIG. 29 and FIG. 30, it is assumed that the data type
definition normally described by <type> tag is determined by the
type definition file 523 specified by "foo.bar.com/types.xsd". In this
exemplary description, a data type to describe a message is defined, and
the <type> tag to set a schema definition is omitted. In return,
import from "foo.bar.com/types.xsd" is conducted through a description
40.

[0219]In definition information 42 defined by a <message> tag 41
(description <message name="printInput">) to define a message
format, the description <part name="fileId" type="xs:unsignedInt"/>
and the description <part name="count" type="xs:unsignedInt"/>
define that an input parameter (printInput) for a print request is
configured from "fileId" of an unsigned integer (unsignedInt) and "count"
of an unsigned integer (unsignedInt). Also, in definition information 44
defined by a <message> tag 43 (description <message
name="printOutput">) to define a message format, the description
<part name="requestId" type="xs:unsignedInt"/> defines that an
output parameter for a print request (printOutput) is configured from
"requestId" of an unsigned integer (unsignedInt).

[0220]In definition information 46 defined by a <portType> tag 45
(description <portType name="netdocPortType">) to define a set of
operations ("operation"), an input message and an output message are
defined for each operation. For example, in definition information 48
defined by an <operation> tag 47 (description <operation
name="print">), the description <input
message="tns:printInput"/> defines that the input-message is
"printInput". Also, the description <output
message="tns:printOutput"/> defines that the output message is
"printOutput". In this case, only print is defined.

[0221]In definition information 50 defined by a <binding> tag 49
(description <binding name="netdocHTTPBinding"
type="tns:netdocPortType">) to map an operation and a message defined
by a <portType> tag 45 to specific protocol and data format, the
operation and message are mapped to the protocol and data format for a
porttype defined by "netdocPortType".

[0223]First, the <sb:operation> tag 53 (description <sb:operation
soapAction="http://foo.bar.com/netdoc/print"/>) is used to define that
the SOAPAction header value is "http://foo.bar.com/netdoc/print" at the
print request time.

[0224]Then, in definition information 55 defined by an <input> tag
54, the description <sb:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"
namespace="http://foo.bar.com/netdoc/"/> is used to define the
encoding format at input time, and in definition information 57 defined
by an <output> tag 56, the description <sb:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" use="literal"
namespace="http://foo.bar.com/netdoc/"/> is used to define the
encoding format at output time.

[0225]Then, in definition information 59 defined by a <service> tag
58 (description <service name="netdoc">) to define a collection of
network end points, a <port> tag 60 (description <port
name="netdocPort" binding="tns:netdocHttpBinding">) is used to define
"netdocPort" being one of the network end points, and furthermore, the
description <sb:address
location="http://printer.foo.bar.com/netdoc"/> is used to define the
address location of the network end point. In other words, it is defined
that binding of the service name "netdoc" is "netdocHttpBinding", and the
service URL (Uniform Resource Locator) is
"http://printer.foo.bar.com/netdoc".

[0226]According to the interface definition file 522 and type definition
file 523 defined in WSDL in this fashion, it is possible to determine not
only the data type and the operation but also URL and the SOAPAction
header.

[0227]A description is given of, in a case where an interface definition
has been input, function declaration of a handler process part and a Web
service function and structure definitions of an input message and an
output message. First, the function declaration of the handler process
part and the Web service function generated at step S526 in FIG. 27 is
described with reference to FIG. 31 and FIG. 32.

[0228]FIG. 31 is a diagram to explain function declaration of the handler
process part. Referring to FIG. 31, in the function declaration of the
handler process part, for example, "netdoc_print_handler" configured from
"netdoc" indicative of a service name, "print" indicative of an operation
name, and "handler" indicative of the handler process part is used as the
function name, and the function is declared as a function of the handler
process part. In this example, "netdoc_print_handler" is used to indicate
a handler process part corresponding to the service to perform a print
operation. The function declaration of the handler process part is output
to a header file of the handler source code 532.

[0229]FIG. 32 is a diagram to explain the function declaration of a Web
service function. Referring to FIG. 32, in the function declaration of a
Web service function, for example, "netdoc_print" configuring from
"netdoc" indicative of a service name and "print" indicative of an
operation name is used as a function name, and the function name is
declared as a function of the Web service function. Also, an argument of
the function of the Web service function designates a structure of an
input message by "Netdoc_printInput" configuring from "Netdoc" indicative
of a service name and "printInput" indicative of the name of the input
message. Also, a structure of an output message is designated by
"Netdoc_printOutput" configuring from "Netdoc" indicative of a service
name and "printOutput" indicative of the name of the output message. The
function declaration of the Web service function is output to a header
file of the handler source code 532.

[0230]A description is given, with reference to FIG. 33, of a structure
definition of an input message generated at step S535 in FIG. 28. FIG. 33
is a diagram to explain a structure definition of an input message.
Referring to FIG. 33, a structure of an input message defines, for
example, "_Netdoc_printInput" configuring from "netdoc" indicative of a
service name and "printInput" indicative of an input message as a
structure. Also, the structure "_Netdoc_printInput" is configured from
the parameter name "fileId" whose parameter type is set as an unsigned
integer by using "unsigned int" and the parameter name "count" whose
parameter type is set as an unsigned integer by using "unsigned int". The
structure of an input message is output to a header file of the handler
source code 532.

[0231]A description is given, with reference to FIG. 34, of a structure
definition of an output message generated at step S536 in FIG. 28. FIG.
34 is a diagram to explain a structure definition of an output message.
Referring to FIG. 34, a structure of an output message is defined as
"_Netdoc_printOutput" configured from "netdoc" indicative of a service
name and "printOutput" indicative of an output message. Also, the
structure "_Netdoc_printOutput" is configured from a parameter name
"requestId" whose parameter type is set as an unsigned integer by using
"unsigned int". The structure of an output message is output to a header
file of the handler source code 532.

[0232]A description is given, with reference to FIG. 35, of an exemplary
program of the handler source code 532 that is automatically generated
based on the interface definition shown in FIG. 29 and FIG. 30. FIG. 35
is a diagram illustrating an exemplary automatically generated handler
source code. Referring to FIG. 35, process outline of individual steps is
shown instead of an actual source code.

[0233]As shown in a description 901, a declared function name, as
illustrated in FIG. 31, of the handler process part is first described in
the handler source code as illustrated in FIG. 35. This handler process
part is a handler for a print function as a Web service function.
Hereinafter, a print handler is referred to. The codes between steps S120
and 5131 are for analyzing a SOAP envelope indicative of a process
request based on an element tree. Also, the codes between steps S140 and
148 are for generating an element tree to generate a SOAP envelope
indicative of a process response.

[0234]After a description of a variable defined in the print handler
locally, step S120 for the print handler to obtain a route element is
described. As an execution result of step S120, a root element (Envelope
element) is obtained. Step S121 to obtain a child node list is described.
As an execution result of step S121, the print handler can obtain
"Header" and "Body" from an element tree.

[0235]Step S122 to obtain an element whose tag name is "Body" from the
child node list is described. Step S123 to obtain a first child node of
the Body element is described. As an execution result of step S123, the
print handler obtains a print element indicative of an operation name.
Step S124 to obtain a child node list of the print element is described.
Step S125 to obtain tag names from the obtained child node list
sequentially (iterative determination is set as step S132) is described.

[0236]Step S126 to determine whether a tag name is "fileID" is described.
If a tag name is "fileID", step S127 to obtain a first child node having
the tag name "fileID" is described. As an execution result of step S127,
the print handler obtains a text node. Step S128 to extract text data
from the obtained text node and convert the text data into an integer is
described. As an execution result of step S128, the print handler sets
the value in a predefined structure as a file ID parameter.

[0237]Step S129 to determine whether the tag name is "count" is described.
If the tag name is "count", step S130 to obtain the first child node
having the tag name "count" is described. As an execution result of step
S130, the print handler obtains a text node. Step S131 to extract the
obtained text node and convert the text node into an integer is
described. As an execution result of step S131, the print handler sets
the value as a print quantity parameter in a predefined structure.

[0238]A description 902 between steps S126 and S131 is an example of the
print handler. However, in other handlers, the determination for each tag
name and the process for tag names are different depending on parameter
definitions of an input message.

[0239]Step S133 to generate each parameter value obtained through
execution of the description 902 as structure data of an input message
and set the parameter value in the data name "in" is described.

[0240]Step S134 to call a function "netdoc_print(in, out), as illustrated
in FIG. 32, of a Web service function declared, whose argument is the
structure data of an input message, is described.

[0241]In execution of step S134, it is determined whether the return value
is erroneous. If the return value is erroneous, step S135 to set
"SOAPFault" in "responseDocument" is described.

[0242]In the following steps S140 through S148, steps to generate an
element tree to generate a process response in a case where no error
occurs in the execution of the function "netdoc_print(in, out)" of the
Web service function are described.

[0243]Step S140 to generate an Envelope element is described. Step S141 to
generate a Body element is described. Step S142 to connect the Body
element to the Envelope element is described. Step S143 to generate a
printResponse element is described. Step S145 to generate a requestId
element is described. Step S146 to connect the printResponse element to
the Body element is described.

[0244]Step S147 to generate a text node by using a request ID obtained as
an execution result of step S134 is described. Step S148 to connect the
text node to the requestId element is described.

[0245]Step S149 to use "responseDocument" indicative of a process result
of the print handler as a return value is described.

[0246]The handler source code 532 described in this manner is not limited
to the print handler, and can be generated by associating the same steps
to other operations. Thus, the operation name "print" in the handler
source code can be changed depending on definitions.

[0247]In this fashion, since automatic generation of the handler source
code 532 makes it possible to generate a large number of simple and
similar codes, it is possible to eliminate a problem that bugs may be
included due to simple mistakes of developers. In addition, since it
takes fewer hours to generate the handler source code 532, it is possible
to reduce workloads on developers. Furthermore, developers can develop a
Web service function without consciousness of differences between a data
format of an XML message and a data format that can be processed in a
program language in the Web service function.

[0248]As mentioned above, by using the handler automatic generation part
510, the handler source code 532 and the type library 533 automatically
generated corresponding to each function of Web service functions
together with source codes configuring necessary process parts as well as
functions of Web service functions are compiled based on the interface
definition 521.

[0249]As described above in the third embodiment, according to the present
invention, a program to convert a data format of a message in accordance
with a message communication protocol between devices is automatically
generated. Thus, it is possible to eliminate the problem that bugs may be
included due to simple mistakes of developers. In addition,
implementation of such an automatically generated program in an image
forming apparatus makes it possible to process the message even if the
Web service function is developed in a conventional method. Thus, it is
possible to easily develop a Web service function in an image forming
apparatus. Also, it is possible to widen cooperation with other systems
connectable to the image forming apparatus.

[0250]According to a program generation method of the present invention, a
computer can be configured to execute an element tree generation step of
analyzing an interface definition to define an interface of a Web service
and generating a first element tree indicative of association between a
plurality of elements configuring the interface definition and a
conversion program generation step of generating a conversion program to
perform a conversion process on request and response messages on the Web
service described in an input and output data format processable by a Web
service function to execute the Web service and a predefined description
format.

[0251]Also, the conversion program generation step can be configured to
have a first program generation step of generating a data type conversion
program to perform conversion between the input and output data format
processable by the Web service function and an input and output message
set in the request and response message described in the predefined
description format and a second program generation step of generating a
second program to analyzing the request message described in the
predefined description format and generating the response message.

[0252]According to a recording medium for storing a computer readable
program of the present invention, recording medium for storing a computer
readable program to cause a computer to execute an element tree
generation step of analyzing an interface definition to define an
interface of a Web service and generating a first element tree indicative
of association between a plurality of elements configuring the interface
definition and a conversion program generation step of generating a
conversion program to perform a conversion process between an input and
output data format processable by a Web service function to execute the
Web service and request and response messages on the Web service
described in a predefined description format based on the first element
tree.

[0253]Also, a recording medium as claimed in claim 11, characterized in
that the conversion program generation step has a first program
generation step of generating a data type conversion program to perform
conversion between the input and output data format processable by the
Web service function and an input and output message set in the request
and response messages described in the predefined description format and
second program generation step of generating a second program to analyze
the request message described in the predefined description format and
generate the response message.

Fourth Embodiment

[0254]In the following, a description is given of an embodiment of the
multifunctional product 1200 as an image forming apparatus in which the
automatically generated handler process part explained in the third
embodiment is incorporated.

[0255]In a fourth embodiment, the multifunctional product 1200 has the
same functional structure and the same hardware structure as those of the
first embodiment, and the description thereof is omitted.

[0256]Then, a detailed description is given of a structure that can
provide a Web service in accordance with SOAP (Simple Object Access
Protocol) in XML (eXtensible Markup Language) in the multifunctional
product 1200. The Web service function is, for example, a software
product (application) described in a program language such as C language.
A process part (handler) for handling between XML and a program language
having different syntaxes is required so that the Web service function
can understand XML process contents described in SOAP as a message. In
the following, a print Web service for printing, a document list
acquisition Web service to acquire a document list, and a document
information acquisition Web service to acquire document information are
exemplified with reference to FIG. 36.

[0257]FIG. 36 is a diagram illustrating an exemplary structure to
implement a Web service. Referring to FIG. 37, a print Web service, a
document list acquisition Web service and a document information
acquisition Web service are provided in the Web service application 1218.
These services may be independent of the Web service application 1218 as
other functions of the application 1230. In FIG. 36, only main functional
components of the multifunctional product 1200 are illustrated, and the
description thereof is omitted.

[0258]Referring to FIG. 36, for the purpose of implementation of a Web
service, an intermediate layer for controlling transmission and receipt
of data between connected devices is provided between the control service
1250 and the Web service application 1218.

[0259]The control service 1250 has ECS 1224, MCS 1225 and NCS 1228 as
components to implement a Web service provided by the Web service
application 1218. NCS 1228 has an HTTP daemon 2 to control HTTP and a
request mediation daemon 7 to mediate a connection process between the
HTTP daemon 2 and the Web service application 1218.

[0260]Also, the intermediate layer 1255, which is a component to absorb
transmission and receipt control of data between connected devices, has a
sequence control library 100, an XML library 110, a SOAP library 120, a
job management part 310 and a file management part 311. The sequence
control library 100 further has an HTTP connection management part 101,
an HTTP service execution part 102 and a POST method distribution process
part 105. The XML library 110 has an XML process part 115, an XML
processor 116 and an XML serializer 117. The SOAP library 120 has a SOAP
action distribution process part 121.

[0261]Furthermore, the Web service application 1218, which is a component
to implement a Web service, has an element tree analysis and generation
handler 200 and a Web service function (WSF) 300. The element tree
analysis and generation handler 200, which is a process part to analyze a
syntax in accordance with a data format of a message in compliance with
SOAP between devices and perform conversion into a data format
processable in the Web service function 300, has a plurality of element
tree analysis and generation handlers such as a print handler 201, a
document list acquisition handler 202 and a document information
acquisition handler 203. It is noted that each of the print handler 201,
the document list acquisition handler 202 and the document information
acquisition handler 203 is a handler process part based on a handler
source code 532 and a type library 533 of a source code 531 automatically
generated by the handler automatic generation part 510 shown in FIG. 17
according to the third embodiment.

[0262]The Web service function 300 has a plurality of Web service
functions such as a print function 301, a document list acquisition
function 302 and a document information acquisition function 303. In this
case, the print handler 201 performs syntax analysis on a data format of
a SOAP message indicative of process contents for the print function 301,
converts the data format into another data format processable by the
print function 301, and requests the print function 301 to perform a
process. Also, the print handler 201 generates a response as a message in
the data format in accordance with SOAP. The document list acquisition
handler 202 and the document information acquisition handler 203 perform
similar processes on the document list acquisition function 302 and the
document information acquisition function 303, respectively.

[0263]The print function 301 receives a file ID and a print quantity as
input parameters, designates the job management part file ID and the
print quantity, and issues a print request to the job management part
310. The print function 301 returns a request ID received from the job
management part 310 as an output parameter. The document list acquisition
function 302 requests the file management part 311 a file list and
returns an ID list received from the file management part 311 as an
output parameter. The document information acquisition function 303
receives a file ID as an input parameter, designates the file ID in the
file management part 311 and requests file information. The document
information acquisition function 303 returns the file information
received from the file management part 311 as an output parameter.

[0264]The job management part 310 manages a queue and execution results of
jobs. Also, the management part 310 communicates with ECS 1224 and MCS
1125 to perform print processes on stored documents. The file management
part 311 communicates with MCS 1225 to obtain file information.

[0265]A description is given, with reference to FIG. 37 and FIG. 38, of a
process from receipt of an HTTP request to transmission of an HTTP
response. FIG. 37 and FIG. 38 are a flowchart to explain a process to
provide a Web service in SOAP.

[0266]The HTTP daemon 2 of NCS 1228 receives a connection request from the
network 15 (step S1100). The connection request is reported to the HTTP
connection management part 101 of the Web service application 1218 via
the request mediation daemon 7. Then, the HTTP connection management part
101 reports the connection request to the HTTP service execution part 102
to provide a service in accordance with HTTP. In response to the report,
the HTTP service execution part 102 establishes connection with the HTTP
daemon 2 and acquires an HTTP request. Such control by NCS 1228 makes it
possible to control HTTP communication only as needed. Thus, it is
possible to utilize resources required for communication control more
effectively compared to a case where the HTTP communication is under
full-time control.

[0267]The HTTP service execution part 102 analyses an HTTP method
indicative of a data transmission method based on the HTTP request
received via the network 15 and checks whether the HTTP method is for a
GET method (step S1101). If the HTTP method is for a GET method, the HTTP
service execution part 102 provides a Web service in accordance with the
GET method (step S1102). In other words, the HTTP service execution part
102 is used to provide Web services other than Web services in accordance
with SOAP.

[0268]On the other hand, if the HTTP method is not for the GET method, the
HTTP service execution part 102 checks whether the HTTP method is for a
POST method (step S1103). If the HTTP method is not for a POST method,
the process control proceeds to step S1107 for an error process and the
process to provide a Web service in accordance with SOAP is terminated.
If the HTTP method is for a POST method, the POST method distribution
process part 105 is called. The POST method distribution process part 105
analyzes HTTP request header information and checks whether the
description format of the HTTP body follows XML (S1104). In other words,
the POST method distribution process part 105 determines whether
"text/xml" is designated in "Content-Type" of the HTTP response header.
If the description format is not XML, the process control proceeds to
step S1107 for an error process. On the other hand, if the description
format is XML, an XML content handler 111 is called.

[0269]The XML process part 115, which serves as a POST method handler,
uses an XML processor 116 to analyze an XML syntax of the HTTP body and
generate a request element tree to represent a relation of tags described
in XML as a tree structure (step S1105). The XML process part 115
determines whether a result of the syntax analysis includes an error
(step S1106). If the syntax analysis result includes an error, the
process control proceeds to step S1107 for an error process. On the other
hand, if the syntax analysis result has no error, the process control
proceeds to step S1109 in FIG. 38.

[0270]The SOAP action distribution process part 121 analyzes a SOAPAction
header of the HTTP request and distributes the HTTP request to a
different element tree analysis and generation handler 200 by means of
URI (Uniform Resource Indicator) (step S1109). In this case, the HTTP
request and the element tree are distributed to the print handler 201 by
designating URI to specify a print Web service, the document list
acquisition handler 202 by designating URI to specify a document list
acquisition Web service and the document information acquisition handler
203 by designating URI to specify a document information acquisition Web
service.

[0272]The Web service function 300 executes logic of a predefined Web
service and returns a result as structure data (step S1112). In this
case, the print function 301, the document list acquisition function 302
and the document information acquisition function 303 execute logic of
respective Web services and return results. The results are in data
formats processable in a program language (such as structures in C
language).

[0273]Each element tree analysis and generation handler 200 generates an
element tree of a response from the resulting structure data (step
S1113). Such an element tree generated by each element tree analysis and
generation handler 200 represents a data structure in which a relation
between XML tags is described through links using pointers from a tag to
another tag. After that, the XML serializer 117 converts the response
element tree into XML through the SOAP action distribution process part
121. The XML serializer 117 converts the element tree into text-based
XML. The converted XML is configured in the HTTP body in accordance with
SOAP, and after attachment of a predefined HTTP header, the resulting XML
is transmitted as an HTTP response (step S1114).

[0274]As mentioned above, the element tree analysis and generation handler
200 performs data conversion corresponding to C language structures on
element trees. In addition, the element tree analysis and generation
handler 200 converts C language structure data into element trees. A
developer can develop a Web service in a program language without
knowledge of SOAP and XML.

[0275]In an initialization process performed by the Web service function
300 at activation time thereof, modules are connected (as illustrated in
solid lines), and a configuration as illustrated in FIG. 36 is formed. In
the initialization process, the POST method distribution process part 105
is activated by being connected to the sequence control library 100 as a
POST method handler, and the XML process part 115, the SOAP action
distribution process part 121 and the element tree analysis and
generation handler 200 are registered to the POST method distribution
process part 105, the XML process part 115 and the SOAP action
distribution process part 121, respectively.

[0276]A description is given, with reference to FIG. 39 through FIG. 41,
of an analysis process of an element tree in the print handler 201 of the
element tree analysis and generation handler 200 as an example. FIG. 39
is a diagram illustrating an exemplary description of an HTTP request in
accordance with SOAP using XML. FIG. 40 is a diagram illustrating an
exemplary description of an element tree converted by the XML processor.
FIG. 41 is a flowchart to explain an element tree analysis process by the
print handler.

[0277]In a case of an HTTP request, as illustrated in FIG. 39, for a print
Web service, the XML processor 112 converts an HTTP body starting with
<SOAP-ENV:Envelope> into an element tree. A tag name 21 "Envelope"
is set as a root element, and a tag name 22 "Header" and a tag name
"Body" are associated as child nodes of the root node with the tag name
21 "Envelope". Furthermore, a child node of the tag name "Body" is named
as a tag name 24 "print", and in addition, a tag name 25 "fileId" and a
tag name 26 "count" are associated as child nodes of the tag name 24
"print" with the tag name 24 "print". Then, the tag name 25

[0278]"Meld" and the tag name 26 "count" are associated with text data 27
"123" and text data 28 "2", respectively. The structure of an element
tree associated in this manner is formed, for example, as a data
structure as illustrated in FIG. 40. In FIG. 40, the tag names 21 through
26 and the text data 27 and 28 are represented as ellipses, and the
association is represented by arrows.

[0279]For an element tree having a data structure as illustrated in FIG.
40, the print handler 201 generates structure data in a program language
processable by the print function 301 in accordance with the flowchart
shown in FIG. 41. In FIG. 41, step numbers correspond to step numbers in
FIG. 35. Referring to FIG. 41, the print handler 201 obtains a root
element (step S120). In this case, the root element becomes an Envelope
element. The print handler 201 obtains a child node list (step S121). In
other words, the tag name 22 "Header" and the tag name 23 "Body" are
obtained. The print handler 201 searches the child node list for an
element having the tag name "Body" and obtains a Body element (step
S122). The print handler 201 obtains a first child node of the Body
element (step S123). In this case, the print handler 201 obtains a print
element. The print handler 201 obtains a child node list of the print
element (step S124). The print handler 201 obtains tag names from the
child node list sequentially (step S125).

[0280]The print handler 201 determines whether a tag name is "fileID"
(step S126). If the tag name is not "fileID", the process control
proceeds to step S129. On the other hand, if the tag name is "fileID",
the print handler 201 obtains a first child node having the tag name
"fileID" (step S127). In other words, a text node is obtained. The print
handler 201 extracts the obtained text node and converts the text node
into an integer (step S128). In other words, the value "123" is set as a
file ID parameter in a predefined structure. In addition, the print
handler determines whether the tag name is "count" (step S129). If the
tag name is not "count", the process control proceeds to step S132. On
the other hand, if the tag name is "count", the print handler 201 obtains
a first child node having the tag name "count" (step S130). In other
words, a text node is obtained. The print handler 201 extracts the
obtained text node and converts the text node into an integer (step
S131). In other words, the value "2" is set as a print quantity in a
predefined structure.

[0281]The print handler 201 determines whether the next child node is
included in the child node list obtained at step S125 (step S132). If the
next child node is included, the process control returns to step S125 to
obtain the next child node, and the same process is performed on the next
child node. If the next child is not included, the analysis process on
the element tree is terminated.

[0282]In such an element tree analyzed in this manner, the print handler
201 sets a value in a parameter of a structure in a program language, as
illustrated in FIG. 42. FIG. 42 is a diagram illustrating an exemplary
argument setting to a function of a Web service function. Referring to
FIG. 42, the value "123" is set in the parameter "unsigned int fileId" of
a structure 29 ("struct Netdoc_printInput") at step S128. Also, the value
"2" is set to the parameter "unsigned int count" at step S131.

[0283]Since the print function 301 of the Web service function 300 is a
"netdoc_print" function declared as a function of a Web service function
by the handler automatic generation part 510 (see FIG. 32), the structure
name "struct Netdoc_printInput" of the structure 29 defined as a
structure of an input message by the handler automatic generation part
510 and the pointer "in" to the structure 29 are set in the argument 30,
as "struct Netdoc_printInput *in". When the print function 301
("netdoc_print" function) is called, a process result of the print
function 301 is returned, for example, as an argument 31 such as "struct
Netdoc_printOutput *out" indicative of the pointer "out" to the structure
name "struct Netdoc_printOutput".

[0284]FIG. 43 is a diagram illustrating an exemplary setting of a process
result by the print handler. Referring to FIG. 43, the print handler 201
obtains a structure 39, to which the process result is to be set, through
the pointer "out" of the argument 31. The structure 39 is a structure
defined as a structure of an output message by the handler automatic
generation part 510 (see FIG. 34). In the structure 39, for example, the
value "100" is set to the parameter "unsigned int requestId" as a process
result.

[0285]A description is given, with reference to FIG. 44 and FIG. 45, of a
element tree generation process to generate an element tree from the
structure 39 indicative of a process result. In FIG. 44, step numbers
correspond to step numbers in FIG. 35. FIG. 44 is a flowchart to explain
an element tree generation process by the print handler. FIG. 45 is a
diagram illustrating an exemplary generated element tree.

[0286]An element tree generation process by a print handler is described
with reference to FIG. 45. Referring to FIG. 44, the print handler 201
generates an Envelope element 32 (step S140). The print handler 201
generates a Body element 33 (step S141). Then, the Body element 33 is
connected to the Envelope element 32 (step S142). Through these steps
S140 through 5142, an HTTP body of an HTTP response in accordance with
SOAP is set.

[0288]The print handler 201 generates a text node 36 from the obtained
request ID (step S147), and the text node is connected to the requestId
element 35 (step S148). In this case, the value "100" is set in the text
node 36.

[0289]For such an element tree generated in this manner, the XML process
part 115 and the XML serializer 112 is used to generate an HTTP body 32
as illustrated in FIG. 46. FIG. 46 is a diagram illustrating an exemplary
description of an HTTP response in accordance with SOAP using XML
converted from the element tree. Referring to FIG. 46, the individual
elements 32 through 36 are described within tags delimited by < >,
and predefined information is described in XML in accordance with a
predefined procedure in compliance with SOAP. The multifunctional product
1200 transmits the HTTP response to a device transmitting the
corresponding HTTP request by means of the HTTP daemon 2 via the network
15. In this fashion, the multifunctional product 1200 provides a Web
service to a device connected via the network 15.

[0290]According to the above embodiment, a source code 531 to convert an
element tree indicative of a relation between elements in XML into input
data in a program language processable by a Web service function and
convert output data in a program language into an element tree in a
predefined description format is automatically generated. As a result,
since a large number of simple and similar codes can be generated, it is
possible to eliminate the problem that bugs may be included due to simple
mistakes of developers. In addition, since the handler source code 532
can be generated fewer hours, it is possible to reduce workloads on
developers.

[0291]In addition, through incorporation of the element tree analysis and
generation handler 200 of the automatically generated source code 531
into the multifunctional product 1200, developers can develop an
application as a Web service function in a conventional development
method, such as in a development method using C language. In addition, it
is possible to easily improve an installed application such that the
application can correspond to a Web service.

[0292]In addition, in the multifunctional product 1200 having the element
tree analysis and generation handler 200, since the Web service function
300 developed as a program can interpret an XML message in accordance
with SOAP, it is possible to provide the Web service function 300 to
other systems. As a result, since systems or computer terminals connected
to the multifunctional product 1200 are not limited, it is possible to
considerably widen availability of the multifunctional product 1200.

[0293]As described above with respect to the fourth embodiment, according
to the present invention, since a process part to convert the data format
of a message in accordance with a message communication protocol between
devices is provided, the message can be processed even by a Web service
function developed in a conventional method. Thus, it is possible to
easily develop a Web service function for an image forming apparatus
without dependence on the description format of a message. Also, an
installed application can be modified to correspond to a Web service.
Furthermore, it is possible to widen cooperation with other systems
connectable to the image forming apparatus.

[0294]Although the preferred embodiments of the present invention have
been described above, the present invention is not limited to the
embodiments. Various variations and modifications can be made within the
scope of features of the present invention.

[0295]The multifunctional product 1200 according to the present invention
can be configured to have a plurality of conversion means for converting
a request message received in accordance with a predefined message
communication protocol corresponding to respective Web service process
means into a process request processable by the Web service process means
and converting the process result produced by the Web service process
means into a response message in accordance with the message
communication protocol.

[0296]Also, the multifunctional product 1200 according to the present
invention can be configured to describe a request message and a response
message in an Extensible Markup Language in accordance with Simple Object
Access Protocol.

[0297]Furthermore, a second data format processable in a program language
and a third data format indicative of a process result output by the Web
service process means can be configured to represent a structure
processable in C language.

[0298]Also, the multifunctional product 1200 according to the present
invention can be configured to have connection control means for, by
informing communication control means for controlling communication in
accordance with a redefined communication protocol and connection
management means via the network that a process request has been
received, controlling connection between the communication control means
and the service providing means for causing the Web service process means
to execute a process in the predefined communication protocol based on
the process request and to provide the process result as a process
response to the device.

[0299]In addition, the predefined communication protocol can be configured
to be Hypertext Transfer Protocol.

[0300]Also, the multifunctional product 1200 according to the present
invention can be configured to have an application having the plurality
of Web service process means, a control service to manage a plurality of
hardware resources used in the image forming apparatus and control use of
the plurality of hardware resources corresponding to a use request from
the application and an operating system to control the application and
the control service.

[0301]The multifunctional product 1200 according to the present invention
has a first message conversion step of converting the request message
into a first data format indicative of the structure of the request
message, and the conversion step has a first data format conversion step
of corresponding the first data format to a second data format
processable in a program language whereby the Web service process step is
developed.

[0302]In a Web service providing method executed in the multifunctional
product 1200 according to the present invention, a first message
conversion step of converting a request message into a first data format
indicative of the structure of the request message can be configured to
generate an element tree based on an element forming the request message
from the request message and a value set for the element and set the
element tree as the first data format.

[0303]Also, in such a Web service providing method, the first data format
conversion step can be configured to set a value to an element of the
second data format processable in the Web service process step by
traversing a link between the elements of the element tree.

[0304]Furthermore, the Web service providing method can be configured to
have a second data format conversion step of converting a third data
format indicative of a process result of a Web service, which is
processable in the predefined program language, produced by the Web
service step and a second message conversion step of describing the
response message in a description format receivable by the device based
on a structure of the response message represented in the fourth data
format.

[0305]Also, in the Web service providing method, the second data format
conversion step can be configured to generate an element tree based on a
value set to an element of the third data format as the process result
and a plurality of elements configuring the response message and set the
element tree as the fourth data format.

[0306]Although the preferred embodiments of the present invention have
been described above, the present invention is not limited to the
embodiments, and various variations and modifications can be made within
the scope of features of the present invention.