Adaptergruppierung
improve this page | report issueÜbersicht
Mobile-Foundation-Adapter führen die serverseitige Logik aus. Außerdem übertragen sie Daten zu Back-End-Systemen und empfangen Daten von Back-End-Systemen. Adapter werden in allen Instanzen der Mobile-Foundation-Laufzeit implementiert und verbrauchen unabhängig von ihrer Verwendung Systemressourcen. Wenn einige Adapter nicht oft von der mobilen Anwendung genutzt werden, gibt es keine Möglichkeit, die Mobile-Foundation-Instanz nur mit den häufig verwendeten Adaptern zu skalieren. Die Skalierung der Umgebung führt dazu, dass alle Adapter auf allen neu hinzugefügten Knoten implementiert und ausgeführt werden. Dieses Verhalten führt zu einem langsamen Start der Mobile-Foundation-Instanz, weil die Laufzeit alle Adapter implementieren und ausführen muss.
Mit dem Feature für Adaptergruppierung können Sie Ressourcenadapter gruppieren und dann zusammen auf einer Reihe von Mobile-Foundation-Knoten ausführen. Diese Reihe von Knoten wird als Gruppebezeichnet. Die Gruppe kann durch das Hinzufügen weiterer Knoten in Abhängigkeit von der Adapterlast skaliert werden. Kunden können anhand der erwarteten Auslastung der Adapter in einer Gruppe im Voraus die Anzahl der Knoten in dieser Gruppe bestimmen.
Die Adaptergruppierung wird nur für Ressourcenadapter unterstützt, nicht aber für Adapter für Sicherheitsüberprüfungen.
Konfiguration
Im Rahmen der Adaptergruppierung ist eine Gruppe eine Sammlung von Mobile-Foundation-Knoten, auf denen eine Reihe von Ressourcenadaptern ausgeführt wird. In einer Farmtopologie mit 10 Knoten können Kunden beispielsweise drei Gruppen erstellen: Gruppe 1 mit 5 Knoten (Knoten 1, Knoten 2, Knoten 3, Knoten 4, Knoten 5), Gruppe 2 mit 3 Knoten (Knoten 6, Knoten 7, Knoten 8) und Gruppe 3 mit 2 Knoten (Knoten 9, Knoten 10).
In einer WAS-ND-Topologie (WebSphere Application Server Network Deployment) können Kunden für die Adaptergruppierung WAS-ND-Cluster erstellen, die den Gruppen der Adaptergruppierung zugeordnet werden. Im nächsten Abschnitt ist erläutert, wie die Adaptergruppierung in der Mobile Foundation funktioniert. Es wird eine Adaptergruppenkonfiguration definiert und die Knoten werden zu einem Teil einer Adaptergruppe gemacht. Zwei Konfigurationsänderungen sind in der Mobile Foundation erforderlich, damit die Adaptergruppierung funktioniert.
Adaptergruppenkonfiguration definieren und implementieren
Die Adaptergruppenkonfiguration definiert Gruppen und die zugehörigen Ressourcenadapter. Die Adaptergruppenkonfiguration hat folgende Struktur und muss mit der Verwaltungs-API implementiert werden.
{
"groups": [
{
"id": "finance",
"adapters": [
{
"name": "SavingAccountAdapter"
},
{
"name": "LoanProcessingAdapter"
}
]
},
{
"id": "hr",
"adapters": [
{
"name": "EmployeeInfoAdapter"
},
{
"name": "OnboardingAdapter"
}
]
}
]
}
Die obige Konfiguration definiert Adaptergruppen und die Adapter, die Teil dieser Gruppen sein müssen. Der Name der Adaptergruppe ist der Wert für den Schlüssel id
. Der Wert für den Schlüssel adapters
ist eine Liste der Ressourcenadapter, die in den jeweiligen Gruppen implementiert werden. Nachfolgend sind die für die Adaptergruppenkonfiguration verfügbaren Verwaltungs-APIs aufgelistet.
Adapterkonfiguration implementieren
Wenn Sie eine Adaptergruppenkonfiguration implementieren möchten, verwenden Sie die folgende Mobile-Foundation-Verwaltungs-API und geben Sie die oben beschriebenen Konfigurationsparameter als JSON-Nutzdaten an.
POST http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/<Laufzeit>/adapterGroupConfig
Beispiel:
curl -X POST --user admin:admin --header 'Content-Type: application/json' -- header 'Accept: application/json' -d '{ "groups": [{ "id": "finance", "adapters":
[ {"name": "SavingAccountAdapter" }, {"name": "LoanProcessingAdapter"}] },{"id": "hr", "adapters": [ {"name": "EmployeeInfoAdapter"}, {"name": "OnboardingAdapter"}]}]}' "http://<host>:<port>/mfpadmin/management apis/2.0/ runtimes/mfp/adapterGroupConfig"
Adaptergruppenkonfiguration abrufen
Wenn Sie eine bereits implementierte Adaptergruppenkonfiguration abrufen möchten, verwenden Sie die folgende Mobile-Foundation-Verwaltungs-API.
GET http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/<Laufzeit>/adapterGroupConfig
Beispiel:
curl -X GET --user admin:admin --header 'Content-Type: application/json' "http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/mfp/adapterGroupConfig"
Adaptergruppenkonfiguration löschen
Wenn Sie eine bereits implementierte Adaptergruppenkonfiguration löschen möchten, verwenden Sie die folgende Mobile-Foundation-Verwaltungs-API.
DELETE http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/<Laufzeit>/adapterGroupConfig
Beispiel:
curl -X DELETE --user admin:admin --header 'Content-Type: application/json' "http://<Host>:<Port>/mfpadmin/management-apis/2.0/runtimes/mfp/adapterGroupConfig"
Gruppen für die Adaptergruppierung definieren
Nachdem Sie die Adaptergruppenkonfiguration definiert und implementiert haben, ist als nächster Schritt die Erstellung der Gruppen erforderlich. Fügen Sie eine JNDI-Laufzeiteigenschaft mit dem Namen mfp.adaptergroup.name
als Gruppennamen hinzu, um die Mobile-Foundation-Knoten zum Teil einer Gruppe zu machen.
Beispiel:
<jndiEntry jndiName="mfp/mfp.adaptergroup.name" value="finance"/>
Wenn Sie in einer Farmtopologie die JNDI-Eigenschaft mfp.adaptergroup.name
zur Datei server.xml
eines Farmknotens hinzufügen, wird dieser Knoten zu einem Teil der in der JNDI-Eigenschaft genannten Gruppe. Wenn die obige JNDI-Eigenschaft für einen Knoten nicht angegeben ist, können Sie das Standardverhalten beobachten. Das bedeutet, alle Adapter werden auf diesem Knoten implementiert.
Wenn Gruppe 1 (Group1) aus den Knoten 1 bis 5 (node1, node2, node3, node4 und node5) besteht, muss auf allen Knoten die Datei server.xml
modifiziert werden. Die JNDI-Eigenschaft muss mit dem Wert Group1
hinzugefügt werden.
Beispiel: Group1 = [node 1, node 2, node 3, node 4, node 5]
<jndiEntry jndiName="mfp/mfp.adaptergroup.name" value=”Group1”/>
In ähnlicher Weise können andere Gruppen definiert werden. Für jeden WAS-ND-Cluster kann die JNDI-Eigenschaft definiert werden, um diesen Cluster zu einer Gruppe für die Adaptergruppierung zu machen.
Adapterimplementierung
Nachdem Sie die Adaptergruppenkonfiguration implementiert und Gruppen definiert haben, werden bei nachfolgenden Ressourcenadapterimplementierungen die in der Adaptergruppenkonfiguration genannten Regeln berücksichtigt. Wenn ein Adapter in der Liste der Adapter für eine Gruppe enthalten ist, wird er nur auf den Knoten der durch die JNDI-Eigenschaft mfp.adaptergroup.name
bezeichneten Gruppe implementiert.
Einige Änderungen, z. B. das Verschieben eines Adapters in eine andere Gruppe, erfordern bei einer bereits aktiven Mobile-Foundation-Instanz den Neustart der Mobile-Foundation-Instanz für alle Gruppen. Wenn ein neuer Adapter zur Adapterliste hinzugefügt wird, ist jedoch kein Neustart der Knoten erforderlich.
Änderungen an Adapteraufrufen
Wenn Sie von den Vorteilen der Adaptergruppierung profitieren möchten, müssen Sie die clientseitigen Adapteraufrufe so ändern, dass sie die Gruppeninformationen in der URI der Ressourcenanforderung enthalten. Der URI hat das Format /adaptergroups/<Gruppenname>/adapters/<Adaptername>/<Methode>
.
Beispiel:
adapterPath = new URI(“/adaptergroups/finance/adapters/SavingAccountAdapter/getBalance”);
WLResourceRequest request = new WLResourceRequest(adapterPath, WLResourceRequest.GET);
Durch die Einbeziehung von Adaptergruppeninformationen in die URI wird der Load Balancer (siehe unten) darüber informiert, dass der Aufruf an Adapter weitergeleitet werden soll, die in der angegebenen Gruppe ausgeführt werden.
Load-Balancer-Änderungen
Die wichtigsten Änderungen, die für ein Funktionieren der Adaptergruppierung erforderlich sind, müssen im Load Balancer vorgenommen werden. Der Load Balancer muss so konfiguriert werden, dass Adapteraufrufe an die laut URI-Muster richtige Gruppe weitergeleitet werden.
Hier sehen Sie eine Load-Balancer-Beispielkonfiguration für HAProxy in einer Farmtopologie. In dieser Konfiguration sind die Farmknoten host1 und host2 als Teil der Gruppe group1 definiert, die Farmknoten host3 und host4 als Teil der Gruppe group2 und der Farmknoten host5 als Standardhost. Wenn die Adapteraufrufanforderung HAProxy erreicht und die URL group1 enthält, wird der Aufruf an host1 und host2 weitergeleitet. Enthält die Anforderungs-URL group2, wird die Anforderung an host3 und host4 weitergeleitet. Alle übrigen Anforderungen werden an host5 weitergeleitet.
frontend localnodes
bind *:81
mode http
acl is_group1 url_sub group1
use_backend group1_server if is_group1
acl is_group2 url_sub group2
use_backend group2_server if is_group2
default_backend nodes
backend group1_server
mode http
balance roundrobin
option forwardfor
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httpchk HEAD / HTTP/1.1\r\nHost:localhost
server group1_server1 <host1>:<Port> check
server group1_server2 <host2>:<Port> check
backend group2_server
mode http
balance roundrobin
option forwardfor
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httpchk HEAD / HTTP/1.1\r\nHost:localhost
server group2_server1 <host3>:<Port> check
server group2_server2 <host4>:<Port> check
backend nodes
mode http
balance roundrobin
option forwardfor
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
option httpchk HEAD / HTTP/1.1\r\nHost:localhost
server default_server <host5>:<Port> check
▲Hinweis: Das Feature für Adaptergruppierung wird nicht über die Mobile-Foundation-Konsole aktiviert. Die Implementierung der Adaptergruppenkonfiguration ist nur mithilfe der APIs des Mobile-Foundation-Verwaltungsservice möglich.
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.