Custom models and text translation come to OCI Language

Part of Oracle Cloud Infrastructure (OCI) AI services, OCI Language service allows you to perform sophisticated text analysis at scale without any machine learning (ML) knowledge. It provides pretrained models for sentiment analysis, entity extraction, language detection, and many other natural language tasks. Today, we’re excited to announce two exciting capabilities in the Language service: Customizable models and automatic text translation. These features are now in limited availability in all OCI’s commercial regions and can be accessed through OCI software developer kits (SDKs) and REST APIs.

Build your own custom language models

OCI Language enables you to train customized language models, even if you’re not a natural language processing (NLP) expert. You can train custom classification and custom named entity recognition (NER) models. The OCI Language service learns from previously labeled data, such as classified records and samples of entities extracted from text, to train the models. After you train a custom model, you can deploy dedicated endpoints to serve your requests.

Custom classification

Imagine that you’re responsible for the support tickets that come into your company. Each day, you receive thousands of tickets that need to be routed to specific departments. In the past, you had humans perform this task. With this tedious work, keeping your employees excited about their work is difficult. Over the last couple of months, your employees have routed thousands of tickets to the right department. Wouldn’t it be great if AI could help them?

Using OCI Language, you can create a custom model that learns from all the work the humans have done in the past.

When the model is trained on previous conversations, it can classify any new requests automatically, freeing humans to perform less tedious tasks.

OCI Language allows you to host the custom models on dedicated endpoints. Depending on the expected throughput you need to handle, you can assign a larger or smaller number of inference units (a unit of compute) to your endpoint.

We described a support ticket classification scenario, but the same principles apply to other use cases, such as document classification, clause classification, and intent recognition.

Custom named entity recognition (NER)

OCI also supports the ability to identify terms that are unique to your domain, such as product part codes, manufacturing terms, and specific financial entities. You provide sample data with labeled entities to train a custom NER model that can then be used to automatically identify the entities in text.

To illustrate the types of problems that using custom NER can solve, let’s continue our support ticket use case. Imagine that many of the support tickets you receive deal with shipment issues. You want to extract critical information from each ticket, such as the order ID, the shipment date, and the name of the recipient.

Using OCI Language, you can automate this process, but first you must gather the training data. OCI Data Labeling, a service for labeling datasets, can help you label the data to train such a model. It allows you to define the custom entities, and then mark the location of those entities in the text, as shown for the following examples:

With the labeled data, you can train your own custom NER model. OCI Language provides an intuitive workflow to create and organize models. You can also evaluate global and entity-specific metrics to help you identify other data that you need to further improve your model.

When you’re pleased with the quality of the model, you can create a dedicated endpoint to automatically perform the entity extraction for you. So, you to convert unstructured data (language prose) into structured data, enabling you to automate downstream processes!

Text translation

OCI Language now allows you to automatically translate text across 21 languages. This exciting feature uses state-of-the-art AI neural machine translation techniques to translate text at scale with high accuracy. Sample use cases of automatic text translation include building multilingual chatbots, automatic application localization, translation of support tickets, article translation and any kind of application that helps you understand others globally.

We’re always expanding our language coverage. At the time of this blog post, the following languages are supported:

◉ Arabic (ar)

◉ Brazilian Portuguese (pt-BR)

◉ Czech (cs)

◉ Danish (da)

◉ Dutch (nl)

◉ English (en)

◉ Finnish (fi)

◉ French (fr)

◉ Canadian French (fr-CA)

◉ German (de)

◉ Italian (it)

◉ Japanese (ja)

◉ Korean (ko)

◉ Norwegian (no)

◉ Polish (pl)

◉ Romanian (ro)

◉ Simplified Chinese(zh-CN)

◉ Spanish (es-ww)

◉ Swedish (sv)

◉ Traditional Chinese (zh-TW)

◉ Turkish (tr)

You can experience the text translation capabilities from the Oracle Cloud Console.

