X

An Oracle blog about Tuxedo Tidbits

Recent Posts

Announcing TSAM Plus 12.2.2.1.0

Introducing TSAM Plus 12.2.2.1.0 The Tuxedo team has been busy over thelast few months making significant enhancements to TSAM Plus. Inthis short series of articles, I will cover the improved out of thebox experience and usability enhancements in this new release. Background TSAM Plus 12.2.2.1.0 builds on the manyenhancements made in the 12.2.2.0.0 release. Features like: Application payload capture –allowing the capture of request and response payloads withoutchanging the application. These payloads can then be used toperform business analytics using tools like Hadoop. Test load generator – a loadtesting tool that uses actual captured payloads to perform loadtesting, regression testing, and stress testing. Tuxedo as a Service – allowsdefining Tuxedo as a Service in private cloud environments.Administrators define the resources, quotas, services, etc., thatend users can request and use. A self service application allowsend users to reserve service instances that may include an entireTuxedo application. Application introspection –tools that greatly simplify moving an application from oneenvironment into another such as a cloud based deployment. along with a number of otherenhancements. What's new in 12.2.2.1.0 This release largely focused onimproving the out of the box experience and overall usabilityenhancements. Starting with an initial monitoring policy that iscreated and enabled during installation to customizable dashboards,this release significantly improves the user experience. Agent Aggregated Service Statistics One of the most powerful features ofTSAM Plus is that data is collected in real-time and on an event byevent basis. The TSAM Plus agent collects data at various monitoringpoints within the Tuxedo kernel and reports that data in real-time toTSAM Manager. TSAM Manager records the data in the database andcalculates statistics and other metrics based upon that raw data. This has several advantages such as real-time information and theability to drill down into each service call or callpath. Howeverthere is a cost associated with this, primarily in moving all thisdata from the monitored systems to TSAM Manager. This typicallymeans for applications with heavy loads, only some of the data can becollected as collecting all possible data for all possible servicecalls and callpaths would likely overwhelm TSAM Manager, the network,or the database. Without this data though, TSAM Manager is unable toproduce summaries or graphs of things like overall performance. In order to reduce the amount of datasent from the monitored systems to TSAM Manager and still be able toget summary data, this release introduces the capability for the TSAMAgent to aggregate performance metrics and have them collected byTSAM Manager on a scheduled basis. As the overhead to collect thedata locally on the agent side is minimal and TSAM Manager controlsthe polling rate at which this data is collect, this data can becollected all the time. The ability to collect data on individualservice calls or callpath still exists by enabling the appropriatemonitoring policies when needed or desired. This aggregated data is collected forall services and includes information such as wait time, executiontime, CPU time, and execution status. During each polling period thedata is accumulated by the TSAM Agent and then pulled by TSAMManager. TSAM Manager uses this data to create dashboards that canbe customized by the user. Here is an example of the All Domainsdashboard. New Dashboards Upon logging into TSAM Manager, thefirst page displayed will now be an All Domains dashboard for allmonitored domains or domain groups (more on domain groups later!) This dashboard can always be returned to by clicking on the Domainslink at the top of the component tree. Clicking on a domain or domain groupwill take you to a customizable Domain or Domain Group dashboard justfor that domain or domain group. The Domain Group Dashboard providesa summary of the domain group with the option of getting the details(Domain Group Details dashboard) of the domains in the group. Domain Groups are a new feature thatallows domains to be placed into groups to help organize the waydomains are shown. Domains can be in more than one group at a time. For customers that use replicated SHM domains that are essentiallyclones of each other, grouping them together allows you to see asummary of all those domains in a single dashboard. Along withDomain Groups, this release also provides the notion of Key Services. Up to 7 Key Services can be defined for a domain or a domain group. Charts can then limit the data they display to just those KeyServices, either taken together or graphed separately. Here's acustomized Domain Dashboard showing line graphs for the Key Services: Customizing Dashboards Clicking on the Customize button, userscan then modify or delete the existing graphs, add new graphs, rearrange the order of the graphs, and define key services. Dashboard customization also allows users to control the time framethe graphs cover, the width of the graph, and whether service metricsare averaged or individual lines for selected services or KeyServices. Here is an example of some customized graphs for theChicago Bankapp Domain dashboard: Dashboards can be set to automaticallyrefresh on a variety of intervals. Domain dashboards also providethe option to examine the detailed data that has been collected forthe domain. Each dashboard has a summary of outstanding alerts forthe domains included in the dashboard as well as the availability ofthe machines, groups, servers, and services within those domains. Adaptive Alerts Speaking of alerts, another new featureis the ability to define alerts based upon historical aggregatedservice statistics. This new type of alert allows comparing currentservice performance against performance statistics that werecollected previously. For example you could define an alert thatindicated the average wait time exceeded 120% of the wait time fromthe same period of time one week ago. As aggregated servicestatistics are collected by default upon installation, an initialalert definition is included as part of the install. It looks like: This alert definition will cause awarning alert to be generated should any aggregated servicestatistics reported exceed 120% of the hourly average wait time orresponse time from the same hour one week ago. Adaptive alerts areonly generated if there is data to compare against. So although thisdefault alert definition is present from installation time, the firsttime it could possibly be triggered is one week after installation. This alert definition, like any other alert definition, can be editedor deleted if desired. Conditional Callpath Monitoring One of the most powerful features ofTSAM Plus is callpath monitoring. Callpath monitoring provides theability to record the performance of all the steps in a sequence ofservice calls. For example, let's say a client calls service A whichin turn calls services B and C, and service C calls service D. Withservice monitoring, we can record the performance of each servicecall independently of any of the other calls, which is often enough. However there may be cases where a specific sequence of calls resultsin poor performance or execution errors. There is where callpathmonitoring can provide the necessary insight to discover thesesequences. In callpath monitoring, a correlationID is assigned to the initial call by the client. That correlationID is carried along with the other context information from caller tocaller. At each point in the callpath data is recorded andeventually sent to TSAM Manager which uses the correlation ID tostitch the callpath data together into one complete callpath. Thisoccurs across machines in a Tuxedo clustered deployment and acrossdomains when using the domain gateway. So in the above example,service C might be in another domain. As long as that domain and theoriginating domain are being monitored by the same TSAM Manager, allthe reported data will be correlated and presented as a singlecallpath. This gives the user very detailedinformation the steps taken by the application, even down to thedetails of each SQL statement execution if Oracle Database is beingused. The difficulty though is that providing all this detail meansall the data needs to be collected by each participating node andreported to TSAM Manager. Even for a simple call such as clientcalling a service that returns directly to the caller, there are 4points of data capture: When the caller places therequest on the server's request queue When the server retrieves therequest When the server places the replyon the client's reply queue When the client picks up thereply The data volume generated by callpathmonitoring can be huge and often most of it is uninteresting. To help reduce the amount of datareported by callpath monitoring, the TSAM Plus 12.2.2.1.0 releaseintroduces the notion of conditional callpath monitoring. The ideais that the callpath data will be collected on the monitored Tuxedomonitored machines, but it won't be reported to TSAM Manager unlesssome condition is met. Defining the condition under which thecallpath will be sent to TSAM Manager is done in the callpath tab ofthe policy creation page. Clicking on the Define Conditional Filterbutton takes you to a page like this: Here you can define an expression thatwhen evaluates to true means the callpath and potentially theprevious and later callpaths are to be sent to TSAM Manager. Thisallows much more monitoring of callpaths without incurring theoverhead that would otherwise be necessary.

Introducing TSAM Plus 12.2.2.1.0 The Tuxedo team has been busy over the last few months making significant enhancements to TSAM Plus. Inthis short series of articles, I will cover the improved out...

Tuxedo as a Microservices Platform

Tuxedo as a Microservices Platform Over the last several years there has been a lot of interest in Microservices Architecture (MSA), although the exact definition of MSA has been elusive.  As best I can tell MSA is largely a collection of characteristics describing a way to define and build services.  Some of these characteristics are: Small modular services often organized around capabilities - separation of concerns Independently replaceable/deployable - replacing the implementation of a service doesn't affect other services Each service runs in a unique process - isolation between service implementations Polyglot services - use the language best suited for the task Lightweight communications mechanism - dumb pipes, smart endpoints Decentralized data management - multiple persistence mechanisms Infrastructure automation - devops and continuous integration I'm sure there are other characteristics associated with microservices, though these seems to be the most common, and lacking an agreed upon definition, I'll address these characteristics in this post.   I'd also like to share an observation from Martin Fowler about the trade-offs made when selecting microservices: Benefits  Costs Strong Module Boundaries:Microservices reinforce modular structure, which is particularly important for larger teams. Distribution:Distributed systems are harder to program, since remote calls are slow and are always at risk of failure. Independent Deployment:Simple services are easier to deploy, and since they are autonomous, are less likely to cause system failures when they go wrong. Eventual Consistency:Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency. Technology Diversity:With microservices you can mix multiple languages, development frameworks, and data-storage technologies. Operational Complexity:You need a mature operations team to manage lots of services, which are being redeployed regularly.  Based upon the characteristics of microservices and the costs/benefits I'd like to propose that Tuxedo makes an excellent microservices platform.  Before I get into why I believe this to be true, I'd like to cover a little bit about what Tuxedo is, sort of a brief recap of an older blog article. Introduction to Tuxedo  Tuxedo, for those unfamiliar with it, is essentially a platform for developing transactional polyglot services.  Virtually everything in Tuxedo is a service, from the management of two phase commit XA transactions to handling point to point and publish and subscribe messaging.  Service invocations are handled via a combination of in memory queues, IPC queues, and network links, depending upon configuration and requirements.  Because of the lightweight nature of in memory or IPC communication, simple services can be executed in under 30 microseconds.  Services can also support network protocols such as REST or SOAP without any modification. Service implementations can be written in C, Java, C++, Python, COBOL, Ruby, and PHP.  Common frameworks such as Spring, Rails, Django, Symfony, and likely many others run just fine in a Tuxedo container.  Often existing code or entire applications can be simply run.  Services execute in a Tuxedo container, which is basically a process monitored by and under the control of Tuxedo.  If a service hangs or crashes, Tuxedo will automatically restart the service.  Multiple copies of services can be run to improve availability or performance, and those copies can be run across a cluster of machines.  Tuxedo automatically load balances requests across copies of services to minimize response time.  Tuxedo is known for handling extremely demanding workloads as illustrated by the leading TPC-C benchmark that used Tuxedo and Oracle Database to achieve over 500,000 transactions/second. Tuxedo Services vs Microservices  The characteristics of microservices listed above largely describe how services should be defined and implemented.  Let's look at those various characteristics and see how well they are supported or not by Tuxedo. Small modular services often organized around capabilities The modularity of services is largely a factor of architecture and design, and not particularly dependent upon the technology stack used to implement the services.   For example, one could define a service called Add that takes two numbers and returns their sum in almost any environment.  Likewise one could create an ERP "service" that performs all the functions of an full fledged ERP system.  Tuxedo applications are often built out of small modular services.  Related services are then typically bundled into servers that host the business logic implementing those services.  Thus it is natural in Tuxedo to organize services around capabilities. Independently replaceable/deployable Replacing the implementation of a service doesn't affect other services.  Large systems will contain many services, and if built using microservices even more services.  The ability to replace a service implementation with a new implementation without affecting other services is key to providing a highly available application.  In Tuxedo, bringing up a new implementation of a service is simply a matter of booting a server that supports the service for C, C++, and COBOL services.  For Java, PHP, Python, and Ruby, new service implementations can be loaded into an existing server.  To ease the transition from old to new, Tuxedo supports service versioning which allows side by side deployment ensuring that older clients can still function while new clients make use of the new versions of services. Each service runs in a unique process By running services in different processes, the operating system will provide isolation between services limiting their interaction through well defined interfaces or communication protocols.  This is as opposed to environments such as JEE where large number of often unrelated services are deployed to the same JVM.  In Tuxedo, service implementations run in a container (called a server in Tuxedo, which is a unique process) that Tuxedo manages and monitors.  How many services are deployed to a single container is purely a matter of choice.  A server can have 1, 2, 10, or 100 service implementations contained within it.  As the Tuxedo runtime is written in C, the Tuxedo footprint and overhead per process is extremely small.  Generally services are bundled together within a server that are functionally or capability related, although that is not a requirement. Polyglot services Use the language best suited for the task.  Many application platforms support a single language, whether that's Java, PHP, Python, or C.  This make creating the application platform simpler, but then forces developers into using that language, whether they have the required skills, or available packages in that language, to get their job done.  Core services that are called frequently may be best suited for C or C++, whereas other services called far less frequently might be faster to develop in Python or Ruby.  Its possible that you have a set of assets in the form of code libraries or other intellectual property developed in a certain language you'd like to use for your new application.  Monolingual platforms based on another language would force you to rewrite those assets, or run multiple platforms. Tuxedo natively supports polyglot services.  Service implementations can be written in C, Java, C++, Python, COBOL, Ruby, and PHP.  Services written in one language can freely call services written in another language.  Regardless of the language a service is written in, it can be accessed and used via native Tuxedo protocols, or via REST or SOAP without any modifications to the service.  As services in Tuxedo are only known by name, clients are unaware of the location or implementation of a service.  Likewise services are unaware of the location (to a certain extent) and implementation of client applications. Lightweight communications mechanism A phrase used by Martin Fowler is to employ smart endpoints and dumb pipes.  This flies somewhat in the face of many SOA implementations that rely on an enterprise service bus  (ESB) to provide smart pipes that perform complex routing functions, apply business rules, perform message transformation including enrichment, etc.  In a microservices based application, endpoints talk directly to each other with minimal work being done by the transport mechanism.   Tuxedo's communication mechanism is mostly dumb pipes.  The pipes know how to route a request to a service to yield the lowest latency, i.e, load balancing or more appropriate load optimization.  The pipes can perform slightly more sophisticated routing that includes data dependent routing to facilitate things like partitioning or sharding. Tuxedo leaves more sophisticated things up to the application such as message enhancement, choreography, and business rules.  In its simplest form, Tuxedo merely places a request for a service on a System V IPC queue that one or more servers are waiting on.  The server picks up the message, dispatches the message to the appropriate service implementation and then places any reply that is generated back on another System V IPC queue. To support REST or SOAP based communication, applications can leverage SALT to provide access to their Tuxedo services as REST or SOAP based services.  Similarly applications can use REST or SOAP based services transparently using SALT.  In either case, the server and client are unaware of the location or implementation of the service being invoked or invoked.  The use of REST or SOAP is simply a matter of configuration. Decentralized data management Multiple persistence machanisms - Perhaps one of the biggest departures from traditional SOA or monolithic applications is around persistent data.  In a monolithic application and in many SOA applications, there are limited numbers of persistent data stores, often only one or at most two relational databases.  In a microservices based application, there may be many different persistent data storage mechanisms.  Each microservice owning its own persistent storage.  This reduces coupling among services, making it easier to replace a service implementation without affecting other services.  If services share a common database, then they probably share common schema.  Changing a shared schema then impacts multiple services, and a schema change may be necessary when a service implementation is updated. There are a number of drawbacks to having many highly decoupled persistence mechanisms, not the least of which is consistency.  Traditional systems have used distributed transactions to ensure consistency among multiple persistent storage mechanisms.  Some have adopted idempotent operations that can be safely replayed using at least once algorithms to try and make the different persistent storage mechanisms consistent.  However most other solutions employed move the burden of consistency to the application and out of the infrastructure.  It's called eventual consistency and relies on the application to ensure that persistent data is eventually consistent.  For simple applications, this is relatively easy to accomplish.  For complex applications where an operating involves a number of services, this can be extremely difficult, especially if atomic consistency is required. Tuxedo is largely data persistence agnostic.  Services can use whatever persistent storage mechanism they like.  Where Tuxedo comes into play with persistent storage is in providing transparent global consistency using XA transactions.   Services are free to implement their own consistency mechanisms and achieve eventual consistency, but they are also free to use XA transactions to ensure consistency without a lot of application logic to handle failures and recovery. Infrastructure automation Devops and continuous integration - it seems that microservices and infrastructure automation go hand in hand.  Clearly you can use one and not the other, but the trend is certainly to combine them as they are somewhat synergistic.  The ability to automate the testing and deployment of services greatly increase the speed with which new services or new service implementations can be put into production.  Automating as much of the development process also leads to more productive development teams.  By using microservices, new services or updated service implementations can be pushed out into production with minimal impact on other services. Tuxedo doesn't provide any explicit support for devops or continuous integration, although nothing prevents teams from using those techniques in building microservices based on Tuxedo.  In fact, I'd love to get people to share their Tuxedo related Chef recipes, Jenkins plug-ins, Puppet modules, Ansible plugins and modules, and Docker and Compose files. Microservices Benefits and Costs Going back to Fowler's benefits and costs of microservices, let's see how Tuxedo could play a role in supporting those benefits and mitigating some of the costs. Benefit: Strong Module Boundaries Strong module boundaries are more a function of architectural and design decisions than the technology to implement the modules.  Monolithic applications can have strong module boundaries, but often don't as it is too easy to access things inside another module in a monolithic application.  With microservices the only interaction that can occur between modules is via the services the module offers.  As each service is in a separate process or address space, accessing anything inside of a module not exposed through services is impossible. With Tuxedo you choose the strong module boundaries by choosing what services are bundled together into a server.  All the services in a server run in a single process and could potentially have access to information or state used by other services in the same server.  Thus you could employ a one service per server model which would provide the highest level of isolation, although potentially at a small cost in performance.  Alternatively you could build your application with all services in one server, although that would basically be a monolithic application approach.  Most Tuxedo applications are somewhere in the middle.  Related services that can benefit from sharing of state or other information via internal in process mechanisms or using the same persistent data store are often grouped together into a server.  Tuxedo doesn't impose any specific bundling requirements or limitations, so the choice is completely up to the architect or developer. Cost: Distribution One of major issues associated with microservices is the cost (latency) of performing service executions.  How much of an issue this is depends largely on the granularity of the services and the cost of calling a service.  If the cost of calling a service is 200 microseconds and the service takes 100 microseconds to execute, using microservices instead of local procedure call that takes essentially 0 microseconds, degrades performance significantly.  However if the service takes 5 milliseconds to execute, the 200 microseconds of overhead to make a service call is insignificant. As services become more fine grained heading towards nanoservices, the cost of performing a service call becomes more significant.  The ratio of service execution time vs cost of invoking a service drops as services become more fine grained making the importance of light weight service calls more important.  How much this impacts any given service is application dependent, but the trend towards finer grained services increases the impact of service invocation costs. Tuxedo provides an extremely lightweight and low cost service invocation mechanism using interprocess communication queues.  Services can be invoked in under 35 microseconds, making the cost of a service invocation nearly negligible for services that take 100s of microseconds to execute.  With SALT any Tuxedo service regardless of implementation can be accessed as a SOAP or REST based service without any changes to service implementations.  As well services can make use of external SOAP or REST based services using SALT.  By using a gateway approach services are potentially isolated from external changes.  The gateway is configuration driven and uses service metadata to transform the request from SOAP or REST to Tuxedo and vice versa.  Benefit: Independent Deployment Being able to deploy services independently of other services makes maintenance and upgrades far easier.  Deployment of monolithic applications is fraught with problems.  A problem in one part of the application often meant that the a new version would have to be rolled back.  As well the deployment of a monolithic application often took hours to days to perform and while that was happening the application was unavailable.  By using microservices that can be independently deployed, the impact of a problem in a service is limited to just that service.  Rolling back that service can often be done in seconds or minutes as opposed to hours or more.   Tuxedo applications are built out of many servers, each offering a set of related services.  To replace a server or group of services, all that is necessary is to update the service binary for native services, or the in the case of Java or scripting languages, simply update the classes or scripts for the service or services in the server and ask for the serve to reload those implementations.  This allows services to be updated without impact other services or incurring significant down time. Cost: Eventual Consistency  Eventual consistency is a code phrase for pushing consistency concerns to the application.  Eventual consistency is difficult to achieve and requires a high level understanding all the state information in an application.  It also requires extensive testing to ensure that all possible failure scenarios that could lead to inconsistent state have been accounted for.  Microservices push for service specific persistent data stores that are only under the control of the microservice creates these islands of state.  Without some external mechanism such as distributed transactions to ensure the consistency of these islands it is highly likely inconsistent data will be seen.  If that inconsistent data is acted upon, it may be extremely difficult to achieve consistency.  For example lets use the case of an on-line order.  The user presses buy and gets a purchase confirmation.  They then check their pending orders and find out that the order isn't there because the state of the system hasn't reached consistency.  Maybe it's as simple as having hit two different servers between the buy request and the check orders request.  Or maybe as the order was being processed it was discovered the items were out of stock or discontinued.  The user unsure of what's happened might place the order again, might call customer services, or any number of other actions only because they saw inconsistent state information.  As the number of services involved in a transaction like this increases so does the number of possible inconsistent states and likely the time required for the state to become consistent. While discouraged by some, distributed transactions can easily solve this problem.  Tuxedo provides XA based distributed transactions transparently to service implementations.  XA ensures that states atomically transitions from one state to another without the possibility of seeing inconsistent state.  Either all updates happen or none of them happen.  The drawback is that locking of state information occurs to prevent seeing the partially updated state.  This can cause performance issues in extremely high volume applications, although Tuxedo is readily able to scale to thousands of transactions per second.  Perhaps though the biggest benefit of distributed transactions is that it removes the concern of state consistency from the application and places it in the infrastructure.  So as long as the infrastructure has a proven distributed transaction implementation, you can be guaranteed your state will be consistent, whereas if you leave it up to the developer to provide eventually consistency, you are place an enormous amount of trust in your developers to handle corner cases and other hard to identify or correct errors. Benefit: Technology Diversity The ability to choose the right tool for the right job is one of the major attractions of microservices.  As each service is deployed independently they can use whatever technology is best suited for their implementation.  This includes choice of language, choice of persistent storage, choice of modularity, etc.  Most monolithic applications are developed using a single language and single persistent storage mechanism.  The choices that were made when these monolithic applications were first developed may no longer be the best choices as new technology becomes available.  This is most obvious in mainframe applications written in COBOL.  The choices made when these applications were built were based upon extremely limited options for developing enterprise applications.  As newer languages were developed it was difficult if not impossible to leverage them in these monoliths. Out of the box Tuxedo supports a variety of service implementation languages.  From traditional native languages such as C, C++, and COBOL, to newer languages such as Java, even to scripting languages such as Python, Ruby, and PHP, Tuxedo supports them all for service development.  This gives the developer the option to choose the language that best fits their needs, either due to inherent features in the language, or due to specific libraries that may be available.  While bindings aren't currently available for other languages such as Javascript or Perl, developing these would not be difficult as they can readily call native language bindings and be called from native languages. Tuxedo also offers developers a choice of persistence mechanisms as Tuxedo doesn't proscribe any specific persistence technology.  Developers are free to use relational database, key value stores, key value caches, object databases, or any other mechanism best suited for the service being developed.  For persistent stores that support XA, Tuxedo can manage distributed transactions across services transparently to the application. As each Tuxedo server is a separate process, they can use different versions of libraries or other artifacts without having to settle on a single version as is the case with many monolithic applications.  Thus new versions of libraries can be adopted by some services while other services using older libraries continue to function without change.  This help mitigate the version dependency problem that often plagues developers.  Cost: Operational Complexity Monoliths greatly simplify operations, administration, and management as teams have far fewer things with which to deal.  Typically it's one operating system, one language, one database, one monitoring system, and more.  There are fewer technologies to learn and processes and procedures to put into place.  Microservices on the other hand can significantly complicate the operations, administration, and management of an application.  Besides the potential multitude of tools and technologies used to build the microservices, there are likely to be smaller but far more frequent updates made to the production system.  If continuous integration is used, then new or updated technologies may get introduced as part of the update of a service.  Operations may have to learn how to troubleshoot many different but similar technologies as one service might have chosen Oracle NoSQL for their state information, another chose Berkeley DB, and yet another a relational database such as Oracle Database.  This could result in having to develop three different backup procedures, three different data recovery procedures, three different monitoring scripts or tools to use, and so on, just for persistent storage. Where Tuxedo can help in this area is by providing out of the box monitoring regardless of language, libraries, or frameworks used.   Tuxedo monitors servers and ensures that they are running and not dead or hung and if they are to automatically restart them.  It provides a centralized logging facility that all servers can  use.  When augmented by TSAM Plus detailed application and service performance data can be collected and monitored to ensure service level agreements are being met.  Service request and response payloads can be transparently collected and stored in Hadoop or a relational database for later analysis with business intelligence tools such as Oracle Business Intelligence.  Those payloads can also be used to replay service requests to check for regressions or load test your services. Summary Microservices are transforming the way applications are designed and built.  By breaking an application into many microservices, each running independently in their own process and only accessed by a service invocation, developers gain benefits such as strong module boundaries, independent deployment, and technology diversity.  This isolation and independence allow multiple teams to work concurrently on an application while minimizing the interactions needed between teams and the services they're implementing.   Some of the costs associated with microservices can mitigated by building them using Tuxedo as the platform.  Tuxedo applications often built using a microservices architecture principles as pretty much everything in Tuxedo is a service.

