The Web service paradigm is an XML-centric application infrastructure. It takes services as the network-addressable entities, describes them in a universal manner (WSDL) in order that they can be discovered (UDDI) and orchestrated into reusable and efficient service-based applications via common communication protocols (SOAP). With Web services, software applications can integrate with previously incompatible systems by creating a layer of abstraction around existing software. This promising technology helps build more efficient Internet applications and thus more productive business relationships.

However, they can increase the cost and difficulty of constructing and maintaining a reliable software system, because these service components are loosely coupled and need to accommodate the evolving Internet and associated standards. Though various approaches have been proposed in this area [1] [2], developers still need to address numerous technical issues when implementing Web service applications, including:

These, coupled with an application strategy that binds service searching, system monitoring, fail-over and security support into the processing logic, result in code recompilation and high maintenance costs as the systems grow and multiply.

To eliminate redundant development of these infrastructure services, an alternative application strategy is proposed to build a generic framework [3] [4]. The generic framework architecture separates the application logic from the implementation and introduces a declarative language to specify the application logic [4] [8]. Since the framework provides implementation infrastructure for the communication management, security services and resource management, developers can focus on the processing logic required by their applications.

There have been a number of concrete proposals for the processing control language, such as the Web Service Flow Language (WSFL) from IBM, the WebL language from Compaq, the XLANG from Microsoft, XML Variant Configuration Language (XCVL) proposed by Wong[9] and XL proposed by Florescu[4]. Are any of these sufficient?

Before making a judgment, let’s examine the requirements in context. In this paper, we will investigate the generic framework; analyze its requirements and those of an associated control language.

This rest of the paper is organized as follows.

Before analyzing the generic application framework, let’s look at a common software component implementation. Figure 1 shows the diagram of the design model, where developers hardcode the software to realize the application logic.

Figure 1. Software Components with Hard-coded Logic

Though there are various tools to speed up the development with this type of design, it is hard to reuse components in other applications or modify the hard-coded processing logic as application requirements evolve or change context. This model also saddles the developers with the low-level implementation details.

As the need to develop software in heterogeneous and adaptive environments increases, such as in the Web services paradigm, applications must maintain high quality with accelerated development cycles. To accomplish this, not only must the application data and schema be abstracted, we propose the application logic and processing model must as well.  This permits component code to be written once yet re-used many times to improve the productivity and quality. 

Figure 2 illustrates a generic framework model where the software component implementation is separate from the application logic. In this design model, the processing logic is specified in a description language rather than the hard-code implementation.

Figure 2. Software Component with Declarative Processing Logic

Because the processing logic is extracted from the framework and described in declarative manner, the component objects can be easily reorganized for different processing purposes, even at run time, as shown in Figure 3, We can also reuse these component objects in a variety of application contexts thus eliminating redundant development and improving code quality.

Figure 3. Software Component driven by Processing Control Description

To implement such software components following the generic framework architecture, we need:

As shown in Figure 4, the framework processor should be able to compile the control document, take the processing instructions to upload the proper software objects and apply the specified processing logic. In addition, it should fetch the input resources to the Input Resources Repository and supply them to the software objects.

Figure 4. Framework Architecture

Within the generic framework, the framework processor is designed to manage the service components and provide infrastructure services such as component deployment, system logging, error handling, workload management and performance tuning.

The FCML document specifies the processing metadata information used by the framework system and declares the proper system responses. Developers design the application logic by explicitly describing it through the application process language expressed in the FCML document.

As presented, the framework infrastructure is designed for large and heterogeneous software systems supporting dynamic updates and evolutionary changes. To deliver this functionality, we propose to abstract the processing logic along with the resources into a declarative syntax. Thus, we need a high-level descriptive processing control language, which is:

We propose that these requirements are best met using an XML-based language instead of a statement-based one[4]. Lets call our candidate framework control markup language FCML as we examine XML’s suitability

First, XML [11] has been widely used for describing network services (WSDL, UDDI) and procedure structure (XLANG, WSFL). It has proven sufficient in representing the application logic.

Second, using an XML format, an FCML document, is inherently standards-based and can be processed reliably with the existing standards-conforming components Floreseu’s paper[4] presents a compelling proposal of a declarative XML programming language in XL. However, since the proposed language itself is not XML-based, it requires an extra complier eliminating the possibility of using the standards-based XML processing utilities and associated XML technologies, which we show the value later.

