This is the second edition of the MTR originally titled "Principles of Interoperability and Integrations", now publicly re-released as "Principles of Interoperability and Integration, Volume 1: Fundamentals".

Principles of Interoperability and Integration, Volume 1: Fundamentals
Download Resources
PDF Accessibility
One or more of the PDF files on this page fall under E202.2 Legacy Exceptions and may not be completely accessible. You may request an accessible version of a PDF using the form on the Contact Us page.
This is the second edition of the MTR originally titled "Principles of Interoperability and Integrations", now publicly re-released as: "Principles of Interoperability and Integration, Volume 1: Fundamentals". As work progressed after the original release, Net-Centric Conversations (NCC) was greatly expanded upon. In addition, Nodes combined with Discovery Scopes to become Sub-Enterprises. These two topics are the basis of "Principles of Interoperability and Integration, Volume 2: Net Centric Conversations and Sub-Enterprises". This new 2nd MTR will be published early Fall 2006, and will also be publicly released. The promise of net-centric warfare is based on the assumption that services (especially web services) can freely converse amongst themselves, and exchange data via messages. The reality is that this is a hard problem, due in no small part to the realities of how we organize services to run within Nodes. In addition, DISA NCES efforts have encouraged us to view the world through nine service types, and much of the discussion has been stove-piped, focusing on one service type at a time. This paper brings together net-centric elements of messaging, discovery and security and examines the minimum coordination to achieve a net-centric conversation between services. This coordination becomes the limiting factor in how quickly we can create, update, or delete a netcentric conversation. In fact we can define an agility metric for the enterprise as: "the highest sustainable rate of creating, updating, and deleting net-centric conversations". An example can be Weather service. If your organization wants to use it (their web service) do you expect to be able to make this connection within months? Weeks? How about minutes or hours? That is what we need to strive for to meet an agile, small adversary.