Tuxedo as a Microservices Platform Over the last several years there has been a lot of interest in Microservices Architecture (MSA), although the exact definition of MSA has been elusive.  As best I...

Tuxedo Mainframe Transaction Publisher

With all the technology advances and more and more apps moving to cloud, a vast number of mission-critical back-end apps are still running on mainframes. These applications are often the backbone of business as mainframes are seen as providing needed performance, reliability and scalability. With new UIs being developed using newer technologies in Java and many other programming languages and running on open systems, integration of mainframe applications with such front-end applications is a real problem. This problems needs a solution, which is at par, if not exceeds, the performance, reliability and scalability of mainframes. Tuxedo mainframe transaction publisher is a solution which enables one to integrate CICS/IMS applications running on system Z with outside world. Integration is bi-directional: one can invoke external Web services, SOAP or Rest APIs, from CICS/IMS transactions or one can expose CICS/IMS transactions as Web services (again SOAP or Rest). In addition, TUXEDO MTP enables one to directly integrate with oracle Service Bus. Using this integration you can also use 2-phase commit XA transaction across the transaction life cycle and across the OSB, Tuxedo and mainframe. The picture below describes the architecture of this integration: Let’s consider a use case. You have a requirement to access a CICS transaction, CustEnq, from a mobile app and your mobile app needs SOAP/http access to CustEnq transaction running on mainframe. Let’s first look at what is in Tuxedo MTP. It consists of following three components: Tuxedo: Tuxedo provides the core messaging infrastructure. SALT: This is the Web services gateway for Tuxedo, responsible for communication with Web services clients and/or external Web services. All the conversion from XML and/or JSON to COBOL copybook format happens in this gateway. This gateway also interacts with TMA on the other side. Tuxedo Mainframe Adapter (TMA): This is the mainframe gateway, which provides bi-directional connectivity to mainframe applications. There are two components of this adapter: GWSNAX runs on the open system side (i.e. on a Unix or Windows machine) and CRM, which generally runs on the mainframe where your mainframe application is running. CRM is a proxy for Tuxedo on mainframe and responsible for interacting with mainframe transactions. Now, after you have gone through the installation Tuxedo MTP, the first step is to get the COBOL copybook for CustEnq and import it into Tuxedo Services Console. Using the console, you can identify which fields are needed in the request message and which ones are needed in the response message. If you need all fields from the copybook in both request and response messages, you do not need to anything. Based on the copybook definition, Tuxedo MTP generates a number of artifacts, including transaction definition, which is loaded in Tuxedo metadata repository. Once you specify a few other parameters such as Web service name, binding for Web service etc. , Web service definition and domain configuration are generated, which are loaded in SALT and TMA configurations respectively. A WSDL for the CustEnq transaction is also prepared, which can now be used by the mobile app. This is all that is needed to access CustEnq as SOAP/http Web service. No programming is needed whatsoever – not even for data conversion from/to XML or JSON. Similar steps are required to access CustEnq as Rest API or to access external Web services from mainframe transactions. For detailed information about configuration, see Tuxedo documentation at:  Mainframe Transaction Publisher. Why you should use Tuxedo MTP as opposed to other solutions available in the market? Here are a few benefits of using Tuxedo MTP: 1.No coding required solution: Tuxedo MTP is a configuration driven solution. No coding is required whatsoever. This makes it simple and extremely quick to deploy this solution to extend reach of your mainframe transactions. 2.Tuxedo MTP has negligible overhead on the mainframe MIPS. We all know that mainframe MIPs are really expansive to use and increasing MIPs usage is the last thing you want to do. With Tuxedo MTP, the only component installed on mainframes is a CRM process, which acts as proxy. Almost all of the processing is done on the open system side by the GWSNAX gateway. 3.Built-in RASP features: With Tuxedo MTP, reliability, availability, performance and scalability come default with it. Tuxedo gateways can be easily configured for redundancy and for scale out/up. Tuxedo MTP can also be configured to work in sysplex environment. 

With all the technology advances and more and more apps moving to cloud, a vast number of mission-critical back-end apps are still running on mainframes. These applications are often the backbone...

Introducing Oracle Tuxedo 12.2.2 Services Console

Oracle Tuxedo 12.2.2 introduces a new console,  Tuxedo12.2.2.0.0 Services Console.  Purpose of this console is to provide afunctional user interface for Tuxedo services management, including servicedefinitions, export, import etc.   In the current release, theconsole is specifically used to manage Tuxedo metadata repository, export orimport Web services (SOAP and/or REST) and for mainframe transactionpublishing.  This post briefly describes each of these functions of theconsole and then describes how you can start using the console with yourapplication.  Metadata repositoryeditor: While Jolt has had a repository for Tuxedo servicedefinitions since Jolt’s inception in late 90’s, concept of metadata repositorywas introduced in Tuxedo core with introduction of SALT Web services. Tuxedometadata repository contains application service definitions, which includeinput/output/error buffer types and associated fields and types.  The servicedefinitions are used to generate WSDL, convert XML or JSON messages into Tuxedobuffer types and vice-versa.   The console enablesadd/edit/delete of service definition entries in the metadata repository. It also enables one to discover service definitions in existing applications atruntime. Discovered definitions are automaticallyentered into the repository.   The console provides a consolidated view of all servicesavailable in the repository as well as services, which are exported or imported as SOAP or RESTful Web services. The services console also serves as a replacement for theJolt repository editor.  In Tuxedo 12.2.2, we have deprecated Joltrepository and its associated editor. This means, you must migrate Jolt repository to Tuxedo metadatarepository and use this console as the repository editor.     Export/Import of Webservices: (SOAP and RESTful): The console makes it much easier to export an existingTuxedo service via a intuitively design user interface.  Existingapplication services can be exported as SOAP/http or as RESTful Webservices.  The console also enables import of external SOAP/http andRESTful Web services into a Tuxedo application by importing an existing WSDLfor SOAP/http services and by importing a JSON definition for RESTful Webservices. Mainframe TransactionPublisher: The console enables export of mainframe transactions asSOAP/http or RESTful Web services.  Mainframe transactions could berunning on an IBM mainframe in CICS or IMS applications. In order to exportsuch transactions as Web services, one just need to import COBOL copybook forthe transaction and perform a few additional steps to export it as a Webservice.  No coding required. Similarly if an application requires accessto an external SOAP or RESTful Web service,  it can be done via the consoleby importing WSDL or REST service definition into the console.   For more information see http://docs.oracle.com/cd/E72452_01/salt/docs1222/config/config.html#wp1138915. The console also supports export of mainframe transactionvia Oracle Service Bus.   How do I get started with the console? It is relatively simple to get started with the console ifyou already have a running application. It’s a two or three step processdepending upon what you want to use the console for. #1: Given that we are talking about metadata all around, youneed to make sure that TMMETADATA server is already configured in yourubbconfig.  If not, add this server to your ubbconfig.   Anentry for TMMETADATA will look like following: TMMETADATASRVGRP=GROUP1 SRVID=2 CLOPT="-A -- -f my_meta.repos" my_meta.repos is a file of your choosing where you want metadatarepository stored. If you already have ametadata repository, you could use that repository here.  #2:  You need to have TMADMSVR added to the ubbconfig. TMADMSVR serves http related to the console.  Note TMADMSVR is not ageneral purpose http server – its purpose is very specific to theconsole.  An entry for TMADMSVR will look like the following: TMADMSVR SRVGRP=GROUP1 SRVID=3 CLOPT="-A -- -a http://localhost:4011" http://localhost:4011/admin/index.html is the URL toaccess the console.   #3:  If you are going to use the console for METADATArepository editing, then you are done. You can start using the console nowusing the URL mentioned in step #2. However, if you are going to use consolefor export/import of SOAP or RESTful Web services, then you need to have SALTgateway configured in ubbconfig.  GWWS is the SALT provided system server,which must be added to the ubbconfig.  An entry for GWWS would like thefollowing: GWWS SRVGRP=GROUP1 SRVID=4 CLOPT="-A -- -i GWWS1" Now you are all set.  You can start using the consoleusing the URL mentioned in step #2.  What is the minimum software level needed to use theconsole: The Services console is available and fully functional inTuxedo and SALT 12.2.2 GA version.  It is recommended that you installTuxedo RP004 or above and SALT RP002 or above in order to get the most benefitout of the console.  Frequently asked questions: 1.    1. Must I use SALT in order to use the newconsole?           No.  SALT and a correspondinglicense is required only if you are planning to export/import web servicesand/or mainframe transactions.  You don’t    even  need to install SALTproduct in order to use the console, if SALT functionality is not needed. 2. Do I have to use the console in order to usemetadata repository server in Tuxedo 12.2.2.  While the console makes itmuch-much easier for you to edit the repository, it is not required that you usethe console.  3. I have a lots of services in my current Joltrepository.  Do I need to reenter those services in the new repository?  You can use tmunloadrepos to create a text version of  Jolt repository and then use tmloadrepos with this text version to load the definitions into the Tuxedo metadatarepository.  Any differences in the entry format is taken care ofautomatically. See http://docs.oracle.com/cd/E72452_01/tuxedo/docs1222/jdg/dvmigrate.html for more information.   4. What happens to the JREPSVR, which is configuredin my application? JREPSVR is not used anymore.Services provided by JREPSVR are now included in TMMETADATA server.  Ifyou have JREPSVR already configured in ubbconfig, you can simply remove it fromubbconfig and instead add TMMETADATA in its place.    5. Do I need to change my Jolt client code in orderto upgrade to Tuxedo 12.2.2?          No change in Jolt client code,whatsoever, is needed.          6. I need to export a mainframe transaction runningin CICS application on IBM mainframe.  However, my organization hasstandardized on Oracle      Service Bus.  Can the Tuxedo Services Console stillhelp me with this?   Yes.  The console provides functionality toimport COBOL copybook for the mainframe transaction and generate all theartifacts required to deploy business and proxy services to the OSB.  Theprocess is similar to what you will do to export such transactions viaSALT.  It is just that instead of generating SALT configuration, wegenerate OSB artifacts for deployment into a running OSB instance.

Oracle Tuxedo 12.2.2 introduces a new console,  Tuxedo 12.2.2.0.0 Services Console.  Purpose of this console is to provide a functional user interface for Tuxedo services management, including serviced...

Oracle Tuxedo User Group North America - Invitation to the meeting

WHEN: Thursday, October 20th, 2016 WHERE: Bridgewater, NJ(New York City Metro Area) Dear Tuxedo Customers and Partners: We arepleased to invite you to the Oracle Tuxedo User Group meeting to be held thisyear at our offices in Bridgewater, NJ.  Your participation in this oneday event will help shape the Oracle Tuxedo product family in the direction ourmost important users, YOU, want it to go.  Not only that, we are confidentthat it will help you network with other Oracle Tuxedo users and learn fromeach other.  OracleTuxedo product family had several major versions of the product released in thelast few years, each version rich in features and functionality, such as cloud enablement and monitoring/management via TSAM Plus. Tuxedocontinues to be actively developed with Tuxedo 12.2.2 version released earlierthis year.  We would like to provide product update, share our roadmap,and enable you to share in the Tuxedo user community’s experience with theproducts. AgendaTopics: · Introductions · Tuxedo Update from PM Team (recent releases, investments) · Customer/partner Use Cases · Mainframe Modernization using Tuxedo/ART · Monitoring Tuxedo apps the right way · Get more out of your Tuxedo apps – Tuxedo in Private/PublicCloud · Product Demos (focused on recent updates, including appmigration to OPC) · Open Discussion (Q&A, requirements) Time: 10am – 4pm, lunch will be provided RSVP: Please register by October 7th via emailto Deepak Goel andinclude the following information: Full name, Company represented, Emailaddress, Mobile phone. Registration and attendance is free. Please also indicate if you will attend Networking Dinner at 6pmfollowing the User Group meeting. Dinner venue: TBD

WHEN: Thursday, October 20th, 2016WHERE: Bridgewater, NJ (New York City Metro Area) Dear Tuxedo Customers and Partners: We arepleased to invite you to the Oracle Tuxedo User Group meeting to be held...

Tuxedo Event Broker

The Tuxedo event broker is an often overlooked component of Tuxedo.  It is extremely powerful and can be used to solve a variety of problems.  This series of blog entries will cover how the event subsystem in Tuxedo can be used. Events in Tuxedo are essentially named buffers that can be published to subscribers.  The Tuxedo event brokers implement publish (post) and subscribe model with events being delivered to subscribers using a variety of mechanisms.  Application components interested in receiving notification of an event being posted can register a subscription.  Subscriptions and the associated delivery or notification of events is handled by two Tuxedo system servers, the System Event Broker (TMSYSEVT) and the User Event Broker (TMUSREVT).  The only difference between a system event and a user event is how the event is named.  Tuxedo system event names all begin with a period ".", whereas the names for user events must start with anything other than a period. An application typically uses the tpsubscribe() API to register a subscription for an event, although the MIB can be used to create a subscription as well.  Subscriptions includes a regular expression that is used to indicate what events the particular subscription is interested in receiving.  Along with the regular expression, a filter based upon the contents of the associated buffer can be defined to further refine which events the subscription is interested in receiving.  For fielded buffer types, the filter is a boolean expression composed from the fields in the buffer.  For STRING buffers it is a regular expression that is applied to the buffer contents.  When an event is posted using tppost(), the event name is compared against the regular expression of all subscriptions.  If the event name matches the regular expression and the filter evaluates to true or matches in the case of a STRING buffer, then the posted event is delivered to the subscribers. Any Tuxedo buffer type can be associated with an event and the type of buffer associated with any particular name can change from event posting to event posting.  Events can be delivered in a variety of ways.  A client can subscribe to have events delivered to its unsolicited message handler.  Events can also be delivered to a service, placed on a /Q queue, written to the ULOG, or passed to a command line.  For example, this call to tpsubscribe("DEPOSIT", "AMOUNT > 10000", NULL, NULL) by a Tuxedo client would cause all events named DEPOSIT that have a field named AMOUNT that is greater than 10000 to be delivered to the clients unsolicited message handler. Subscriptions to /Q queues or to a service using tpsubscribe() require a event control structure parameter that defines either the service name or the queue information necessary for the event broker to deliver the event notification. More in my next post...

The Tuxedo event broker is an often overlooked component of Tuxedo.  It is extremely powerful and can be used to solve a variety of problems.  This series of blog entries will cover how the event...

Announcing the Tuxedo Advanced Performance Pack

