<$BlogRSDURL$>

IT KEE

IT bits and bytes

Friday, June 03, 2005

Bharti Tele-Ventures is a landmark deal
On March 26th, IBM and Bharti Tele-Ventures of India announced a ten-year outsourcing deal. The deal is significant because:
According to a recent Gartner Group report, the deal highlights the opportunity that exists in India. According to the report, enterprises in India consider outsourcing to be a key component of their future IT strategy and see the global solution providers as a viable option.
Bharti Tele-Ventures has a leading presence in all areas of telecommunication services and plans to expand its footprint in India.
IBM will consolidate, transform and manage the comprehensive IT infrastructure and applications of Bharti Tele-Ventures, including all customer-facing IT applications, internal-facing applications and the IT infrastructure (data centers, and IT help desks) and will enhance disaster recovery capabilities.
IBM will deploy an open standard-based framework, Service Provider Delivery Environment (SPDE), that gives Bharti Tele-Ventures the freedom and flexibility to introduce the latest in voice, data and content-based services to its customers.
The deal value is estimated to be US$225-US$275million for the first five years and US $700-US$750million over ten years. Bharti Tele-Ventures' payments to IBM will be linked to the percentage of revenues generated by Bharti Tele-Ventures and pre-defined service-level agreements.
Bharti Tele-Ventures and IBM will jointly develop and market IT and telecom solutions and services, for the Indian market which will support its explosive growth. This arrangement brings together Bharti Tele-Ventures' leading-edge network and integrated communications service-provider capabilities with IBM's unparalleled innovation and technology leadership. Customers will benefit from seamless communications and computing. The initiative will also introduce application services to the small business and mass market segments.
Bharti Tele-Ventures is identified as a preferred supplier of telecommunication services to IBM India

posted by OttoKee  # 12:35 AM

Thursday, June 02, 2005

Mainframe Integration Within .NET
By: Hugh Raiford