Third, an XML-based language is more extensible than a functional programming languages based on statement expressions as [4], which requires coding changes and re-compilation for updates and changes. As an example, simply adding an attribute can extend or modify current processes. Also, XML Namespaces can be used to identify and introduce new processes as supported . This XML fragment illustrates how the “SOAP:” namespace prefix is bound to the soap messaging logic.

<processSet>
    <sequence>
      <process name="packMesg.p">
        <input name="inPkMessage" type="java:String"/>
        <output name="outPkMessage" type="soap:Message"/>
      </process>
      <process name="sendMesg.p">
        <input name="outPkMessage" type="soap:Message"/>
      </process>
    </sequence>
  </processSet>

In addition to identify the FCML document with the name in Unique Resource Identifier (URI), we can associate each FCML document with a “targetNamespace” to identify the domain of the application logic definitions. This enables sharing and reuse of the processing logic definitions. For example, if a database stores the FCML documents and identified by their target namespaces and name, they can be easily retrieved. Thus, application developers can make use of the database as a FCML document resource repository for the application implementations. As we will discuss in later section, target namespaces can be used for schema-driven application logic management.

Fourth using text-based XML provides the flexibility for runtime updates and automatic processing. The XML Schema type definitions for XML can be used to for application logic management. This will be discussed further in later sections.

Figure 5 illustrates the proposed structure of an FCML document. The document consists of three parts: FCML declarations, process definitions, and the processing logic descriptions. In this paper, the FCML is not formally presented as in [4] [5] [6] [7] but merely serves to illustrate the language features for supporting the framework architecture. It extends the XML Pipeline [14] description to support the extension of processing flow models and incorporates some of the good features proposed in XLANG [5] and WSFL [7].

Figure 5. Content Model for Application Schema

<appSchema name="MessageBroker"
        targetNamespace="http://xmlns.oracle.com/xdk/sample" 
        xmlns:pipeline="http://xmlns.oracle.com/xdk/pm/process/pipeline" 
        xmlns="http://xmlns.oracle.com/xdk/fcml"
        xmlns:java="http://xmlns.sun.com/java"
        xmlns:soap="http://schema.soap.org/soap">

<?xml version="1.0" encoding="UTF-8"?>
<appSchema id="http://xmlns.oracle.com/xdk/example/StockQuery"
                     targetNamespace="http://xmlns.oracle.com/xdk/fcml/sample"
                     xmlns:soap="http://schema.xmlsoap.org/soap" >
<processdef name="soaprpc.p" definition="oracle.xml.xdk.soaprpc"/>
<processSet>
  <all>
    <process id="p1" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example.com/soap/stockQuote"/>
      <input name="param" type="soap:param" value="ORCL"/>
      <output name="stockQuote" type="soap:message"/>
    </process> 
    <process id="p2" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example.com/soap/CurrencyRate"/>
      <output name="CurrencyRate" type="soap:message"/>
    </process> 
    <process id="p3" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example.com/soap/StockIndex"/>
      <input name="param" type="soap:param" value="Nasdaq"/>
      <output name="param" type="soap:message"/>
    </process> 
  </all>
</processSet>
</appSchema>

<?xml version="1.0" encoding="UTF-8"?>
<appSchema id="http://xmlns.oracle.com/xdk/example/StockQuery"
           targetNamespace="http://xmlns.oracle.com/xdk/fcml/sample"
           xmlns:soap="http://schema.xmlsoap.org/soap" >
<processdef name="soaprpc.p" definition="oracle.xml.xdk.soaprpc"/>
<processSet>
  <pick>
    <process id="p1" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example01.com/soap/stockQuote"/>
      <input name="param" type="soap:param" value="ORCL"/>
      <output name="stockQuote" type="soap:message"/>
    </process> 
    <process id="p1" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example02.com/soap/stockQuote"/>
      <input name="param" type="soap:param" value="ORCL"/>
      <output name="stockQuote" type="soap:message"/>
    </process> 
    <process id="p1" type="soaprpc.p">
      <input name="address" type="soap:address" 
                value="http://www.example03.com/soap/stockQuote"/>
      <input name="param" type="soap:param" value="ORCL"/>
      <output name="stockQuote" type="soap:message"/>
    </process> 
  </pick>