Well now that the busyness of OpenWorld is behind us, it's time to spice things up here on the Tuxedo blog.  The Tuxedo team is pleased to announce the availability of the Tuxedo Advanced Performance Pack.  This add-on option for Tuxedo improves application performance, availability, and manageability.  I'll briefly describe the features and benefits of this new option, but for more details please see the newly published white paper. The Tuxedo Advanced Performance Pack has three major categories of enhancements: Core enhancements that all Tuxedo applications can leverage Oracle Database related enhancements for those applications using Oracle Database Oracle RAC using XA distributed transaction enhancements for customers using Tuxedo and RAC with XA transactions Together these enhancements can improve application performance by a factor of 2x to 3x, without any changes to application code.  In fact, all of the features provided by the Tuxedo Advanced Performance Pack are enabled simply by making a small change to the Tuxedo configuration file.  The core enhancements include: Self-tuning Lock Mechanism to automatically and dynamically set the value of SPINCOUNT to optimize the access to Tuxedo semaphores such as the Bulletin Board lock.  Shared Memory Interprocess Communication - Instead of using System V IPC message queues to communicate between processes, the Tuxedo Advanced Performance Pack provides a facility to use shared memory based messaging.  The result is a reduction of buffer copies normally needed with IPC queues to zero copy messaging, all in user mode.  For applications using large buffers, the performance improvement under heavy load should be dramatic. Tightly Coupled Transaction Branches Spanning Domains - This feature allows Tuxedo to use the same GTRID for distributed transactions that cross domain boundaries, such as one Tuxedo domain calling another Tuxedo domain, or WTC calling a Tuxedo domain.  This allows the sharing of locks and updates to resource managers preventing things like deadlocks that might have otherwise occurred.  As well when used with RAC, if the participating domains were connected to the same RAC database, then RAC will respond with XA_RDONLY for all branches but the last, speeding up transaction commits. Concurrent Global Transaction Table Lock - This feature moves the synchronization of access to the Tuxedo global transaction table (GTT) out from under the Bulletin Board semaphore, to its own semaphore.  As well each transaction in the table has it's own semaphore to allow concurrent updates to the entries.  This eliminates and lock contention for applications making heavy use of XA transactions. These next set of features benefit Tuxedo applications that utilize Oracle Database: Instance Awareness - Although technically a feature of the Tuxedo Advanced Performance Pack, it's real benefit is in what other features it allows.  Essentially this feature lets Tuxedo know the details of Oracle Database connections.  In other words, what database, service, and instance any given Tuxedo server is using. FAN Support - The Tuxedo Advanced Performance Pack introduces a new Tuxedo server, TMFAN, that connects to Oracle Database ONS to receive FAN notifications.  With this information, Tuxedo can make intelligent decisions based upon the configuration and state of a RAC database.  This enables the following features: Planned Maintenance - When TMFAN receives a notification of planned maintenance for a RAC instance, TMFAN directs the Tuxedo servers connected to that instance to switch their connections to another instance to provide uninterrupted availability. Unplanned Outages - The TMFAN server will get an ONS notification that an instance has failed, and as a result will remove Tuxedo servers connected to that instance from service routing selection.  The affected Tuxedo servers will be told to switch their connection to another instance and resume processing.  Thus eliminating in most scenarios any outage by client applications. RAC Load Balacing - FAN periodically notifies RAC clients about how their load should be distributed across RAC instances.  When TMFAN receives a load balancing advisory, it attempts to ensure that the Tuxedo load for that database adheres to the advisory by changing the routing of requests, and changing the number of connections to each instance. End-to-End Application Tracing - One of the more difficult jobs for a database administrator is identifying the source of problems.  With this feature, Tuxedo will automatically tag Oracle Database sessions with the name of the Tuxedo server, service, and client information.  Thus a dba can quickly locate Tuxedo applications, servers, services, or clients that are causing performance problems and work with the development team to remediate those problems. Finally these features help applications that use Oracle RAC with Tuxedo distributed transactions: Common XID - The tightly coupled transaction branch feature allows a GTRID to be shared across domains.  This feature extends that to allow the use of a single XID across Tuxedo servers and domains when requests end up using the same RAC instance.  The result is that in many cases instead of having a number of separate but related GTRIDS, and potentially a number of different transaction branches for the same RAC database, all requests if possible use the same instance and the same XID.  Ultimately this could result in a single one phase commit instead of a protracted cross domain two phase commit. Partial One Phase Read-Only Optimization for RAC - Distributed transactions that span RAC instances have separate transaction branches for each instance involved in an XA transaction.  When a transaction manager prepares these various branches, Oracle Database does an optimization where it reports XA_READONLY for all branches but that last.  This feature leverages that capability by preparing all transaction branches but one.  If all other branches report read-only, then the final branch can be committed with a one-phase commit, bypassing the prepare step and the transaction log write.  This can substantially improve the performance of applications that primarily use RAC. XA Transaction Affinity - This feature attempts to minimize the number of RAC instances involved in a distributed transaction.  During the routing of a request, Tuxedo will give preference to servers that are connected to a RAC instance that is already enlisted in the transaction.  The result is a smaller commit tree and the potential for a one phase commit if RAC is the only resource manager involved in the transaction.  As well, minimizing the number of RAC instances involved in the transaction minimize the amount of cross instance traffic within RAC. Single Group Multiple Branches - Normally Tuxedo associates a single transaction branch with a Tuxedo server group.  This presents difficulties if the server group is using a RAC based database service as RAC does not allow a single transaction branch to span RAC instances.  This feature allows a Tuxedo server group to use multiple transaction branches if necessary.  The result is that Tuxedo servers using XA transactions with RAC can now use database services that are offered on multiple instances.  If the particular Tuxedo server a request is routed to is associated with a new instance for the transaction, the Tuxedo Advaned Performance Pack will create a new transaction branch for the newly enlisted instance. All of these features add up to huge improvements in application performance, application availability, and simplified management.  Tuxedo servers using XA can now fully utilize the features of Oracle RAC including non-singleton services to improve performance and availability.  The integration of FAN into Tuxedo means that Tuxedo can dynamically respond to changes in RAC load and configuration, without any operator intervention.   Together they provide an unbeatable combination of performance, availability, and manageability.

Well now that the busyness of OpenWorld is behind us, it's time to spice things up here on the Tuxedo blog.  The Tuxedo team is pleased to announce the availability of the Tuxedo Advanced Performance...

User Group Meeting Invitation

North American Tuxedo User Group Meeting  The Oracle Tuxedo product management team would like to invite you to this year's North American Tuxedo User Group Meeting being held in Chicago on Thursday October 8, 2015.  Your participation in this one day event will help shape the future of the Oracle Tuxedo product family in the direction our most important users, YOU, want it to go.  Not only that, we are confident that it will help you network with other Oracle Tuxedo users and learn from each other.  The Oracle Tuxedo product family has had several major releases over the last few years, each release rich in new features and functionality. Tuxedo continues to be actively developed with Tuxedo 12.2.2 version planned for 2016.  We would like to provide you with product updates, share our roadmap, and enable you to share in the Tuxedo user community’s experience with the products. Agenda Topics: Introductions Tuxedo Update from PM Team (recent releases, investments) Customer Use Cases (hear from other customers) Mainframe Modernization using Tuxedo/ART Tuxedo Extreme Performance Pack (new Tuxedo option) Tuxedo in Cloud (direction, use cases) Product Demos (focused on recent updates) Open Discussion (Q&A, requirements)  Additional Information Address: Two Pierce Place, 17th Floor, Itasca, IL 60143 Time: 10am – 4pm, lunch will be provided RSVP: Please register by September 18th by sending an email to deepak.goel@oracle.com and include the following information: Full name, Company represented, Email address, and Mobile phone.  Registration and attendance are free of charge.  Networking Dinner following the User Group meeting. Details to be provided prior to the event.

North American Tuxedo User Group Meeting  The Oracle Tuxedo product management team would like to invite you to this year's North American Tuxedo User Group Meeting being held in Chicago on Thursday...

Tuxedo Sample Applications

Wow, it's been way too long since my last post.  I'll try to post more often. I wanted to point out a little side project I've been working on that I thought maybe others might be interested in.  It's essentially a github project to create samples and scripts to help get people started with Tuxedo.  None of it meant for prime time, and it's all open source, i.e., meaning other contributors are welcome.  So far I have a few things working well. Tuxedo and Docker One of the subprojects within the github repository is a set of files to help using Tuxedo in Docker.  If you're not familiar with Docker, I highly recommend checking out their website.  It basically is a set of tooling around Linux Containers that makes it easy to create a container on your machine.  There is a Dockerfile and associated scripts  that allows one to download the Tuxedo installer and rolling patch kit, and create a Docker image with Tuxedo installed, patched, and ready to go.  The installation and patching of Tuxedo is all automated.  When you're done, you'll have a working Docker image.  To test it, there is a fully automated runme script for the Tuxedo simpapp application in the installers directory of the project.  Copy that into your Docker image and execute it.  It should copy, build, and run the simpapp application.  Check out the README.md for more information. Tuxedo and Vagrant Vagrant is another approach to building test and development environments.  Instead of focusing on Linux Containers, Vagrant focuses on creating Virtual Machines, specifically VirtualBox virtual machines.  Although other runtime environments (providers) are supported by Vagrant, VirtualBox is supported out of the box, so to speak.  Inside the Vagrant subproject, there are files and scripts that will create a VirtualBox VM that has Tuxedo installed, patched, and ready to go.  Checkout the README.md for more information. Tuxedo and RAC For those wanting to play with Tuxedo and RAC, there is another subproject called RAC that you can use to create multiple VMs that support RAC and Tuxedo.  This project builds upon another github project that helps you create a RAC cluster from 1 to N nodes and as well creates application VMs that can be used to run other things such as Tuxedo.  This project contains the files and instructions to create a RAC cluster and multiple Tuxedo machines that have the Oracle Database Instant Client installed.  Like the other projects, the actual installers for the Oracle projects must be first downloaded from OTN.  Once that is done and a simple edit made to the Vagrantfile to define the number of each type of machine and their memory configurations, two commands get you a working set of interconnected VirtualBox VMs that are running RAC and Tuxedo.  A very quick way to get started with Tuxedo and RAC.   Again, please see the README.md file for more information. As these are open source projects, please feel free to contribute.  The easiest way to do that is create a github account and request to join the TuxedoUsers github organization.

Wow, it's been way too long since my last post.  I'll try to post more often. I wanted to point out a little side project I've been working on that I thought maybe others might be interested in. ...

Tomcat and Tuxedo - Perfect together

