Team Development Technology

1

• Team Development Technology
• Paul Gustavson

2
1 Federation Development Issue

• Lack of effective communication and coordination
  among team members throughout the development
  process.
• Independent Development
• Misunderstanding of Requirements
• Miscommunication of a desired capability
• Worst case scenario
• Problems / issues are not manifested until the
  first execution of an HLA federation.

3
What can be done?

• Use the FEDEP
• Generalized Framework for building HLA
  Federations
• Encourages communication and coordination

The FEDEP does not guarantee that federation
development effort will be free of communication
and coordination problems.
4
What else can be done?

• Automation support for the FEDEP
• Tool Integration
• Automated Information Exchange(Requirements,
  DIFs, Lexicon, Reuseable Object Models)
• Increased Team Member Coordination

Need a ubiquitous mechanism for wiring tools
and faclitating communication and coordination
among team members.
5
CAFDE - The First Initiative

• Open Tool Architure
• Provides a framework for
• Tool Integration
• Tool Interoperability
• Collaboration
• Language Neutral API
• C type specification

Addressed needs of tool users and developers.
6
CAFDE Benefits

• Facilitates FEDEP Automation
• Automated Data/DIF Sharing
• Easy Tool Integration
• Project Management Support
• Multi-Environment Collaboration

Strength is tool interoperablity within a single
environment (CPU).
7
CAFDE Integration in Visual OMT

• ceAppJoin
• ceAppLeave
• cePublishDIF
• ceSubscribe
• ceUnsubscribe
• ceRetrieveDIF
• ceAppAlign
• ceSetAlignment
• ceGetAlignment
• ceGetLastError
• wm_pub_dif
• wm_app_resize
• wm_app_view_update
• wm_app_shutdown

8
CAFDE Hurdles

• Community Embracement
• Tool Vendor NIH
• Not enough user demand
• Architecture Limitations
• Type of clients limited to a predefined set of
  capabilities and services.
• Data exchange limited to DIFs, UseCase, Lexicon,
  and File Locations
• Collaboration limited to real-time support
  (synchronous).
• Implementation limited to Windows (DLL)
• 8-Bit ASCII Character Encoding (as opposed to 16
  Bit Unicode Character Encoding)
• Primarily HLA focus

CAFDE has been only the start at providing an
infrastructure that can leverage the concepts of
the FEDEP among players, tools and repisitories...
9
Next Step - CODENet

• Utilizes latest and emerging Internet
  technologies
• XML
• SOAP
• WSDL
• Provides a web-service mechanism for developers
  and their applications to share and exchange
  information regardless of disparate applications,
  platforms or programming languages.

10
The Concept of Web Services

• Today
• Yahoo, Amazon.com, Orbitz, e-Trade
• Access via Web-browser
• Tomorrow
• Software as service
• Offer access to specialized utilities that
  perform various services external to your
  computer
• Integrate seamlessly and autonomously with your
  local software
• Applications other than a browser will take
  advantage of these services providing newfound
  capabilities for users
• Facilitates greater reuse, compentization and
  interoperability

11
Levels of Reuse

• Object Language Level
• C, Ada, Small Talk
• Polymorphism, Inheritance, Encapsulation lt-
  Abstraction
• Component Level
• Precompiled Binary/Byte Code
• Visual Basic Controls (VBX), ActiveX, Visual
  Component Library (VCL), JavaBeans, Base Object
  Models (BOMs)
• Application Level
• Interface to external / reuseable Web Services
• Language and Platform Independent
• Network Dependency

12
The Branding of Web Services

• Microsoft .NET
• Sun ONE -Open Network Environment
• IBM Web Sphere

All of these product technologies center on the
application of XML and SOAP
13
XML

• Platform-neutral syntax description language for
  structuring, documenting and sharing data.
• Text-based
• Wide variety of XML Parsers
• Schema (XSD)
• Transformations (XSL, XSLT)

14
SOAP - Simple Object Access Protocol

• SOAP is the protocol used to access Web Services
  such as CODE-Net
• SOAP marshals method calls using an XML encoding.
  
• SOAP connections use HTTP as a transport
  protocol.
• HTTP is a common denominator and allows clients
  to communicate with an application server
  protected by a firewall
• SOAP connections work in cross-platform
  applications (supported on both the Windows and
  Linux).
• As with HTTP connections, callbacks are
  unsupported when the connection is formed via
  SOAP.
• SOAP connections limited to a single remote data
  module in the application server.

15
SOAP Payload