In a recent Gartner survey, 48 percent of enterprises worldwide reported plans to adopt Microsoft .NET technology. Considering that .NET entered the marketplace as recently as February 2001, this survey sends a resounding message ­ Microsoft technology has established a strong foothold in the enterprise computing arena.
Microsoft .NET is the future direction of the Microsoft software machine. With over 6 million Visual Studio .NET developers in the market and the stated goal of allowing these developers to create "reliably built, hosted, deployed, and utilized solutions using Web services," .NET has been or will be integrated into all Microsoft products.
Determined to make its mark in a space long dominated by IBM and other Java-centric vendors, Microsoft has devoted a great deal of resources to rounding out its overall offering to the enterprise. Furthermore, Microsoft's commitment to user-friendly, application development technology that requires significantly less coding than rival platforms only means that this adoption rate will continue to climb in the years to come.
Mainframe Computing Remains SteadfastAs the battle between Microsoft and Java continues to heat up, interestingly enough there are more transactions processed by IBM CICS (Customer Information Control System) and IMS (Information Management System) systems than by the Internet in its entirety. Of the Fortune 500, 490 companies leverage CICS alone to process more than 30 billion transactions, or $1 trillion worth of business, each and every day.
IT departments in large corporations manage over 50,000 CICS code modules written in COBOL, Assembler, or PL/I. The oldest modules are 25 to 30 years old, but still continue to process mission-critical data every day ­ and due to the extraordinary level of customization these applications have endured ­ they will continue to function for many years to come. Reinforcing this position, organizations devote approximately 75% of yearly IT budgets toward maintaining and evolving this mainframe code.
Despite the continued reliance on legacy computing, enterprise technology has evolved at an exponential rate over the past decade ­ especially in the case of Microsoft. While many of these new technologies have failed to make the leap from theory to practical adoption and on to persistence, one vision ­ the .NET service-oriented architecture (SOA) ­ has revolutionized the way developers think about building enterprise applications. In short, .NET offers more than just technological hype, instead promising to deliver a standardized way to develop and deploy modern enterprise applications.
Organizations today are already building modern components and Web services using .NET technologies, but the reliance on legacy applications is ever present. Therefore, the challenge for enterprise organizations lies in the need to incorporate legacy applications within the modern service-oriented architecture of .NET. Once this is accomplished, the next hurdle is performance ­ getting the most out of the mainframe via the SOA.
Since it is too costly and risky to simply recode core mainframe applications in .NET-centric programming languages, enterprise developers must leverage a tool to isolate specific business transactions from within multiple legacy systems and expose these transactions as reusable components and Web services within .NET. Furthermore, these components and Web services must communicate with mainframe logic in a manner that optimizes performance at runtime. Only by doing so will enterprise organizations truly realize the benefits of .NET and the service-oriented architecture.
The Pathway to Mainframe LogicCentral to this challenge is the manner in which developers access core host logic from the .NET Framework. In the past, enterprise organizations have employed a variety of products to help incorporate mainframe applications into more modern computing paradigms. From simple emulation tools to advanced extension solutions to message queuing software, these products are still in use at many large organizations today. However, as technology evolves, so do the technical and business requirements that influence the enterprise adoption cycle.
Direct to Raw DataDirect database calls to raw mainframe data sound like an ideal solution. They deliver lightning-quick response times, and allow the developer to repackage the data upon retrieval in any format needed. Unfortunately, all is not as it seems. The original developers of mainframe systems were faced with a shortage of hard-drive storage space. To get around the tremendous costs of storage on the mainframe, developers stored most mainframe databases within various types of compressed files built with very confusing formats.
Additionally, by accessing the data directly, developers lose the real benefit of most mainframe applications ­ the business logic. In legacy mainframe systems, the business logic is tied into the user interface layer, so by going directly to the raw data, developers lose the ability to decipher the meaning of that data. This approach also runs the risk of corrupting the data when writing back to the mainframe database, since many applications have data that is updated from batch (or offline) applications.
Screen-Based Entry to LogicFor years, because of the failings of direct database access, screen scraping was the accepted method of accessing mainframe logic from Windows or ASP applications, and in some cases today, screen scraping is still necessary. If, due to technical reasons, a screen-based approach is needed, there is a significant number of vendors that can fulfill these requirements and provide rapid access to a variety of mainframe systems.
It may be that there is no tool available that offers an alternative to a screen-based approach for a particular type of mainframe environment (this is true for many types of systems), or it may be that the customer does not own the mainframe. Whatever the case, in these situations the mainframe integration engine will act as a stand-alone application server and reside somewhere within .NET.
However, complicating this type of installation is the proprietary nature of most mainframe integration technologies. Most enterprise organizations would rather not paint themselves further into a corner, so it is important for architects to find as open a solution as possible so that they may truly utilize the benefits of the .NET Framework.
To this end, certain vendors in the Microsoft camp have written their integration tools in .NET programming languages such as C#. By doing so, these vendors allow the enterprise to deploy the integration engine natively within .NET. Additionally, the source code enables developers to script custom code and easily extend functionality to disparate applications.
While these types of tools offer good flexibility, sometimes the level of runtime performance provided by a screen-based approach is simply not enough ­ especially when developers are dealing with the enormous number of transactions characteristically handled by large mission-critical mainframe applications.
Uninterrupted Approach to LogicHowever, as discussed, technological evolution continues, and as they attempt to incorporate mainframe processing functionality into the .NET SOA, enterprise organizations are ready to take a strategic step forward. By allowing organizations to easily and cost-effectively migrate from a screen-based approach and middle-tier deployment, certain technologies represent this step forward.
When working with CICS on the mainframe, there exists today a much more attractive mainframe integration option ­ native deployment within CICS (see Figure 1). With this option enterprise organizations have the ability to leverage several secure, high-performance application programming interfaces to CICS and IMS logic as they build and deploy modern .NET components and Web services. These interfaces include:
COMMAREA: Within the COMMAREA CICS facility, the Distributed Programming Link (DPL) function enables a CICS client program to call a CICS server program in a remote CICS region. In fact, DPL access provides the strongest performance metrics when building business components or Web services from existing CICS programs.
Open Transaction Manager Access (OTMA): OTMA is a transaction-based, connectionless client/server protocol. Though easily generalized, its implementation is specific to IMS in an MVS sysplex environment. It was designed by IBM to allow for high-performance communication with IMS applications. Developers can use OTMA to provide high-performance integration with MFS (Message Format Service) and non-MFS IMS applications.
3270 Bridge: Another facility of CICS, the 3270 Bridge intercepts the flow of data into and out of a CICS transaction before a 3270 data stream is generated as output or expected as input. The 3270 Bridge is a more intrusive method than the COMMAREA options, necessitating an intricate interaction with back-end programs. However, this approach does provide strong performance metrics. When it is not possible to utilize the COMMAREA facility and the DPL option, the 3270 Bridge is the preferred methodology.
Front-End Programming Interface (FEPI): FEPI allows for much broader coverage of older CICS, Natural, CA-IDMS, CA-IDEAL, as well as IMS applications. FEPI provides access, by means of simulated terminals, to CICS or IMS applications available through a communications network, and then enables developers to write CICS application programs that access other CICS or IMS applications. FEPI is the solution of choice for older CICS systems that do not allow DPL access.
When accessing CICS logic on the back end, the COMMAREA option is the best option (approximately 30 percent of CICS programs support DPL access), in that performance increases up to ten times over screen-based solutions. However, if accessing CICS logic through the COMMAREA is not an option, the 3270 Bridge and FEPI provide substantial gains as well, often more than four to six times the performance of screen-scraping solutions.
On the IMS side, OTMA is the preferred option when possible, offering performance gains five to eight times better than screen-based solutions. If not, FEPI is still a viable choice, allowing access to all visual IMS applications as well as mainframe applications that do not utilize BMS (Business Message Standard) maps, such as Natural, CA-IDEAL, and CA-IDMS. While FEPI does simulate screen scraping, all processing is done inside of CICS on the mainframe, allowing this approach to achieve a two to three times performance gain over typical screen-based solutions.
These four direct approaches (see Figure 2) fall into two distinct categories ­ linkable modules (COMMAREA and OTMA) and 3270-oriented (3270 Bridge and FEPI). Linkable modules, the two options that offer the highest performance, are stand-alone programs without a presentation interface. Other programs that implement the presentation interface generally call (link) these modules, which then expect a formatted structure on input and produce a formatted structure on output. The called program does not see a device-dependent data stream.
On the other hand, 3270-oriented applications ­ which offer less in performance ­ are manipulated only by their user interface. These applications expect data entered on a keyboard and, in return, format screens back.
By working within CICS and using any one of these approaches to bridge between legacy applications and .NET, enterprise organizations can enjoy a number of benefits that they would normally not have if leveraging a screen-based solution, including:
Significant performance gains: Provides substantial runtime performance increases over screen-based access to legacy applications.
Removal of dual-maintenance requirement: Removes the traditional screen-scraping requirement of modifying the new .NET component or Web service whenever the legacy application is changed.
Cleaner architecture: Eliminates many of the traditional steps involved with screen-based mainframe integration, appeals greatly to mainframe developers who are wary of a three-tier approach, and eases security concerns as well.
ConclusionWhile removing the requirement for dual maintenance and engendering a cleaner architecture are attractive benefits, direct mainframe access delivers real return on investment at runtime, in the form of substantially increased performance gains.
No one has ever questioned the mainframe's superiority when high-volume transactional performance is the issue. However, the mainframe's stovepipe existence is no longer viable in today's .NET application development world. Likewise, until enterprise organizations can mimic the mainframe's scalability and reliability as they build new .NET applications from scratch, developers must leverage the mainframe to build robust .NET components and Web services.
To ensure secure high performance within the .NET SOA, these components and Web services must have direct access to core mainframe logic at runtime. Only then will the mainframe truly play a pivotal role within the SOA, and only then will .NET truly succeed in enterprise computing.