</processSet>
</appSchema>

Web Service applications are designed to cross business boundaries and integrate disparate enterprise systems across Web. These systems are normally large, distributed and heterogeneous. While a lot of effort has been expended in building the system, there is typically even more expended to monitor, secure and manage the system to make it stable, secure and reliable.

These systems require tools to manage preferably in an automatic fashion. Their creation is facilitated by access not only to the log files but also the application logic. The framework architecture makes this possible. As the FCML descriptions are in XML format, we can use the XML Schema metadata definitions to regulate and secure the application logic and ensure its integrity.

The FCML processor performs validation when its documents are compiled. Many application developers are familiar with XML schema validation of XML configuration files. However, under the framework infrastructure, we are not dealing with property data but the application logic. Thus this XML schema validation is not limited to ensuring data integrity, but also the range of processes and application logic available to the framework processor.

Another powerful aspect of this schema-driven application management is that we use it for application process security. In the XML schema definition, if we constrain the process execution logic and its namespace this limits the possibility of ad-hoc or rogue processing in FCML instances.

Finally, the unique name and the target namespace defined for each FCML document, further facilitates central schema-driven management of the application descriptions by allowing an FCML repository to be built and well maintained.

To illustrate this framework, we have built an adaptive application component under a distributed inventory management scenario. Figure 6 illustrates its overall structure. In this distributed database application, we synchronize the inventory content across the entire network system using Web services, such as dynamic branch registration, inventory updates and purchase order request.

Figure 6. Sample Distributed Inventory System

Figure 7 shows the Web services interfaces setup to expose the inventory management process for the HQ and the branches. To provide asynchronous communication, we make use of the Oracle9i Advanced Queuing (AQ) to implement the SOAP message queue, which provides necessary infrastructure services support for an enterprise-messaging application, including security and transactional management.

Figure 7. Inventory Architecture

Figure 8shows the actions taken by the message broker component through the business process. After the update message push into the message query in the HQ database, the message broker takes the XML message, processes it and packaging the message with a standard SOAP envelope. It then sends out the packaged SOAP message to Web service servers of the branch inventory systems.

Figure 8. Message Broker

We implement a framework processor and define FCML documents to descript the processing logic for the message broker component.

Let’s look at two of the specific processes. The first component process receives the XML message and packages it into SOAP format and sends it out to the branch system. We describe the logic in FCML as follows:

<appSchema 
   name=http://xmlns.oracle.com/xdk/pm/sample/MessageBroker
        http://xmlns.oracle.com/xdk/sample
   xmlns:pipeline="http://xmlns.oracle.com/xdk/pm/process/pipeline" 
   xmlns="http://xmlns.oracle.com/xdk/fcml"
   xmlns:java="http://xmlns.sun.com/java"
   xmlns:soap="http://schema.soap.org/soap">
 <processdef name="packMesg.p" type="pipeline:process"
   def="oracle.xml.pm.PackMessage"/>
 <processdef name="sendMesg.p" type="pipeline:process"  
   def="oracle.xml.pm.SendMessage"/>
 <processSet>
    <sequence>
      <process name="packMesg.p">
        <input name="inPkMessage" type="java:String"/>
        <output name="outPkMessage" type="soap:Message"/>
      </process>
      <process name="sendMesg.p">
        <input name="outPkMessage" type="soap:Message"/>
      </process>
    </sequence>
  </processSet>
</appSchema>

Two processes are defined; “packMesg.p” for the SOAP message packaging and “sendMesg.p” for SOAP message deliver. These are associated to Java classes through their respective <processdef> elements.

The processing logic is defined with the <processSet> element. The <sequence> sub-element specifies the sequential flow model for the process: package, packaging the message into SOAP format and sending it out.

The framework processor, as show in Figure 9, compiles the above FCML instructions, uploads the required Java Classes and calls them serially. It uses the Input Resource Repository to store the XML message and intermediate processing results for the logic execution.

Figure 9. Application Process for Message Broker Component

The framework processor receives all of its processing logic through the FCML file. Its job is to apply the logic and organize the components for the processing. Notice that in order for the components to be addressable by the framework processor, they must follow the same definition specification. In the sample implementation, all the Java classes implement this common framework interface.

