Will Microsoft .Net connect the enterprise?

Using networking capabilities called Web Services to open up the enterprise, Redmond, Wash.-based Microsoft’s .Net allows operations and business managers to take the real-time pulse of their businesses—any time and from anywhere. This virtual stethoscope also lets them see what’s happening at any place of their choosing within the enterprise.

.Net’s ability to let enterprises roll up information, so that factory-floor data can be transformed into business decision-making information for executives, means those managers can learn the truth of their enterprise’s production and delivery health in creative, immediate, business-expanding ways.

Reducing the cost of integration is one high-level benefit, says Chris Colyer, Microsoft’s industry manager for general manufacturing in the company’s manufacturing industry solutions group. “On average, companies are spending around $7 on integration for each $1 of software purchased.” Those costs are to connect and reuse existing assets, including all applications and data gathered in silos throughout the enterprise.”

Ultimately, Web Services will also increase revenue opportunities, he says. “You can broaden partnerships, deepen customer relationships and build mobility into your organization so that they can get access to critical information—anyplace, anytime, anywhere.”

Also, Web Services are promising “when you’re looking at enterprise performance management and collaboration strategy—and enterprise integration.”

Even so, there may be some confusion about what .Net is and how it works. Or what it can do and why. Or what comprises the eXtensible Markup Language (XML)-based Web Services, the core of .Net. Or why enterprise managers should be interested in these.

It’s connectivity, says Ron Sielenski, Micro-soft’s senior industry technology strategist for manufacturing solutions, about .Net.

fter Microsoft launched the .Net initiative, it began to release Visual Studio .Net, the .Net Framework and Windows CE .Net. But Sielinski emphasizes that “.Net isn’t any of those products—or even the sum of those products. More precisely, it is the underlying set of principles that guided the development of those products.”

To develop it, the company identified and then harnessed two significant technology trends. “The first is the continuing advance of computing power. The second is a similar advance of networking capabilities, both in reach (i.e., wireless versus tethered) and speed (i.e., broadband versus dial-up modems).”

That, he says, means “the widespread adoption and availability of the Internet provides a very low-cost way of establishing communications.”

One key technology is XML. “It’s one of the ways to bridge the gap that existed for years,” Sielinski says. “In the past, developers had to choose between competing object technologies—either component object model (COM) or common object request broker architecture (CORBA)—which ultimately limited those applications’ ability to talk to each other.”

It was always a challenge for enterprise customers to integrate applications spanning those platforms, he says. But “that’s what we have with XML Web Services. We have a technology that’s completely understood.”

According to Sielenski, there is a “tremendous amount of industry momentum” behind the .Net concept. “Every one of the standards that makes up the XML Web Services was developed by Microsoft and IBM and other companies, as appropriate.”

“Enterprise customers can choose the applications that best meet their business needs,” Sielenski says. “They don’t have to lock themselves into a single platform, based upon arcane technical criteria, when they want to integrate their applications.”

It is not called the .Net platform, but rather the Windows platform, he says. “It has five core component sets.”

The first set is composed of server products, “including the Windows servers and our other enterprise servers: SQL Server, Xchange Server, BizTalk Server, and others.”

Then, he says, “We have our set of client operating systems and platforms, such as Windows XP, the Tablet PC, and a wealth of handheld devices. We also offer a set of user experiences: MSN and MS Office, for example.”

In addition to that, service sets such as Passport .Net, MapPoint .Net and .Net Alerts are offered. And finally, there are development toolsets such as Visual Studio .Net as well as the .Net framework.

The services are examples of a new approach to computing, Sielenski says. “Web Services expose very specific capabilities that can be accessed over the Internet. These services aren’t meant as full-blown applications for people to use—they don’t even necessarily expose a user interface.”

The fundamental concept is very simple, Sielenski says, and “that’s probably why XML is so effective.”

First in the protocol stack for establishing device connections, there is transmission transfer protocol/Internet protocol. Communications protocols include Hypertext transfer protocol (HTTP), file transfer protocol (FTP), simple mail transfer protocol, and the like. The messages themselves are encoded as XML, which can be read on any platform.

Next is simple object access protocol (SOAP), Sielenski says, “which is simply a way of separating messages into two parts: a header and body. The beauty of that is that you have given computers the ability to inspect messages without necessarily having to read their contents.”

Above that layer is the Web Services description language (WSDL). This XML document basically describes the capabilities of a Web Service and how messages can be used together.

Sielenski says, “If you look at the protocol stack, up to this point, you can do anything with the messages. You can send a purchase order, engineering change request, or other kind of message. Or you could do more complicated things, like expose an application programming interface.”

At one layer higher, “is universal description, discovery and integration (UDDI). Basically that provides a mechanism of discovery of the Web Services as well as where the Web Services are located.”

Sielinski’s favorite example of Web Services in manufacturing is what the OPC Foundation (for OLE for Process Control) has done with OPC XML Data Access. “They’ve created a Web Services version of their data-access specification. The original was Component Object Model-based. Now they have one that can be used via Web server.” (See News for more on OPC XML DA.)

What that means, he says, “is that you have a standardized interface for reading or writing variable information, pretty much anywhere within the operational domain. For instance, you might have a human-machine interface or supervisory control-and-data acquisition application and you want to integrate that with a manufacturing execution system.”

Further uses of Web Services, he says, include tracking “the status or availability of a particular machine. You could expose its operation state via a Web Service. Or, if you’re trying to manage inventory, you could ask what’s the volume of a particular chemical in your customer’s storage tanks.”

One cool thing about Web Services, Sielenski says, “is that you can do it across firewalls, if that’s necessary and appropriate.”

Imagine, he says, “if I have a very long pipeline or power distribution network, and one of the things that I want to do is connect to individual stations using a dial-up modem. I could actually call the individual stations and exchange info via Web Services, without experiencing any difficulties I might’ve had using COM or other binary protocols over the Internet.”

However, no one seriously believes that an executive wants to watch the ones and zeros of a programmable logic controller (PLC) from his or her desk, Sielenski says.

At every enterprise level, information gets transformed and aggregated. The ones and zeros of the PLC are translated as ‘open’ and ‘closed’ at the operator level. At the next level, the supervisor sees that an individual machine is up or down.

But, as data go farther in an enterprise, says Sielenski, “the context tends to shift, too. So while local and supervisory systems would be used to operate machines and monitor performance, an execution system would track the material crossing machines, in terms of individual production orders.”

From an operations perspective, product being manufactured is part of a production order, he says, but from a business perspective, the product is part of a customer order. “The enterprise resources planning system will be tracking the order for the customer.”

Sielenski says, “If I’m an executive and I want to know what the status of my corporation is today, it’s a rollup of all that information. The important thing is that if these applications weren’t tied directly to one another, you’d have latencies (time delays) between the information sharing between systems.”