Tuxedo provides numerous integration options to work with existing applications and other technologies.  For example the most recent release of SALT provides RESTful Web services for your Tuxedo services without writing or changing a line of code.  At Oracle Open World last week we demonstrated how you can leverage the Spring Framework and Tuxedo transaction management capabilities inside the Tuxedo Java server.  In this post I'll show how one can run Tomcat inside the Tuxedo Java Server and utilize Tuxedo services directly from Tomcat.  Although the example is trivial, showing calling the Tuxedo TOUPPER service from the simpapp sample application, it illustrates the minimal amount of effort necessary to run Tomcat inside the Tuxedo Java server and call a Tuxedo service. To use the Tuxedo Java server, the server needs to be configured and added to the Tuxedo UBBCONFIG file.  A new server entry needs to be added similar to: TMJAVASVR SRVGRP=GROUP1 SRVID=2 CLOPT="-A" CLOPT="-- -c TJSconfig.xml" MINDISPATCHTHREADS=2 MAXDISPATCHTHREADS=10 For this example, the minimum and maximum dispatch threads could be set to 1 as we're not hostingany Tuxedo services in this instance of the Java Server.  These lines could be added directly to the UBBCONFIG file for the simpapp sample application. Next a configuration file is needed for the Tuxedo Java server to set things like classes to load, classpaths, and the like.  Here is a copy of TJSconfig.xml as used by the above server definition: <?xml version="1.0" encoding="UTF-8"?><TJSconfig version="2.0">    <classpath-config> <classpath>${CATALINA_HOME}/bin/*.jar</classpath> <classpath>${CATALINA_HOME}/lib/*.jar</classpath>    </classpath-config>    <tux-server-config>        <server-class name="MyTuxedoJavaServer"></server-class>    </tux-server-config></TJSconfig> This adds the Tomcat jar files to the classpath and adds a class called MyTuxedoJavaServer to the configuration. Let's look at the source for MyTuxedoJavaServer and see how this class allows us to start up Tomcat. import com.oracle.tuxedo.tjatmi.TuxedoJavaServer;import com.oracle.tuxedo.tjatmi.TuxException;public class MyTuxedoJavaServer extends TuxedoJavaServer { private TomCatThread tc = null; public MyTuxedoJavaServer() { // Create the thread that will be used to bootstrap Tomcat tc = new TomCatThread(); return; } public int tpsvrinit() throws TuxException { // Startup Tomcat tc.start(); return 0; } public void tpsvrdone() { // Shutdown Tomcat tc.shutdown(); return; }} The constructor for the class creates an instance of the thread that will be used to bootstrap Tomcat. The only other two methods are the standard startup and shutdown methods called by the Tuxedo Java server at server startup and shutdown.  These methods simply start and shutdown the Tomcat thread. Next let's look at the TomCatThread class that is used to bootstrap Tomcat.  It looks like:  import org.apache.catalina.startup.*;public class TomCatThread extends Thread { private Bootstrap bs = null; public void run() { try { bs = new Bootstrap(); bs.setCatalinaHome("/home/oracle/projects/tc/apache-tomcat-7.0.54"); bs.start(); System.out.println("After starting Tomcat Thread."); } catch (Exception e) { System.out.println("Received exception" + e); } } public void shutdown() { try { bs.stop(); bs.destroy(); } catch (Exception e) { System.out.println("Received exception while shutting down Tomcat thread" + e); } }} This class simply extends the Thread class and in its run method creates an instance of the Tomcat bootstrap, sets the home directory for Tomcat, and starts Tomcat running.  The shutdown method just stops the Tomcat embedded server. Next we need a helper class to help keep track of the Tuxedo context that will be associated with each Tomcat thread.  To make a Tuxedo service call, or most other Tuxedo calls, a thread needs to be associated with an application context in Tuxedo.  This is done using the tpappthrinit() method that creates a new Tuxedo context and associates it with the thread.  We'll use thread local storage to store the created context to be used whenever the thread needs to make a Tuxedo call.  I've used a class called TuxedoThreads to maintain this association: package todd;import com.oracle.tuxedo.tjatmi.TuxATMITPException;import com.oracle.tuxedo.tjatmi.TuxAppContext;import com.oracle.tuxedo.tjatmi.TuxAppContextUtil;public class TuxedoThreads { public static final ThreadLocal<TuxAppContext> userThreadLocal = new ThreadLocal<TuxAppContext>(); public static void set(TuxAppContext tc) { userThreadLocal.set(tc); } public static TuxAppContext get() throws TuxATMITPException { TuxAppContext tc = userThreadLocal.get(); if (null == tc) { // No Tuxedo context gotten for this thread yet, so get one TuxAppContextUtil.tpappthrinit(null); tc = TuxAppContextUtil.getTuxAppContext(); userThreadLocal.set(tc); } return userThreadLocal.get(); }}  To access the thread's Tuxedo context, we'll simply call the get() class method and if the thread hasn't already created a Tuxedo application context, it will create one and store it in thread local storage.  Otherwise it just returns the previously created Tuxedo context.  One thing to keep in mind is that each thread Tomcat uses will eventually end up with a Tuxedo context.  This means that you need to allow for this in the MAXACCESSORS setting in the UBBCONFIG file. All that left now is to either use the TuxedoThreads class in a JSP or servlet file or use it in another Java class that they call.  I'll opt for the later as it makes the JSP easier to read.  So here is the MyTest Java class that makes the Tuxedo service call to the TOUPPER service: package todd;import com.oracle.tuxedo.tjatmi.*;import weblogic.wtc.jatmi.TypedString;public class MyTest { public String toUpper(String inStr) throws TuxATMITPReplyException, TuxATMITPException { // Get the threads Tuxedo context TuxAppContext tc = TuxedoThreads.get(); // Create the Tuxedo request buffer and call the Tuxedo service TuxATMIReply rply = null; TypedString req = new TypedString(inStr); TypedString rplyData = null; rply = tc.tpcall("TOUPPER", req, 0); rplyData = (TypedString) rply.getReplyBuffer(); return rplyData.toString(); }} The class has a single method that takes a Java String and it creates a Tuxedo TypedString buffer and calls the Tuxedo TOUPPER service.  It then gets the returned buffer and returns that to the caller.  Here is a trivial JSP using this class to uppercase a string:  <%@ page import="todd.*"%><%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Test of Tuxedo service call</title></head><body> <% MyTest foo = new MyTest(); %> Hello World uppercased is <%= foo.toUpper("Hello World") %></body></html>  The JSP simply creates an instance of the MyTest class and uses the toUpper method to get the upper case version of Hello World.

Tuxedo provides numerous integration options to work with existing applications and other technologies.  For example the most recent release of SALT provides RESTful Web services for your Tuxedo...

Why is old bad?

I keep coming across situations where someone tells me that Tuxedo is old like that is a bad thing.  I'm old, well, maybe older, and it seems fine to me.  I like to think I'm like fine wines and single malt scotches that get better with age.  So why is old necessarily a bad thing? I believe it comes from the notion that old technology has been replaced by something newer.  In a sense this is certainly true.  I don't see a lot of 8 track players these days because they were replaced by cassette tapes, which were replaced by CDs, which were replaced by digital audio players.  Yet there are purists who content vinyl records still offer the best sound quality, although my ears certainly can't confirm that.    Most people would argue that Unix is modern technology yet Unix was first developed in 1969 making it one of the oldest technologies currently in use.  So why is technology that is 45 years old considered modern?   I believe it is because Unix has kept up with the times.  It has adopted to changes in hardware, operating system design, programming styles and the like.  Tuxedo was first developed in 1982 and likewise has kept up with changes in hardware, application server design, programming languages, and communication techniques.  So where is the difference? For example, in the 1990s messaging, CORBA, and multi-threaded programming were all the rage.  Tuxedo adopted messaging, CORBA, and multi-threading.  In the 2000s SOAP based web services, the Service Component Architecture, and dynamic programming languages such as Python, Ruby, and PHP became popular and Tuxedo adapted to support those.  More recently Oracle introduced Engineered Systems where the hardware and software was designed to work together to optimize performance.  Tuxedo has been updated to leverage these engineered systems to provide enhancements that can dramatically improve application performance.  Recent releases of Tuxedo now offer support for developing applications in Java, support for RESTful based web services, and tight integration with Oracle Real Application Clusters. The above may make it sound like Tuxedo lagged behind the technology curve, yet nothing could be farther from the truth.  The Open Group's standard for distributed transaction support known as XA primarily came from Tuxedo.  Service Oriented Architecture or SOA has also been the rage over the last decade, yet Tuxedo has been SOA based since its inception.  Everything in Tuxedo is a service.  This has allowed Tuxedo and Tuxedo applications to adopt newer technologies often with no application changes required.  A service written 20 years ago in C can transparently be used as a SOAP or REST web service with absolutely no changes to the service implementation.  That same service can also be called from Python and appears to the Python developer as just another method.  Want to re-implement that C service in Java without impacting any existing usage of that service?  No problem. Another word for old that has mixed connotations is mature.  Like old, it can be a bad thing if it has remained unchanged.  However in the world of enterprise software maturity is usually a good thing as it brings with it stability.  Who puts a version 1.0 product into production?  I believe there are few products on the market that have as low a defect rate as Tuxedo has.  This is largely because the code is tested extensively by Oracle and used by the thousands of customers over the last 32 years.  As one customer stated in an Oracle Open World presentation a few years ago that in 15 years of using Tuxedo, they never had a production outage.  That's stability. So I'm left wondering why is old bad?

I keep coming across situations where someone tells me that Tuxedo is old like that is a bad thing.  I'm old, well, maybe older, and it seems fine to me.  I like to think I'm like fine wines and...

Tuxedo at Oracle Open World 2014

The Tuxedo team will be present in force at Oracle Open World 2014.  We have 7 sessions directly related to Tuxedo presented by engineers, customers,  architects, and product management.  Please add them to your schedule builder so you don't miss them.  They are: Monday 2:45-3:30PM Moscone South 304 Oracle Tuxedo 12.1.3: What’s New and Why You Should Care [CON8261] Come hear Frank Xiong - VP for the Tuxedo product family, describe what we've been working on.  He'll be joined by Deepak Goel - Tuxedo Product Manager, and Anastasio Garcia - Middleware, SOA & Delivery Manager from Telefónica España. Monday 4:15-5:15PM Hotel Nikko - Nikko Ballroom III Simplify and Optimize Oracle Tuxedo Application Deployments and Management [HOL9448] Jared Li - Tuxedo development manager, and Chris Guo - Principle Member of Technical Staff will conduct a hands-on lab using Oracle TSAM Plus, Oracle Enterprise Manager, and Oracle Business Transaction Management to monitor, manage, and administer Tuxedo applications.  Monday 5:45-6:45PM Hotel Nikko - Nikko Ballroom III Use Java, the Spring Framework, and Oracle Tuxedo to Extend Existing C/C++/COBOL Apps [HOL9447] A cast of thousands (Maggie Li, Chris Guo, Maurice Gamanho, and myself) will conduct a hands on lab demonstrating how easy it is to use Java and Spring to develop and extend Tuxedo applications.  Tuesday 10:45-11:30AM Moscone South 200 Oracle Tuxedo Makes It Easy to Develop Composite Apps with Java, C, C++, and COBOL [CON8228] Jared Li and Deepak Goel will present ways customers can develop composite applications that leverage the performance of C/C++/COBOL while still allowing the rapid creation of business logic in Java, all in a single environment. Tuesday 7:00-7:45PM Moscone South 301 Oracle Tuxedo Monitoring and Management: Birds-of-a-Feather Meeting [BOF9641] Come to a Birds of a Feather sessions where Deepak Goel, myself, and Mark Rakhmilevich will present some information on monitoring and managing best practices as well as an open discussion about how to best manage, monitor, and administer Tuxedo applications. Wednesday 3:30-4:15PM Moscone South 200 The ART and Practice of Mainframe Migration and Modernization [CON8229] Mark Rakhmilevich - Sr. Director Product Management/Strategy, Rui Pereira - Principal Sales Consultant, and Jeffrey Dolberg - Senior Principal Product Manager, will describe how customers are migrating their mainframe CICS, IMS and batch applications from costly IBM mainframe environments to open systems with Tuxedo and Tuxedo ART. Thursday 9:30-10:15AM Marriott Marquis - Salon 14/15 Management and Monitoring of Oracle Tuxedo: Integrated, Automated [CON8273] I will be presenting on the new features in TSAM Plus 12c that can be used to efficiently manage, monitor, and administer Tuxedo applications.  I will cover the recent integration of the Tuxedo observer for BTM, and how to decide on the right tool and strategy to address common performance and availability issues.  And as always please stop by the Tuxedo booth in the Oracle DEMOgrounds in Moscone South.  We love to see customers and answer their questions.  This is your chance to meet product developers, product managers, engineering managers, and architects all focused on Tuxedo! Hope to see you there!! Todd LittleOracle Tuxedo Chief Architect 

The Tuxedo team will be present in force at Oracle Open World 2014.  We have 7 sessions directly related to Tuxedo presented by engineers, customers,  architects, and product management.  Please add...

High Availability Part 6

As I’ve already mentioned, redundancy is critical to providing high availability because things do fail, even software.  In my previous post I described how to provide redundancy for some of the Tuxedo system servers.  In this post I’ll cover how to provide redundancy for the remaining system servers as well as application provided servers. Tuxedo provides many integration options to connect Tuxedo applications to other systems, including other Tuxedo applications.  The connectors or gateways that provide these integration options are essentially all network based.  These servers include the Tuxedo domain gateway, the various listeners such as the workstation listener or WSL, or add-on products such as the SALT Web service gateway or GWWS.  All of these servers listen on network ports which cannot be shared across servers, and all of them can have multiple copies of them running in the same Tuxedo machine.  But since they can’t share network ports, they have to be configured individually, instead of just running identical multiple copies of them. For the listeners such as the WSL, JSL, and ISL, this means that multiple copies should be running across the machines in a cluster.  Although a load balancer can be used to distribute the load across the multiple copies that are each listening on their own host and port address, the clients for these listeners have that capability built in.  So by properly configuring the address string that clients use to connect to the Tuxedo application, load balancing and failover can be handled by Tuxedo without the need for an external load balancer. For the SALT Web service gateway, multiple GWWS instance can be configured on a machine or in a cluster.  Each Web service should be configured with multiple endpoints for inbound services to ensure the service is available even if a particular gateway is down.  This is controlled by the WSDF for the service and the SALTDEPLOY file.  As well more than one gateway should import any required external Web services that need to be called. The Tuxedo domain gateway GWTDOMAIN and its related administrative servers GWADM and DMADM also need to be considered.  The GWADM and DMADM servers are not involved in the normal message flow of the domain gateway, so configuring them for redundancy doesn’t really help availability, although they can be configured to have redundant copies.  The GWTDOMAIN system server on the other hand is required to process messages, so to ensure connectivity it is valuable to have multiple copies of the domain gateway running at the same time.  The best case scenario is multiple copies of GWTDOMAIN running on separate Tuxedo machines in a clustered configuration.  This requires defining at least two domain gateway groups in the UBBCONFIG file and two local access points in separate domain gateway groups in the DMCONFIG file.  Each gateway can be connected to multiple remote domains.  To further improve availability of imported services, for each imported service, you can specify a list of failover/failback domains that an imported service can be imported from.  You can also import the same service more than once to load balance requests across the multiple remote domains. Finally this leaves us with application provided servers.  As should be obvious, to achieve high availability multiple copies of these should be run and distributed across multiple machines in a clustered configuration.  Within a server group, Tuxedo makes this trivial by just specifying the MIN and MAX parameters on the server’s definition in the *SERVERS section of the UBBCONFIG.  Adding the same server to multiple server groups spread across multiple machines ensures that the failure of any given server or machine won’t prevent the application from functioning.  Obviously running multiple copies of servers can also be used to scale out an application. By following the above recommendations, your application should be free of any single points of failure.  One way to verify this is follow the flow of a request through the entire system from client, through the various servers the request must travel and analyze what would happen if all the servers along a single path were unavailable.  Can the next request still be processed?  If not, you have a single point of failure.

As I’ve already mentioned, redundancy is critical to providing high availability because things do fail, even software.  In my previous post I described how to provide redundancy for some of the...

High Availability Part 5

In the first parts of this series on highavailability, I’ve explained what high availability means, how availability isdefined and measured, what impacts availability, and what needs to be done ingeneral to improve availability.  In thispost I’ll look at some of the features in Tuxedo that aid in creating highlyavailable applications. The first thing I want to cover is usingredundancy to improve availability. Ifyou recall from the second post, just adding a single level of redundancy canmake a huge improvement in availability. This is often noted in many highly available systems where they claimthere is no single point of failure, meaning that for every required component,there is at least one duplicate or redundant copy of it. Highly available hardware platforms likeExalogic are designed this way with redundant power distribution and power supplies,redundant networks, redundant or extra fans, redundant SSDs, etc. So any given failure of a single hardwarecomponent will not bring the system down. Tuxedo is designed with this strategy in mind, i.e., no single point offailure. Let’s look at each type ofcomponent in a Tuxedo application and see how it can be made redundant. Each of the critical Tuxedo systemservers can have additional copies of them run. When I say critical, I mean those that are required for the applicationto perform its task. The reason Iqualify this is that often I’m asked about the Bulletin Board Liason (BBL),Distinguished Bulletin Board Liason (DBBL), and the BRIDGE. These three servers cannot have multiplecopies of them running. So how doesTuxedo provide high availability if these servers cannot run redundantly? For the BBL and DBBL, the answer is thatthese servers are not needed by Tuxedo to process requests. So if a BBL or the DBBL crash for somereason, the application can still function as normal request processing doesn’tneed those servers to be up to function. These servers are primarily responsible for management, configuration,and housekeeping tasks. So while one ofthem is temporarily down, the application continues to run, but certain configurationand administration tasks may not be able to be performed until the failed serveris restarted. The BRIDGE on the other hand may be inthe path of application request processing so why does it being down not necessarilyaffect application availability? Thislargely depends upon the application configuration. Ideally each machine in a clusteredconfiguration would be running all the servers necessary to process applicationrequests. In this case, Tuxedo wouldnote that the BRIDGE is down and route requests only to local servers. Certain unavoidable configurations such aswhere a server cannot be run on more than one machine at a time, or singletonservers, may cause temporary unavailability of the services offered by thatserver, but this should be extremely short. The reason it will be short is that Tuxedo operates on a buddy system,meaning that every process has another process that is monitoring it presenceand usually its health as well. Allconfigured processes are monitored by the BBL. So if the BRIDGE fails, the BBL will automatically restart it and ingeneral the worst that has happened is some requests will be temporarilydelayed as no requests will be lost. Since every process needs a buddy to monitor it, the BRIDGE monitors theBBL, so if the BBL should crash, the BRIDGE will automatically restart the BBL. One final comment on these specific systemservers, they contain no application or customer provided code and are highlytested, so their likelihood of failing to begin with is extremely low. Let’s take a quick look at the othercommon Tuxedo system servers. TMQUEUEservers can be run with multiple copies accessing the same queuespace on asingle machine. Thus if one of the TMQUEUEservers fails, the others will just continue to process /Q requests for thequeuespace. Should the machine thequeuespace is on fail, then it would be necessary to migrate the server groupcontaining the TMQUEUE servers to another machine. With Tuxedo 12c, this process can beautomated with automatic server group migration, such that the server groupwill automatically be migrated to its backup machine. So the failure of a machine here couldintroduce some minimal unavailability for the queuespace while the servers are beingmigrated. Planned enhancements to TuxedoMessage Queue (TMQ) should address even this small bit of unavailability of aqueuespace in a future release. In themeanwhile, there is nothing preventing multiple queuespaces with same name existingin a single domain, so TMQUEUE servers could be run on multiple machines, butthese queuespaces will be independent of each other; so a dequeue operationcould block even though there are messages in the “queue”, because the dequeueoperation ended up on a machine where there are no messages in that queue. The next set of system servers are thosethat operate in a master/slave arrangement. These include the Tuxedo event brokers and the CORBA naming servers. These servers operate in such a fashion thatone server is configured as the master server, and when changes are made, ithas the responsibility of propagating the changes to the slave servers. The master or slave servers can handleread-only requests and master and slaves communicate via standard tpcalls,meaning they can be run across multiple machines. If the master server dies, it is normallyconfigured as restartable, it will be restarted by the BBL and then restore itsstate from the slave servers. So worstcase there may be an extremely brief period of time while a new eventsubscription or new CORBA naming entry can’t be made, but event posting andname lookups can still proceed even during this brief period when the master isdown. In my next post I’ll cover the remainingsystem servers and application servers as they are both handled in the same wayfor redundancy. In subsequent posts I’llcover other ways to improve the availability of Tuxedo applications such as thebuilt in failover/failback capabilities of Tuxedo as well as means to automateapplication or configuration specific steps to remediate failures.

In the first parts of this series on high availability, I’ve explained what high availability means, how availability is defined and measured, what impacts availability, and what needs to be done ingen...

High Availability Part 4

To Err is Human; To Survive is HighAvailability In this post I’d like to look at thevarious causes of unavailability or outages. Themost obvious although often overlooked is that of scheduled systemmaintenance. Now whether that is includedin your measurement of availability depends upon the stack holders for a systemor application. The ideal systems haveno scheduled maintenance that causes the system to be unavailable. That isn’t to say they don’t receivemaintenance, but that the maintenance doesn’t cause the system to beunavailable. This can be done via rollingupgrades, site switchovers, etc. For nowit suffices to say that this type of down time is intentional, known, andtypically scheduled. The interesting part comes in looking atother causes of unavailability, in particular those caused by failures. The most commonly thought of failure is thatof a hardware failure such as a disk drive failing, or a server failing. These failures tend to be obvious and easilyremedied. Most people then guess thatsoftware failures make up the next significant portion of failures. But as is all too often the case, the mostcommon failures in highly available systems are those caused by people. Estimates place hardware failures at around10% of the causes of an outage. This lowpercentage is largely due to the ever improving MTBF of hardware. Software is estimated to cause about 20% ofoutages for highly available systems. The remaining 70% of outages are attributable to human action, andincreasingly these actions are intentional, i.e., purposeful interruptions ofservice for malicious intent such as denial of service attacks. To give an example a study was done onreplacing a failed hard drive in a software RAID configuration. A seemingly simple task, yet a surprisingnumber of cases of replacing the wrong drive occurred in the first few times anengineer was asked to repair the systems. This indicates that putting procedures in place to repair a system isn’tadequate, but that actually performing the procedures several times is neededto eliminate human error. But moreimportantly it points out the need to eliminate human intervention as much aspossible as any human intervention either for normal operation or forremediating a failure has a significant possibility of being doneincorrectly. That incorrect interventioncould be relatively catastrophic as in replacing the wrong drive in the abovestudy caused a complete loss of data in some instances. So what is the takeaway from thisinformation? Minimize or eliminate humanintervention as much as possible in order to minimize outages attributable tohuman error. Typically this meansautomating as much as possible any necessary steps to resume normal operationafter a failure or even during normal operation. Every manual step taken by an administratorhas some probability of causing an outage. It also suggests that repair procedures be well tested, preferably in atest environment that duplicates the production environment. More on how Tuxedo can help solve theseproblems in my next entry.

To Err is Human; To Survive is High Availability In this post I’d like to look at the various causes of unavailability or outages. The most obvious although often overlooked is that of scheduled systemm...

High Availability Part 3

In my previous posts on High Availability I looked at the definition of availability and ways to increase the availability of a system using redundant components.  In this post I'll look at another way to increase the availability of a system.  Let’s go back to the calculation ofavailability: Based upon this formula, we can see thatif we can decrease the MTTR, we can increase the overall availability of thesystem. For a computer system, let’slook at what makes up the time to repair the system. It includes some time that may not beobvious, but in fact is extremely important. The timeline for a typical computer system failure might look light: Normal operation Failure or outage occurs Failure or outage detected Action taken to remediate the failure or outage System placed back into normal operation Normal operation Most people only consider item (4) above,the time taken to remediate the outage. That might be something like replacing a failed hard drive or networkcontroller. It could even be as simpleas reconnecting an accidentally disconnected network cable, a 30 second repair.But the MTTR isn't 30 seconds. It’s thetime included in (3), (4), and (5) above. For the network cable example, the amount of time taken in (3) willdepend upon network timers at multiple levels and could be many minutes if justrelying on the operating system network stack. The time taken for (4) may be as low as the 30 seconds needed toreconnect the cable although finding the cable might take a bit longer than 30 seconds. The time for (5)again depends upon the service resumption steps such as re-establishing a DHCPaddress, reconnection of applications or servers, etc. So on the surface the MTTR may be assumed to be30 seconds, the actual time could be many minutes, especially in the extremecase where systems, servers, applications, etc., need to be restarted or rebooted manuallyto recover. So how does this impact system design forhighly available systems? It indicatesthat whatever can be done to decrease items (3), (4), and (5) above, willimprove overall system availability. Themore of these steps that can be automated, the lower the MTTR one can achieve, andthe higher the availability of the system. Too often the detection phase (3) is left up to someone calling ahelp desk to say they can’t access or use the system. As well items (4) and (5) often requiremanual intervention or steps. When onewants to achieve 99.99% availability, manual repairs or remediation is going tomake that very difficult to achieve. More on the causes of failures in my nextpost.

In my previous posts on High Availability I looked at the definition of availability and ways to increase the availability of a system using redundant components.  In this post I'll look at another...

High Availability Part 2

To compute the availability of a system, you need to examinethe availability of the components that make up the system.  To combine the availability of thecomponents, you need to determine if the components failure prevents the systemfrom being usable, or if the system can still be available regardless of thefailure. Now that sounds strange untilyou consider redundancy. In anon-redundant subsystem, if it fails, the system is unavailable. So in a completely non-redundant system, theavailability of the system is simply the product of each component’savailability: A very simplifiedview of this might be:      Client => LAN => Server => Disk If we take the client out of the picture as it really isn't part of the system, we at least have a network, a server, and a disk drive tobe available in order for the system to be available. Let’s say each has an availability of 99.9%,then the system availability would be: or 99.7% available. That’s roughly equivalent to a day’s worth ofoutage a year. So although eachsubsystem is only unavailable about 9 hours a year, the 3 combined ends upbeing unavailable for over a day. As thenumber of required subsystems or components grows the availability of the overallsystem decreases. To alleviate this, onecan use redundancy to help mask failures. With redundant components, the availability is determined by theformula: Let’s look at just the servercomponent. If instead of a single serverwith 99.9% availability , we have two servers each with 99.9% availability, butonly one of them is needed to actually have the system be available, then theavailability of the server component of the system increases from 99.9% to 99.999%or 5 nines of availability just by adding an additional server. As you can see, redundancy can dramaticallyincrease the availability of a system. If we have redundant LAN and disk subsystems in the example above,instead of 99.7% availability, we get 99.997% availability or about 16 minutesof down time a year instead of over a day of down time. OK, so what does all of this have to dowith creating highly available systems? Everything! What it tells us isthat all things being equal, simpler systems have higher availability. In other words, the fewer required componentsyou have the more available your system will be. And it tells us that to improve availabilitywe can either purchase components with higher availability, or we can add someredundancy into the system. Buying morereliable or available components is certainly an option, although generallythat is a fairly costly option. Mainframe computers are an example of thisoption. They generally provide better availability than blade servers, but do so at a very high premium. Usingcheaper redundant components is typically much cheaper and can even betteroverall availability. More on high availability in my next post. 

To compute the availability of a system, you need to examine the availability of the components that make up the system.  To combine the availability of thecomponents, you need to determine if the...

High Availability

As companies become more and more dependent upon theirinformation systems just to be able to function, the availability of thosesystems becomes more and more important. Outages can costs millions of dollars an hour in lost revenue, let alonepotential damage done to a company’s image. To add to the problem, a number of natural disasters have shown thateven the best data center designs can’t handle tsunamis and tidal waves,causing many companies to implement or re-evaluate their disaster recoveryplans and systems. Practically everycustomer I talk to asks about disaster recovery (DR) and how to configure theirsystems to maximize availability and support DR. This series of articles will contain some ofthe information I share with these customers. The first thing to do is define availability and how it ismeasured. The definition I prefer isavailability represent the percentage of time a system is able to correctlyprocess requests within an acceptable time period during its normal operatingperiod. I like this definition as itallows for times when a system isn’t expected to be available such as duringevening hours or a maintenance window. However, that being said, more and more systems are being expected to beavailable 24x7, especially as more and more businesses operate globally andthere is no common evening hours. Measuring availability is pretty easy. Simply put it is the ratio of the time asystem is available to the time the system should be available. I know, not rocket science. While it’s good to measure availability, it’susually better to be able to predict availability for a given system to be ableto determine if it will meet a company’s availability requirements. To predict availability for a system, oneneeds to know a few things, or at least have good guesses for them. The first is the mean time between failuresor MTBF. For single components like adisk drive, these numbers are pretty well known. For a large computer system the computationgets much more difficult. More on MTBFof complex systems later. Then nextthing one needs to know is the mean time to repair or MTTR, which is simply howlong does it take to put the system back into working order. Obviously the higher the MTBF of a system, the higheravailability it will have and the lower the MTTR of a systemthe higher the availability of the system. In mathematical terms the system availability in percent is:  So if the MTBF is 1000 hoursand the MTTR is 1 hour, then the availability would be 99.9% or often called 3nines. To give you an idea about howmuch down time in a year equates to various number of nines, here is a tableshowing various levels or classes of availability: Availability Total Down Time per Year Class or # of 9s Typical application or type of system 90% ~36 days 1 99% ~4 days 2 LANs 99.9% ~9 hours 3 Commodity Servers 99.99% ~1 hour 4 Clustered Systems 99.999% ~5 minutes 5 Telephone Carrier Servers 99.9999% ~1/2 minute 6 Telephone Switches 99.99999% ~3 seconds 7 In-flight Aircraft Computers As you can see, the amount of allowed downtime gets verysmall as the class of availability goes up. Note though that these times are assuming the system must be available24x365, which isn’t always the case. More about high availability in my next entry. 

As companies become more and more dependent upon their information systems just to be able to function, the availability of those systems becomes more and more important. Outages can costs millions of...

Tuxedo vs MQ Series or other MOMs - No comparison

I'm often involved in situations where customers are looking for a messaging system because they believe the solution to building enterprise systems is to settle for a messaging oriented middleware or MOM.  Tuxedo has been classified as a MOM and some analysts still place it in that category, but that is sort of like saying a Ferrari is just a car or an F-35 is just an airplane.  Tuxedo is no more a MOM than WebLogic Server or WebSphere Application Server are MOMs.  Sure, they have messaging facilities, but their core value isn't in providing messaging services.  Their core value as application servers is to simplify the life of the enterprise application developer and the OA&M staff supporting the applications they've developed.  The primary function of a MOM is to get a message from point A to point B without the application having to worry about how it got there.  It's a fantastic model for application development if you're willing to build all the rest of what an application server provides, as you will have to build those things if you want to provide an enterprise application.  One of the fundamental differences between a MOM and an application server is that a MOM doesn't offer such things as ensuring your application is actually running and doing useful work.  A MOM typically doesn't manage any aspect of your application or infrastructure other than getting those messages from point A to point B. What does an application server provide that a MOM typically doesn't provide?  Fundamentally application servers provide a container that hosts your business logic.  MOM's don't provide a container, they provide a library that offers an API to move messages.  An application server on the other hand provides a runtime and management environment to host your business logic.  In JEE terms, a MOM let's you build clients, typically an OS process that you manage yourself.  The MOM worries about the messaging servers and only the messaging servers.  So monitoring, managing, and restarting failed clients is up the application to handle.  As well, since a MOM really only provides client services, it means it can't manage things such as application consistency through such things as transaction management, or application availability or scalability through things like dynamic scale out and load balancing.  In fact, a MOM can't do most of what an application server can do, whereas an application server can do everything a MOM can do and much, much more. So what does this have to do with Tuxedo?  Well Tuxedo is a multi-language application server built on SOA principles and designed to support the most demanding enterprise applications on the planet.  It provides containers to host your business logic so your application doesn't have to worry about things like scaling, availability management, and the like.  Your application focuses on providing business value through the business services you develop, instead of focusing on infrastructure that provides little to no business value on its own.

I'm often involved in situations where customers are looking for a messaging system because they believe the solution to building enterprise systems is to settle for a messaging oriented middleware or...

Integrating Tuxedo Global Transactions across Web Services

Global Transactions A global transaction is a series of service calls where the services involved write to a resource (typically update or create a record in a database), and all updates or creations must be completed or none at all so that no inconsistency exists. For example, imagine performing a balance transfer from one account to another, and that the information pertaining to those accounts is stored in two different databases. The succession of service calls would be as follows: withdraw amount from database 1, deposit amount to database 2, commit (withdrawal and deposit become effective and are reflected in future balance displays). Applications running on Oracle Tuxedo, combined with a database resource such as Oracle Database can guarantee what is called in computer science Atomicity, Consistency, Isolation and Durability (or ACID properties). Web Services In world more and more connected, Web Services and SOAP standards have been developed to address needs to exchange information irregardless of the system on which it is available. A Web Service is a “public” interface to a business operation that is exposed in a standardized way. Other standards are developed as needs arise, such as WS-Addressing, WS-ReliableMessaging or WS-Security, and software vendors implement those in order to provide more features. Such features are usually advertised in service interfaces so that provider and consumer can agree on levels of functionality and automatically adjust interactions. For instance, a service provider may offer a secure version of its services but still allow non-secure consumers to see and use a scaled-down version of the same services, even though they do not implement the full stack of security standards. The standard that combines Global Transactions and Web Services is WS-AtomicTransaction or WS-AT. Consider the example below: Each of the different actors in this use-case may be housed in completely different organizations, with their own software, networks and databases. Using Web Services standards ensures that the applications will communicate with each other despite potentially using different software vendors, having different software life-cycles and so on. The SALT gateway is a Tuxedo system process that adds Web Services support to Tuxedo applications. Tuxedo services can be exposed as Web Services, or Tuxedo client programs can invoke Web Services seamlessly, that is by making it seem like the Web Services are simply other Tuxedo services. In that spirit, integrating Tuxedo services with Web Services Atomic Transactions is as simple as changing some elements of configuration: Add a transaction log so a record of prepared transactions is kept, so that in the case of a failure those in-flight transactions can be resolved, usually rolled back but in some cases committed. In the Tuxedo-to-external Web Service direction, associate a standard policy descriptor to instruct the SALT gateway on what to do when a transaction propagation is requested: mandatory or optional propagation, or no propagation at all (no policy present). This policy file will look as follows: <?xml version="1.0"?> <wsp:Policy wsp:Name="TransactionalServicePolicy"     xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"     xmlns:wsat="http://docs.oasis-open.org/ws-tx/wsat/2006/06"> <wsat:ATAssertion wsp:Optional="true"/> </wsp:Policy> When exposing a Tuxedo service as a Web Service, the SALT gateway will generate the proper WSDL containing the WS-AT capabilities. A WS-AT transaction will propagate into Tuxedo and the remote side will coordinate it. When invoking a Web Service, the assertion will be contained in the remote WSDL, and the SALT utilities used to import the Web Service configuration will process those automatically and generate a WS-AT policy file such as seen above. Then when a transaction is started on the Tuxedo side it can be propagated to the outside, and in this case coordinated by Tuxedo. It is possible to expand existing applications to Web Services, and of course develop new ones, and take advantage of WS-AT by way of the SALT gateway. Summary For Oracle Tuxedo, Oracle SALT provides a native Web Services implementation that ties global transactions and Web Services together. Oracle Tuxedo users are already used to the scalability and high-availability of their applications. Oracle SALT brings Web Services interoperability to Oracle Tuxedo, and does so in a configuration-oriented manner, that is it is not even necessary to modify existing applications or develop new ones in order for them to inter-operate with Web Services. 

Global Transactions A global transaction is a series of service calls where the services involved write to a resource (typically update or create a record in a database), and all updates or creations...

Using Tuxedo application service version with Oracle SALT

To expand on this previous entry, here are some more details on how to use application service version with Web Services through the Oracle SALT gateway. Using Tuxedo application service version in conjunction with Tuxedo services exposed as web services The GWWS gateway gets REQUEST_VERSION and VERSION_RANGE from UBBCONFIG, calls to actual Tuxedo service are made with REQUEST_VERSION inherited from configuration, if different settings are needed, such as specific traffic from specific gateway to be routed to specific services, another gateway instance can be configured in a group with different REQUEST_VERSION value and started  Example (UBBCONFIG excerpt):  ...  *GROUPS  GROUP1          LMID=L1 GRPNO=2 VERSION_RANGE="1-2"  GROUP2          LMID=L1 GRPNO=2 VERSION_RANGE="3-4"  GWWS_GRPV1          LMID=L1 GRPNO=3 REQUEST_VERSION=1  GWWS_GRPV2          LMID=L1 GRPNO=3 REQUEST_VERSION=2 ...  *SERVERS  mySERVER SRVGRP=GROUP2 SRVID=30  ...  GWWS SRVGRP=GWWS_GRPV1 SRVID=30 CLOPT="-A -- -i GW1" GWWS  SRVGRP=GWWS_GRPV2 SRVID=30 CLOPT="-A -- -i GW2" ... In the example above GWWS in group GWWS_GRPV1 inherits request version "1" from its UBBCONFIG settings, and therefore exposes services that are advertised by Tuxedo application servers which include "1" in their VERSION_RANGE settings, such as GROUP1 here. If a service exposed by GWWS is actually performed by a server in GROUP2 the result will be a TPENOENT error forwarded to the remote Web Services client. Using this mechanism, it is possible to map different endpoints to services with different versions. Since versions are per-group, this is done by placing GWWS servers in their own group, and either use proxy mapping in front of GWWS (via Apache server or other), or by directly accessing the endpoints of the Web Services. For example, these settings would be added to the UBBCONFIG above: SALTDEP: ...     <GWInstance id="GW1">        <Inbound>            <Endpoint use="http_port_v1"/>         <Inbound>     </GWInstance>      <GWInstance id="GW2">         <Inbound>             <Endpoint use="http_port_v2"/>         <Inbound>     </GWInstance>  ...  Service WSDF:  <wsdf:Definition>     <wsdf:WSBinding id="svc_binding">         <wsdf:Servicegroup id="svc_PortType">             <wsdf:Service name="STOCK_QUOTE"/>         </wsdf:Servicegroup>         <wsdf:SOAP>             <wsdf:AccessingPoints>                 <wsdf:Endpoint address="http://my.server:3331/quote" id="http_port_v1"/>                 <wsdf:Endpoint address="http://my.server:3332/quote" id="http_port_v2"/>             </wsdf:AccessingPoints> ... Using Tuxedo application service version in conjunction with External web services imported into Tuxedo using SALT Since 1 GWWS instance cannot advertise more than 1 service with same name, that same service would have to be in different instance, for that reason, the existing mechanism can simply be used: configure multiple GWWS instances with VERSION_RANGE in its *GROUP settings accordingly. Example (UBBCONFIG excerpt):  ...  *GROUPS  GROUP2          LMID=L1 GRPNO=2 VERSION_RANGE="1-2"  GROUP3          LMID=L1 GRPNO=3 REQUEST_VERSION=1 VERSION_RANGE="3-4"  ...  *SERVERS  GWWS SRVGRP=GROUP2 SRVID=30  ...  GWWS SRVGRP=GROUP3 SRVID=30  ...  In the above example, Tuxedo programs (client or server) call an external Web Service exposed by both GWWS in groups GROUP2 and GROUP3. Programs using version 1 or 2 will be routed to the service exposed by GWWS in GROUP2 which may connect to endpoint 1, and programs using version 3 or 4 will be routed to the service exposed by GWWS in GROUP3 which may connect to a different endpoint than GWWS in GROUP2.  Stay Connected Follow Tuxedo on: LinkedIn YouTube Tuxedo Blog Follow Cloud Application Foundation (CAF): Twitter   Blog

To expand on this previous entry, here are some more details on how to use application service version with Web Services through the Oracle SALT gateway. Using Tuxedo application service version in...

Sterci processes financial messages 7x faster while lowering TCO

Headquartered in Geneva, Sterci Group is a market-leadingfinancial messaging solutions company with subsidiary divisions in London,Brussels, Toronto, New York, Paris, Riyadh, Singapore and Zurich. Sterci’s productsand services provide banks, corporations and financial institutions with integratedbusiness solutions for transactional banking, multi-bank connectivity, fulldata integration, reconciliation, cash management, zero balancing and marketdata management. Sterci partners with Oracle to deliver mission critical andbest-in-class solutions their clients can depend upon. Many of their customers wererunning old financial messaging switches like IBM mainframes and HP’s Tandem typeplatforms that are very expensive to support. Sterci’s view was to help thoseorganizations lower their total cost of ownership. Sterci wanted an applicationserver environment that had transactional monitoring capabilities that wererobust, high performing, easy to distribute, and widely supported in themarket. Oracle Tuxedo was an obvious fit. Tuxedo is widely distributed,widely used, mature, highly available and highly performing. With Oracle Tuxedo and Exalogic, Sterci wentfrom processing half a million to 3.5 million financial messages per hour whilelowering the total cost of ownership. Watch the video, Sterci Clientsup to 7x Faster with Oracle Tuxedo, with Rob Kotlarz, Business DevelopmentDirector, of Sterci to learn more. Stay Connected Follow Tuxedo: Stay Connected Follow Cloud Application Foundation:

Headquartered in Geneva, Sterci Group is a market-leading financial messaging solutions company with subsidiary divisions in London,Brussels, Toronto, New York, Paris, Riyadh, Singapore and...

The Realities of Rehosting – Four Customer Stories, by Mark Rakhmilevich, Product Mgmt, Strategy Director Product Development

Mainframe customers have options.  Not that mainframe vendors, like IBM, wouldtell them.  In fact, IBM recently puttogether a presentation on “The Reality of Rehosting” and, as you can guess,they weren’t enthusiastic about the notion of moving applications from themainframe to open systems.  On the otherhand, some mainframe users who presented at a recent Oracle OpenWorld are waymore enthusiastic about their options when leveraging Tuxedo to migrateapplications off the mainframe.  Theseare their stories on the “realities of rehosting.”  Banco Bilbao Vizcaya Argentaria (BBVA) BBVA, a global bank with100,000 MIPS of IBM mainframe capacity deployed across Europe and the Americashas began rehosting their core banking transactions and other mainframeapplications to Oracle Tuxedo and Oracle Database.  With over 3000 MIPS already rehosted in 2012and another 12,000 under way in 2013, the bank has crunched the numbers andestimated $1M/year savings for every 1000 MIPS of rehosted workloads.  They rely on robust Tuxedo and OracleDatabase foundation, coupled with Tuxedo Mainframe Adaptors for integrationwith IBM CICS and IMS, and GoldenGate for database synchronization, to run a hybridcore banking infrastructure with full security and global transactioncoordination across rehosted transactions and those that are still on themainframe.  Operating in many countriespresents complex regulatory challenges for BBVA, including requirements formanaging local customer data and transactions in-country. Using Tuxedo andOracle Database, BBVA is able to deploy a small “bank-in-a-box” datacenter configurationin those countries that have this requirement. Speaking at Oracle Open World  2012 , Antonio Gelart, head of BBVAmodernization program, stated that the bank’s goal is zero MIPS – no mainframes– and with the success of early rehosting projects they can see a clear pathtowards this goal. Mazda Mazda, long known as an innovator in automobile industry, is right sizing its IT infrastructure to meetthe challenges of the current economic disruptions. Shedding the legacymainframe environment, Mazda has chosen to migrate its cost accounting system offthe mainframe to a Linux environment powered by Tuxedo and Tuxedo’s ApplicationRuntime (ART) for Batch.  Accomplishingthis migration in about one year, Mazda has revamped some of its applicationprograms in Java and successfully married the traditional mainframe batchframework provided by Tuxedo ART with Java programs.  Describing this migration project at Oracle OpenWorld 2012, Masuhiro Yoshioka, Mazda’s IT infrastructuremanager, said that they chose Oracle Tuxedo for its strong reliability and availabilitycharacteristics, which are critical for Mazda’s cost accounting system thatfeeds into quarterly and annual financial reporting. In addition to significantcost savings expected from decommissioning one of the two mainframes, Mazda hasseen significant performance improvements from parallelizing the overnightbatch processing across a distributed batch farm supported by Tuxedo’sdistributed batch framework.  Onceacquired, the taste for rehosting stays strong. Mazda is now looking at rehosting an IBM IMS application from its lastremaining mainframe to Tuxedo’s Application Runtime for IMS. Caja de Valores (CdV) CdV, an IT arm of Buenos Aires StockExchange, began its mainframemodernization quest in 2001 with a 3-yr project to re-write about 4M lines ofCOBOL code to Java.  Fast forward to2007, and, in the words of Alejandro Wyss, the CdV CIO, no critical subsystemhas been migrated, the budget for re-write was overrun by 3X, and re-writeproject has achieved less than 30% of the total scope, while COBOL code basegrew to 6M LoC.  A new approach wasrequired, one that moved the application functionality to more flexible opensystems infrastructure in a short timeframe and with low risk.  CdV determined that rehosting the applicationsto Oracle Tuxedo, where the application logic is preserved intact in COBOL andonly technical APIs are adapted or emulated to run on a Linux or UNIX platform,was a more promising option.  Startingwith the Stock Trading application as a pilot, the entire migration wasaccomplished in 20 months.  Deploying onLinux to achieve HW vendor independence, CdV was able to leverage Tuxedo’s built-inclustering capabilities to move to an application grid enabling Active/Active fault-tolerantservices infrastructure, while increasing throughput by 200% at a fraction of amainframe cost.  Leveraging Tuxedo’s standards-basedintegration options, CdV is able toreduce overall risk and cut time to market for new capabilities by 30%.    A Top 5 Global Bank It’sdifficult to imagine a more critical banking system than a SWIFT FinancialMessaging application.  Lifeblood of anymajor bank is its connectivity into the global financial fabric managed by SWIFTthat interconnects over 8000 banks and many of their corporate customers. For abank that’s in the top 5 of SWIFT messaging volumes, an aging SWIFT FinancialMessaging solution is a serious risk.  Settingcriteria for a mainframe replacement solution that could consolidate disparate SWIFTmessaging systems and perform at 10x current system’s throughput, the Bankembarked on a series of performance benchmarks. The clear winner – a Tuxedo-based GT Exchange application from Sterci, a long term Tuxedo ISV thatspecializes in SWIFT financial messaging market, deployed on Exalogic ElasticCloud System. In fact, once the Bank has seen its 4x throughput advantage overIBM AIX/pSeries (2.58M complex SWIFT messages/hr on Exalogic compared to 620Kon IBM p750 servers), they’ve decided to deploy it across 2 countries and 4datacenters using 8 quarter-rack Exalogic systems.  While this is a mainframe application replacementexample rather than rehosting of an existing application, it underlines theperformance advantages that can be achieved through Tuxedo optimizations onExalogic. Migrating off expensive, inflexible mainframe systems to Tuxedo These four customers are notalone in migrating off expensive and inflexible mainframe systems toTuxedo-powered open systems infrastructure. They are just the more recentexamples of mainframe migrations leveraging Tuxedo that demonstrate significantcost and risk reduction benefits, and highlight the gains in performance,datacenter flexibility, and business agility customers can achieve usingTuxedo-based migration approach.  Insubsequent posts we’ll highlight the technical details of these migrations, andshare best practices for migrating mainframe applications to Tuxedo. More Information Press Release:  Oracle Enhanced Mainframe Rehosting for Oracle Tuxedo 12c Web Page:  Tuxedo page on oracle.com Stay Connected Follow Tuxedo: Stay Connected Follow Cloud Application Foundation:

Mainframe customers have options.  Not that mainframe vendors, like IBM, would tell them.  In fact, IBM recently put together a presentation on “The Reality of Rehosting” and, as you can guess,they...

Increase the Availability of Your Tuxedo Applications and Improve IT Productivity with TSAM Plus--By Deepak Goel, Senior Director, Software Development

Find out how you can increase the productivity of your IT staffand the availability of your Tuxedo applications using Oracle TuxedoSystem and Application Monitor Plus 12c (TSAM Plus 12c).  Checkout YouTube video below by Todd Little, Managing Tuxedo Applications with TSAM Plus12c and OEM CC12c.   TSAM Plus 12c is a management and monitoring solution forTuxedo 12c applications.  It helps improve performance andavailability of Tuxedo applications and expedite  problem resolution in bothdev/test and production environments, while monitoring several domains at thesame time.  TSAM 12c has many features, which help automate day-to-dayoperations such as resource deployments, scale up and out of application nodesand service level management, increasing the productivity of IT staff as theydo not need to worry about writing scripts, or moving from one console toanother console or correlating messages from one product to another in order todiagnose a critical production problem.  TSAM Plus 12c includes a plugin for Oracle EnterpriseManager Cloud Control 12c, which allows Tuxedo applications to be monitored andmanaged from the same console as other Oracle products, including WebLogic andDatabase. TSAM Plus 12c Functionality can be broadly categorized as follows: Application Performance Management:  TSAM Plus 12cgreatly improves application performance by providing unique functionality toautomatically detect performance bottlenecks; quickly diagnose theseperformance problems, and identify their root cause Operations Automation: TSAM Plus 12c automates commonmanual and error prone operations allowing administrators to focus on morestrategic initiatives. With TSAM Plus 12c , Tuxedo applications can be packagedin a self contained application package along with required configurationartifacts and stored in a central repository, ready for deployment, to anexisting domain, or to interactively create a new Tuxedo domain or to addadditional nodes to an existing domain. Both physical and virtual environmentsare supported.  In addition, With TSAM Plus 12c, it is much easier to makechanges in configuration of Tuxedo applications in production environmentwithout having to restart the application, thus avoiding costly downtime. WithTSAM Plus 12c, A Tuxedo domain can be changed dynamically, in addition tocreating a new Tuxedo domain from scratch. TSAM Plus 12c also helps withday-to-day operational tasks, such as manually start and stop applications andstart new instances of an application server. Service Level Management: TSAM Plus 12c helps ITorganizations to achieve high availability, performance, and optimized servicelevels for their business services. More Information Datasheet:  OracleTuxedo System and Application Monitor Web Page:  Tuxedo page on oracle.com Stay Connected Follow Tuxedo: Stay Connected Follow Cloud Application Foundation:

Find out how you can increase the productivity of your IT staff and the availability of your Tuxedo applications using Oracle Tuxedo System and Application Monitor Plus 12c (TSAM Plus 12c).  Checkout...

Developing and Deploying Services in Java on Tuxedo 12c is Easy and Straightforward by Todd Little, Oracle Tuxedo Chief Architect

One of the 187 new features in Tuxedo 12c is theability to develop Tuxedo services in Java.  Prior to Tuxedo 12c, tocreate a Tuxedo service in Java meant adding another application server such asWebLogic Server or IBM WebSphere to the environment and using either theWebLogic Tuxedo Connector (WTC) or the Tuxedo JCA Adapter.  The servicewas then developed in Java, deployed to the Java EE application server, andthen connected to existing Tuxedo applications via the Tuxedo domaingateway.  This meant that every request from Tuxedo to these Java servicesentailed a network hop and any distributed transactions required a subordinatetransaction to be started in the Java EE application server.  As well, anynative Tuxedo service called by the Java service now required another networkhop--all in all usable, but requiring more administration, more resources, andmore complexity.Java Server Support The Java Server support in Tuxedo uses a POJO programming model based upon JavaSE.  The programming environment and APIs used for service development isJATMI, the same API used in WTC.  JATMI is essentially an object orientedversion of the standard Tuxedo Application to Transaction Monitor Interface(ATMI).  It supports virtually all of the ATMI features and should be veryfamiliar to anyone that has developed Tuxedo services in anotherlanguage.  Yet Java developers have access to the rich set of classlibraries that Java developers have come to know and love.  Since theenvironment is Java SE based, Java EE features such as transaction managementare provided by the JATMI classes instead of the Java Transaction API. Developing & Deploying Java Service on Tuxedo is easyDeveloping and deploying services in Java on Tuxedo is extremely easy andstraightforward.  The basic steps are to create a Java class that extendsthe TuxedoJavaServer class provided by JATMI.  Create one or more methodsthat will handle Tuxedo service requests.  These methods take a TPSVCINFOinstance as the only parameter that contains such information as the name ofthe service called and the typed buffer the caller passed to the service. The method extracts whatever information it needs from the typed buffer,performs its business logic and then creates a typed buffer to reply to thecaller.  Finally the class calls the tpreturn() method to return the replybuffer back to the caller. Configuring the Tuxedo Java Server Once the server class or classes have been developed and compiled, the TuxedoJava Server TMJAVASVR needs to be added to the Tuxedo UBBCONFIG file. This Tuxedo provided server will load the JVM, load the server classes, andtake care of dispatching incoming requests to the methods in the serverclasses.  Which classes to load and the mapping between Tuxedo servicenames that the server will offer are defined in an XML based configurationfile. By default each public method in the server classes is advertised as thename of the Tuxedo service.   This configuration file also specifiessuch things as the classpaths to be used, JDBC driver and connectioninformation for accessing a database, and resources such as FML/FML32 fieldtables and VIEW/VIEW32 classes.  After updating and loading the UBBCONFIGfile, the application is ready to be booted and tested. Sample Implementation and Configuration Here is what a simple Java service implementation might look like: public void JAVATOUPPER(TPSVCINFO rqst) throwsTuxException {         TuxAppContext myAppCtxt =getTuxAppContext();         /* The theapplication context */         TypedBuffer svcData =rqst.getServiceData();        /* Get the callersdata */         TypedString TbString =(TypedString)svcData;        /* Assume it's aSTRING buffer */         String newStr =TbString.toString().toUpperCase();    /* Get the string andupper case it */         TypedString replyTbString = newTypedString(newStr);    /* Create the reply buffer */         myAppCtxt.tpreturn(TPSUCCESS, 0,replyTbString, 0);    /* Return reply buffer to caller */     } The entry in the UBBCONFIG for the Tuxedo Java Server might look like: TMJAVASVRSRVGRP=GROUP1 SRVID=2  CLOPT="-A"          CLOPT="-- -cTJSconfig.xml"          MINDISPATCHTHREADS=2MAXDISPATCHTHREADS=10 which would start a single copy of the Tuxedo Java Server with 10 threads to handle requests. The configuration file TJSconfig.xml for this server might look something like: <?xmlversion="1.0" encoding="UTF-8"?> <TJSconfig>     <TuxedoServerClasses>         <TuxedoServerClassname="MyTuxedoJavaServer"></TuxedoServerClass>     </TuxedoServerClasses> </TJSconfig> where MyTuxedoJavaServer is the name of the Java class that extends the TuxedoJavaServer class.Multiple copies of theTuxedo Java Server can be run just as any other Tuxedo server using the sameconfiguration file or each using their own configuration file.  Allstandard Tuxedo buffer types are supported, so services can use STRING, CARRAY,MBSTRING, FML/FML32, XML, or VIEW/VIEW32 buffers.  As well, Java servicescan call other Tuxedo services by using the tpcall() method on theTuxAppContext. Summary As the Tuxedo Java Server is a standard Tuxedo server, all of the monitoring,management, and administration capabilities that Tuxedo provides to C or otherlanguage servers is available to services written in Java.  These servicesalso benefit from the unmatched reliability, availability, scalability, andperformance that Tuxedo has proven to provide at thousands of customersites.  By providing Java support in Tuxedo, customers are free to choosethe language that best suits their application development needs, whether it isC, C++, COBOL, Python, Ruby, PHP, and now Java, and they all work togetherseamlessly to provide one integration application. Stay Connected Tuxedo: Cloud Application Foundation (CAF):