Source: oracle.com

Continue reading

Fourth Quarterly update on Oracle Graph (2022)

Oracle Graph Server and Client 22.4 is available for download for use with databases in the Cloud (OCI Marketplace image is available) and for databases on-premises. Note that the new features described here are not yet available in Graph Studio, we will update this post when they are available.

Oracle Graph Server and Client version 22.4 has been released and contains a number of feature updates. Graph Server (PGX) now supports a graph loading progress reporting API, subgraph loading enhancements, and synchronization for published graphs. Oracle Graph Server and Client 22.4 is the first release to fully implement PGQL 1.5. You can find this specification here:  https://pgql-lang.org/spec/1.5/. These PGQL updates include the ability to use IS as an alternative for a colon, support for scalar subqueries, and support for EXISTS and NOT EXISTS subqueries. This release also includes some packaging enhancements and desupported features, which can be found at the end of this post.

Graph Server (PGX) Features

Graph reading progress reporting API

Oracle Graph Server 22.4 includes a new API added to PgxFuture that retrieves loading progress. This feature works with PG view graphs. 

This is an example of how the progress reporting API can be used:

PgxFuture<PgxGraph> future = session.readGraphByNameAsync("MYGRAPH", GraphSource.PG_VIEW)

FutureProgress progress = future.getProgress() // new API

Optional<GraphLoadingProgress> loadingProgress = progress.asGraphLoadingProgress()

long numLoadedVertices = loadingProgress.get().getLoadedVertices()

Subgraph loading enhancements

Previously, a subgraph was given the same name as the PG view plus a number. However, the load() function now accepts a name as a parameter. Additionally, the query for the subgraph now allows for any-directed edge patterns.

This is an example of how these features can be used when creating a subgraph:

PgxGraph subgraph = session.readSubgraph()

    .fromPgView("MYGRAPH")

    .queryPgql("MATCH (s)-[e]-(d)") // NEW: any-directed pattern

    .load("MYSUBGRAPH") // NEW: name the resulting subgraph

Synchronize published graphs

Published graphs in the Graph Server (an application can ‘publish’ graphs to share with other sessions connected to the Graph Server) can now be synchronized with updates in the database. Previously only graphs within a session could be synchronized.   This is enabled by using the new API to specify the graph configuration object when creating a synchronizer object.

This is an example of how the graph configuration can be included in the synchronizer call:

Synchronizer synchronizer = new Synchronizer.Builder<FlashbackSynchronizer>()

    .setType(FlashbackSynchronizer.class)

    .setGraph(graph)

    .setGraphConfig(graphConfig) // NEW

    .setConnection(connection)

    .build()

PGQL Features

IS as an alternative for colon (:)

In previous versions of Oracle Graph, a colon (:) was used to indicate label predicates. To include syntax in the SQL/PGQ standard (the draft ISO standard for SQL to query property graphs), the newest version of Oracle Graph now supports “IS” as a label predicate. However, this feature is additive, and does not remove the ability to use a colon as a label predicate.

This is an example of the label predicate options in 22.4:

//Before

FROM MATCH (s:Friend) -[e:knows]-> (d:Person)

//Starting 22.4 the following is supported

GROM MATCH (s IS Friend) -[e IS knows]-> (d IS Person)

PGQL on PG Views: Scalar Subqueries

Oracle Graph Server and Client 22.4 allows you to use scalar subqueries in PG views.  You can use them as part of an expression. A scalar query is a query that returns a scalar value, exactly one row and exactly one column. In this latest release of Oracle Graph, you can use scalar queries as part of an expression in a SELECT, WHERE, GROUP BY, HAVING or ORDER BY clause.

For example, you could write a query such as the following:

SELECT p.name AS name

    , ( SELECT SUM(t.amount)

        FROM MATCH (a) <-[t:transaction]- (:Account)

      ) AS sum_incoming

    , (SELECT SUM(t.amount)

        FROM MATCH (a) -[t:transaction]-> (:Account)

      ) AS sum_outgoing

    , (SELECT COUNT(DISTINCT p2)

        FROM MATCH (a) -[t:transaction]-> (:Account) -[:owner]-> (p2:Person)

        WHERE p2 <> p 

      ) AS num_persons_transacted_with

    , (SELECT COUNT(DISTINCT c)

        FROM MATCH (a) -[t:transaction]-> (:Account) -[:owner]-> (c:Company)

      ) AS num_companies_transacted_with

        FROM MATCH (p:Person) <-[:owner]-> (a:Account) 

ORDER BY sum_outgoing + sum_incoming DESC

PGQL on PG Views: EXISTS and NOT EXISTS subqueries

EXISTS and NOT EXISTS return true or false depending on whether the subquery produces at least one result, given the bindings obtained from the outer query.

In the following example, we can query to find friends of friends, and for each friend of friend, return the number of common friends. Assuming we have a graph that shows relationships among a group of people, we can do this simply with a NOT EXISTS subquery:

SELECT fof.name, COUNT(friend) AS num_common_friends

    FROM MATCH (p:Person) -[knows]-> (friend:Person)

                  -[knows]-> (fof:Person)

    WHERE NOT EXISTS (

        SELECT * FROM MATCH (p) -[:knows]-> (fof)

    )

Packaging Enhancements

◉ There is a new Oracle Cloud Infrastructure Marketplace image for RDF Server that uses Apache Tomcat. Users can choose between the image that uses Apache Tomcat or the one that uses Oracle WebLogic Server when deploying RDF Server.

◉ The Graph Server RPM now declares libfortran as a dependency. This dependency is required by PGX.ML.

◉ The Graph Server RPM installation now generates a self-signed certificate into /etc/oracle/graph/server_keystore.jks

Source: oracle.com

Continue reading

JSON Relational Duality: The Revolutionary Convergence of Document, Object, and Relational Models

JSON Relational Duality is a landmark capability in Oracle Database 23c that provides game-changing flexibility and simplicity for Oracle Database developers. This breakthrough innovation overcomes the historical challenges that developers have faced when building applications, either when using the relational model or when using the document model.

JSON Relational Duality delivers a solution that provides the benefits of both relational tables and JSON documents, without the tradeoffs of either model.

Limitations using relational and document models for app dev

The relational approach is very powerful but not always the easiest for app dev 

The relational model is very powerful and efficient since it uses data normalization to ensure data integrity while avoiding data duplication. Relational operations make modeling and accessing data very flexible, however, in some cases, it is not always the easiest for developers:

◉ Developers typically build apps in terms of app-tier language objects, while relational databases store data as tables, rows, and columns. Constructing individual application-tier objects often requires accessing multiple tables. 

◉ To get around these difficulties, developers often use Object Relational Mapping (ORM) frameworks. While ORMs can simplify app-dev, they also introduce significant overheads: They usually require multiple database round-trips to manipulate a single app-tier object, they are inefficient because they do not take full advantage of the capabilities of the database engine, they do not manage concurrency control very well, and applications need to use different ORM frameworks for different languages. They are also extremely poor at batch or bulk operations that must insert or modify many app-tier objects. 

◉ Application-tier ORM frameworks also introduce the possibility of divergent semantics across modules and microservices unless all of them share exactly the same mapping information.

The relational model is therefore a very efficient data storage format but sometimes poses challenges for developers when used as a data access format and ORMs introduce inefficiencies and other trade-offs.

 

JSON document databases have their own shortcomings

Document databases are popular with developers because they make it easy to retrieve and store hierarchically organized data corresponding to app-tier language objects. The JSON document model allows apps to directly map objects into a hierarchical JSON format, avoiding the need for decomposition or reconstitution, and the associated complexities. However, the JSON document model is far from ideal as a storage format because:

◉ Documents often need to store overlapping data. For example, different Order documents may store the same Customer information redundantly. Data duplication leads to inefficiency and potential inconsistency, since an update to shared information (such as a customer phone number) may require updating many Order documents atomically. 

◉ To get around this problem, some document databases recommend normalizing documents using references: Instead of including the Customer document within the Order document, an Order document may simply include an ID for that Customer document. However, normalizing documents completely defeats the simplicity of the document model, and results in a model that is actually the worst of both worlds!

◉ It is also very difficult to model many-to-many relationships using the document model. Attempts to model the relationships lead to even greater data duplication and the potential for additional inconsistencies. 

Documents/JSON are therefore a developer-friendly data access format and make it easy for developers to get started, but have significant limitations as a data storage format, especially as the complexity of an app increases.

How Oracle Database 23c JSON Relational Duality revolutionizes app dev

Oracle Database 23c JSON Relational Duality converges the benefits of the Relational and Document worlds within a single database without any of the tradeoffs discussed earlier. The new capability in Oracle Database 23c that enables this convergence is referred to as a JSON Relational Duality View. 

Figure 1: JSON Relational Duality: Best of both worlds

 

Using Duality Views, data is still stored in relational tables in a highly efficient normalized format but is accessed by apps in the form of JSON documents (figure 2). Developers can thus think in terms of JSON documents for data access while using the highly efficient relational model for data storage, without having to compromise simplicity or efficiency. In addition to this, Duality Views hide all the complexities of database level concurrency control from the user, providing document level serializability.

Figure 2: Stored as rows - Accessed as JSON documents

Duality Views can be declared over any number of tables using intuitive GraphQL syntax. For example, the following Duality View renders the relational data available in the order, orderitem and customer tables as a JSON document corresponding to an app-tier Order object:

Figure 3: Declaring a Duality View

Developers can easily define different Duality Views on the same or overlapping set of relational tables, making it easy to support multiple use cases on the same data (such as OrderObj and ShipmentObj Duality views that share common tables such as orderitem and customer). 

Using Duality Views, developers now have much greater flexibility: 

◉ SQL access to all data, including data in JSON columns, using SQL JSON extensions 

◉ JSON document access to all data, including access to data stored in relational tables, using Duality Views

Developers can manipulate JSON documents produced by Duality Views in ways they are used to, using their usual drivers, frameworks, tools, and development methods.

Extreme simplicity and flexibility for developers

Developers greatly benefit from the simplicity of being able to retrieve and store all the data needed for a single app-tier object in a single database operation. Applications using Duality Views can now simply read a document from the view, make any changes they need, and write the document back without having to worry about the underlying relational structure:

◉ Duality Views eliminate the need for ORM frameworks

◉ Reads and writes of Duality Views can use familiar HTTP operations such as GET, PUT, and POST. 

◉ Applications that prefer an API over HTTP can use the Simple Oracle Document Access API (SODA), Oracle Database API for MongoDB, or ORDS. 

◉ Application operations using Duality Views are optimally executed inside the database since they enable fetching and storing all rows needed for an app-tier object use case in a single database access, in contrast with the often inefficient database access code generated by ORMs.

JSON Relational Duality therefore provides the storage, consistency and efficiency benefits of the relational model while also providing the simplicity and flexibility of the JSON document model.

Lock-Free Concurrency Control with Oracle Database 23c 

Duality Views also benefit from a novel lock-free or optimistic concurrency control architecture in Oracle Database 23c that enables developers to manage their data consistently across stateless operations.

◉ Traditional locking does not work with stateless operations such as REST GET and PUT since locks are stateful and cannot be held across stateless calls.

◉ A new lock-free concurrency control algorithm in Oracle Database 23c allows for consistent updates across stateless operations.

◉ The lock-free scheme extends the Entity Tag (ETAG) concept from the HTTP protocol into the core database, an ETAG being a hash or a signature for the contents of a retrieved web page.