posted by OttoKee  # 11:45 PM

Archives

04/01/2004 - 05/01/2004   05/01/2004 - 06/01/2004   06/01/2004 - 07/01/2004   07/01/2004 - 08/01/2004   08/01/2004 - 09/01/2004   09/01/2004 - 10/01/2004   12/01/2004 - 01/01/2005   01/01/2005 - 02/01/2005   02/01/2005 - 03/01/2005   04/01/2005 - 05/01/2005   05/01/2005 - 06/01/2005   06/01/2005 - 07/01/2005   07/01/2005 - 08/01/2005   08/01/2005 - 09/01/2005   03/01/2006 - 04/01/2006   06/01/2006 - 07/01/2006   08/01/2006 - 09/01/2006   09/01/2006 - 10/01/2006   10/01/2006 - 11/01/2006   11/01/2006 - 12/01/2006   12/01/2006 - 01/01/2007   03/01/2007 - 04/01/2007   04/01/2007 - 05/01/2007   05/01/2007 - 06/01/2007   08/01/2007 - 09/01/2007   09/01/2007 - 10/01/2007   01/01/2008 - 02/01/2008   02/01/2008 - 03/01/2008   03/01/2008 - 04/01/2008   06/01/2008 - 07/01/2008   07/01/2008 - 08/01/2008   09/01/2008 - 10/01/2008   10/01/2008 - 11/01/2008   11/01/2008 - 12/01/2008   03/01/2009 - 04/01/2009   04/01/2009 - 05/01/2009   09/01/2009 - 10/01/2009   12/01/2009 - 01/01/2010   05/01/2010 - 06/01/2010   07/01/2010 - 08/01/2010   08/01/2010 - 09/01/2010   12/01/2010 - 01/01/2011   01/01/2011 - 02/01/2011   10/01/2011 - 11/01/2011   01/01/2012 - 02/01/2012   02/01/2012 - 03/01/2012   03/01/2012 - 04/01/2012   09/01/2015 - 10/01/2015  

This page is powered by Blogger. Isn't yours?