Repository: juddi Updated Branches: refs/heads/master be1878f7d -> 02c3b6d02
JUDDI-912 updating documentation for the replication bits JUDDI-919 fixing some of the example apps to default to SSL for example replication endpoints Project: http://git-wip-us.apache.org/repos/asf/juddi/repo Commit: http://git-wip-us.apache.org/repos/asf/juddi/commit/02c3b6d0 Tree: http://git-wip-us.apache.org/repos/asf/juddi/tree/02c3b6d0 Diff: http://git-wip-us.apache.org/repos/asf/juddi/diff/02c3b6d0 Branch: refs/heads/master Commit: 02c3b6d0269a1d826589cb6295bd9c43593075d2 Parents: be1878f Author: Alex <[email protected]> Authored: Mon Feb 16 15:05:35 2015 -0500 Committer: Alex <[email protected]> Committed: Mon Feb 16 15:05:35 2015 -0500 ---------------------------------------------------------------------- docs/asciidoc/Guide/en-US/Guide.asciidoc | 2 + .../Guide/en-US/GuideAdministration.asciidoc | 10 +- .../en-US/GuideConfigurationServer.asciidoc | 42 ++-- .../Guide/en-US/GuideReplication.asciidoc | 211 +++++++++++++++++++ .../juddi/replication/ReplicationNotifier.java | 5 +- .../apache/juddi/samples/JuddiAdminService.java | 4 +- .../adminconsole/hub/JUDDIRequestsAsXML.java | 4 +- .../juddi/adminconsole/hub/UddiAdminHub.java | 2 - src/site/xdoc/releases.xml | 1 - 9 files changed, 247 insertions(+), 34 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/docs/asciidoc/Guide/en-US/Guide.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/Guide.asciidoc b/docs/asciidoc/Guide/en-US/Guide.asciidoc index 8309d24..35c0064 100644 --- a/docs/asciidoc/Guide/en-US/Guide.asciidoc +++ b/docs/asciidoc/Guide/en-US/Guide.asciidoc @@ -24,6 +24,8 @@ include::GuideAdministration.asciidoc[] include::GuideConfigurationServer.asciidoc[] +include::GuideReplication.asciidoc[] + include::GuideRootSeedData.asciidoc[] include::GuideHowToDeployjUDDITo.asciidoc[] http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc b/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc index 9cebbcd..fc14b7c 100644 --- a/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc +++ b/docs/asciidoc/Guide/en-US/GuideAdministration.asciidoc @@ -620,6 +620,8 @@ This section is broken down into guidance for the jUDDI server and for the jUDDI * Disable sending authentication tokens to subscription notifications (config/juddi/notification/sendAuthTokenWithResultList=false) +* If you're using the replication services, configure your application server to use mutual certification authentication for that deployment (per the specification's recommendation). + ==== jUDDI Client (and developers) * Never log auth tokens. Protect it as if it was a password @@ -678,20 +680,20 @@ The jUDDI web services (juddiv3.war) is designed to be scaled to multiple server ===== Scaling using a common database -The first and simplest mechanism is for the instances of juddiv3.war to share the same database. All of jUDDI's database calls are transactional SQL, meaning that concurrent changes will function just fine from multiple concurrent users. Each instance of juddiv3.war must point to the same database and must use the same Node ID. See the Database Configuration Chapter for more information. +The first and simplest mechanism is for the instances of juddiv3.war to share the same database. All of jUDDI's database calls are transactional SQL, meaning that concurrent changes will function just fine from multiple concurrent users. Each instance of juddiv3.war must point to the same database and must use the same Node ID and configuration settings. See the Database Configuration Chapter for more information. ===== Scaling using Subscriptions -The second mechanism is to use the Subscription API to import data and updates from a remote registry. Unfortunately, this scenario isn't quite yet supported for jUDDI, but will be in a future release. +The second mechanism is to use the Subscription API to import data and updates from a remote registry. Unfortunately, this scenario isn't quite yet supported for jUDDI, but may be in a future release. ===== Replication API -The third mechanism is the Replication API, which is part of the OASIS UDDIv3 specification. jUDDI unfortunately does not currently implement this specification but may in the future. +The third mechanism is the Replication API, which is part of the OASIS UDDIv3 specification. Since version 3.3, jUDDI provides support for synchronizating UDDI servers using the techniques described in the specification as Replication. See the Replication Services chapter for additional information, ==== Limitations of jUDDI -jUDDI's web services have no explicit upper bound on the volume of businesses and services registered. Load testing has shown that at least 10,000 are support for each category. The upper limit is more of a function of both the underlying database implementation and hardware (free disk space). In either case, the likelihood of hitting the limit is low for most instances. If you happen to run into scaling issues, please file a bug report at JUDDI's JIRA site at: https://issues.apache.org/jira/browse/JUDDI +jUDDI's web services have no explicit upper bound on the volume of businesses and services registered. Load testing has shown that at least 10,000 are supported for each category. The upper limit is more of a function of both the underlying database implementation and hardware (free disk space). In either case, the likelihood of hitting the limit is low for most instances. If you happen to run into scaling issues, please file a bug report at JUDDI's JIRA site at: https://issues.apache.org/jira/browse/JUDDI http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc b/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc index 3c38c45..31f10a0 100644 --- a/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc +++ b/docs/asciidoc/Guide/en-US/GuideConfigurationServer.asciidoc @@ -20,7 +20,7 @@ IMPORTANT: When referring to configuration 'properties', we are really referenci |_juddi/auth/token/Timeout_ |Time in minutes to expire tokes after inactivity.|N |_15_ |_juddi/auth/token/Expiration_ |As of 3.1.5 Duration of time for tokens to expire, regardless of inactivity.|N |_15_ |_juddi/auth/token/enforceSameIPRule_ |As of 3.2 This setting will enable or disable the auth token check to ensure that auth tokens can only be used from the same IP address that they were issued to..|N |_true_ -|_juddi/auth/authenticator@useAuthToken | Indicates that the authenticator is use requires a UDDI auth token. Set to false when using HTTP based authenticators | N | _true_ +|_juddi/auth/authenticator@useAuthToken_ | Indicates that the authenticator is use requires a UDDI auth token. Set to false when using HTTP based authenticators | N | _true_ |=========================================================================================== @@ -46,7 +46,7 @@ IMPORTANT: When referring to configuration 'properties', we are really referenci |_juddi/configuration/reload/delay_ |The time in milliseconds in which juddiv3.xmlis polled for changes.|N|5000 |=========================================================================================== -CAUTION: Take caution in changing the jUDDI Node ID. If jUDDI has already been started at least once and the Node ID is changed, an existing records will not be editable. If you want to change from the default value, do so before you first start jUDDI by editing the configuration file. +CAUTION: Take caution in changing the jUDDI Node ID. (Updated at 3.3) jUDDI can now change Node IDs via the Admin console. However care must be taken to prevent changes to data while the rename is in progress. It is recommended to use the Admin console to change the Node ID. It will automatically update the database and the _juddiv3.xml_ configuration file. === Email @@ -83,7 +83,7 @@ Starting with 3.2.1, jUDDI can now send a test email via the juddiv3.war/admin c |_juddi/maxInClause_ | The maximum number of "IN" clause parameters. Some RDMBS limit the number of parameters allowed in a SQL "IN" clause. |Y|[_1000_] |_juddi/maxNameElementsAllowed_| The maximum name size and maximum number of name elements allows in several of the _FindXxxx_ and _SaveXxxx_ UDDI functions |N|[_5_] |_juddi/maxNameLength_ | The maximum name size of name elements|N|[_255_] -|_juddi/maxRows_ | The maximum number of rows returned in a find_* operation. Each call can set this independently, but this property defines a global maximum. This is related to the _maxInClause_ setting (the same?).|N|1000 +|_juddi/maxRows_ | The maximum number of rows returned in a find* operation. Each call can set this independently, but this property defines a global maximum. This is related to the _maxInClause_ setting (the same?).|N|1000 |=========================================================================================== === RMI Proxy @@ -107,7 +107,7 @@ RMI Proxy properties that can be referenced in the _juddiv3.xml_ file and is onl |Property Name |Description |Required |Default Value or [Example Value] |_juddi/cryptor_ | jUDDI Cryptor implementation class that jUDDI will use to encrypt and decrypt password settings |N|_org.apache.juddi.cryptor.DefaultCryptor_ |_juddi/keygenerator_ | Key generator implementation that jUDDI will use to create UDDI keys if no key is passed in by the user.|N|_org.apache.juddi.keygen.KeyGenerator_ -|_juddi/uuidgen _ | UUID generator implementation that jUDDI will use to create UUIDs.|N|_org.apache.juddi.uuidgen.DefaultUUIDGen_ +|_juddi/uuidgen_ | UUID generator implementation that jUDDI will use to create UUIDs.|N|_org.apache.juddi.uuidgen.DefaultUUIDGen_ |=========================================================================================== === Subscription @@ -128,7 +128,7 @@ RMI Proxy properties that can be referenced in the _juddiv3.xml_ file and is onl === Custody Transfer -.Transfer properties that can be referenced in the _juddiv3.xml file. +.Transfer properties that can be referenced in the _juddiv3.xml_ file. [options="header"] |=========================================================================================== |Property Name |Description |Required |Default Value or [Example Value] @@ -138,20 +138,20 @@ RMI Proxy properties that can be referenced in the _juddiv3.xml_ file and is onl === Validation -.These settings are for validating the data that users store in jUDDI. They can be referenced in the _juddiv3.xml file. +.These settings are for validating the data that users store in jUDDI. They can be referenced in the _juddiv3.xml_ file. [options="header"] |=========================================================================================== |Property Name |Description |Required |Default Value or [Example Value] |_juddi/validation/enforceReferentialIntegrity_|As of 3.1.5 This setting will force referential integrity for all tModels (except keyGenerators), category bags, bindingTemplate/AccessPoint/hostingRedirector (referencing another host), tModelInstanceParms and anything else that references a KeyName default value is true. Set to false for backwards compatibility or for a more lax registry.|N|[_true_] -|_juddi/validation/rejectInvalidSignatures/enable | Enables or Disables the validation of signatures when a publisher attempts to save an entity | N | false -|_juddi/validation/rejectInvalidSignatures/enable/trustStorePath | Path to the trust store. Can be overridden via system properties. If not specified, the Windows trust store will be used, else the default JRE trust store will be used. | N | [truststore.jks] -|_juddi/validation/rejectInvalidSignatures/trustStoreType | The type of store to use | N | JKS -|_juddi/validation/rejectInvalidSignatures/trustStorePassword | The clear text or encrypted password to the trust store | N | -|_juddi/validation/rejectInvalidSignatures/trustStorePassword@isPasswordEncrypted | True/False | N | false -|_juddi/validation/rejectInvalidSignatures/trustStorePassword@cryptoProvider | A cryptographic provider, representing the one that was used to encrypt | -|_juddi/validation/rejectInvalidSignatures/checkTimestamps | If true, certificates are checked against the time validity | N | false -|_juddi/validation/rejectInvalidSignatures/checkTrust | If true, the certificates trust chain is validated against the trust store | N | false -|_juddi/validation/rejectInvalidSignatures/checkRevocationCRL | If true, the certificate will attempted to be validated using online certificate revocation protocols | N | false +|_juddi/validation/rejectInvalidSignatures/enable_ | Enables or Disables the validation of signatures when a publisher attempts to save an entity | N | false +|_juddi/validation/rejectInvalidSignatures/enable/trustStorePath_ | Path to the trust store. Can be overridden via system properties. If not specified, the Windows trust store will be used, else the default JRE trust store will be used. | N | [truststore.jks] +|_juddi/validation/rejectInvalidSignatures/trustStoreType_ | The type of store to use | N | JKS +|_juddi/validation/rejectInvalidSignatures/trustStorePassword_ | The clear text or encrypted password to the trust store | N | +|_juddi/validation/rejectInvalidSignatures/trustStorePassword@isPasswordEncrypted_ | True/False | N | false +|_juddi/validation/rejectInvalidSignatures/trustStorePassword@cryptoProvider_ | A cryptographic provider, representing the one that was used to encrypt | +|_juddi/validation/rejectInvalidSignatures/checkTimestamps_ | If true, certificates are checked against the time validity | N | false +|_juddi/validation/rejectInvalidSignatures/checkTrust_ | If true, the certificates trust chain is validated against the trust store | N | false +|_juddi/validation/rejectInvalidSignatures/checkRevocationCRL_ | If true, the certificate will attempted to be validated using online certificate revocation protocols | N | false |=========================================================================================== @@ -163,7 +163,7 @@ Logging properties that can be referenced in the _juddiv3.xml_ file. [options="header"] |=========================================================================================== |Property Name |Description |Required |Default Value or [Example Value] -|_juddi/logging/logInquirySearchPayloads| Enables request payload logging for the Inquiry Find apis |N| false +|_juddi/logging/logInquirySearchPayloads_| Enables request payload logging for the Inquiry Find apis |N| false |=========================================================================================== === Performance @@ -174,20 +174,20 @@ Perofrmance properties are referenced in the _juddiv3.xm_ file. [options="header"] |=========================================================================================== |Property Name |Description |Required |Default Value or [Example Value] -|_juddi/performance/enableFindBusinessTModelBagFiltering| UDDI defines a mechansim to filter findBusiness relates based on tModelInstanceInfo within their service's binding templates. This is an expensive operation and will cause significant performance degredation on larger registries. For spec complliance, it should be set to true. We suspect it's not a commonly used feature and recommend setting this to false. |N| true +|_juddi/performance/enableFindBusinessTModelBagFiltering_ | UDDI defines a mechansim to filter findBusiness relates based on tModelInstanceInfo within their service's binding templates. This is an expensive operation and will cause significant performance degredation on larger registries. For spec complliance, it should be set to true. We suspect it's not a commonly used feature and recommend setting this to false. |N| true |=========================================================================================== === Replication .These properties are used to tweak the replication service capabilities. -Perofrmance properties are referenced in the _juddiv3.xm_ file. +These properties are referenced in the _juddiv3.xml_ file. [options="header"] |=========================================================================================== |Property Name |Description |Required |Default Value or [Example Value] -|_juddi/replication/getChangeRecordsMax| The maximum number of records to return from a getChangeRecord request |N| 100 -|_juddi.replication.start.buffer | Specifies the amount of time to wait before the replication timer initially fires. (in ms) | N | 5000 -|_juddi.replication.interval | Specifies the interval at which the replication timer triggers (in ms). | N | 5000 +|_juddi/replication/getChangeRecordsMax_ | The maximum number of records to return from a getChangeRecord request |N| 100 +|_juddi/replication/start/buffer_ | Specifies the amount of time to wait before the replication timer initially fires. (in ms) | N | 5000 +|_juddi/replication/interval_ | Specifies the interval at which the replication timer triggers (in ms). | N | 5000 |=========================================================================================== http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/docs/asciidoc/Guide/en-US/GuideReplication.asciidoc ---------------------------------------------------------------------- diff --git a/docs/asciidoc/Guide/en-US/GuideReplication.asciidoc b/docs/asciidoc/Guide/en-US/GuideReplication.asciidoc new file mode 100644 index 0000000..02b2c9f --- /dev/null +++ b/docs/asciidoc/Guide/en-US/GuideReplication.asciidoc @@ -0,0 +1,211 @@ +[[chapter-Replication]] +== Replication Services + +=== Introduction + +The UDDIv3 specification introduced a Replication API that outlines a mechansim for maintaing data ownership and data synchronization across more than one UDDI node. The replication specification has a number of facets that to the casual reader, can see overwhelmingly complex. jUDDI v3 provides support for the majority of the UDDIv3 replication API. This article will attempt to describe the in's and out's of the specification, what jUDDI supports and doesn't, finally, how to use it with your jUDDI instance(s). + +=== UDDIv3 Replication Overview + +The UDDIv3 replication API defines a number of web service methods that are used to manage and replicate UDDI data. Each node is responsible for maintaining a record of all changes made both locally and at all remote nodes. Everytime a Business, Service, Binding, tModel, or Publisher Assertion changes, all nodes are notified of the change. Once receiving the notification of the change, all nodes are then responsible to obtain the change set, apply it locally, and then retransmit (if needed and based on topology). The topology is configured via the Replication Configuration. With jUDDI, this is configured using the adminstration console. + +There's one important note to remember. Each piece of data in UDDI is owned by a given node. + +==== UDDIv3 Replication Topology + +The specification identifies two scenarios for replication topology. + + 1. Non-directed Graph: All nodes can talk directly to each other and have direct communication with each other. + 2. Directed Graph: Nodes can only talk to subset of the complete set of nodes. + +The Non-directed graph is easier to implement and to understand. During the "notify" phase of replication, the node where the change originates, simply tell's everyone it knows about it. + +In a directed graph, the node where the change originates only notifies the nodes designated nodes. This typically forms some kind of ring in which one node notifies the next and so on until the original change ends up at the origin. + +==== Conflict handling + +The specification defines a mechanism that is similar to a two step commit (for those familiar with database terminology). Esscentially, when a given change (typically a new record) is created, it then notifies all other nodes to put a block on the new record's keys and waits for all nodes to respond with an "OK" to commit message. This prevents the same record from being created in multiple locations. These types of messages are refered to in the specification as NewDataConditional. As of the time of this writting jUDDI doesn't support it. When a record is created at the same at two different nodes within the same replication graph, jUDDI will simply reject the change and prevent the modifications or the transfer from happening. Records that fail to apply for one reason or another are stored in the database and can be accessed via the admin console via "Admin" and selected "getFailedReplicationChangeRecords" from the drop down menu. + +=== Configuring your jUDDI Node for replication + +Prerequisites: + + 1. Each node must have a unique ID associated with it. + 2. Each node must have the UDDI v3 Replication service deployed and configured for CLIENT-CERT authentication using SSL/TLS. + 3. Each node must have a configured JKS key store and trust store. + +==== Changing the Node ID + +Forgot to change the Node ID before starting jUDDI for the first time? No problem. Visit the jUDDI Administration console at http://localhost:8080/juddiv3/admin, then go to the Admin page and select "Change Node Id" from the drop down menu. + +==== Setting up CLIENT-CERT authentication + +Since a registry can be corrupted via the replication endpoint, it is important to provide adequate security. The UDDI spec recommends using mutual certificate authentication. This is somtimes returned to as "CLIENT-CERT", certificate based authentication, or two-way SSL. All of these terms really refer to the same thing. jUDDI comes prebundled with Apache Tomcat that is configured for mutal certificate authentication out of the box (with self signed certificates). To setup CLIENT-CERT authentication, please see the documentation for your web application server. + +==== Setting the Replication Configuration + +To set the replication configuration, you'll need to go to http://localhost:8080/juddiv3/admin then click on "Admin" in the top navigation bar and login. Once logged in, select "set_ReplicationNodes" from the drop down menu. The text entry field is actually resizable, so you'll probably want to make it bigger. This text box should be pre-populated with an example replication configuration. Edit the replication as needed, then click the "Go!" button to save it. + +Note: when saving the configuration, several of the fields (time stamp, serial number) will be overwritten by the server. This is normal. + +Additional notes: +jUDDI doesn't currently support maximumTimeToSyncRegistry, maximumTimeToGetChanges, and controlledMessage. Due to the way the specification was written, these fields are mandatory (they must be in the Replication Configuration XML), but jUDDI wont't respect them. + +===== Replication Configuration + +When using jUDDI's Admin console to set the replication config, here's a few things to keep in mind (using xpath notation). + + - replicationConfiguration/operator() - All nodes in the replication graph must be listed in the Operator section, including all directed graph nodes + - replicationConfiguration/registryContact - Must have at least one contact. If one is specified for the node's root business, then jUDDI will include that with the default config. + - replicationConfiguration/communicationGraph - Must be specified with all nodes listed as identified by the NodeID in replicationConfiguration/operator/operatorNodeID. + - replicationConfiguration/communicationGraph/controlledMessage must be specified. jUDDI uses a '*' to represent all messages. + - replicationConfiguration/maximumTimeToSyncRegistry isn't used and jUDDI will always set it to 1 + - replicationConfiguration/maximumTimeToGetChanges - isn't used and jUDDI will always set it to 1 + - replicationConfiguration/serialNumber - jUDDI will always set this to the time stamp when the configuration was last changed (time since epoch) + - replicationConfiguration/timeOfConfigurationUpdate - jUDDI will always set this to the time stamp when the configuraiton was last changed in a human readable form. The UDDI specification doesn't state what format it should be in, so we used ISO 8601 as the format. + +Everytime the configuration changes, an audit log is required in jUDDI log file. + +Here's an example default configuration +---- +<?xml version="1.0" encoding="UTF-8"?><replicationConfiguration xmlns="urn:uddi-org:repl_v3" xmlns:ns2="urn:uddi-org:api_v3" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#";> + <serialNumber>1424114880586</serialNumber> + <timeOfConfigurationUpdate>201502161428-0500</timeOfConfigurationUpdate> + <registryContact> + <ns2:contact> + <ns2:personName>unknown</ns2:personName> + </ns2:contact> + </registryContact> + <operator> + <operatorNodeID>uddi:juddi.apache.org:node1</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact/> + <soapReplicationURL>http://localhost:8080/juddiv3/services/replication</soapReplicationURL> + </operator> + <communicationGraph> + <node>uddi:juddi.apache.org:node1</node> + <controlledMessage>*</controlledMessage> + </communicationGraph> + <maximumTimeToSyncRegistry>1</maximumTimeToSyncRegistry> + <maximumTimeToGetChanges>1</maximumTimeToGetChanges> +</replicationConfiguration> +---- + +Here's an example non-directed replicaton graph. In this example, all changes perform on all nodes get set to all the other nodes. +---- +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> +<replicationConfiguration xmlns="urn:uddi-org:repl_v3" xmlns:ns2="urn:uddi-org:api_v3" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#";> + <serialNumber>0</serialNumber> + <timeOfConfigurationUpdate></timeOfConfigurationUpdate> + <registryContact> + <ns2:contact> + <ns2:personName>unknown</ns2:personName> + </ns2:contact> + </registryContact> + <operator> + <operatorNodeID>uddi:juddi.apache.org:node1</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact useType="admin"> + <ns2:personName xml:lang="en">bob</ns2:personName> + </ns2:contact> + <soapReplicationURL>https://localhost:8443/juddiv3replication/services/replication</soapReplicationURL> + </operator> + <operator> + <operatorNodeID>uddi:another.juddi.apache.org:node2</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact useType="admin"> + <ns2:personName xml:lang="en">mary</ns2:personName> + </ns2:contact> + <soapReplicationURL>https://localhost:9443/juddiv3replication/services/replication</soapReplicationURL> + </operator> + <communicationGraph> + <node>uddi:juddi.apache.org:node1</node> + <node>uddi:another.juddi.apache.org:node2</node> + <controlledMessage>*</controlledMessage> + </communicationGraph> + <maximumTimeToSyncRegistry>1</maximumTimeToSyncRegistry> + <maximumTimeToGetChanges>1</maximumTimeToGetChanges> +</replicationConfiguration> +---- + +In this example, we have a directed graph where Node 1 sends to Node2, Node 2 to Node 3, and Node 3 to Node 1. Note the addition of the replicationConfiguration/communicationGraph/edge() that defines this interaction pattern. Again all nodes defined in edges must also be defined both in the communicationGraph and as operator() XML elements. +---- +<?xml version="1.0" encoding="UTF-8" standalone="yes"?> +<replicationConfiguration xmlns="urn:uddi-org:repl_v3" xmlns:ns2="urn:uddi-org:api_v3" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#";> + <serialNumber>0</serialNumber> + <timeOfConfigurationUpdate></timeOfConfigurationUpdate> + <registryContact> + <ns2:contact> + <ns2:personName>unknown</ns2:personName> + </ns2:contact> + </registryContact> + <operator> + <operatorNodeID>uddi:juddi.apache.org:node1</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact useType="admin"> + <ns2:personName xml:lang="en">bob</ns2:personName> + </ns2:contact> + <soapReplicationURL>https://localhost:8443/juddiv3replication/services/replication</soapReplicationURL> + </operator> + <operator> + <operatorNodeID>uddi:another.juddi.apache.org:node2</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact useType="admin"> + <ns2:personName xml:lang="en">mary</ns2:personName> + </ns2:contact> + <soapReplicationURL>https://localhost:9443/juddiv3replication/services/replication</soapReplicationURL> + </operator> + <operator> + <operatorNodeID>uddi:yet.another.juddi.apache.org:node3</operatorNodeID> + <operatorStatus>normal</operatorStatus> + <ns2:contact useType="admin"> + <ns2:personName xml:lang="en">mary</ns2:personName> + </ns2:contact> + <soapReplicationURL>https://localhost:10443/juddiv3replication/services/replication</soapReplicationURL> + </operator> + <communicationGraph> + <node>uddi:another.juddi.apache.org:node2</node> + <node>uddi:juddi.apache.org:node1</node> + <node>uddi:yet.another.juddi.apache.org:node3</node> + <edge> + <messageSender>uddi:juddi.apache.org:node1</messageSender> + <messageReceiver>uddi:another.juddi.apache.org:node2</messageReceiver> + </edge> + <edge> + <messageSender>uddi:another.juddi.apache.org:node2</messageSender> + <messageReceiver>uddi:yet.another.juddi.apache.org:node3</messageReceiver> + </edge> + <edge> + <messageSender>uddi:yet.another.juddi.apache.org:node3</messageSender> + <messageReceiver>uddi:juddi.apache.org:node1</messageReceiver> + </edge> + </communicationGraph> + <maximumTimeToSyncRegistry>1</maximumTimeToSyncRegistry> + <maximumTimeToGetChanges>1</maximumTimeToGetChanges> +</replicationConfiguration> +---- + + +==== Performing Custody Transfer between nodes + +Custody transfer (from a user's perspective) happens exacty the same way as it would to transfer between two users on the same node. The only change is that the Replication API plays a signficant role in this process and is thus a requirement. + + +==== What's Supported and What's Not + +Supported Configurations + - Directed graph replication with retransmit + - Non-directed + - All UDDI data is replicated (Business, Binding, Serivce, tModels and Publisher Assertions) + - Custody transfer from Node to Node within the replication graph. + +Functions not supported + - Conditional Data Updates + - Configuration Settings: + - maximumTimeToSyncRegistry + - maximumTimeToGetChanges + - OperatorStatus - Node Status (New, Normal, Resigned) + - Controlled Messages (all messages are sent to all nodes) + + + http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/juddi-core/src/main/java/org/apache/juddi/replication/ReplicationNotifier.java ---------------------------------------------------------------------- diff --git a/juddi-core/src/main/java/org/apache/juddi/replication/ReplicationNotifier.java b/juddi-core/src/main/java/org/apache/juddi/replication/ReplicationNotifier.java index 6f0a680..4a51df1 100644 --- a/juddi-core/src/main/java/org/apache/juddi/replication/ReplicationNotifier.java +++ b/juddi-core/src/main/java/org/apache/juddi/replication/ReplicationNotifier.java @@ -65,9 +65,8 @@ public class ReplicationNotifier extends TimerTask { private static Log log = LogFactory.getLog(ReplicationNotifier.class); private Timer timer = null; - private long startBuffer = AppConfig.getConfiguration().getLong(Property.JUDDI_NOTIFICATION_START_BUFFER, 20000l); // 20s startup delay default + private long startBuffer = 5000;//AppConfig.getConfiguration().getLong(Property.JUDDI_NOTIFICATION_START_BUFFER, 20000l); // 20s startup delay default private long interval = 5000;//AppConfig.getConfiguration().getLong(Property.JUDDI_NOTIFICATION_INTERVAL, 300000l); //5 min default - private long acceptableLagTime = AppConfig.getConfiguration().getLong(Property.JUDDI_NOTIFICATION_ACCEPTABLE_LAGTIME, 10000l); //1000 milliseconds private static String node = null; private static UDDIService uddiService = new UDDIService(); @@ -79,6 +78,8 @@ public class ReplicationNotifier extends TimerTask { public ReplicationNotifier() throws ConfigurationException { super(); timer = new Timer(true); + startBuffer=AppConfig.getConfiguration().getLong(Property.JUDDI_REPLICATION_START_BUFFER, 5000l); + interval = AppConfig.getConfiguration().getLong(Property.JUDDI_REPLICATION_INTERVAL, 5000l); timer.scheduleAtFixedRate(this, startBuffer, interval); if (queue == null) { queue = new ConcurrentLinkedQueue(); http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/juddi-examples/more-uddi-samples/src/main/java/org/apache/juddi/samples/JuddiAdminService.java ---------------------------------------------------------------------- diff --git a/juddi-examples/more-uddi-samples/src/main/java/org/apache/juddi/samples/JuddiAdminService.java b/juddi-examples/more-uddi-samples/src/main/java/org/apache/juddi/samples/JuddiAdminService.java index 57ce10e..4834b00 100644 --- a/juddi-examples/more-uddi-samples/src/main/java/org/apache/juddi/samples/JuddiAdminService.java +++ b/juddi-examples/more-uddi-samples/src/main/java/org/apache/juddi/samples/JuddiAdminService.java @@ -682,9 +682,9 @@ public class JuddiAdminService { replicationNodes = new ReplicationConfiguration(); } - if (replicationNodes.getCommunicationGraph() == null) { + //if (replicationNodes.getCommunicationGraph() == null) { replicationNodes.setCommunicationGraph(new CommunicationGraph()); - } + //} Operator op = new Operator(); op.setOperatorNodeID("uddi:juddi.apache.org:node1"); op.setSoapReplicationURL("http://localhost:8080/juddiv3/services/replication";); http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/JUDDIRequestsAsXML.java ---------------------------------------------------------------------- diff --git a/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/JUDDIRequestsAsXML.java b/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/JUDDIRequestsAsXML.java index acfa03c..d05565b 100644 --- a/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/JUDDIRequestsAsXML.java +++ b/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/JUDDIRequestsAsXML.java @@ -159,9 +159,9 @@ public class JUDDIRequestsAsXML { op.setOperatorNodeID(thisnode); op.setOperatorStatus(OperatorStatusType.NORMAL); - String url = "http://localhost:8080/juddiv3/services/replication";; + String url = "https://localhost:8443/juddiv3replication/services/replication";; try { - url = AppConfig.getConfiguration().getString(Property.DEFAULT_BASE_URL_SECURE) + "/services/replication"; + url = AppConfig.getConfiguration().getString(Property.JUDDI_BASE_URL_SECURE) + "replication/services/replication"; } catch (ConfigurationException ex) { Logger.getLogger(JUDDIRequestsAsXML.class.getName()).log(Level.SEVERE, null, ex); } http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/UddiAdminHub.java ---------------------------------------------------------------------- diff --git a/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/UddiAdminHub.java b/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/UddiAdminHub.java index 01e3503..9a578e4 100644 --- a/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/UddiAdminHub.java +++ b/juddiv3-war/src/main/java/org/apache/juddi/adminconsole/hub/UddiAdminHub.java @@ -26,8 +26,6 @@ import java.util.ArrayList; import java.util.List; import java.util.Map; import java.util.Properties; -import java.util.logging.Level; -import java.util.logging.Logger; import javax.persistence.EntityManager; import javax.persistence.EntityTransaction; import javax.persistence.Query; http://git-wip-us.apache.org/repos/asf/juddi/blob/02c3b6d0/src/site/xdoc/releases.xml ---------------------------------------------------------------------- diff --git a/src/site/xdoc/releases.xml b/src/site/xdoc/releases.xml index d43ecae..8fb01fa 100644 --- a/src/site/xdoc/releases.xml +++ b/src/site/xdoc/releases.xml @@ -43,6 +43,5 @@ </table> </section> - </section> </body> </document> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