◉ When a GET is performed on a Duality View, the returned JSON document also contains the ETAG of the set of rows used in constructing the document.

◉ When that document is modified and later PUT back into the database, the supplied ETAG is compared with the current ETAG of the rows. If the ETAG differs, the object must have been modified between the GET and the PUT and the PUT is rejected

◉ The application can then re-GET the document with the new ETAG and retry the PUT

◉ If the PUT is successful, we are guaranteed that no intervening changes have occurred to the object and ensuring document-level atomicity and consistency. 

◉ Document-level serializability using lock-free concurrency control allows developers to focus on their app instead of implementing debugging concurrency control and data consistency issues within the application-tier.

Source: oracle.com

Continue reading

Ensuring Data Consistency in Microservice Based Applications

In my previous post I described Oracle’s newly announced product, Oracle Transaction Manager for Microservices (MicroTx). In this post I’ll cover why distributed transactions are needed in a microservice based application and the various distributed transaction protocols supported by MicroTx.

As application architecture moves from monoliths, through SOA, to today’s microservices, issues crop up that monoliths and some SOA based applications don’t need to worry about. One area in particular is around data consistency. In a monolithic application, typically all data is stored in a single database. Consistency across tables is managed by local transactions to ensure the data remains consistent, i.e., an update to two tables either both succeed or neither of them succeed. Moving to microservices where each microservice maintains its own database, local transactions are no longer sufficient to provide consistency.  This is where distributed transactions become a requirement.

Distributed Transactions

To help ensure data consistency across microservices, a distributed transaction is often used. Distributed transactions try to move a system from one consistent state to another consistent state.  hey are often utilized to handle the various failure scenarios that can occur in distributed systems, ideally without burdening the application developer with too much work. One of the earliest distributed transaction protocols is the XA two phase commit protocol defined by The Open Group. Using XA, applications can ensure that the updates to multiple data sources can be done while still adhering to the ACID guarantees of a transaction.

ACID

Transaction protocols typically try to provide ACID guarantees, where ACID is an acronym for:

◉ Atomicity – All changes occur or none of the changes occur – prevents partial updates.

◉ Consistency – The system as a whole move from one consistent state to another consistent state.

◉ Isolation – Changes by one transaction aren’t seen by any other transaction until the transaction is complete - sometimes referred to as serializability meaning the results are the same whether transactions execute in parallel or are serialized.

◉ Durability – Once the outcome of the transaction has been determined, the outcome is durably recorded and will take place even in the presence of temporary failures.

Not all transaction models ensure all these ACID properties. The popular Saga model of eventual consistency for example typically gives up Isolation, which can lead to inconsistent outcomes that are difficult to compensate as a transaction may make a decision based upon potentially dirty or stale data.

XA

The XA standard for Distributed Transaction Processing defines the model and the protocol that occur between the Application Program (microservice), the Transaction Manager, and the Resource Managers (databases). The basic flow is:

1. Application Program asks Transaction Manager to start a transaction

2. Application Program updates one or more Resource Managers

3. Application Program asks Transaction Manager to commit the transaction

4. Transaction Manager asks each Resource Manager to prepare, meaning be ready to commit when asked

5. If all Resource Managers successfully prepare, then the Transaction Manager tells all Resource Managers to commit

6. If a failure occurs before the decision to commit by the Transaction Manager is made, all Resource Managers will be asked to rollback

While the above is greatly simplified, it shows the general flow. From the XA Specification:

If we replace the monolithic application program with a set of microservices, we will see something like the following picture. A client or other microservice calls A, which starts the XA transaction by calling the Transaction Manager. A’s business logic updates its resource manager and calls B which also calls the transaction manager to enlist in the transaction. B’s business logic does some updates to its resource manager and calls C. Likewise, C calls the transaction manager to enlist in the transaction and its business logic updates its resource manager. Finally, A calls the transaction manager to commit or rollback the transaction. The transaction manager then prepares and commits A, B, and C’s resource mangers or rolls them back.