• ltsoapEnvelope
• xmlnssoapurnschema-xmlsoap-orgsoap.v1gt
• ltsoapHeadergt
• lterrorconditiongt
• soapmustUnderstandtrue
• xmlnshttp//updateattributeinformation.com
• lt/errorconditiongt
• lt/soapHeadergt
• ltsoapBodygt
• ltFederateUpdateAttribute
• xmlnsFederate urnuuid
• C3979D17-89C6-11D4-EA71-FE00C7902810gt
• ltobjectgt432lt/objectgt
• ltvelgt1093.354lt/velgt
• lt/soapBodygt
• lt/soapEnvelopegt

• Contains a schema Uniform Resource Identifier
  (URI)
• mustUnderstand -if the receiving system does
  not understand the URI, an error message must be
  returned.
• SOAP message Body -informs the processing system
  to update attributes

16
WSDL-Web Services Description Language
XML format for describing network services as a
set of endpoints operating on messages containing
either document-oriented or procedure-oriented
information. - W3C

• Identfies external methods available by a web
  service.
• Analogous to an IDL file.
• App uses the WSDL to identify RPCs that can be
  made for requesting and retrieving.
• RPC comm
• HTTP Get/Post
• MIME
• SOAP

17
CODENet WSDL
18
What is CODE-Net?

• Open Tool Environment based on XML and SOAP.
• Designed to integrate and heighten communication
  among
• User Development Tools
• Data Transformation Services
• Repository Systems
• Allows multiple systems and its developers to
  share and exchange information regardless of the
  disparate applications, platforms or programming
  languages used.

19
Categories

• User Development Tool
• primary job is to create and publish information
  for user (e.g. OMT tool)
• Data Transformation Service
• primary job is take in data or data request,
  process it, and output results (e.g. OMT1.3 to
  OMT1516)
• Repository System
• primary job is store and/or retrieve data.(e.g.
  OMDD)

20
Back To The FEDEP
Collaboration via CODENet
21
FEDEP Step One

• Goal Collective define and doucment the
  objectives of the federation.
• CODNet Provides conduit for publishing and
  sharing
• User/Sponsor Needs
• Federation Objectives

22
FEDEP Step Two

• Goal Develop an appropriate representation fo
  the real world domain.
• CODNet Facilitates collaboration effort in
  verifying and validating scenarios and conceptual
  model with federation stakeholders.

23
FEDEP Step Three

• Goal Identify responsibilities and
  functionalities to be provided by each
  participant
• CODENet Offers mechanism for close colaboration
  among all federate participants to ensure a
  common understanding of federation goals and
  requirements.

24
FEDEP Step Four

• Goal Team to develop the specification for
  information interhange that will occur between
  all federates at run-time.
• CODENet Used to integrate object model tools
  and provide access to object model libraries.

25
FEDEP Step Five

• Goal Integrate and Test the federates, ensuring
  that they adhere to the interoperability
  requirements (including FOM compliance)
• CODENet Validate, test, and debug FOM with other
  federates through CODENet without RTI
• Faster development
• Improved confidence

26
FEDEP Step Six

• Goal Execute and Analyze the results of the
  federation execution.
• CODENet Provides environment for sharing results
  and utilizing external anaylsis tools.
• Better understanding of results and issues
• Corrective Actions can be made on-the fly.

27
HLA Collaborative ActivitiesSupported through
CODE-Net
Requirements Gathering
Lexicon Look Up
Conceptual Modeling
VVA Consistency Checker
OM Development
OMRepository (FOMs, BOMs)
OM Mapping
OMT 1.3 (BNF) to IEEE 1516 Converter
FederationPlanning
Meta-dataMatching
Test and Debug
Allows you to build a community from individual
tools, services, and respositories
28
Potential Future Products

• Store and Forward Service
• Group Sharing
• Repository
• Use Cases
• FOMs/SOMs
• BOMs
• Meta-Data Matching
• Lexicon Look Up

• HLA Compliance Testing
• Pre-Integration Testing
• Execution Testing
• Mapping Services
• OM and Requirements Repositories
• Meta-data Matching
• Protocol Agent Deployment

29
Leveraging CODENet Services

• Services made available through a WSDL Document.
• WSDL Document dynamically published by CODENet
  (viewable with a broswer)
• Import WSDL document (types and interfaces) into
  your application
• Tools Delphi, Kylix, CBuilder, Visual.Net
  Studio
• SOAP Libraries
• Or Interface to CODENet Wrapper
• Windows DLL

30
CODE-Net Composition
User Management
Project Management
Process Management
Client Management
Data Declaration Management
Data Distribution Management
31
User Management
CAFDE
CODE-Net
UserJoin
UserLogIn
UserAdd
UserRemove
No password support
UserChangePassword
UserLeave
UserLogOff
Better security
UserList
32
Project Management
CAFDE
CODE-Net
GroupJoin
ProjectAdd
ProjectRemove
GroupLeave
ProjectList
Group Focusedcollaboration
ProjectMemberAdd
ProjectMemberRemove
ProjectMemberList
Project Focusedcollaboration w/ limited version
stamping support
33
Process Management

