Client- vs. Server-Side
XML indeed is becoming the lingua franca among large, disparate, distributed computing environments. Applications receive and generate data in XML format. The integration model we implemented at my orgainization is a two-tier, client-server model rather than a three-tier one. As with the SOAP RPC model, XML data is sent through the network. But unlike SOAP's, our setup doesn't contain an envelope packed with encoded information for the message and header. The processing overhead with SOAP's XML payload is the W3C architecture's main trade-off: Time-sensitive transaction processing applications don't need that kind of payload baggage.
You can configure the XML-based intranet model to simply send and receive XML messages over the network. Because it uses cross-platform components, such as XSLT (Extensible Stylesheet Language Transformation) processing for creating HTML pages and J2EE application servers, this architecture gives you plenty of leeway in how you configure your processors. That's a big plus. In most organizations, the driving force behind application hosting and configuration is the total cost of ownership--the cost of building, hosting and maintaining an application.
The main goal of this scaled-down XML architecture is to reduce the overhead from parsing so your application's performance improves. It's flexible for XSLT processing, too. Say you need to buy another processor or server for your XSLT processing. This XML model would let you take the cheaper way out, off-loading XSLT processing--where XML files are transformed into HTML--onto your HTTP server or the client browser instead of buying new hardware and using Java resources. Putting XSLT processing on an HTTP server is the best option when you want mass distribution of XML documents. It's the job of the server to transform them into HTML for browsers. The client-side approach, however, is a little trickier. If you prefer running XSLT on the client, your browser must support XSLT 1.0 or XSL-WD, as Microsoft Internet Explorer 5+, Netscape 6+ and Mozilla do. And your client machines must have at least a gigabyte of memory.
IBM's zSeries, meanwhile, is optimized for I/O-intensive, database management systems and queue parallel-processing applications, so it really doesn't make sense to use this state-of-the-art server for HTTP Web processing with static pages, GIF and XSL files. Let the mainframe handle database calls and place your XSLT processing on an HTTP server or client.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
