Summarizing ICF

•Download as PPTX, PDF•

1 like•1,750 views

The document discusses the Identity Connector Framework (ICF) which isolates connectors from provisioning tools like OIM. The ICF consists of a Service Provider Interface (SPI) layer used to develop connector implementations and an Application Programming Interface (API) layer which acts as a gateway to invoke connectors while shielding clients. OIM utilizes an OIM-ICF API Glue layer which wraps the ICF API and contains classes that orchestrate calls between OIM and the underlying ICF connectors.

Software

ICF SPI
(1) Built using
ICF Connector
Bundle

ICF SPI
(1) Built using
1. Connector
2. Configuration
3. CreateOp
4. UpdateOp
5. DeleteOp
connector-framework.
jar
ICF Connector
Bundle

ICF SPI
(1) Built using
connector-framework.
jar
ICF API
connector-framework.
jar
Implementation Contained within
1. Connector
2. Configuration
3. CreateOp
4. UpdateOp
5. DeleteOp
ICF Connector
Bundle
connector-framework-internal.
jar

ICF SPI
(1) Built using
connector-framework.
jar
ICF API
connector-framework.
jar
Uses
Implementation Contained within
1. Connector
2. Configuration
3. CreateOp
4. UpdateOp
5. DeleteOp
OIM-ICF API
Glue
(is a layer on top of)
ICF Connector
Bundle
connector-framework-internal.
jar
OIM
Connector
(2) Invokes via Adapter Factory
icf-oim-intg.jar
Contained within
ICProvisioningManager
and other classes
Contains

(3) Invokes
ICF SPI
(1) Built using
connector-framework.
jar
ICF API
connector-framework.
jar
Uses
Implementation Contained within
1. Connector
2. Configuration
3. CreateOp
4. UpdateOp
5. DeleteOp
OIM-ICF API
Glue
(is a layer on top of)
ICF Connector
Bundle
connector-framework-internal.
jar
(2) Invokes via Adapter Factory
icf-oim-intg.jar
Contained within
OIM
Connector
ICProvisioningManager
and other classes
Contains

(3) Invokes
(4) Executes operation via Proxy
ICF SPI
(1) Built using
connector-framework.
jar
ICF API
connector-framework.
jar
Uses
Implementation Contained within
1. Connector
2. Configuration
3. CreateOp
4. UpdateOp
5. DeleteOp
OIM-ICF API
Glue
(is a layer on top of)
ICF Connector
Bundle
connector-framework-internal.
jar
(4) Picks up relevant
(2) Invokes via Adapter Factory
Contained within
icf-oim-intg.jar
OIM
Connector
ICProvisioningManager
and other classes
Contains

The gist . . .
• Identity Connector Framework (ICF)
– Why? Isolates a connector from its prospective consumers (provisioning tools like OIM)
– How is this made possible? By splitting up ICF into SPI and API layers
• Service Provider Interface (SPI)
– Used to develop connector implementation for a specific target system
– Decouples a connector from OIM, facilitates easier development & testing
• Application Programming Interface (API)
– Gateway to connector functionality – ensures that the provisioning layer remains
shielded from SPI layer
– Encapsulates logic to invoke connector implementation without exposing client to SPI
details
• OIM-ICF API Glue
– Wrapper on top of ICF API – a convenient implementation to save us from doing all the
hard work!
– Set of classes which internally orchestrate calls to ICF API layer
– Called by Adapters (process task) within OIM

Similar to Summarizing ICF

By Balazs Gerofi, RIKEN Advanced Institute For Computational Science RIKEN Advanced Institute for Computation Science is in charge of leading the development of Japan's next generation flagship supercomputer, the successor of the K. Part of this effort is to design and develop a system software stack that suits the needs of future extreme scale computing. In this talk, we focus on operating system (OS) requirements for HPC and discuss IHK/McKernel, a multi-kernel based operating system framework. IHK/McKernel runs Linux with a light-weight kernel (LWK) side-by-side on compute nodes with the primary motivation of providing scalable, consistent performance for large scale HPC simulations, but at the same time to retain a fully Linux compatible execution environment. We provide an overview of the project and discuss the status of its support for ARM architecture. Balazs Gerofi Bio Research Scientist at RIKEN Advanced Institute For Computational Science. Email bgerofi@riken.jp For more info on The Linaro High Performance Computing (HPC) visit https://www.linaro.org/sig/hpc/