Which is a little complicated and we’ll explain how this can be simplified using Oracle Transaction Manager for Microservices (MicroTx) in my next post.

Sagas

Sagas are a distributed transaction model that relies on the idea of eventual consistency. This means that during the execution of the transaction, some microservices are in an inconsistent state with respect to the other microservices involved in the transaction. Sagas provide the advantage that each microservice uses local transactions to maintain consistency within the microservice. This reduces the time locks are held to just the duration of the local transaction instead of for the entire duration of the distributed transaction as is done in XA.

In this picture we can see Sagas look a lot like XA transactions, but with some significant differences. First in Sagas, there isn’t any notion of a resource manager. Another difference is that all the participants use local transactions during the Saga execution instead of a distributed transaction. However, the most significant difference is that the microservice must provide application logic to complete or compensate its part of the Saga. Compensating the microservice’s part of the Saga can become quite complicated as the microservice’s state may have changed due to other Sagas by the time it comes to compensate. How and what completing or compensating means and performed is completely up to the application. This in contrast to XA transactions where the infrastructure takes care of committing or rolling back the state of the involved resource managers.

The basic flow for Saga is:

1. Initiator calls the transaction coordinator to begin a Saga

2. Initiator calls one or more participant microservices

3. The participant microservices enlist in the saga by calling the transaction coordinator to provide their complete and compensate URIs.

4. The initiator then calls the transaction coordinator to complete or compensate the saga

5. The transaction coordinator calls each participant’s complete or compensate URI

Try-Confirm/Cancel

The Try-Confirm/Cancel transaction model relies on a specific application pattern where microservices provide reservations of resources that will later either be confirmed or canceled. Confirming a reservation means that the resource is now owned by the caller, whereas canceling the reservation means the resource is put back into inventory. It is a two-phase transaction model that doesn’t require locking and the risk of deadlocks or performance issues. However, it is only suitable for application that use a reservation of resources model.

The basic transaction flow for Try-Confirm/Cancel is as follows:

1. Initiator calls the transaction coordinator to begin the Try-Confirm/Cancel transaction

2. Initiator calls one or more participants to make reservations

3. Participants make the reservation and return a URI representing the reservation

4. Initiator calls the transaction coordinator to either confirm or cancel the transaction

5. The transaction coordinator then confirms or cancels all of the reservations using PUT or DELETE

Later in this series of blog posts, I’ll cover how MicroTx can simplify the use of distributed transactions for each of these models.

Select the Right Protocol for the Required Consistency

By providing multiple distributed transaction protocols, MicroTx allows application developers to choose the level of consistency needed for their microservices. For very strong consistency, developers can choose the XA protocol and get all the ACID properties of a transaction that spans their microservices. One of the benefits of using XA is that it doesn’t require any application logic to ensure consistency. All that’s required is to bracket the beginning and end of a transaction.

Some applications may be better suited for Sagas where the overall transaction time may be quite long, say over the interaction with a user. In these sorts of applications, Sagas in the form of Eclipse MicroProfile Long Running Actions (LRAs) provide a solution. LRAs provide a form of eventual consistency where systems may be inconsistent with one another but will eventually be consistent. One issue with LRAs is that unlike XA, there is no isolation, so other requests may see this temporary inconsistent state across the microservices involved. Also, LRAs require application specific logic to complete as well as compensate a microservice’s involvement in the transaction.

The third supported transaction protocol is the Try-Confirm/Cancel protocol. It relies completely on HTTP verbs to manage a distributed transaction. During the first part of the protocol, the initiator makes POST requests to reserve resources. Once all the resources are reserved, it asks the transaction coordinator to confirm all the reservations. The transaction coordinator then calls PUT on all the resources to confirm the reservation. If all the reservations can’t be made or for some other reason, the initiator can ask the transaction coordinator to cancel all the reservations. The transaction coordinator then calls DELETE on all the reserved resources.