• Custom Process to be followed for a Project can
  be defined.
• Applying Scenario Steps w/ Exceptions
  Variations (borrowing from Use Case Scenarios)
• Define Roles/Responsiblities for Rule Steps
• Associates Users to Roles / Responsibilities
• Example
• FEDEP Six Step Process

CODE-Net
XML Schema defined to fill in Rule Set
DefineRuleSet
Assign Process(es)for a Project
GetRuleSets
XML Schema defined for indentifying a Role
DefineRole
Assign Roles and Responsibities of Users to a
Process
GetRolesResponsiblities
AssignResponsiblity
Project Focusedcollaboration w/ limited version
stamping support
34
Use Case - Content Development Process

• Individual authors desired content (DEV)
• Content is submitted for Peer Review (PR)
• Peer Review occurs, suggested revisions returned
  to developer.
• Developer accepts/rejects suggested revisions by
  peer reviewer and submits updated content for
  Tech Editing (TE)
• Tech Editing occurs, suggested revisions returned
  to author.
• Developer accepts/rejects suggested revisions by
  Tech Editor and submits updated content for final
  approval
• Content approved and published by Manager (M)

• CODE-Nets Role
• Manages the overall process flow
• Allows these Rules to defined and followed
• Integrates the tools necessary to perform these
  checks
• Isolates areas of responsibilites through Project
  Management
• Data published is Version stamped / Time stamped

35
Client Management
CAFDE
CODE-Net
AppJoin
ClientJoin
ClientList
Capabilities Manager Network Interface Requiremen
t Support Construction Support Transition
Support Collaboration Mechanism UseCase
Tool Lexicon Tool Other
SubscriptionList
Publishable
PublicationList
Unpublishable
DefineDataType
AppLeave
ClientLeave
GetDataTypes
Subscribe
Subscribe
Define and list data types
Unsubscribe
Unsubscribe
Data Types DIFs Use Cases Lexicon File Locations
36
Data Distribution Management
CAFDE
CODE-Net
RetrieveDIF
RetrieveData
RetrieveUseCase
DefineDataType
RetrieveLexicon
GetDataTypes
RetrieveFileLocation
Define and list data types and sub types
PublishDIF
PublishData
PublishUseCase
DefineSubType
Data can be associated to projects
PublishLexicon
PublishFileLocation
GetSubTypes
RequestData
RequestLexiconQuery
Request for service support or data!
RequestUseCaseQuery
CheckForData
Various Windows Callback Messages
SOAP in a client/server model, does not support
callbacks
37
CAFDE -vs- CODE-Net

• Open Specification (API)C type Interface
• Implementation limited to Windows / language
  neutral
• Data exchange limited to DIFs, UseCase, Lexicon,
  and File Locations
• Type of clients limited to a predefined set of
  capabilities and services.
• Strength is tool interoperablity within a single
  environment (CPU).
• Collaboration limited to real-time support
  (synchronous).

• Open Specification (API) WSDL (electronically
  digestable)
• Implementation is platform / language neutral via
  SOAP
• Allows new DataTypes and SubTypes to be created
  and exchanged.
• Client capabilities and services limitless
• Facilitates tool interoperabilty among users of
  multiple systems.
• Colloboration supports store-and-forward
  (asynchronous)

38
CODENet ServerApplication Options

• ISAPI/NSAPI Dynamic Link Library
• ISAPI and NSAPI Web server applications are DLLs
  that are loaded by the Web server. Client request
  information is passed to the DLL as a structure.
  Each request message is handled in a separate
  execution thread.
• CGI standalone executable
• A CGI standalone Web server application is a
  console application that receives client request
  information on standard input and passes the
  results back to the server on standard output.
  Each request message is handled by a separate
  instance of the application.
• Win-CGI standalone executable
• A Win-CGI standalone Web server application is a
  Windows application that receives client request
  information from a configuration settings (INI)
  file written by the server and writes the results
  to a file that the server passes back to the
  client. Each request message is handled by a
  separate instance of the application.
• Apache Shared Module (DLL)
• An Apache Web server application is a DLL that is
  loaded by the Web server. Client request
  information is passed to the DLL as a structure.
  Each request message is automatically handled in
  a separate execution thread.

39
Summary

• Well-managed collaboration is a BIG NEED in our
  community!
• CODENet provides a dynamic and peristent service
  for
• players
• tools
• repositories
• other services
• CODENet provides a next generation web service
  infrastructure to support our simulation
  development needs.

40
Questions?
41
(No Transcript)
42
CODE-Net SDK