An Overview of the IHK/McKernel Multi-kernel Operating System

Linaro

Best Practices for Enterprise OSGi Applications - Emily Jiang

mfrancis

DEVNET-1128 Cisco Intercloud Fabric NB Api's for Business & Providers

Cisco DevNet

Spring framework

Sonal Poddar

My keynote at Eclipsecon Europe 2013. One of the attractive qualities of OSGi is its role in enabling technologies that adopt it to manage the cost of their own success. Anything that gains adoption - in technology or elsewhere - picks up baggage as a result and needs to figure out how to deal with current installations while expanding in new directions. The WebSphere platform has been around for almost as long as Java and knows a thing or two about baggage but still manages to travel to many places with just a carry-on allowance. We adopted OSGi internally 8 years ago and have gradually increased our exploitation with each passing release, most recently and deeply with the lightweight WAS Liberty Profile. It hasn't all been plain sailing and we learned from a number of mistakes made along the way. When WebSphere Application Server first adopted OSGi it had over 10 million lines of code in a modest number of huge JARs. The engineering effort to modularize that into a “sensible” number of OSGi bundles was fairly significant. We had a global development team spread across a dozen labs and nearly as many timezones, all learning OSGi principles at the same time. What could possibly go wrong? We did not, for example, initially adopt the services part of the OSGi architecture but it’s how we can now start/stop individual technologies of the Java EE Web Profile on the WAS Liberty profile, in a 50MB install with a 2-second startup, while still supporting a massive deploy base of applications on older levels of Java EE. One of the challenges OSGi continues to face is over when to be “front of office” and when to be “back”. As the industry accelerates towards cloud, OSGi is an internal part of IBM’s strategy for high-density virtualized Platform-as-a-Service through WebSphere Liberty. Today’s cloud provisioning strategies, for example the buildpacks used by Heroku and CloudFoundry, are designed to be technology-agnostic. As a programming model for the cloud, OSGi is in a position of strength with its heavily service-oriented architecture. But in the spirit of agnosticism, one of the next steps OSGi needs to take is simply greater availability of the core OSGi framework in some of the more popular cloud platforms. Once there are more OSGi services running in those environments then the value and simplicity of autowiring OSGi services as cloud services becomes more apparent. Expectations and vision has to be managed up and down any organization that invests in OSGi - from the executive leadership team responsible for the business's bottom line, through the distributed architecture/development teams building tomorrow's technology on top of today’s, to the marketing and sales organization who need to sell the result to both IT and line of business. The value proposition has to be tailored to the audience. This is the story of how WebSphere has had outstanding success with the former four-letter acronym that IBM Marketing still wants to expand.

Travelling light for the long haul

Ian Robinson

OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule) ABSTRACT One of the attractive qualities of OSGi is its role in enabling technologies that adopt it to manage the cost of their own success. Anything that gains adoption - in technology or elsewhere - picks up baggage as a result and needs to figure out how to deal with current installations while expanding in new directions. The WebSphere platform has been around for almost as long as Java and knows a thing or two about baggage but still manages to travel to many places with just a carry-on allowance. We adopted OSGi internally 8 years ago and have gradually increased our exploitation with each passing release, most recently and deeply with the lightweight WAS Liberty Profile. It hasn't all been plain sailing and we learned from a number of mistakes made along the way. When WebSphere Application Server first adopted OSGi it had over 10 million lines of code in a modest number of huge JARs. The engineering effort to modularize that into a “sensible” number of OSGi bundles was fairly significant. We had a global development team spread across a dozen labs and nearly as many timezones, all learning OSGi principles at the same time. What could possibly go wrong? I’ll spend a little time reviewing the consequences of our bundles-first-services-later approach but our success was initially limited to having the equivalent of a well-organized and large container ship which could travel at speed but needed a pretty wide berth. Our initial investment in OSGi delivered on most of the internal benefits we wanted but failed on some of the external ones that matter to our customers. Application Servers are used in different ways by Developers and IT Operations. Ops teams care about the overall cost, including performance and availability, of the platform and the applications it supports; Dev teams care about how quickly and easily they can create and deliver their applications and treat the server as a tool. Only some of them know or care about OSGi; multi-channel enablement and cloud deployment are the current pressures they are under. Today, WebSphere is a consumer of OSGi in two distinct fashions. Internally we learned from our earlier experiences and embraced an OSGi services model to enable us to run the same runtime just as fast but in a far more dynamic fashion: it’s how we can start/stop individual technologies of the Java EE Web Profile independently on the WAS Liberty profile, in a 50MB install with a 2-second startup while still support all our customers’ existing deployments. Externally we support both Enterprise OSGi and traditional Java EE as application programming models, on the same runtime and using the same Eclipse-based tools. Our customers who understand and care about OSGi can develop and deploy web application bundles and multi-bundle enterprise applications. Those who don’t care about OSGi benefit from it ind