Source: oracle.com

Continue reading

Announcing Oracle Tuxedo 22c

Oracle is pleased to announce a new major release of Oracle Tuxedo, version 22c (22.1.0.0.0).  This release contains a number of enhancements and new features.  This blog post briefly describes the various changes in this release.

Kubernetes and Cloud Based Deployments

Tuxedo 22c simplifies deployment in Kubernetes and cloud environments and enables non-Tuxedo specialists to more easily deploy and manage Tuxedo. Along with this release, Oracle is providing Dockerfiles and Helm charts in Github to help run Tuxedo applications in container-based environments such as Docker and Kubernetes. Using these files as a starting point, developers can quickly create an image that has Tuxedo and their application already installed and ready to run.  Once the image has been created, containers in Docker can easily be started with the docker run command.  To deploy the image in Kubernetes, Oracle is providing helm charts to take care of installation and running the image.  These charts have been tested on minikube, Oracle Kubernetes Engine (OKE) in Oracle Cloud, and should work with other Kubernetes distributions including Red Hat OpenShift. Sample applications along with their Dockerfiles and Helm charts are also in Github.

We plan to continue providing additional tools and integrations for deploying and running Tuxedo applications in cloud-native environment, including integration with native Kubernetes observability and management tools to make it easier to run Tuxedo in Kubernetes and Cloud environments.

Figure 1. Pre-built Tuxedo containers in Oracle Container Registry enable faster and simpler Kubernetes and Cloud deployments

Integrating Tuxedo Applications into a Microservices Based Application

This new release of Tuxedo fosters re-use of existing Tuxedo services (native or re-hosted from mainframe) in Microservices applications.  It includes an enhanced Service Architecture Leveraging Tuxedo (SALT) release that enables Tuxedo services written in C/C++, COBOL, or Java to participate in an XA distributed transaction managed by Oracle Transaction Manager for Microservices (MicroTx).  Using SALT and MicroTx, new microservices developed in Java or TypeScript can use existing Tuxedo services exposed as REST end-points in SALT as part of a distributed XA transaction.  This allows Tuxedo services to be included in an XA transaction coordinated by MicroTx that spans multiple databases, ORDS/APEX applications, Java and TypeScript based microservices, and Oracle Blockchain Platform smart contracts. The result is a broader transaction orchestration across polyglot application components, enabling strong data consistency, reducing development, and simplifying testing and troubleshooting.

Figure 2. Transaction orchestration of Tuxedo services with polyglot Microservices enables re-use and speeds up adoption of more flexible and modular application architectures

Oracle Database Application Continuity Support

Application Continuity (AC) is a feature available with Oracle Real Application Clusters (RAC), Oracle RAC One Node, and Oracle Active Data Guard options that masks temporary database outages from applications. AC masks these outages by recording the database session locally and replaying the recording should the connection to the database be lost. This is all done in the database driver and transparent to the application so that the outage appears to the application as a slightly delayed execution.

In order to support Application Continuity in all recoverable failure scenarios, it is necessary for the client application to demarcate session boundaries, i.e., when a database session starts and when it ends.  Tuxedo 22c provides an option to automatically call the Oracle Client Interface (OCI) start session API prior to starting to process a service request and then call the OCI end session API when the service completes.  This allows non-XA Tuxedo services to transparently leverage Application Continuity  and hide most database disruptions from the Tuxedo service without any code changes.  Note this only works for servers not currently involved in an XA transaction.  XA transactions are not supported by Application Continuity.

Figure 3. Close integration with Oracle Database Application Continuity shields Tuxedo applications from errors caused by recoverable database disruptions

Secure Deployments