One of the 187 new features in Tuxedo 12c is the ability to develop Tuxedo services in Java.  Prior to Tuxedo 12c, to create a Tuxedo service in Java meant adding another application server such asWebL...

Three New Features Improve Availability of Tuxedo Based Applications- by Todd Little, Oracle Tuxedo Chief Architect

Tuxedo 12cR1 introduced several new features to help improve the availability of Tuxedo applications.  While Tuxedo is known for providing extremely high reliability, availability, scalability, and performance (RASP), there are always things Oracle can do to improve the availability of an application.  This post will cover three new features that help improve the availability of Tuxedo based applications.Highly available systems try to avoid single points of failure to ensure the survivability of an application even in the midst of a failure.  Tuxedo has provided means to avoid single points of failures in virtually all scenarios except one, and that is when customers use data dependent routing or DDR.  DDR allows an application to be partitioned based upon the values contained in a field of a request buffer.  In the Tuxedo sample bankapp application, the ACCOUNT_ID field in a request message is used to determine which group of servers should handle the request.  This is controlled by the *ROUTING section in the UBBCONFIG file.  For each range of values, a server group can be specified to handle requests.  The issue with regards to availability is that only a single server group can be specified in releases prior to Tuxedo 12cR1.  While a server group can have multiple servers in it such that the failure of a single server won't cause a problem, a server group can only reside on a single machine in a cluster.  Thus if the machine that the server group is on fails, there will be some period of time that the partition of the application associated with that group of servers is unavailable.  Requests to the servers in that partition will fail until the machine is restarted or the server group migrated to another machine. Improved *ROUTING Section With Tuxedo 12cR1 the *ROUTING section can now specify up to three server groups that can be associated with a range of values.  This now allows the application partition to span up to 3 machines allowing the partition to still be available even if two of the machines completely fail.  Besides improving the availability of a partition, it also increases the scalability of a partition as now the resources of up to three machines can be utilized to process requests.  This same improvement is included in the Tuxedo domain gateway as well.  This allows the domain gateway to specify up to three remote domains that can be associated with a range of values in a field.  When combined with multiple gateways, multiple domains, and multiple network links, applications can achieve unmatched levels of availability.Automatic Migration of Machines and Server Groups Another feature increasing availability of Tuxedo applications introduced in Tuxedo 12cR1 is the automatic migration of machines and server groups.  Since very early on, Tuxedo has had mechanisms to allow a machine to be migrated from one host to another, or for a server group to be migrated from one machine to another.  This provides a recovery mechanism in the case of a machine or server group failure.  Prior to Tuxedo 12cR1 the migration process was a manual one that required either manual intervention or the creation of scripts that could perform some level of automated migration.  While the failure of a machine or server group by itself doesn't typically affect the availability of a properly configured application, it may leave the application with one or more single points of failure.  This can be mitigated by ensuring there are always at least three copies of servers or server groups such that if one fails, redundancy is still maintained.  Even though it's not possible to define more than one BACKUP machine for the MASTER machine, and there is only one MASTER machine at any point in time, the failure of the MASTER machine doesn't necessarily impact application availability.  This is one misconception many Tuxedo customers have about MP or clustered operations with Tuxedo.  They see the MASTER machine as a single point of failure, but in fact normal application processing goes on even if the MASTER machine fails.  This is because the DBBL process which runs on the MASTER machine isn't involved in normal request routing.  All that happens if the MASTER fails or for some other reason the DBBL can't be reached is that configuration changes can't occur until the DBBL becomes available.What automatic migration does under most failure scenarios, is to automate the migration of a machine to its backup, or a server group to its backup machine.  This eliminates the possibility of human error causing even more problems during a failure, and as well minimize the time to restore the system to normal operation or reducing the mean time to repair (MTTR).  Reducing MTTR is one of the most effective ways of increasing overall system availability.  Enabling these features is a simple matter of adding two new options to the *RESOURCES section of the UBBCONFIG file.  For more details, see the Migrating Your Application [http://docs.oracle.com/cd/E35855_01/tuxedo/docs12c/ada/admigt.html] section of the Tuxedo 12cR1 documentation. Service Versioning Finally the last availability related feature added in Tuxedo 12cR1 is service versioning.  While that may not sound particularly related to high availability, what it allows is the concurrent deployment of multiple versions of an application.  By being able to run multiple versions of an application simultaneously, customers can gradually introduce new versions of their application without having to shut down their application or impacting existing users in any way.Service version requires no changes to the application code, although presumably there are changes, probably even incompatible changes, which is why Oracle introduced service versioning.  The only required changes are in the UBBCONFIG file.  The APPVER option needs to be set in the *RESOURCES section, and then the REQUEST_VERSION, VERSION_RANGE, and VERSION_POLICY options added to the *RESOURCES section or to any server groups that need versioning support.  The REQUEST_VERSION indicates the version number requests will have.  For native clients and servers it is either the value specified at the *RESOURCES section or then *GROUPS section, with the latter having precedence.  Subsequent calls in the call path will have the request version associated with the server that made the request, unless the VERSION_POLICY is set to PROPAGATE which means the callers service version should be used.  The VERSION_RANGE then indicates what request versions a server is able to process.  When Tuxedo performs request routing, it will determine the request version number and then only select servers that support that version number.  Thus when an incompatible change is made, you would associate a new request version with any updated callers of the service, and set the version range of servers appropriately to ensure that only updated servers handle the requests.  This allows for the introduction of gradual changes and lets the application developer decide what versions of a service interface any given server supports.These new features further enhance Tuxedo's capability to support highly available applications without requiring the customers to build those capabilities into their application code.  The result is that customers can deploy applications that provide 99.999% or better availability, while being able to scale those applications to 100s of thousands of services executed per second. Was this information helpful? Please share your comments and let us know if there are any Oracle Tuxedo topics you would like us to discuss. More Information Oracle Tuxedo Release Notes Stay Connected Follow Tuxedo on: LinkedIn YouTube Tuxedo Blog Follow Cloud Application Foundation(CAF): Twitter Blog