• CODE-Net API Document (Word)
• Compiled Server Application
• ISAPI DLL -or-
• CGI Exe
• Client Side DLLs (for developers who dont have
  SOAP technology as part of their development
  environment)

43
Benefits of Research

• Demonstrates how web service technology will make
  data interchange more efficient by providing
  central services and functionality without
  specific platforms and operating system.
• Supports reusability of objects and data through
  strict object-oriented design and implementation
  of applications and objects that are to be stored
  and shared via the web service clients and server.

44
CODE-Net

• Collaboration Conduit
• Facilitates Automation

45
(No Transcript)
46
Need a ubiquitous mechanism for wiring tools
and faclitating communication and
coordination among team members.
47
CODENet - Under The Hood
48
(No Transcript)
49
Web Service
50
(No Transcript)
51
What is a Service's "Style"?

• HINT If you are using a toolkit that only does
  basic RPC and does not do "Document Style" SOAP,
  services with style "DOC" will probably NOT work
  for you.
• Style, as defined by WSDL 1.1 refers to whether a
  SOAP envelope is structured for sending XML
  documents or whether it is a serialized
  representation of an RPC method call.
• The more general case is "document style". This
  simply means that the SOAP Body carries a generic
  XML document. There's no explicit concept of
  "method invocation" coming into play here it's
  simply about passing XML docs back and forth
  between the client and server.
• The way the SOAP specification handles RPC is by
  specifying that the payload carried by the SOAP
  body takes on a specific form. This form is
  specified in section 7 of the SOAP spec. Yes, it
  is still an XML document being carried in the
  SOAP Body, but it's a document that must conform
  to the requirements if section 7 of the SOAP spec.

52
What is a Service's "Style"?

• An example of the SOAP Body of a document style
  SOAP Envelope is shown below
• ltSOAP-ENVEnvelopexmlnsSOAP-ENV"http//schemas.
  xmlsoap.org/soap/envelope/"SOAP-ENVencodingStyle
  "http//schemas.xmlsoap.org/soap/encoding/"/gtltSO
  AP-ENVBodygtltStockQuoteRequest
  symbol"FOO"/gtlt/SOAP-ENVBodygtlt/SOAP-ENVEnvelop
  egt
• As you can see, in document style soap, what's
  carried within the body is one or more XML
  documents. The protocol places no constraint on
  how that document needs to be structured that's
  totally handled at the application level.

53
What is a Service's "Style"?

• An example of the SOAP Body of a RPC-style SOAP
  envelope is shown below
• ltSOAP-ENVEnvelopexmlnsSOAP-ENV"http//schemas.
  xmlsoap.org/soap/envelope/"SOAP-ENVencodingStyle
  "http//schemas.xmlsoap.org/soap/encoding/"/gtltSO
  AP-ENVBodygtltmGetStockQuote xmlnsm"urnxmethod
  sexample"gtltSymbolgtFOOlt/Symbolgtlt/mGetStockQuote
  gtlt/SOAP-ENVBodygtlt/SOAP-ENVEnvelopegt
• Yes, there is an XML document being encapsulated
  by the SOAP Body - just as there was with the
  "document style" example. But in the "rpc style"
  case, this document's structure isn't being
  defined directly by the application instead,
  it's being defined by SOAP section 7 and the SOAP
  toolkit itself is most likely generating this
  XML the end-user of the toolkit (the one
  invoking the remote method) is probably never
  coming into direct contact with this document.
  It's simply an encoding of the method call being
  specified by the end-user.
• In the example above, "GetStockQuote" is the
  method name and "Symbol" is the input parameter
  to the method. The namespace on the GetStockQuote
  method wrapper element is a deployment parameter
  and often critically used by SOAP servers to help
  dispatch an incoming request to the proper objectt

54
What is a Service's "Style"?

• The Interoperabilty Impact
• If a service that accepts and sends
  document-style envelopes receives an RPC-style
  request envelope, or vice versa, the SOAP
  envelope will most likely not be accepted. That's
  because at the wire level, the document actually
  being received in the SOAP Body is different in
  the two cases.
• Most of the early work on SOAP toolkit
  implementations focused on RPC-style SOAP. Today,
  it's more balanced between RPC and document
  styles - for example, MS .NET defaults to
  document style when publishing a SOAP service.
  There is no "right" answer as to which should be
  used - both styles are suited for different
  situations. In some cases, the expressiveness of
  XML documents is preferable needed in other
  cases, the easy integration into development
  environments that SOAP RPC gives you (with
  automatic type serialization/deserialization,
  etc) is important.
• Finally, it's important to point out that many
  toolkits that have built-in WSDL processing (and
  there are more and more these days) can handle
  both document and RPC styles, since all of the
  info needed to formulate the request , including
  which style is being used, is contained in the
  WSDL blueprint.