470. This appendix describes an extract of some main requirements for an ESB in a military, mainly tactical, environment.

471. Mobility and Availability of the ESB Infrastructure:

472. One of the main requirements in the military sector is the mobility of a mobile client and service. The service and the client change the location and the ESB must support that location changes. Additional the ESB Infrastructure on the client and on the service must also be mobile. Independent from the status of the ESB environment the user should work in worst case locally on his equipment (using the local services).

473. Furthermore the ESB infrastructure must be on one site mobile and on the other site the ESB infrastructure must be also redundant in case of breakdown. For example the SAML Architecture (PEP, PDP, ...) and the PKI and the usage must be mobile and redundant. Therefore it is necessary to provide a replication of the critical and important data of the ESB infrastructure.

474. The current implementation of the ESB infrastructure looks like a more static environment with some redundancies.

475. Bandwidth in a Military Environment:

476. In a tactical, mobile environment low bandwidth is a major topic. Highly mobile military networks use for example radio communication (VHF, UHF) or Tactical Data Links (Link 16/22, VMF, JREAP, ...), SATCOM, directed antenna systems etc.. Contrary to this requirement the current ESB environment requires a high bandwidth and is IP based.

477. That means due to the design of an ESB the communication system must be able to fulfil its requirements. On one site some communication equipments must be improved like IP communication via radio, but on the other site the ESB design must take care about a low bandwidth (data rate). One improvement on the ESB design could be the usage of "Binary XML".

478. Binary XML, or Binary Extensible Markup Language, refers to any specification which defines the compact representation of XML in a binary format. How to involve Binary XML into SOA/SOAP and/or into the ESB Infrastructure and into the Client/Service Architecture (data model), is to analyze.

479. Remark: At the beginning it makes sense to start in an environment with higher bandwidth, but by the design of the ESB and the target of the ESB should be to support networks based on IP with lower bandwidth.

480. ESB Security in a Military Environment:

481. Because of the not included Security Standards, the security implementation in the ESBs isn't uniform and also some features are not implemented. Additional in the military environment the requirements related to the Security is different and especially from the nations.

482. Related to this it is necessary to define a security standard into the ESB / EMS Profile. Then based on this the implementation should be arranged in the ESB environment.

483. Online and Offline ESB Management:

484. In the military environment an ESB Management (including Service Management) is required. For example it is not only necessary to manage the access on a service at the first. Also due to the runtime of an operation between a client and service it could be necessary to change the service profile – for example: role/priority based reduction or refusal of a service usage, or changing of the setting of the QoS (Quality of Service agreement).

485. Furthermore a flexible and mobile management and monitoring of the ESB Infrastructure together with the service provider is required.

486. Interoperability: Non-interoperable ESB implementations

487. Currently a lot of implementations for an ESB exist like SOPERA, WebSphere, ORACEL ESB (BPEL), Software-AG ESB. Every ESB implementation contains an own framework which should be included on the client and server application. In the most ESB implementations the Client/ESB interface and the Service/ESB interface is proprietary. That means, it isn't possible to contact with a Service or Client based on the ESB "A" implementation the ESB "B". This is only possible in this case, if the Client/ESB interface and the Service/ESB interface are implemented based on standards (for based on an ESB / EMS Profile).

488. Currently a lot of different ESB implementations exist and the current aim (workaround / first step) is to enable federation of two or more ESB architectures that conform to the common specification for ESBs. The Appendix chapter 6 explains an example of a Federated ESB Reference Architecture.