Tuxedo 12cR1 introduced several new features to help improve the availability of Tuxedo applications.  While Tuxedo is known for providing extremely high reliability, availability, scalability, and...

Oracle Tuxedo Mainframe Adapters Provide High Availability, Failover and Load Balancing- See the Demo

Oracle Tuxedo Mainframe Adapters Provide High Availability,Failover and Load Balancing- See the Demo Oracle TuxedoMainframe Adapters provides bi-directional, fully transactional access to and frommainframe CICS, IMS and batch applications. Oracle Tuxedo applications caninvoke CICS, IMS & Batch apps running on mainframes and vice-versa. CRM can support multiple connections and multiple links whichmakes high availability like load balancing and failover become possible. CRMsupports multiple connections including: Several GWSNAXs connect to a single CRM. Theconnected Gateways share a common configuration offering a common set ofservices High availability: Supports inbound loadingbalance (round robin) High availability: Supports inbound failover High availability: Supports inbound transactionaffinity. Interoperatiblity: only supports GWSNAX/CRMof qwc Note: The GWSNAXs must be in different Tuxedodomains. See the video belowfor a demonstration on how to configure Tuxedo Mainframe Adapters for highavailability, failover/failback and load balancing. A step-by-step demo shows how the software works in real-time. Stay Connected FollowTuxedo on: LinkedIn YouTube Tuxedo Blog FollowCloud Application Foundation (CAF):   Twitter Blog

Oracle Tuxedo Mainframe Adapters Provide High Availability, Failover and Load Balancing- See the Demo Oracle Tuxedo Mainframe Adapters provides bi-directional, fully transactional access to and frommain...

Application Service Version- Oracle Tuxedo 12c

The application service version feature provides a configuration-driven approach to deploy different versions of Tuxedo application services in a domain or across domains without changing the existing application. With application service version feature, you can logically partition Tuxedo applications into different virtual application domains, machines, and server groups to respond to various business requirements, including uninterrupted application upgrade for high availability. The Application Service Versioning feature provides MIB support to obtain and change version information at runtime. It also provides cross domain, TMQFORWARD and COBOL support. You can use the application service version feature to: Plan, develop, test, scale and deploy Oracle Tuxedo applications Partition different virtual application domains and different virtual server groups in the current Oracle Tuxedo management hierarchy. Set up user applications according to a defined version Seamlessly upgrade the application and reduce upgrade procedure risk Check out the video below to learn more about what to consider when using application service version, new configuration attributes in the UBB configuration file and the domain configuration file, and to see a demo.

The application service version feature provides a configuration-driven approach to deploy different versions of Tuxedo application services in a domain or across domains without changing the existing...

Calling an existing Web service from Tuxedo is easy—See for yourself

Find out how easy it can be to invoke an existing web service from Tuxedo. Check out the YouTube video with Maurice Gamanho, Oracle SALT: Calling Web Service, which includes a live demo starting with an actual web service interface and ending with an application calling it. Oracle SALT, the Web services gateway for Tuxedo, provides transparent, reliable access to existing Oracle Tuxedo services as standard Web services and enables Tuxedo applications to call standard Web services in a high-performance, easy-to-use, and configuration-driven model.In this video, you will see a step by step demo that shows how Oracle Tuxedo applications can call external Web services as Tuxedo services, with the gateway seamlessly transforming the call using SOAP over HTTP protocol. Some of the many benefits include: ·         Widespread access to applications using Web services without any Web services specific coding·         Interoperability among distributed applications that span diverse hardware and software platforms·         Improved performance, scalability, reliability, and standard support In addition to the benefits mentioned above, the Oracle SALT gateway is also helpful when it comes to configuring extra features such as security, encryption, transactions, reliable messaging, and proxy settings. Oracle SALT uses the Oracle Tuxedo security framework for authentication, protects point-to-point transactions using Secure Socket Layer (SSL) protocols, and can route traffic through SOCKS proxies.   Additional InformationDatasheet: Oracle Service Architecture Leveraging TuxedoWeb Page: Tuxedo Page on Oracle.comYouTube Video: Oracle SALE: Calling Web ServiceStay ConnectedFollow Tuxedo on: LinkedIn YouTube Tuxedo BlogFollow Cloud Application Foundation (CAF):   Twitter    Blog

Find out how easy it can be to invoke an existing web service from Tuxedo. Check out the YouTube video with Maurice Gamanho, Oracle SALT: Calling Web Service, which includes a live demo starting with...

Integrating Oracle Tuxedo Applications into a SOA Environment

Oracle Tuxedo Oracle Tuxedo is the C/C++/COBOL application server of choice, running mission-critical applications in conventional and cloud deployments. It is deeply integrated with WebLogic Server enabling bi-directional transactional communication between Java applications and C/C++/COBOL applications. Easy Integration into SOA environmentsAs one of the original SOA platforms, everything in Oracle Tuxedo is a service. Oracle Tuxedo services are location and implementation independent. They adhere to a contract, and are interoperable with other Oracle Tuxedo services and service oriented platforms. This makes integrating Oracle Tuxedo applications into a SOA environment natural and straightforward, regardless if the business logic is written in C, C++, Java, COBOL, Python, Ruby, or PHP.Client Only and Server to Server OptionsThere are a number of integration techniques that can be used to integrate Oracle Tuxedo applications into a SOA world. The first decision to make when choosing an integration options is whether a Client Only option or a Server to Server option best fits your business needs.  Client Only OptionsFor environments where requests flow only from the client environment to Oracle Tuxedo, there are Client Only Options. The client’s transaction context is never extended to the Oracle Tuxedo system. Oracle Tuxedo transactions started by the client are delegated to Oracle Tuxedo and are separate from any transaction context in which the client may be participating.Server to Server OptionsFor environments where Oracle Tuxedo is able to make calls to the non-Oracle Tuxedo system as well as receive calls, there are Server to Server integration options. Some of these options support distributed transactions and security context propagation.  Java IntegrationOracle Tuxedo provides the following Java integration options.  Oracle WebLogic Tuxedo Connector (WTC), a standard component of Oracle WebLogic Server, provides bi-directional service invocations to and from Oracle Tuxedo and Oracle WebLogic Server within context of global, XA transactions. Using WTC,  based on Tuxedo domains, Tuxedo applications can invoke JEE applications running on WebLogic and vice-versa.  With its integrated JMS bridge, JMS Messages can flow to/from Oracle Tuxedo /Q queues and vice-versa.  Oracle Tuxedo JCA Adapter provides similar capabilities as WTC, but for all JEE application servers. It allows bi-directional, transactional interactions between JEE applications and Oracle Tuxedo applications. Native Java Support available in the Oracle Tuxedo 12c release means services can be implemented in Java as plain old Java objects or POJOs. Developers can use JATMI to develop Oracle Tuxedo services in Java and leverage Oracle’s scalable, highly available infrastructure to create or extend their enterprise to class SOA applications. Jolt provides access to Oracle Tuxedo services from essentially any Java environmentranging from stand alone Java applications, applets running inside a browser, to clients running inside a JEE application server. It provides a simple set of Java classes that support  Oracle Tuxedo client facilities such as invoking services, enqueuing and dequeuing messages to Oracle Tuxedo /Q queues, and subscribing to Oracle Tuxedo Event Broker for publish and subscribe interactions. Web Services IntegrationThe Oracle Services Architecture Leveraging Tuxedo (SALT) provides bi-directional SOAP/HTTP support for Oracle Tuxedo applications. This product is completely configuration driven, meaning that no coding is necessary to access remote web services or to allow remote applications to access Oracle Tuxedo services as web services. SALT provides a high performance point to point integration mechanism using open standards. It is an ideal solution for customers standardizing on SOAP/HTTP as their protocol of choice for integrating applications.  SALT supports most of the common web services standards including SOAP 1.1 and 1.2, SOAP with attachments, MTOM, WSDL 1.1, WS-Policy, WS-Addressing, WS-ReliableMessaging, WS-Security 1.0 and 1.1, WS-Coordination, and WS-AtomicTransaction 1.0. This allows integration with most other web services platforms including Oracle WebLogic Server, Axis for Java 2.0, Microsoft .NET framework 3.0, Oracle Service Bus, and Oracle BPEL, as well as most other popular SOAP/HTTP offerings..NET IntegrationOracle Tuxedo includes support of a .NET client library that can be used to access Oracle Tuxedo services from a .NET application. Like Jolt, the .NET client is a client only offering so .NET application can invoke Oracle Tuxedo services, but Oracle Tuxedo cannot invoke .NET applications. WebSphere MQ Integration Oracle Tuxedo ships with a bi-directional MQ adaptor that allows messages placed on MQ queues to be delivered to an Oracle Tuxedo service and the reply from the Oracle Tuxedo service to be placed on the output MQ Queue. Applications needing staged transactional delivery of requests can use standard Oracle Tuxedo distributed transaction management to ensure exactly once processing of messages.Mainframe Services IntegrationThe Oracle Tuxedo Mainframe Adapter (TMA) provides an excellent foundation for integrating legacy mainframe systems, such as IBM CICS and IMS/TM,  into a modern SOA environment. With TMA, mainframe applications see Tuxedo services as though they were local and Tuxedo services see mainframe applications services as local services.  allow the sharing of services between Oracle Tuxedo and the mainframe systems.Like other integration options built on Oracle Tuxedo’s domains technology, TMA supports identity propagation and support distributed transactions. Service Bus IntegrationOracle Service Bus (OSB) is an enterprise service bus that supports the integration, mediation, and monitoring of a variety of types of services.   For each type of service supported by OSB a transport is used to handle the connection and interfacing to the specifics of the service. OSB also has a built-in transport for Oracle Tuxedo.  The Oracle Tuxedo transport supports Oracle Tuxedo based business services that can be accessed from any OSB proxy as well as Oracle Tuxedo proxy services which allow Oracle Tuxedo applications to call services mediated by OSB. Oracle Tuxedo provides many ways to connect with other SOA platforms and environments. For more detailed information about each of the integration choices, download the white paper, Oracle Tuxedo in a SOA World. Stay ConnectedFollow Tuxedo on: LinkedIn YouTube Tuxedo BlogFollow Cloud Application Foundation (CAF):   Twitter    Blog

Oracle Tuxedo Oracle Tuxedo is the C/C++/COBOL application server of choice, running mission-critical applications in conventional and cloud deployments. It is deeply integrated with WebLogic Server...

Oracle Tuxedo at Oracle Open World 2012