Travelling Light for the Long Haul - Ian Robinson

mfrancis

Mr201307 investigation into_emet4.0_eng

FFRI, Inc.

SAN_Module3_Part1_PPTs.pptx

ShivarajPatil58

Burp Suite Extension Development

NSConclave

Module 06 (1).pdf

Rania Mabrouk

"Session Presentation from Visual Studio 2012 Launch" A Techie without efficient tools is only half the good! This session will give you the armor to battle the 2 most common scenarios we run into. 1. A production defect that cannot be reproduced in a test environment. 2. Not being able to reproduce poor application performance experienced in Production in a test environment. This session targets to show you how to use IntelliTrace in Production and Visual Studio Standalone profiler to the best of your advantage.

A techis guide to combating bugs & poor performance in production

Tarun Arora

5.5.1.2 packet tracer configure ios intrusion prevention system (ips) using...

Salem Trabelsi

Hp fortify source code analyzer(sca)

Nagaraju Repala

An introduction to the Spring Framework

weili_at_slideshare

CCNA v6.0 ITN - Chapter 02

Irsandi Hasan

Beginners guide on how to start exploring IoT 2nd session

veerababu penugonda(Mr-IoT)

An introduction to Symfony 2 for symfony 1 developers

Giorgio Cefaro

CCA security answers chapter 2 test

Soporte Yottatec

Symfony vs CodeIgniter

Mobicules Technologies

When virtualization encounters afl blackhat eu2016--1.4

月锋李

Similar to Summarizing ICF (20)

An Overview of the IHK/McKernel Multi-kernel Operating System

Best Practices for Enterprise OSGi Applications - Emily Jiang

DEVNET-1128 Cisco Intercloud Fabric NB Api's for Business & Providers

Spring framework

Travelling light for the long haul

Travelling Light for the Long Haul - Ian Robinson

Mr201307 investigation into_emet4.0_eng

SAN_Module3_Part1_PPTs.pptx

Burp Suite Extension Development

Module 06 (1).pdf

A techis guide to combating bugs & poor performance in production

5.5.1.2 packet tracer configure ios intrusion prevention system (ips) using...

Hp fortify source code analyzer(sca)

An introduction to the Spring Framework

CCNA v6.0 ITN - Chapter 02

Beginners guide on how to start exploring IoT 2nd session

An introduction to Symfony 2 for symfony 1 developers

CCA security answers chapter 2 test

Symfony vs CodeIgniter

When virtualization encounters afl blackhat eu2016--1.4

Recently uploaded

AI/ML Infra Meetup May. 23, 2024 Organized by Alluxio For more Alluxio Events: https://www.alluxio.io/events/ Speaker: - Junchen Jiang (Assistant Professor of Computer Science, @University of Chicago) Prefill in LLM inference is known to be resource-intensive, especially for long LLM inputs. While better scheduling can mitigate prefill’s impact, it would be fundamentally better to avoid (most of) prefill. This talk introduces our preliminary effort towards drastically minimizing prefill delay for LLM inputs that naturally reuse text chunks, such as in retrieval-augmented generation. While keeping the KV cache of all text chunks in memory is difficult, we show that it is possible to store them on cheaper yet slower storage. By improving the loading process of the reused KV caches, we can still significantly speed up prefill delay while maintaining the same generation quality.

AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG

Alluxio, Inc.

Agnieszka Andrzejewska - BIM School Course in Kraków

bim.edu.pl

OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam

takuyayamamoto1800

Key takeaways: Challenges of building platforms and the benefits of platformless. Key principles of platformless, including API-first, cloud-native middleware, platform engineering, and developer experience. How Choreo enables the platformless experience. How key concepts like application architecture, domain-driven design, zero trust, and cell-based architecture are inherently a part of Choreo. Demo of an end-to-end app built and deployed on Choreo.