Oracle security policies as defined by Oracle Software Security Assurance program require that Oracle products when deployed are secure by default.  Secure in this context means they only use encrypted communication, they use approved authentication, authorization, and cryptographic algorithms.  Deploying a product in an insecure fashion requires explicit configuration by the customer.  As a result, Tuxedo 22c by default requires that authentication and authorization be enabled, and that all network communication uses TLS with approved ciphers.  This may be difficult to implement or not needed for some Tuxedo customers, so Tuxedo 22c provides options to allow disabling certain security features such as TLS communication, and disabling authentication and authorization.  If customers choose to deploy in an insecure fashion by setting these configuration options, they will be warned in the Tuxedo ULOG that they’re deploying in an insecure fashion.  Other security enhancements include updates to open-source packages used by Tuxedo and security bug fixes.

Source: oracle.com

Continue reading

Announcing Oracle Transaction Manager for Microservices Free

Oracle is pleased to announce the availability of Oracle Transaction Manager for Microservices Free. This new product provides distributed transaction coordinator services for a variety of transaction protocols. Using this product, microservices developers can easily ensure the consistency of data across their microservices, even in the presence of failures. The coordinator itself is a microservice and readily deployed into a service mesh framework such as Istio/Envoy with Kubernetes.

As application architecture moves from monoliths, through SOA, to today’s microservices, issues crop up that monoliths and some SOA based applications don’t need to worry about. One area in particular is around data consistency. In a monolithic application, typically all data is stored in a single database. Consistency across tables is managed by local transactions to ensure the data remains consistent, i.e., an update to two tables either both succeed or neither of them succeed. Moving to microservices where each microservice maintains its own database, local transactions are no longer sufficient to provide consistency. This is where distributed transactions become a requirement.

Distributed Transactions

To help ensure data consistency across microservices, a distributed transaction is often used. Distributed transactions try to move a system from one consistent state to another consistent state. They are often utilized to handle the various failure scenarios that can occur in distributed systems, ideally without burdening the application developer with too much work. One of the earliest distributed transaction protocols is the XA two phase commit protocol defined by The Open Group. Using XA, applications can ensure that the updates to multiple data sources can be done while still adhering to the ACID guarantees of a transaction.

Multiple Supported Distributed Transaction Protocols

The initial release of the product is being offered for free and intended to allow developers to start leveraging distributed transactions in their microservice based applications. Support is provided for XA based distributed transactions, Sagas in the form of Eclipse MicroProfile Long Running Actions, and the Try-Confirm/Cancel transaction protocol. Microservice developers are free to choose the distributed transaction protocol best suited for their application based upon their application’s consistency requirements.

This initial free release provides support for microservices developed in:

◉ Java using Jax-RS in Helidon, WebLogic Server, and Spring Boot

◉ Typescript using Express.js

◉ PL/SQL using Oracle Application Express and Oracle REST Data Services

◉ C/C++/COBOL running in Tuxedo and exposed as REST services using SALT

◉ Oracle Blockchain Platform smart contracts

with more languages and platforms to come.

Microservice Based Transaction Coordinator

Transaction Manager for Microservices consists of a microservice based transaction coordinator that can be deployed into a containerized environment such as Kubernetes or Docker Swarm. Provided as well is a set of language specific client libraries that provide APIs and CDI annotations to access the transaction coordinator’s services. These libraries also include request and response filters to automatically propagate transaction context between microservices and enlist called microservices in the transaction.

Focused on Ease of Development

Using the supplied client libraries, applications can easily be extended to support their consistency requirements with a minimal amount of effort. In many cases with a few lines of code modified or added to an existing microservice it will be able to initiate or participate in a Transaction Manager for Microservices managed transaction. The included samples cover different use cases such as financial transactions requiring strong consistency, to making travel reservations with looser consistency requirements. Provided helm charts for Kubernetes, minikube, and Docker Swarm make deploying Transaction Manager for Microservices a simple task taking just minutes. 

Source: oracle.com

Continue reading