Oracle Open World is almost here. There is quite a bit of Tuxedo totalk about at this year’s OOW. Primary focus will be on Tuxedo 12c, which was announced in August 2012 and is now generally available. Tuxedo 12c is amajor release which many-many new and exciting features in almost all components of Tuxedo. You will not only hear about thesefeatures in various conference  sessions, you will also have an opportunity to seethese features in action at demo grounds or play with these yourselves inhands-on-labs. Following is listing of Tuxedo related activities at OOW 2012: Conference Sessions Mon 1 Oct, 2012 10:45 AM - 11:45 AM, Oracle Tuxedo: What’s New in 12 c,Strategy, and Roadmap, Moscone South - 309 4:45 PM - 5:45 PM, Simplify Operations, Administration, and Management of Oracle Tuxedo Applications, MarriottMarquis - Golden Gate C3 Wed 3 Oct, 2012 3:30 PM - 4:30 PM, TheArt and Practice of Mainframe Migration and Modernization, Moscone South - 309 Thu 4 Oct, 2012  2:15 PM - 3:15 PM,High-Performance, Scalable Enterprise Messaging for C/C++/COBOL Applications,Marriott Marquis - Salon 7 HOL (Hands-on Lab) Tues 2 Oct, 2012 5:00 PM - 6:00 PMDeploy, Manage, and Monitor Oracle Tuxedo Applications in the Enterprise Cloud,Marriott Marquis - Salon 3/4 Wed 3 Oct, 2012 1:15 PM - 2:15 PM, DevelopC/C++ Applications for the Cloud with Oracle Tuxedo and Oracle Solaris Studio, MarriottMarquis - Salon 5/6 BOF(Birds-of-a-Feather) Mon 1 Oct, 2012 6:15 PM - 7:00 PM, DevelopScalable, Highly Available Enterprise Services in Java with Oracle Tuxedo, MarriottMarquis - Golden Gate C1 Demos Oracle Tuxedo: #1 Enterprise Cloud Platform for C/C++/COBOL Apps,  Moscone South, Right - S-215 Mainframe Rehost withOracle Tuxedo Runtimes for CICS, IMS, and Batch, Moscone South, Right - S-216 Tuxedo Customer AppreciationDinner Monday 1 Oct, 2012 7:30PM - Please contact your Oracle Account Representative to attend. Limited seating. DeepakGoel Sr.Director, Software Development Oracle

Oracle Open World is almost here. There is quite a bit of Tuxedo totalk about at this year’s OOW. Primary focus will be on Tuxedo 12c, which was announced in August 2012 and is now generally...

Tuxedo Load Balancing

A question I often receive is how does Tuxedo perform load balancing.  This is often asked by customers that see an imbalance in the number of requests handled by servers offering a specific service. First of all let me say that Tuxedo really does load or request optimization instead of load balancing.  What I mean by that is that Tuxedo doesn't attempt to ensure that all servers offering a specific service get the same number of requests, but instead attempts to ensure that requests are processed in the least amount of time.   Simple round robin "load balancing" can be employed to ensure that all servers for a particular service are given the same number of requests.  But the question I ask is, "to what benefit"?  Instead Tuxedo scans the queues (which may or may not correspond to servers based upon SSSQ - Single Server Single Queue or MSSQ - Multiple Server Single Queue) to determine on which queue a request should be placed.  The scan is always performed in the same order and during the scan if a queue is empty the request is immediately placed on that queue and request routing is done.  However, should all the queues be busy, meaning that requests are currently being processed, Tuxedo chooses the queue with the least amount of "work" queued to it where work is the sum of all the requests queued weighted by their "load" value as defined in the UBBCONFIG file.  What this means is that under light loads, only the first few queues (servers) process all the requests as an empty queue is often found before reaching the end of the scan.  Thus the first few servers in the queue handle most of the requests.  While this sounds non-optimal, in fact it capitalizes on the underlying operating systems and hardware behavior to produce the best possible performance.  Round Robin scheduling would spread the requests across all the available servers and thus require all of them to be in memory, and likely not share much in the way of hardware or memory caches.  Tuxedo's system maximizes the various caches and thus optimizes overall performance.  Hopefully this makes sense and now explains why you may see a few servers handling most of the requests.  Under heavy load, meaning enough load to keep all servers that can handle a request busy, you should see a relatively equal number of requests processed.  Next post I'll try and cover how this applies to servers in a clustered (MP) environment because the load balancing there is a little more complicated. Regards,Todd LittleOracle Tuxedo Chief Architect

A question I often receive is how does Tuxedo perform load balancing.  This is often asked by customers that see an imbalance in the number of requests handled by servers offering a specific service. Fi...

Leveraging Infiniband to bypass the BRIDGE

As Deepak mentioned in the previous post, the Tuxedo team has spent a lot of effort in leveraging some of the unique features of the Exalogic platform.  Specifically we've developed support for Remote Direct Memory Access.  This is a feature of Infiniband that allows one node to read or write directly into the memory of another node.  In particular this can all be done from user mode, meaning there is no need to enter the operating system kernel to pass information from one node to another node.Tuxedo 11gR1PS2 uses this RDMA capability to bypass the BRIDGE process used in a Tuxedo cluster (MP mode domain.)  In standard hardware environments, when a request is made to a server on a remote node, the request is given to the BRIDGE which in turn passes the request to the remote BRIDGE which eventually places the request on the appropriate server's queue.  The reply message takes the reverse path being placed on the local BRIDGE queue, relayed to the remote BRIDGE by a network connection, and then finally placed on the client's reply queue.  In some cases this becomes a bottleneck as the BRIDGE is only partially multi-threaded.  So on high core count systems with a lot of requests being made to remote servers, the BRIDGE creates a throughput bottleneck.  As well the BRIDGE introduces substantial latency as the total round trip requires 4 System V IPC messages and two network messages.  Where a local request/response can be performed in about 35 microseconds, a remote request/response through the BRIDGE can take about 1100 microseconds.  This diagram shows the message flow: With the BRIDGE bypass feature, a native client uses RDMA to place its request directly on the remote server's queue, and the reply is placed directly on the client's reply queue.  This eliminates two message queue operations and two network operations.  The net result is that throughput increases 7 fold for remote operations by bypassing the BRIDGE and reduces latency from 1100 microseconds to 160 microseconds.  This diagram shows the message flow: For the next release of Tuxedo sometime this summer, we're planning even more optimizations to achieve even more throughput and lower latency for remote operations.

As Deepak mentioned in the previous post, the Tuxedo team has spent a lot of effort in leveraging some of the unique features of the Exalogic platform.  Specifically we've developed support for Remote...

Tuxedo is now optimized for Exalogic

We are in 2012! Wish you all a very happy new year. In case you missed the announcement, we released a new version of Tuxedo, Tuxedo 11.1.1.3.0, middle of December 2011. If you have seen the press release, you know this release includes Tuxedo optimizations for the Exalogic platform. This is first of the blog in a series to talk about Oracle Tuxedo 11.1.1.3.0 features. We have changed the guts of Tuxedo to take full advantage of Exalogic technology, specially related to Infiniband. These technologies are SDP (Socket Direct Protocol) and RDMA over Infiniband. All Tuxedo components now can use SDP instead of TCP/IP when communicating with other components running on Exalogic and/or Exadata. Use of SDP generally results in less CPU consumption, leaving more for applications to use. With RDMA over Infiniband, clients/servers on one node can talk directly to servers on the other node without going through the BRIDGE process. This serves two purposes, it eliminates BRIDGE as the bottleneck and reduces the latency of communication by an order of magnitude, in some case to as low as a few microseconds. The benchmarks results from our in-house tests have been shown dramatic improvement in throughput.In addition, one cool feature Tuxedo 11.1.1.3.0 release includes is self tuning of SPINCOUNT. Tuxedo now monitors application workload on Exalogic and based on the workload it adjusts the value of SPINCOUNT dynamically for the best use of CPU cycles. Optimized tuning of SPINCOUNT is crucial as SPINCOUNT is used in the context of bulletin board locking and impacts almost each and every operation in Tuxedo. With Tuxedo 11.1.1.3.0 on Exalogic, there is one less thing to worry about when configuring Tuxedo. Other features includes in this release are:-OVM 3.0 certification-OVAB (Oracle Virtual Assembly Builder) plugin for Tuxedo-TLOG Store in DatabaseKeep an eye at this blog for more details to follow!Deepak GoelSr. Director, Tuxedo Development

We are in 2012! Wish you all a very happy new year. In case you missed the announcement, we released a new version of Tuxedo, Tuxedo 11.1.1.3.0, middle of December 2011. If you have seen the press...

Oracle Tuxedo at OOW 2011

Oracle Open World 2011 is just around the corner. There will be quite a bit of Oracle Tuxedo specific activities this year. We will host five breakouts, two hands-on-labs and one birds-of-feather session. You will hear what’s new with Tuxedo and see many of the new features in action at the demo grounds. We will kick off the activities with Tuxedo roadmap discussion and delve into new features introduced over the last year, such as deploying existing Tuxedo applications and/or mainframe applications on Exalogic for better performance, reduced complexity and reduced operating expenses. Here is chronological listing of all Tuxedo related sessions:1. 15730: Oracle Tuxedo: Roadmap and Strategy - Monday, 2pm2. 15705: High performance web applications with C/C++/PHP/Python - Monday, 5pm3. 33700: Birds-of-Feather: Road to Oracle Exalogic for Oracle Tuxedo Applications – Monday, 6:30pm4. 15040: The ART and Practice of Mainframe Migration and Modernization – Tuesday, 4pm5. 31020: Hands-on-Lab: Mainframe to Oracle Exalogic – Wednesday, 4:45pm6. 15703: Integrating Oracle WebLogic/SOA with Legacy Mainframe Applications - Thursday, 10:30am7. 31120: Hands-on-Lab: Develop High performance, service-oriented C/C++ applications for Oracle Exalogic – Thursday, 12pm 8. 15731: Modernizing Mainframe Applications Using Oracle Tuxedo ART 11g – Thursday, 1:30pmHope to see you in these sessions and at demo grounds!Deepak GoelSr. Director, Tuxedo Development

Oracle Open World 2011 is just around the corner. There will be quite a bit of Oracle Tuxedo specific activities this year. We will host five breakouts, two hands-on-labs and one...

Tuxedo is certified on Exalogic and other platforms

It has been a while since we last shared some news. I will start with two news items, which I believe are of general interest: 1.Tuxedo is now supported on Exalogic X2-2 running either Linux or Solaris 11 Express. If you are not familiar with what Exalogic is, please visit http://www.oracle.com/exalogic. "Oracle Exalogic Elastic Cloud is the world's first and only integrated cloud machine--hardware and software engineered together to provide a "cloud in a box"". Our internal benchmark have shown that Tuxedo can effectively leverage 40Gb bandwidth of Exalogic's Infiniband, resulting in higher throughput and lower latencies. This is also one of the focus areas for Tuxedo going forward. We will continue to enhance Tuxedo for better performance on Exalogic. A lot is in the pipeline. Continue to watch for news in this space.2.Tuxedo 11g (11.1.1.2.0) is now certified and available for use on following platforms: •Suse Linux 11 64-bit - You can run both 32-bit and 64-bit Tuxedo binaries •Windows 2008 R2 - 32-bit Tuxedo binaries•It appears Windows 7 adoption as a client platform is increasing across the corporate world. We have had received a few queries for Tuxedo support on Windows 7. Tuxedo 10gR3 (Tuxedo 10.3) client only installer is now available for Windows 7. To keep yourself up-to-date on latest platform support, see Tuxedo certified platforms table. Deepak GoelSr. Director, Tuxedo

It has been a while since we last shared some news. I will start with two news items, which I believe are of general interest: 1. Tuxedo is now supported on Exalogic X2-2 running either Linux or Solaris...

TSAM SLA Monitoring

One of the most powerful features of TSAM is the ability to monitor Service Level Agreements. TSAM provides two alerting mechanisms. One allows you define alerts that should be checked by the TSAM console. As data is reported to TSAM Manager (the data collection and storage portion of TSAM) it is compared against alerts that have been defined in the console. This can be a great tool in monitoring your Tuxedo applications. The one drawback though is that the data has to be reported to TSAM Manager. Given that many Tuxedo applications process 100's or 1000's of requests per second, if the monitoring policies for these kinds of applications enable reporting most of the information that can be collected, it is likely that the TSAM Manager component will be overwhelmed with too much data.In order to provide finer grained monitoring and ensure that SLAs are being adhered to, TSAM allows alerts to be defined at the plug-in level. The triggering of these alerts is based upon an FML32 boolean expression against the monitoring data evaluating to true. Once an alert is triggered, an alert may be sent to the TSAM Manager, trigger a Tuxedo event to be processed by the Tuxedo EventBroker, and optionally have the message be dropped from the servers IPC queue in the event that there is no point in processing the request.In my next post, I'll give the details on how these sorts of alerts are defined and some additional ideas about what sort of actions you might want to take place when these alerts are triggered.Regards,Todd LittleOracle Tuxedo Chief Architect

One of the most powerful features of TSAM is the ability to monitor Service Level Agreements. TSAM provides two alerting mechanisms. One allows you define alerts that should be checked by the TSAM...

Announcing availability of Tuxedo 11gR1 PS1 release

I am happy to announce general availability of Tuxedo 11gR1 PS1 release (version 11.1.1.2.0). This release introduces several enhancements and features - almost all of which are driven by customer feedback received during 11gR1 beta, POCs and other direct customer engagements, especially related to mainframe application rehosting. Given below are highlights of the features/enhancements included in this release. Note that, we will talk about and demonstrate many of the new features at OOW, San Francisco Week of September 19th. If you are coming to OOW, please plan to attend one or more of the Tuxedo sessions and also stop by our demo pod W-190 in Moscone West. I will post list of Tuxedo sessions along with timing and venue separately. This will be a great event. New features/Enhancements in Tuxedo ART Runtime and Workbench 11gR1 PS1:-More coverage for CICS APIs -Support for RRDS-Enhanced CICS TSQ and TDQ support-SSL for TN3270 Terminal server-Sort support for migrated files-Support for additional JCL features-Enhanced batch utilities and parallelization of batch job execution-Enhanced management of batch outputNew features/Enhancements in Tuxedo core and other product options:-Support for multiple resource managers from a Tux application server -Extremely simplified JCA Adapter configuration and deployment -Flexible AUTOTRAN configuration within Tuxedo and JCA Adapter-Monitoring of Tuxedo ART batch Jobs from TSAM -Support of TSAM and SALT on OpenVMS and OS/400 -Availability of Tuxedo Mainframe Adapters (SNA, TCP and OSITP) -Enhanced mainframe connection management for TMA SNAFor detailed list of new features/enhancements, see product documentation at: http://download.oracle.com/docs/cd/E18050_01/tuxedo/To download Tuxedo 11gR1 PS1 release, go to: http://www.oracle.com/technetwork/middleware/tuxedo/downloads/index.html. Regards,DeepakSenior Director, Software DevelopmentOracle Fusion Middleware

I am happy to announce general availability of Tuxedo 11gR1 PS1 release (version 11.1.1.2.0). This release introduces several enhancements and features - almost all of which are driven by customer...

What is Oracle Tuxedo?

Surprisingly this is an all too common question. It recently came up in the Tuxedo OTN forum and based upon the response I got to my answer to this question, I thought it would be useful to post that here as well. So my answer was (and still is):Tuxedo is an application server for non-Java languages. Specifically what this means is that it provides a bunch of facilities that help customers build and deploy enterprise applications written in C, C++, COBOL, and with the SALT add-on applications written in Python and Ruby. As an application server, it provides containers to host your business logic written in those languages. It provides facilities to transparently distribute your application across a cluster of machines and to route and load balance requests across the machines in the cluster and the servers within a machine. If machines fail or network links fail, Tuxedo will automatically route requests to the remaining accessible servers in the cluster, thus providing extremely high availability. When those resources are returned to service, Tuxedo will automatically start making use of those resources, thus you get failover and failback. Tuxedo tends to be used where RASP (Reliability, Availability, Scalability, and Performance) are paramount in the application. Tuxedo customers regularly get 99.99% to 99.999% availability for their applications with some customers running continuously for years without an outage. As a highly optimized application server, Tuxedo can invoke a service in another process and get a response back in around 35 microseconds. That performance combined with Tuxedo's clustering capabilities allows it to be able to handle 100,000's of requests/second, as Tuxedo scales nearly linearly from a single process on a single machine, to clusters of clusters.As one of the original SOA platforms, everything in Tuxedo is a service that is accessed by name. A client simply calls a service by name passing a buffer of information. Tuxedo automatically routes the request to the least loaded server that can handle the request and then automatically dispatches the request in the server to the business logic associated with that service. The service implementation then processes the request in the buffer and returns a buffer to the caller containing the response from the service. Requests can be made synchronously, asynchronously, queued, or one-way. Other services provided by Tuxedo include transaction monitoring to support distributed XA transactions, store and forward messaging with a variety of QoS options, pub/sub messaging, a variety of gateways to provide transparent access to MQ Series queues, SNA and TCP gateways to transparently connect to CICS and IMS applications, and Java connectors that provide connectivity to JEE application servers. Clients for Tuxedo services can be written in C, C++, COBOL, .Net, and Java.With an add-on product called SALT, Tuxedo can support bi-directional SOAP/HTTP(S) web services, thus providing easy integration into other SOA environments. With SALT, existing Tuxedo services can be made available as SOAP/HTTP(S) services without any change to the existing Tuxedo servers. As for "wrappers", SALT does use wrappers, or more accurately stubs and skeletons, in its support of the SCA standards. This allows business logic to implemented as a simple C++, Python, or Ruby function and all of the messaging and buffer handling is handled transparently by the SALT generated stubs and skeletons. This can make it quite easy to take an existing monolithic application and break it up into a set of Tuxedo services with little to no changes to the existing monolithic application code.Tuxedo also provides extensive management and monitoring capabilities, especially with the TSAM (Tuxedo System and Application Monitor) add-on which provides detailed end-to-end performance monitoring of a Tuxedo application.Lately Tuxedo has been used by many customers to migrate their COBOL applications from legacy environments such as IBM's CICS and IMS on expensive mainframe systems to much less expensive distributed systems. Two recent Tuxedo related products ART and ART Workbench provide tooling and a runtime infrastructure to help in these migrations, which are performed with primarily or only automated code transformation that replaces mainframe specific APIs with Tuxedo compatible APIs. Thus the business logic remains untouched, and only the technical APIs are modified. These customers often find that their total cost of ownership of the migrated application is reduced by 50-80%, while still maintaining mainframe or better quality of service.

Surprisingly this is an all too common question. It recently came up in the Tuxedo OTN forum and based upon the response I got to my answer to this question, I thought it would be useful to post that...

Tuxedo at Oracle Open World 2010

At Oracle Open World 2010, we will have several break-out sessions and hands-on lab focused on Tuxedo; all exciting and informative as ever. These sessions and HOLs discuss new products, technologies and best practices for developing mission-critical, enterprise applications using Tuxedo. In addition, we will demonstrate following on the exhibition floor: 1. How to rehost mainframe applications on to Tuxedo without change to application code and save 50 to 80% in operational costs 2. Develop and deploy new web apps written in dynamic languages to improve scalability and extensibility 3. Develop new C/C++ Web services quickly using modern and standards based tools. List of breakout sessions and Hands-on-labs is as follows: Conference Sessions at Oracle Open World: 1. S317398: Oracle Tuxedo Roadmap: Mission Critical SOA and Mainframe Application Rehosting Speaker: Frank Xiong, Vice President, Tuxedo Development 2. S317401: The ART of Mainframe Migration and Modernization Speaker: Mark Rakhmilevich, Director, Product Management 3. SOA Application Development Using Oracle Service Architecture Leveraging Tuxedo Speakers: Anant Mahajan, Accenture and Sumit Kumar Agrawal, Accenture Conference Sessions and Hands-on-Labs at Oracle Develop: 1. S317399: Leverage high performing non-Java services from Java applications Speakers: Todd Little, Chief Architect, Tuxedo Development, and Paco Gomez, Master Principal Sales Consultant 2. S317400: How to improve scalability and availability of PHP/Python/Ruby web apps? Speakers: Deepak Goel, Senior Director, Tuxedo Development and Maurice Gamanho, Consulting Member of Technical Staff 3. S318572: Develop enterprise apps in PHP, Python or Ruby and scale with Oracle Tuxedo, Speakers: Maurice Gamanho, Todd Little and Deepak Goel 4. S318573: Be an ARTist: Re-host an IBM Mainframe Online Application to Oracle Tuxedo Speakers: Paco Gomez, Jared Li, Director, Software Development and Xin Cao, Software Developer Visit http://www.oracle.com/us/openworld/036763.htm?src="6896290&Act=84" to register for the event and/or to build your schedule.Deepak GoelSenior Director, SW Development

At Oracle Open World 2010, we will have several break-out sessions and hands-on lab focused on Tuxedo; all exciting and informative as ever. These sessions and HOLs discuss new products, technologies...

Tuxedo Virtual Developer Days