Accelerate Enterprise Software Engineering with Platformless

WSO2

AI/ML Infra Meetup | Perspective on Deep Learning Framework

Alluxio, Inc.

The European Union Agency for Law Enforcement Cooperation (Europol) has suffered an alleged data breach after a notorious threat actor claimed to have exfiltrated data from its systems. Infamous data leaker IntelBroker posted on the even more infamous BreachForums hacking forum, saying that Europol suffered a data breach this month. The alleged breach affected Europol agencies CCSE, EC3, Europol Platform for Experts, Law Enforcement Forum, and SIRIUS. Infiltration of these entities can disrupt ongoing investigations and compromise sensitive intelligence shared among international law enforcement agencies. However, this is neither the first nor the last activity of IntekBroker. We have compiled for you what happened in the last few days. To track such hacker activities on dark web sources like hacker forums, private Telegram channels, and other hidden platforms where cyber threats often originate, you can check SOCRadar’s Dark Web News. Stay Informed on Threat Actors’ Activity on the Dark Web with SOCRadar!

SOCRadar Research Team: Latest Activities of IntelBroker

SOCRadar

Les Buildpacks existent depuis plus de 10 ans ! D’abord, ils étaient utilisés pour détecter et construire une application avant de la déployer sur certains PaaS. Ensuite, nous avons pu créer des images Docker (OCI) avec leur dernière génération, les Cloud Native Buildpacks (CNCF en incubation). Sont-ils une bonne alternative au Dockerfile ? Que sont les buildpacks Paketo ? Quelles communautés les soutiennent et comment ? Venez le découvrir lors de cette session ignite

Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...

Anthony Dahanne

Breaking the Code : A Guide to WhatsApp Business API.pdf

Meon Technology

Even though at surface level ‘java.lang.OutOfMemoryError’ appears as one single error; underlyingly there are 9 types of OutOfMemoryError. Each type of OutOfMemoryError has different causes, diagnosis approaches and solutions. This session equips you with the knowledge, tools, and techniques needed to troubleshoot and conquer OutOfMemoryError in all its forms, ensuring smoother, more efficient Java applications.

TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERROR

Tier1 app

Vitthal Shirke Microservices Resume Montevideo

Vitthal Shirke

Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...

informapgpstrackings

A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1

KnowledgeSeed

In software engineering, the right architecture is essential for robust, scalable platforms. Wix has undergone a pivotal shift from event sourcing to a CRUD-based model for its microservices. This talk will chart the course of this pivotal journey. Event sourcing, which records state changes as immutable events, provided robust auditing and "time travel" debugging for Wix Stores' microservices. Despite its benefits, the complexity it introduced in state management slowed development. Wix responded by adopting a simpler, unified CRUD model. This talk will explore the challenges of event sourcing and the advantages of Wix's new "CRUD on steroids" approach, which streamlines API integration and domain event management while preserving data integrity and system resilience. Participants will gain valuable insights into Wix's strategies for ensuring atomicity in database updates and event production, as well as caching, materialization, and performance optimization techniques within a distributed system. Join us to discover how Wix has mastered the art of balancing simplicity and extensibility, and learn how the re-adoption of the modest CRUD has turbocharged their development velocity, resilience, and scalability in a high-growth environment.

Beyond Event Sourcing - Embracing CRUD for Wix Platform - Java.IL

Natan Silnitsky

WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation

WSO2

Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...

rajkumar669520

Abortion ^Clinic ^%[+971588192166''] Abortion Pill Al Ain (?@?) Abortion Pill...

Abortion Clinic

Top Mobile App Development Companies 2024

XongoLab Technologies LLP

Into the Box 2024 - Keynote Day 2 Slides.pdf

Ortus Solutions, Corp

Using IESVE for Room Loads Analysis - Australia & New Zealand

IES VE

