1 / 26

Core Services block

Core Services block. Basic Definitions (proposed). Core Services Basic set of generally available services Non-COI specific, of use to multiple COIs (intersection between COIs) Either: Produced by the Enterprise Or: Mandatory to be produced by all

michelet
Download Presentation

Core Services block

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Core Services block

  2. Basic Definitions (proposed) • Core Services • Basic set of generally available services • Non-COI specific, of use to multiple COIs (intersection between COIs) • Either: • Produced by the Enterprise • Or: • Mandatory to be produced by all • Other service implementations are based on the core services • Common Services (more common than core) • All services that are available to all • Includes Core services • Serves a large community of users • Core Enterprise Services (GIG) • CES, or Core Enterprise Services. Generic information services that apply to any COI, provide the basic ability to search the enterprise for desired information, and then establish a connection to the desired service. • Core Service Standards • Basic service descriptions and information standards • WSDL, UDDI, SOAP

  3. Basic Definitions (proposed) 2 • Initial Services (Are they core?) • First services to be released • The services that provides Quick Wins, most value for investment • Kernel Services • Infrastructure enabling services upon which the service exchange infrastructure is built. Part of Core services. • Microkernel Services • The smallest set of services required in order to make a service exchange infrastructure work. Part of Kernel Services. • Service Reference Model • A model, principles and patterns showing how services work together to produce a set of higher order services, e.g. based on a tier or layered pattern or any other collaboration pattern.

  4. Type of Core Service specifications • Service Type or description defined, can be implemented by many producers all with different properties. No guaranties given by the enterprise that any service instances is available at a particular point in time. • Service instances available to everybody on the net. Produced by the enterprise, some service level on e.g. availability is guaranteed by the enterprise • Mandatory services that all on the net must make available to the enterprise. May be a different set for producers versus consumers.

  5. Core Services (from DoD Shared Services) Core services consist of basic infrastructure capabilities needed across the enterprise. Examples of core services include discovery, messaging, mediation, storage, user support, security, collaboration and enterprise management. These types of services have typically been developed for commercial customers and are available from vendors on a per license basis or are acquired as managed services on the DoD networks and made available to programs of record. A business model that provides broad availability for these services to the DoD in a cost-effective manner can contribute to the development of an SOA. In addition, common core services and a greater maturity in the standards for these service areas are needed to resolve interoperability issues that still exist between vendors and therefore, between resulting DoD implementations in several core service areas (e.g., messaging and discovery). Although open standards have helped to reduce the problems of vendor incompatibility, there are still many remaining gaps in today’s standards that limit the ability to share information or services across communities.

  6. Common Services (from DoD shared services) Common services are work products that support a broad base of service consumers. Examples include weather, satellite propagation, logistics modules, track management, data fusion, and other capabilities that are needed by multiple mission areas, communities of interest (COIs), or programs of record. This category of service provides the greatest opportunity for increased effectiveness from interoperability and for reduced cost, including financial savings from economies of scale.

  7. Service classifications, CEN NEA Example Kernel Services? Core Services?

  8. CEN NEA Policies • Policy Framework • Directories • Security • Metadata • Ontology • Service Definition • Quality of Service, Service Level Agreements • Modeling • Commercial • Service Chaining

  9. CEN NEA Infrastructure and Enablers • Repository, Registry, Catalogue • Security (18 different) • Contract and Payment • Helpdesk • Testing • Training, Tutorial • Development • Time • QoS Supervision • Messaging • Etc.

  10. CEN NEA General Services

  11. CEN NEA COI Specific Services

  12. Examples of OASIS related work • ebXML, processes and services • ebXML Messaging • ebXML Registry • Translating Web Services • Web Services Notification • Web Services Security • Web Services Transaction • Web services resources • Web Services Quality

  13. Examples of W3C related work • WS Security • WS Policy • WS Trust • WS Choreography • WS Interoperability • Time services

  14. Areas of services standardization • Service concept • Business process • Policy • Security • Service definitions and descriptions • Information models • Service Data Objects, information sharing and management • Resources • Transactions • Service management • Service level agreements, Quality of services

  15. System Management BusinessApplications Security Support Applications Infrastructure Security Service support Integra-tion HSI Support Communication Control Data Management Infrastructure Kernel LedsystT TRM – Technical Reference Model • The TRM will contain • Business Applications which are unique to NBD, i.e. Blue Force Tracking • Common Support Applications, i.e. Mail, GIS-services • Integration of system functions through Infrastructure functions, i.e. Service Directory, Data base manager, Dialogue handling • Kernel functions, like operating system, basic access functions • Security services across all systems • System Management services across all systems • Service Registry • Service Bus The TRM contains the building blocks to develop the FMLS 2010 system. Interface specifications and standards will be defined by the architecture. This is the basis for the technical system implementation.

  16. The technical system functions are structured according to the “Technical Reference Model -TRM” in LedsystT

  17. Ex LedsystT TRM block System Management Services

  18. Ex LedsystT Business applications

  19. Ex LedsystT NERE – Network Enabling Runtime Environment - 1

  20. GIG DISA NCES Services Infrastructure: NCES Increment 1 Capabilities Shared Info Space Net-Centric Apps Collaboration Enterprise Collaboration Content Discovery and Delivery SOA Foundation Service Discovery People Discovery Service Security Text Messaging Enterprise Search Service Management Web Conference Service Messaging Content Delivery Application Sharing Service Mediation Whiteboard Identity Management

  21. Old NCOW RM (In ver 1.1 Nov 05 there is no model).

  22. NNEC FS Core services • Foundation (Core) Services • i. Discovery • ii. Information Assurance (Security) • iii. Messaging • iv. Enterprise Service Management • Interoperability (Core) Services • i. Storage • ii. Application • Collaboration (Core) Services • i. Mediation • ii. Collaboration • iii. User Assistance

  23. NNEC Layered service architecture

  24. NNEC Apps to Core services

  25. Separation of Concerns • User/application perspective • Management perspective • Infrastructure perspective • Security perspective

  26. Drivers in the selection of Core Services • Establish enablers in a stable way avoiding large later rework • Separate user/application from admin/infrastructure • Prepare for plug-in of anticipated later additions with minimum effect on other parts • Implement as much as possible as services • Quick Wins by providing maximum value per cost • Easy to implement • Useful for a large community • High value for the users/stakeholders

More Related