Although summer has arrived and I've been pretty quiet, it's not because of lack of things to do or lack of things that have been done. I'm excited to announce that the Oracle Technology Network will be hosting a set of Tuxedo focused Virtual Developer Days. These will be one day or less on-line conferences hosted by OTN around the world during the months of July-September. Here is some additional information:Oracle Tuxedo, a strategic component of Oracle Fusion Middleware, has significantly evolved during last several years to meet requirements of today's enterprise applications. With introduction of features such as native Web services, an extremely easy-to-use new programming model, metadata driven development, support for Python/Ruby programming languages and much more, Oracle Tuxedo provides a complete platform for enterprise application development. How do you keep up with all the advances in Oracle Tuxedo?Join us at this free, online, multi-language event series to learn how you can get the most out of your existing Tuxedo services and quickly develop new Web applications.• Learn new Oracle Tuxedo features from the comfort of your laptop• Learn what Python, Ruby, and PHP have to do with Oracle Tuxedo• Get Hands-on either locally with VirtualBox or hosted via the Cloud• Network Online with Peers, Oracle Tuxedo architects and developers worldwide• Live Chat in virtual chatroom• Sessions, Labs, and Live Help in LOCAL Language!• Post-event access to conference material• Cloud Hands on Labs powered by RackspaceReview the agenda details, dates, and language support options.Space is limited, so register for this event now!For information and to register go to: http://www.oracle.com/goto/otnvddOh yeah, maybe the most important part, I'll be giving the keynote for the English language versions of the event! :-)Regards,Todd LittleOracle Tuxedo Chief Architect

Although summer has arrived and I've been pretty quiet, it's not because of lack of things to do or lack of things that have been done. I'm excited to announce that the Oracle Technology Network will...

Python and Ruby in Tuxedo

With the release of SALT 11gR1, you can now develop Python/Ruby services/applications on Oracle Tuxedo platform. Python functions or Ruby classes can be invoked as Tuxedo services by other Tuxedo services or clients and, in addition, Python/Ruby applications can invoke existing Tuxedo services. SALT 11gR1 combines the proven scalability, reliability and performance of the Tuxedo runtime infrastructure with the agility provided by these dynamic scripting languages, providing a highly available and almost linearly scalable platform for Python and Ruby application development. Another benefit of developing Python and Ruby applications with Tuxedo is that services are SOA enabled from inception by virtue of Tuxedo's comprehensive integration options with J2EE app servers, mainframe applications, Web services, etc.Other interesting features are dynamic re-loading of scripts, where script changes are picked up automatically or when the administrator decides, and server-side typing, where Python functions and Ruby classes are given interfaces by way of the Tuxedo Metadata Repository.More information can be found on the Oracle SALT 11gR1 documentation page. See also SCA Python and Ruby Programming and Python and Ruby Data Type Mapping.

With the release of SALT 11gR1, you can now develop Python/Ruby services/applications on Oracle Tuxedo platform. Python functions or Ruby classes can be invoked as Tuxedo services by other...

TSAM 11gR1

The Tuxedo System and Application Monitor (TSAM) 11gR1 release provides powerful new application monitoring capabilities, as well as significant improvements in ease of use. The first thing users will notice is the completely redesigned user interface in the TSAM console. Based on Oracle ADF, the console is much easier to navigate, provides a Web 2.0 style interface with dynamically updating panels, and a look and feel familiar to those that have used Oracle Enterprise Manager. Monitoring data can be viewed in both tabular and graphical form and exported to Excel for further analysis.A number of new metrics are collected and displayed in this release. Call path monitoring now displays CPU time, message size, total transport time, and client address giving even more end-to-end information about a specific Tuxedo request. As well the call path display has been completely revamped to make it much easier to see the branches of the call path. The call pattern display now provides statistics on successful vs failed calls, system and application failures, and end-to-end average elapsed time. Service monitoring now displays minimum and maximum message size, CPU usage, and client address. System server monitoring now includes monitoring the SALT gateway servers to provide detailed performance metrics about those servers.Perhaps the most significant new feature is the consolidation of alert definitions and policy management. In previous versions of TSAM, some alerts were defined and checked on the monitored systems while others were defined and checked in the console. Policy management could be performed on both the monitored node via environment variable or command, as well as from the console. Now all alert definitions and policy definitions are only made using the console. For alerts this means that regardless of where the alert is evaluated it is defined in one and only one place. Thus the plug-in alert mechanism of previous releases can now be managed using the TSAM console, making SLA alert definition much easier and cleaner.Finally there is support in TSAM for monitoring rehosted mainframe applications. The newly announced Oracle Tuxedo Application Runtime for CICS and Batch can be monitored in the TSAM console using traditional mainframe views of the application such as regions. Look for a future blog entry with more details on this as well as some entries providing a glimpse of the console.TSAM gives users a single point for monitoring the performance of all of their Tuxedo applications.

The Tuxedo System and Application Monitor (TSAM) 11gR1 release provides powerful new application monitoring capabilities, as well as significant improvements in ease of use. The first thing users will...

Tuxedo 11gR1 Client Server Affinity

One of the major new features in Oracle Tuxedo 11gR1 is the ability to define an affinity between clients and servers. In previous releases of Tuxedo, the only way to ensure that multiple requests from a client went to the same server was to establish a conversation with tpconnect() and then use tpsend() and tprecv(). Although this works it has some drawbacks. First for single-threaded servers, the server is tied up for the entire duration of the conversation and cannot service other clients, an obvious scalability issue. I believe the more significant drawback is that the application programmer has to switch from the simple request/response model provided by tpcall() to the half duplex tpsend() and tprecv() calls used with conversations. Switching between the two typically requires a fair amount of redesign and recoding.The Client Server Affinity feature in Tuxedo 11gR1 allows by way of configuration an application to define affinities that can exist between clients and servers. This is done in the *SERVICES section of the UBBCONFIG file. Using new parameters for services defined in the *SERVICES section, customers can determine when an affinity session is created or deleted, the scope of the affinity, and whether requests can be routed outside the affinity scope.The AFFINITYSCOPE parameter can be MACHINE, GROUP, or SERVER, meaning that while the affinity session is in place, all requests from the client will be routed to the same MACHINE, GROUP, or SERVER. The creation and deletion of affinity is defined by the SESSIONROLE parameter and a service can be defined as either BEGIN, END, or NONE, where BEGIN starts an affinity session, END deletes the affinity session, and NONE does not impact the affinity session.Finally customers can define how strictly they want the affinity scope adhered to using the AFFINITYSTRICT parameter. If set to MANDATORY, all requests made during an affinity session will be routed to a server in the affinity scope. Thus if the affinity scope is SERVER, all subsequent tpcall() requests will be sent to the same server the affinity scope was established with. If the server doesn't offer that service, even though other servers do offer the service, the call will fail with TPNOENT. Setting AFFINITYSTRICT to PRECEDENT tells Tuxedo to try and route the request to a server in the affinity scope, but if that's not possible, then Tuxedo can try to route the request to servers out of scope.All of this begs the question, why? Why have this feature? There many uses for this capability, but the most common is when there is state that is maintained in a server, group of servers, or in a machine and subsequent requests from a client must be routed to where that state is maintained. This might be something as simple as a database cursor maintained by a server on behalf of a client. Alternatively it might be that the server has a connection to an external system and subsequent requests need to go back to the server that has that connection. A more sophisticated case is where a group of servers maintains some sort of cache in shared memory and subsequent requests need to be routed to where the cache is maintained. Although this last case might be able to be handled by data dependent routing, using client server affinity allows the cache to be partitioned dynamically instead of statically.

One of the major new features in Oracle Tuxedo 11gR1 is the ability to define an affinity between clients and servers. In previous releases of Tuxedo, the only way to ensure that multiple requests...

Tuxedo 11gR1 Released

I've been a little quiet the last several months as the Tuxedo team has been very busy. Today Oracle announced the 11gR1 release of the Tuxedo product family. This release includes updates to Tuxedo, TSAM, and SALT, as well as 3 new products that Oracle is announcing today. These 3 new products are the Oracle Tuxedo Application Runtime for CICS and Batch, Oracle Application Rehosting Workbench, and the Tuxedo JCA Adapter. By providing a CICS equivalent runtime and a rehosting workbench to automate the rehosting of COBOL CICS code, JCL procedures, data definitions, and data, Oracle has significantly lowered the effort and risk to rehost mainframe CICS and Batch applications onto the Tuxedo runtime on open systems. By moving off proprietary legacy mainframes, customers have experienced better performance and achieved a 50-80% lowering of their total cost of ownership.The rehosting tools allow the COBOL business logic to remain unchanged and automate the replacement of CICS statements with calls to Tuxedo. The rehosted code can then run on open systems 'as-is'. Users can still use the same TN3270 interfaces they are used to eliminating the need for retraining. Batch procedures can be run and managed under a JES2 like environment. For the first time, customers have the tools and enterprise class runtime environment to move their key legacy assets off the mainframe and on to distributed open systems whether the application uses 250 MIPS, 25,000 MIPS, or more.More on these exciting new options in additional blog entries. For additional information on the Tuxedo 11gR1 release and these exciting new products, please visit http://www.oracle.com/us/products/middleware/tuxedo/index.htm and http://www.oracle.com/technology/products/tuxedo/index.html.

I've been a little quiet the last several months as the Tuxedo team has been very busy. Today Oracle announced the 11gR1 release of the Tuxedo product family. This release includes updates to Tuxedo,...

Developing Tuxedo Servers with SALT and SCA

The recent release of SALT 10gR3 dramatically changes the effort required to build Tuxedo servers. Prior to this new version of SALT, Tuxedo supported two types of servers, ATMI and CORBA. The CORBA support in Tuxedo is very scalable and provides a great model for distributed object systems, especially where state is involved. The CORBA model is well understood and standardized and applications are built using a remote method call model. ATMI on the other hand is a messaging centric API based upon The Open Group XATMI specification. Servers developed using this API can be highly efficient and scalable, but tend to be rather technical API intensive.Technical APIs are those APIs that access infrastructure or system functions that are not directly related to the business functions the application provides. Thus APIs that allocate messages, populate messages, send and receive messages, invoke services, etc., are all technical APIs. While not bad in and of themselves, technical APIs can get in the way of programmer productivity.The SCA Client and Implementation standard defines how a particular programming language should provide SCA capabilities. In the case of C++ it defines the classes and methods that need to be provided by an SCA runtime that supports SCA clients and servers written in C++. This blog entry will show how a Tuxedo ATMI server and an SALT SCA based server are written. To keep the business logic to a minimum and pick a subject area familiar to all I'll use a simple 4 function calculator.ATMI ServersIn an ATMI server, the developer creates services as C functions. The function is dispatched automatically by Tuxedo, whether in a single thread or in a worker thread for multi-threaded servers. The function receives as an argument a structure that contains such information as the name of the service, some flags, and a pointer to the message sent by the client. The function then extracts the information sent by the client from the message, performs whatever business function needs to be performed, creates and populates a return message, and then returns that message to the client. Here is an ATMI server that implements for services, ADD, SUBTRACT, MULTIPLY, and DIVIDE.ATMI Calculator Server/*(c) 2009 Oracle Corporation. All Rights Reserved. */#include #include #include /* TUXEDO Header File */#include /* TUXEDO Header File */#include /* FML32 functions */#include "calcflds.h" /* FML32 field definitions *//* This function performs the actual service requested by the client.Its argument is a structure containing among other things a pointerto the data buffer, and the length of the data buffer.*//* ADD service */void ADD(TPSVCINFO *rqst){ FBFR32 *transf;/* fielded buffer of decoded message */ floataddend1, addend2, result; transf = (FBFR32 *)rqst->data; /* get the fields out of the buffer */ if (Fget32(transf, ADDEND1, 0, (char *)&addend1, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing ADDEND1 field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } if (Fget32(transf, ADDEND2, 0, (char *)&addend2, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing ADDEND2 field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } result = addend1 + addend2; (void) Fchg32(transf, ADDEND1, 0, NULL, 0); (void) Fchg32(transf, ADDEND2, 0, NULL, 0); (void) Fchg32(transf, RESULT, 0, (char *)&result, 0); /* Return the transformed buffer to the requestor. */ tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);}/* SUBTRACT service */void SUBTRACT(TPSVCINFO *rqst){ FBFR32 *transf;/* fielded buffer of decoded message */ floatminuend, subtrahend, result; transf = (FBFR32 *)rqst->data; /* get the fields out of the buffer */ if (Fget32(transf, MINUEND, 0, (char *)&minuend, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing MINUEND field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } if (Fget32(transf, SUBTRAHEND, 0, (char *)&subtrahend, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing SUBTRAHEND field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } result = minuend - subtrahend; (void) Fchg32(transf, MINUEND, 0, NULL, 0); (void) Fchg32(transf, SUBTRAHEND, 0, NULL, 0); (void) Fchg32(transf, RESULT, 0, (char *)&result, 0); /* Return the transformed buffer to the requestor. */ tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);}/* MULTIPLY service */void MULTIPLY(TPSVCINFO *rqst){ FBFR32 *transf;/* fielded buffer of decoded message */ floatmultiplier, multiplicand, result; transf = (FBFR32 *)rqst->data; /* get the fields out of the buffer */ if (Fget32(transf, MULTIPLIER, 0, (char *)&multiplier, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing MULTIPLIER field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } if (Fget32(transf, MULTIPLICAND, 0, (char *)&multiplicand, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing MULTIPLICAND field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } result = multiplier * multiplicand; (void) Fchg32(transf, MULTIPLIER, 0, NULL, 0); (void) Fchg32(transf, MULTIPLICAND, 0, NULL, 0); (void) Fchg32(transf, RESULT, 0, (char *)&result, 0); /* Return the transformed buffer to the requestor. */ tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);}/* DIVIDE service */void DIVIDE(TPSVCINFO *rqst){ FBFR32 *transf;/* fielded buffer of decoded message */ floatdividend, divisor, result; transf = (FBFR32 *)rqst->data; /* get the fields out of the buffer */ if (Fget32(transf, DIVIDEND, 0, (char *)÷nd, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing DIVIDEND field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } if (Fget32(transf, DIVISOR, 0, (char *)&divisor, 0) < 0 ) { (void)Fchg32(transf, STATLIN, 0, "Missing DIVISOR field", 0); tpreturn(TPFAIL, 0, rqst->data, 0L, 0); } result = dividend / divisor; (void) Fchg32(transf, DIVIDEND, 0, NULL, 0); (void) Fchg32(transf, DIVISOR, 0, NULL, 0); (void) Fchg32(transf, RESULT, 0, (char *)&result, 0); /* Return the transformed buffer to the requestor. */ tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);}Each service implementation uses the the FML32 functions to extract the incoming fields from the message sent by the client, then performs the simply business logic of a calculator. Finally it modifies the original message to remove the input fields, add the result field, and returns that to the client.SCA ServersSCA servers in SALT 10gR3 have all of their message handling performed by the SCA container and generated code. These pieces accept a message, extract the appropriate fields, then call a C++ method to perform the business logic. The method simply returns the result to the SCA runtime which in turn creates a reply message and returns that to the client. With the ATMI Binding Extension provided by SALT, a normal ATMI buffer is used to hold the request and reply messages which allows interoperability with ATMI clients and server. Here is an example of a 4 function calculator server written using the SCA container.SCA Calculator Server/*(c) 2009 Oracle Corporation. All Rights Reserved. */#include #include "CalculatorServiceImpl.h" #include "tuxsca.h"using namespace std;using namespace osoa::sca;/*** Calculator component implementation*/namespace services{ namespace calc { float CalculatorServiceImpl::add(const float addend1, const float addend2) { return addend1 + addend2; } float CalculatorServiceImpl::subtract(const float minuend, const float subtrahend) { return minuend - subtrahend; } float CalculatorServiceImpl::multiply(const float multiplicand, const float multiplier) { return multiplicand * multiplier; } float CalculatorServiceImpl::divide(const float dividend, const float divisor) { return dividend / divisor; } } // End calc} // End servicesAs you can see, there is considerably less code to write for an SCA based server. As well the code is all pure C++ code without any technical or middleware APIs used. This same code could be used in many ways, not just within the context of an SCA service implementation.Hopefully these two simple examples illustrate some of the benefits of using SCA to implement services. In my next entry, I'll show how this same 4 function calculate can be accessed as a web service and how SALT help makes this a trivial exercise requiring no code changes to either the ATMI server or the SCA server.

The recent release of SALT 10gR3 dramatically changes the effort required to build Tuxedo servers. Prior to this new version of SALT, Tuxedo supported two types of servers, ATMI and CORBA. The CORBA...

Oracle Tuxedo 10gR3 releases

Oracle is announcing the availability of the 10gR3 releases of Tuxedo, Services Architecture Leveraging Tuxedo (SALT), and Tuxedo System and Application Monitor (TSAM). This is the first release of Tuxedo products since the acquisition of BEA by Oracle last year, and one that goes far beyond a simple rebranding. Sure the releases are rebranded, but these releases provide significant enhancements for both existing customers and new customers.The new versions can be downloaded at the Oracle Tuxedo Downloads page and the documentation can be found at the Oracle Tuxedo 10.3 Documentation page.Highlights of What's New in SALTSCA SupportCertainly the most exciting part of these releases is the support for the Service Component Architecture (SCA) in SALT 10gR3. SCA is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services while embracing existing SOA standards such as Web services.In the SCA model, software components can assembled into applications. Components can offer services and consume services, although how services are provided and accessed is determined outside the application. Typically how services are provided and accessed is defined by an external XML based description language called the Service Component Definition Language (SCDL), although the model also allows annotations to fill that role. Besides this assembly model, there are also specifications for language specific implementations. These specifications describe how a particular language accesses an SCA run-time and how components written in the language provide and access services provided by other components.One of the goals of SCA is to minimize the intrusion of middleware APIs into business logic and therefore minimize or eliminate tying business logic to a specific middleware implementation. In this release of SALT it is possible to implement services without using any middleware APIs and clients only need to make API calls to get a reference to the local SCA runtime and references to services. Service invocations are performed by simply calling C++ methods that map directly to the service being invoked.Another goal of SCA is to separate the business logic from the underlying technology used to invoke services. The details of how components are wired to services is controlled by the SCDL for the component. Thus the same component can access another service provided as a Web service, another SCA component, or an ATMI service, with the choice being made externally via SCDL. With the JATMI binding extension, it is possible for Java SCA clients to invoke Tuxedo services (traditional ATMI or SCA) directly via the workstation protocol without having to go through the overhead of SOAP.Overall this new programming model and method for assembling applications out of reusable components should significantly improve programmer productivity.SDO supportIn addition to support for the SCA assembly model and an SCA runtime container, SALT 10gR3 also includes support for Service Data Objects (SDO). SDO provides the ability to handle complex graphs of objects, automated transformation to and from XML, and change list support. As an SDO data graph is mutated, a list of the changes is maintained with the SDO data graph. Thus a service can provide an SDO data graph to a client, the client can make local changes to the data graph, and then return it to the server. When the server receives the updated data graph, it can examine the change list to determine what has changed and make the corresponding updates to the original source of the data. Since both the original state and the updated state are available, it is possible to implement optimistic concurrency controls.Service Contract DiscoverySALT 10gR3 also includes a feature that allows the discovery of service contracts. By examining the messages exchanged between ATMI clients and servers, SALT can infer a service contract for the service. This information can then be loaded in the Tuxedo metadata repository and used in exposing the service as a Web service or by development tools.Access LogTo aid in understanding the usage of the Web service gateway feature of SALT, a new access log is provided that tracks usage of the gateway. This includes information such as high water mark of number of clients and named clients that users can utilize to ensure compliance with their Tuxedo license.Highlights of What's New in TuxedoCustomer that develop their own communication gateways will be glad to hear that Tuxedo servers can now act as clients or initiators of work within Tuxedo. Servers have always been able to be clients of other servers, but only in the context of servicing the request from an actual client. This made it difficult to develop things like communication gateways as the gateway needs to act like a client at times and at other times act like a server, and yet still be managed by Tuxedo. With the addition of application created contexts in Tuxedo 10gR3, servers can now create new contexts that can be used to initiate client requests.Although the adoption of IPv6 has been relatively slow, the US government and other customers are now requiring that purchased software support IPv6. This new release of Tuxedo now supports IPv6 for all network communication. And like SALT, Tuxedo now maintains an access log that allows tracking named users and high water and current client count.What's New in TSAMThis release of TSAM is a relatively minor one. It contains support for TSAM Manager running on Oracle WebLogic Server and Oracle Application Server (OC4J) as well as support for IPv6.

Oracle is announcing the availability of the 10gR3 releases of Tuxedo, Services Architecture Leveraging Tuxedo (SALT), and Tuxedo System and Application Monitor (TSAM). This is the first release...