AI/ML Infra Meetup May. 23, 2024 Organized by Alluxio For more Alluxio Events: https://www.alluxio.io/events/ Speaker: - Lu Qiu (Data & AI Platform Tech Lead, @Alluxio) - Siyuan Sheng (Senior Software Engineer, @Alluxio) Speed and efficiency are two requirements for the underlying infrastructure for machine learning model development. Data access can bottleneck end-to-end machine learning pipelines as training data volume grows and when large model files are more commonly used for serving. For instance, data loading can constitute nearly 80% of the total model training time, resulting in less than 30% GPU utilization. Also, loading large model files for deployment to production can be slow because of slow network or storage read operations. These challenges are prevalent when using popular frameworks like PyTorch, Ray, or HuggingFace, paired with cloud object storage solutions like S3 or GCS, or downloading models from the HuggingFace model hub. In this presentation, Lu and Siyuan will offer comprehensive insights into improving speed and GPU utilization for model training and serving. You will learn: - The data loading challenges hindering GPU utilization - The reference architecture for running PyTorch and Ray jobs while reading data from S3, with benchmark results of training ResNet50 and BERT - Real-world examples of boosting model performance and GPU utilization through optimized data access

AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...

Alluxio, Inc.

Recently uploaded (20)

AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG

Agnieszka Andrzejewska - BIM School Course in Kraków

OpenFOAM solver for Helmholtz equation, helmholtzFoam / helmholtzBubbleFoam

Accelerate Enterprise Software Engineering with Platformless

AI/ML Infra Meetup | Perspective on Deep Learning Framework

SOCRadar Research Team: Latest Activities of IntelBroker

Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...

Breaking the Code : A Guide to WhatsApp Business API.pdf

TROUBLESHOOTING 9 TYPES OF OUTOFMEMORYERROR

Vitthal Shirke Microservices Resume Montevideo

Field Employee Tracking System| MiTrack App| Best Employee Tracking Solution|...

A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1

Beyond Event Sourcing - Embracing CRUD for Wix Platform - Java.IL

WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation

Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...

Abortion ^Clinic ^%[+971588192166''] Abortion Pill Al Ain (?@?) Abortion Pill...

Top Mobile App Development Companies 2024

Into the Box 2024 - Keynote Day 2 Slides.pdf

Using IESVE for Room Loads Analysis - Australia & New Zealand

AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...

Summarizing ICF

1. Summarizing ICF. . .

2. ICF Connector Bundle

3. ICF SPI (1) Built using ICF Connector Bundle

4. ICF SPI (1) Built using 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp connector-framework. jar ICF Connector Bundle

5. ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp ICF Connector Bundle connector-framework-internal. jar

6. ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar

7. ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar Contained within icf-oim-intg.jar

8. ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar (2) Invokes via Adapter Factory icf-oim-intg.jar Contained within OIM Connector

9. ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Uses Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar OIM Connector (2) Invokes via Adapter Factory icf-oim-intg.jar Contained within ICProvisioningManager and other classes Contains

10. (3) Invokes ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Uses Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar (2) Invokes via Adapter Factory icf-oim-intg.jar Contained within OIM Connector ICProvisioningManager and other classes Contains

11. (3) Invokes (4) Executes operation via Proxy ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Uses Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar (4) Picks up relevant (2) Invokes via Adapter Factory Contained within icf-oim-intg.jar OIM Connector ICProvisioningManager and other classes Contains

12. (3) Invokes (4) Executes operation via Proxy ICF SPI (1) Built using connector-framework. jar ICF API connector-framework. jar Uses Implementation Contained within 1. Connector 2. Configuration 3. CreateOp 4. UpdateOp 5. DeleteOp OIM-ICF API Glue (is a layer on top of) ICF Connector Bundle connector-framework-internal. jar (4) Picks up relevant (2) Invokes via Adapter Factory Contained within icf-oim-intg.jar OIM Connector ICProvisioningManager and other classes Contains (5) Executes CRUD Operations on Target System

13. The gist . . . • Identity Connector Framework (ICF) – Why? Isolates a connector from its prospective consumers (provisioning tools like OIM) – How is this made possible? By splitting up ICF into SPI and API layers • Service Provider Interface (SPI) – Used to develop connector implementation for a specific target system – Decouples a connector from OIM, facilitates easier development & testing • Application Programming Interface (API) – Gateway to connector functionality – ensures that the provisioning layer remains shielded from SPI layer – Encapsulates logic to invoke connector implementation without exposing client to SPI details • OIM-ICF API Glue – Wrapper on top of ICF API – a convenient implementation to save us from doing all the hard work! – Set of classes which internally orchestrate calls to ICF API layer – Called by Adapters (process task) within OIM

Summarizing ICF

Recommended

Recommended

More Related Content

Similar to Summarizing ICF

Similar to Summarizing ICF (20)

Recently uploaded

Recently uploaded (20)

Summarizing ICF