A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention generally relates to middleware and transaction-based systems, and in particular to a system and method for providing Service Component Architecture (SCA) data transformation in a middleware or transaction-based system.
Middleware platforms, such as Tuxedo, provide support for distributed transaction processing in an enterprise-level computing environment. Such platforms, including Tuxedo, are particularly adept at unlocking enterprise legacy applications, and extending those enterprise legacy applications so that they can be used in a service-oriented manner, while at the same time delivering scalability and standards-based interoperability.
The term Service-Oriented Architecture (SOA) generally refers to a more recent software strategy which organizes the discrete functions contained within enterprise applications into interoperable, standards-based services, which can then be combined and reused to meet particular business needs. The related Service Component Architecture (SCA) describes a model for building applications and systems using SOA, and further builds on open standards, such as Web services, to extend and complement existing SOA approaches. The eXtreme Transaction Processing (XTP) describes an application style aimed at implementing large-scale, business-critical, transactional applications on the basis of distributed architectures, which in turn are implemented by leveraging commodity hardware and standards-based software.
These are the general environments within which embodiments of the present invention are intended to be used.
Disclosed herein is a system and method for providing service component architecture (SCA) data transformation in a distributed transaction processing environment. In accordance with an embodiment, an SCA software component can be used to provide a service to transform data and requests from a service-oriented data format to a transactional data format, such as a Tuxedo or other format. In accordance with an embodiment, a configuration file, such as a schema file, is used to define the transformation between the service-oriented and transactional data formats. The SCA software components operate to communicate with a transaction component, perform the data transformation automatically, and support a transaction process on the transaction component.
In accordance with an embodiment, an SCA extension for the Tuxedo ATMI interface is provided, which allows for seamless data transformation between SCA applications and Tuxedo clients or servers. Tuxedo clients and servers can access data using standard Tuxedo buffer types, such as FML32, FML, VIEW32, VIEW, MBSTRING, STRING and other Tuxedo buffer types, and the data is automatically transformed to or from standard SCA data types. This allows one side of the application to use Tuxedo buffer types while the other side can use SCA buffer types. Support is also provided for SCA to SCA mode applications. Both sides of the application can use SCA data transformation APIs, and the Tuxedo FML32 datatype can be used to transmit the data from one side of the application to the other. The net effect is that SCA applications can be combined with existing Tuxedo applications without requiring any change to the Tuxedo applications; and new hybrid SCA-Tuxedo applications can be developed with each side of the application using the APIs that are best suited for that software.
Embodiments of the invention are illustrated herein by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. It should be noted that references to “an” or “one” or “some” embodiment(s) in this disclosure are not necessarily to the same embodiment, and such references mean at least one.
The description of various embodiments of the invention as following uses Tuxedo functions or libraries as an example for distributed transaction functions or libraries. It will be apparent to those skilled in the art that other types of distributed transaction functions or libraries can be used without limitation.
In accordance with an embodiment, the system provides a transaction capability for Service Component Architecture (SCA) components in a Service Oriented Architecture (SOA) environment. The system allows SCA components to run on top of a transaction platform, such as, for example, the Tuxedo infrastructure. In accordance with an embodiment, an SCA Container provided in Tuxedo can take advantage of Tuxedo's important features: such as reliability, availability, scalability, and performance. In addition, The SCA Container in Tuxedo can integrate Tuxedo closer into an SOA environment. In accordance with an embodiment, enabling SCA in Tuxedo also contributes to solving the complex distribution requirements of eXtreme Transaction Processing (XTP).
In accordance with an embodiment, data transformation can be performed automatically between a SCA data format and a non-SCA data format, such as a transactional manager interface format, in order to support one or more transaction processes on a transactional server in a service-oriented environment. Here, both the SCA data format and the non-SCA data format can be either transactional or non-transactional.
A schema file can be used to define data transformation between the SCA data format and the non-SCA data format. Based on the schema, data transformation can be performed automatically on the transaction data, so that a software component can communicate with the transaction server. In accordance with an embodiment, the transaction server includes one or more transaction processes. Each of the transaction processes can use one or more services provided by a software component in the service-oriented environment to handle the one or more transaction data. The transaction processes at a transaction component, which consumes the transaction data, can also be invoked by other software components in the service-oriented environment.
SCA provides a programming model that aims at simplifying component re-use, and providing seamless communications between components. A Service Component Definition Language (SCDL) describes what components can perform in terms of interactions between each other, and instructs the framework to set-up necessary links or wires. As used in SCA, SCDL is an XML based language that is used to describe services, references, wires, components, and composites.
In an SOA environment, a SCA component is a configured instance of an implementation that includes the defined properties, provided services, and required service references. The aggregation of one or more components is referred to as a “composite”. A “service” is a business function provided by a SCA component. A “reference” is a SCA component dependency on a service. A “wire” is a link between a service and a reference.
In accordance with an embodiment, a programming interface (API) is provided to support the development of transactional applications. For example, in accordance with an embodiment, a modified form of the Application-to-Transaction Monitor Interface (ATMI) is provided, which enables native Tuxedo applications to communicate with SCA components. In accordance with an embodiment, an ATMI binding and SCA container also enables SCA applications to take advantage of the Tuxedo framework, and allows SCA components to interoperate with native Tuxedo processes. In this manner, SCA applications can be combined with Tuxedo applications in an integrated environment, without requiring any change to the Tuxedo applications themselves. The applications in such an integrated environment can use those portions of APIs from both Tuxedo and SCA that are best suited to the particular application. In addition, the capabilities of the Tuxedo complex data type, such as FML32, can be used within SCA applications. In this manner, smooth interoperability and/or migration to/from Tuxedo and SCA can be achieved, and newer SOA-like capabilities can be easily introduced into the Tuxedo environment.
In accordance with an embodiment, a runtime reference binding extension is provided as an implementation of the client-side aspect of the SCA container. The runtime reference binding encapsulates the necessary code to call other services, such as SCA components, Tuxedo servers, Web Services, and other services, transparently from an SCA-based component.
Users of the runtime reference binding extension, such as client applications, can provide different environment variables. These environment variables can be used by the SCA framework, in particular by an SCA kernel implementation that configures and manages the SCA environment. In addition, these environment variables can override the same parameters that are passed using command-line options. The followings are examples of these environment variables:
In accordance with an embodiment, users use a buildscaclient command that encapsulates the environment variables above to perform calls over the Tuxedo infrastructure. The resolution of Tuxedo service and other parameters passed in the binding declaration are performed transparently. In accordance with an embodiment, checks can be made for process initialization and runtime, and an exception can be thrown if necessary.
In accordance with an embodiment, an ATMI binding reference can be used in a client-only application. Strict client applications, as opposed to server components making client calls, are programs that only make references to other SCA components. These programs load the SCDL model by calling the CompositeContext::getCurrent( ) method. Client applications can join a Tuxedo application and have the same characteristics as a regular ATMI client performing tpinit( ) with the TPMULTICONTEXTS flag. Such a client, which makes more than one reference via the ATMI binding, can issue one tpinit( . . . TPMULTICONTEXTS) call per reference. The call can be made at service lookup time (i.e. when calling CompositeContext::locateService( )). tpterm( ) can be invoked internally, when the CompositeContext object, obtained by calling CompositeContext::getCurrent( ) goes out of scope or an exception is caught. Successive calls to CompositeContext::locateService( ) can therefore not perform successive tpinit( ) calls. Each reference can have an associated Tuxedo application context that is internally shared among multiple threads if the client application is multi-threaded.
In accordance with an embodiment, a runtime service binding extension is provided as an implementation of the server-side aspect of the SCA container. The runtime service binding extension encapsulates the necessary code and framework components to allow other SCA components, existing Tuxedo clients, or other service requesters, to transparently call SCA-based components.
In accordance with an embodiment, SCA components can be contained in shared libraries, used by the SCA kernel or the SCA framework. The runtime service extension can resolve these libraries at run-time, using the environment information below:
In accordance with an embodiment, a generated Tuxedo SCA server can dynamically link to SCA composites that declare services with bindings of type ATMI. This server can be generated using the buildscaserver command. In one example, this server can be added to a configuration file in order to include the SCA components, which it hosts as part of the Tuxedo application. The service binding extension code can then be linked to the server stub. This server can advertise services corresponding to the deployment rules. Requests received by the server can be assumed to be in a format suitable for processing by SCA components.
In accordance with an embodiment, in an environment such as Tuxedo, an SCA component implementation can be bootstrapped inside a Tuxedo server, so that the Tuxedo framework can forward requests to the Tuxedo server and send replies back to the client processes. The SCA component implementations can also be encapsulated in the Tuxedo server process.
In accordance with an embodiment, components can be built as SCA components, to create a number of shared libraries whose entry points correspond to the interfaces defined for the implementations. A Tuxedo server can then be built and constructed by parsing the corresponding SCDL code and interfaces. This generates a source file that dynamically advertises different Tuxedo services. The number of different Tuxedo services is defined by the <service> elements in the SCDL code that contains <binding.atmi> elements. The format of the binding provides a hint as to what actual method can be exposed by each Tuxedo service. Methods without a corresponding ATMI binding may not be exposed through Tuxedo.
In one example, the code generated in the above step contains the following functions:
In addition, each server can advertise a number of extra services for administrative purposes. These services can be invoked using a scaadmin tool. New servers hosting new composites are allowed to be added like normal Tuxedo application servers by dynamically configuring the Tuxedo application.
An important part of SCA is the Service Data Objects (SDO) protocol that allows heterogeneous data to be accessed in a uniform way. SDO is used to simplify data programming and let the developer to focus on the business logic implementation instead of underline data programming technology.
In accordance with an embodiment, SCA data transformation capabilities are provided for the transformations from SCA Service Data Objects (SDO) to Tuxedo data types, and the transformations from Tuxedo data types to SCA Service Data Objects (SDO). In addition, SCA data transformation capabilities are provided for both C++ applications and Java® applications using the JATMI interface. In addition, the data transformation capabilities can also be developed to support a C implementation of SCA.
In accordance with an embodiment, the system allows for seamless data transformation between SCA applications and Tuxedo clients or servers. Tuxedo clients and servers can access data using standard Tuxedo buffer types such as FML32, FML, VIEW32, VIEW, MBSTRING, STRING and other Tuxedo buffer types. These Tuxedo format specific data can be automatically transformed to/from standard SCA data types. Support can also be provided for SCA-to-SCA mode applications. For example, one side of an application can use Tuxedo buffer types, and the other side can use SCA buffer types. Both sides of the application can use SCA data transformation APIs, and the Tuxedo FML32 data type can be used to transmit the data from one side of the application to the other.
In accordance with an embodiment, data transformation used by Tuxedo as a binding is governed by an interface, i.e. all communication performed on top of Tuxedo using the SCA kernel can be conducted starting from the interface.
The above example can send and receive a Tuxedo STRING buffer. With regard to the binding and reference extension implementations, the determination of the actual Tuxedo buffer to be used is provided by the contents of the /binding.atmi/bufferType element of the SCDL configuration. In addition, the type of buffer returned or sent is determined by a server or client, respectively. Both the client and server can be either an ATMI program or an SCA component.
In accordance with an embodiment, users can provide an XML or other schema that describes the SDO object. The schema is made available to the service or reference extension runtime using the /binding.atmi/schemaLocation element. The schema can be used internally to associate element names and field names.
In accordance with an embodiment, there is no distinction made between SCA-SCA communication and SCA-ATMI communication, since components do not need to be aware of the type of implementation of the other side.
Invoking a Tuxedo Service from a Client Application
In accordance with an embodiment, the system provides two commands, buildscacomponent and buildscaserver, that can parse SCDL definitions and interfaces and produce a Tuxedo-deployable server along with Tuxedo-deployable elements, such as shared libraries containing SCA components and SCDL configuration. The buildscacomponent is used first to build the shared libraries containing the SCA components (as application code). Then, the buildscaserver command is used to build the server that can perform the interfacing between Tuxedo message queues and SCA components. In one example, the buildscaserver command takes source code (such as .c or .cpp files) and associated SCDL source as input, and the buildscaserver phase does not construct any application code.
In accordance with an embodiment, Web Service bindings are used to leverage the Web Service protocol such as SOAP gateways. The SCA components can physically be hosted in Tuxedo servers, and the communications from/to the Tuxedo servers can be performed through a Web Service gateway. SCA clients using a Web Services binding can remain unchanged whether the server is running in a Tuxedo environment or a native SCA environment (i.e. exposing the component using the Web Services binding for instance).
When SCA components are exposed using the Web Services binding (for example, binding.ws), the system provides tooling that can generate WSDF information, metadata entries and FML32 field definitions. For example, when SCDL code of SCA components to be hosted in a Tuxedo domain (i.e., service elements) contains <binding.ws> elements, the buildscaserver command generates a WSDF entry in a file named service.wsdf where ‘service’ can be replaced using the name of the service exposed. An accompanying service.mif and service.fml32 field table files are also generated, based on the contents of the WSDL interface associated with the Web Service. A WSDL interface can be composed by the user, and an error message is printed out, if no WSDL interface can be found.
When a Web service binding, or binding.ws, is used, the data transformation includes inbound data transformation and outbound data transformation.
In accordance with an embodiment, the inbound data transformation includes two steps: first, a web service gateway transforms the SOAP message into a Tuxedo buffer; then, the reference extension runtime transforms the Tuxedo buffer into a C++ representation following the rules outlined above.
Similarly, the outbound data transformation also includes two steps: first, the service extension runtime transforms a C++ or Java representation into a Tuxedo buffer following the rules outlined above; then, a web service gateway transforms the Tuxedo buffer into a SOAP message.
In accordance with an embodiment, data transformation takes place at different times, such as when a reference extension is processing a client request; when a reference extension is processing a server reply; when a reference extension is processing a request; or when a reference extension is processing a reply. Correspondingly, error handling can also be implemented separately.
For the case when a reference extension processes a client request, an exception is thrown to the client. If the error takes place in a transaction, the transaction is rolled back.
For the case when a reference extension processes a server reply, an exception is thrown to the client process. If the error takes place in a transaction, the transaction is rolled back.
For the case when a service extension processes a request, the exception is caught and the call is terminated. A TPESYSTEM error is returned to the originating client. An error message is written to the ULOG with details of the exception. If the error takes place in a transaction, the failure return causes the transaction to be marked rollback-only.
For the case when a service extension processes a reply, the exception is caught and the call is terminated. A TPESYSTEM error is returned to the originating client. An error message is written to the ULOG with details of the exception. If the error takes place in a transaction, the failure return causes the transaction to be marked rollback-only.
In accordance with an embodiment, an error can be an actual combination of the following possible errors:
In accordance with an embodiment, an exception can be thrown and handled internally, thus its structure is not visible to the user. Exceptions may not be mapped between SCA and ATMI, and the specific data to be populated in each exception can vary.
In accordance with an embodiment, an ATMI process can call an SCA component using the ATMI client as shown below:
A metadata repository entry can be provided as shown below:
A C++ interface can be generated from the above metadata repository entry, as shown below:
A SCA component implementation excerpt is shown below:
The above service can be published in the SCA Composite definition as shown below:
In Example 1, the SCA component has no knowledge on whether the request is coming from an ATMI client, or from another SCA component. In accordance with an embodiment, although the above example uses metadata repository information, the use of service metadata is not required for data transformation. The metadata is used only to generate a SCDL file, and is not referenced at runtime. As a result, any size parameters configured for input, output, or error buffers in service metadata can be ignored during data mapping. A SCDL file generated without the use of metadata is equally valid for data transformation.
In accordance with an embodiment, a service can handle a complex data type by taking one or more parameters sufficient to identify an employee as input and filling in the rest of the parameters for the complex data type. Example 2 below shows an ATMI client excerpt using complex data type.
An SCA component implementation excerpt is shown below:
The SCA Composite definition is shown below:
The present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
In some embodiments, the present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.
The foregoing description of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to the practitioner skilled in the art. The code examples given are presented for purposes of illustration. It will be evident that the techniques described herein may be applied using other code languages, and with different code.
The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.