public interface LogicComponent 
{
  public void setInputType(String type);
  public void setInputValue(Object value);
  public Object getResult();
  public void execute();     // Invoke the component object
}

We can easily add a second process introducing business logic into the message broker component. The FCML description is shown in the following example:

<appSchema name="http://xmlns.oracle.com/xdk/pm/sample/MessageBroker"
                       targetNamespace="http://xmlns.oracle.com/xdk/sample" 
                       xmlns="http://xmlns.oracle.com/xdk/fcml"
                       xmlns:java="http://xmlns.sun.com/java"
                       xmlns:soap="http://schema.soap.org/soap">
  <processdef name="logic.p" def="oracle.xml.pm.ProcessMessage"/>
  <processdef name="packMesg.p" def="oracle.xml.pm.PackMessage"/>
  <processdef name="sendMesg.p" def="oracle.xml.pm.SendMessage"/>
  <processSet>
    <sequence>
      <process name="logic.p">
        <input name="inMessage" type="java:String"/>
        <output name="outPcMessage" type="java:String"/>
      </process>
      <process name="packMesg.p">
        <input name="outPcMessage" type="java:String"/>
        <output name="outPkMessage" type="soap:Message"/>
      </process>
      <process name="sendMesg.p">
        <input name="outMessage" type="soap:Message"/>
      </process>
    </sequence>
  </processSet>
</appSchema>

Here we define a process, “logic.p” and put at the start of the sequenced processes. After updating the FCML document, this process will be incorporated by the framework processor at run-time. The message broker component now has a business logic block as its first process in addition to the SOAP message packaging and delivery as illustrated in Figure 10.

Figure 10. Message Broker Component plus Logic

Thus the sample application demonstrates that we can modify the not only processing logic by simply updating the definitions in FCML document. If we turn to the schema for our FCML document we can see how validation can be used to manage and protect the application. Note the schema for the <processdef> complex type:

<xs:complexType name="processdefType">
  <xs:attribute name="name" use="required">
    <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="packMesg.p"/>
        <xs:enumeration value="sendMesg.p"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="def" use="required">
    <xs:simpleType>
      <xs:restriction base="xs:NMTOKEN">
        <xs:enumeration value="oracle.xml.pm.PackMessage"/>
        <xs:enumeration value="oracle.xml.pm.ProcessMessage"/>
        <xs:enumeration value="oracle.xml.pm.ProcessMessage"/>
        <xs:enumeration value="oracle.xml.pm.SendMessage"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
</xs:complexType>

In this case the allowable process and class hierarchy is tightly defined through enumeration. Only three methods “oracle.xml.pm.packMessage”, “oracle.xml.pm.processMessage” and “oracle.xml.pm.sendMessage” are permitted in any FCML document instance. This of course could be relaxed to allow any methods in “oracle.xml.*” or even additional packages.

Finally this schema can be augmented to provide security checking on the class. This can be done as follows:

<xs:complexType name="processType">
   <xs:sequence>
     <xsl:element name="input" minOccurs="0" maxOccurs="unbounded"
              fcml:conidtion="URLResource" fcml:operation="ValidResourceCheck">
      <xs:element name="output" minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="param" minOccurs="0" maxOccurs="unbounded"/>
   </xs:sequence>
    <xs:attribute name="name" type="xs:String"/>
    <xs:attribute name="type" type="xs:String"/>
  </xs:complexType>

The point is that the built-in flexibility and extensibility can be managed through schema validation.

Web services, based upon the component system architecture, is a promising technology that will increasingly integrate heterogeneous applications and simplify the enterprise applications. After extensive implementation feedback, we find that a truly successful web services solution is more than simply embracing core standards such as XML, WSDL, and UDDI and wrapping everything in SOAP [16]. This paper analyzes the power of XML technologies to build, manage and deploy a web services system with a framework architecture having the desirable characteristics of reusability, extensibility, declarative design, and manageability.

This approach relieves developers from the tasks of implementing a low level infrastructure and set of services and allows them to concentrate on the processing logic. The added benefit of its declarative architecture results in reducing the time-to-market and project cost. We believe the use of XML brings more value to this architecture and associated XML technologies such as XML Schema can be used for better system management. .

Further areas to investigate are finalizing the FCML definitions by defining how the performance tuning, network communication, and resource management can be managed through the same declarative model and how the framework can be integrated into the middleware system.