diff options
Diffstat (limited to 'lib/orber/doc/src')
82 files changed, 0 insertions, 10814 deletions
diff --git a/lib/orber/doc/src/CosNaming.xml b/lib/orber/doc/src/CosNaming.xml deleted file mode 100644 index 251e721df1..0000000000 --- a/lib/orber/doc/src/CosNaming.xml +++ /dev/null @@ -1,71 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>CosNaming</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>CosNaming</module> - <modulesummary>The CosNaming service is a collection of interfaces that together define the naming service.</modulesummary> - <description> - <p>The naming service provides the principal mechanism for clients to find - objects in an ORB based world. The naming service provides an initial naming - context that functions as the root context for all names. Given this context - clients can navigate in the name space. </p> - <p>Types that are declared on the CosNaming level are:</p> - <code type="none"><![CDATA[ -typedef string Istring; -struct NameComponent { - Istring id; - Istring kind; -}; - -typedef sequence <NameComponent> Name; - -enum BindingType {nobject, ncontext}; - -struct Binding { - Name binding_name; - BindingType binding_type; -}; - -typedef sequence <Binding> BindingList; - ]]></code> - <p>To get access to the record definitions for the structs use:</p> - <code>-include_lib("orber/COSS/CosNaming.hrl").</code> - <p>Names are not an ORB object but the can be structured in components as seen by - the definition above. There are no requirements on names so the service can support - many different conventions and standards.</p> - <p>There are two different interfaces supported in the service:</p> - <list type="bulleted"> - <item>NamingContext</item> - <item>BindingIterator</item> - </list> - </description> - -</erlref> - diff --git a/lib/orber/doc/src/CosNaming_BindingIterator.xml b/lib/orber/doc/src/CosNaming_BindingIterator.xml deleted file mode 100644 index 69b0f42b22..0000000000 --- a/lib/orber/doc/src/CosNaming_BindingIterator.xml +++ /dev/null @@ -1,99 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>CosNaming_BindingIterator</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>CosNaming_BindingIterator</module> - <modulesummary>This interface supports iteration over a name binding list.</modulesummary> - <description> - <p>This interface allows a client to iterate over the Bindinglist it has been - initiated with.</p> - <p>The type <c>NameComponent</c> used below is defined as:</p> - <code type="none"> - -record('CosNaming_NameComponent', {id, kind=""}). - </code> - <p><c>id</c> and <c>kind</c> are strings. </p> - <p>The type <c>Binding</c> used below is defined as:</p> - <code type="none"> - -record('CosNaming_Binding', {binding_name, binding_type}). - </code> - <p><c>binding_name</c> is a <c>Name = [NameComponent]</c> and - <c>binding_type</c> is an enum which - has the values <c>nobject</c> and <c>ncontext</c>.</p> - <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it - is included with:</p> - <code type="none"> - -include_lib("orber/COSS/CosNaming/CosNaming.hrl"). - </code> - </description> - <funcs> - <func> - <name>next_one(BindinIterator) -> Return</name> - <fsummary>Return a binding</fsummary> - <type> - <v>BindingIterator = #objref</v> - <v>Return = {bool(), Binding}</v> - </type> - <desc> - <p>This operation returns the next binding and a boolean. The latter - is set to true if the binding is valid otherwise false. If the boolean - is false there are no more bindings to retrieve.</p> - </desc> - </func> - <func> - <name>next_n(BindinIterator, HowMany) -> Return</name> - <fsummary>Return a binding list</fsummary> - <type> - <v>BindingIterator = #objref</v> - <v>HowMany = int()</v> - <v>BindingList = [Binding]</v> - <v>Return = {bool(), BindingList}</v> - </type> - <desc> - <p>This operation returns a binding list with at most HowMany bindings. - If there are no more bindings it returns false otherwise true.</p> - </desc> - </func> - <func> - <name>destroy(BindingIterator) -> Return</name> - <fsummary>Destroy the iterator object</fsummary> - <type> - <v>BindingIterator = #objref</v> - <v>Return = ok</v> - </type> - <desc> - <p>This operation destroys the binding iterator.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/CosNaming_NamingContext.xml b/lib/orber/doc/src/CosNaming_NamingContext.xml deleted file mode 100644 index 4c83e6a240..0000000000 --- a/lib/orber/doc/src/CosNaming_NamingContext.xml +++ /dev/null @@ -1,243 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>CosNaming_NamingContext</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>CosNaming_NamingContext</module> - <modulesummary>This interface supports different bind and access functions for names in a context.</modulesummary> - <description> - <p>This is the object that defines name scopes, names must be unique within a - naming context. Objects may have multiple names and may exist in multiple - naming contexts. Name context may be named in other contexts and cycles are - permitted.</p> - <p>The type <c>NameComponent</c> used below is defined as:</p> - <code type="erl">-record('CosNaming_NameComponent', {id, kind=""}).</code> - <p>where <c>id</c> and <c>kind</c> are strings. </p> - <p>The type <c>Binding</c> used below is defined as:</p> - <code type="erl">-record('CosNaming_Binding', {binding_name, binding_type}).</code> - <p>where <c>binding_name</c> is a Name and <c>binding_type</c> is an enum which - has the values <c>nobject</c> and <c>ncontext</c>.</p> - <p>Both these records are defined in the file <c>CosNaming.hrl</c> and it - is included with:</p> - <code type="erl">-include_lib("orber/COSS/CosNaming/CosNaming.hrl").</code> - <p>There are a number of exceptions that can be returned from functions in this - interface.</p> - <list type="bulleted"> - <item> - <p>NotFound is defined as </p> - <code type="erl"> --record('CosNaming_NamingContext_NotFound', - {rest_of_name, why}).</code> - </item> - <item> - <p>CannotProceed is defined as </p> - <code type="erl"> --record('CosNaming_NamingContext_CannotProceed', - {rest_of_name, cxt}). - </code> - </item> - <item> - <p>InvalidName is defined as </p> - <code type="erl"> --record('CosNaming_NamingContext_InvalidName', {}). - </code> - </item> - <item> - <p>NotFound is defined as </p> - <code type="erl">-record('CosNaming_NamingContext_NotFound', {}).</code> - </item> - <item> - <p>AlreadyBound is defined as </p> - <code type="erl">-record('CosNaming_NamingContext_AlreadyBound', {}).</code> - </item> - <item> - <p>NotEmpty is defined as </p> - <code type="erl">-record('CosNaming_NamingContext_NotEmpty', {}).</code> - </item> - </list> - <p>These exceptions are defined in the file <c>CosNaming_NamingContext.hrl</c> and it - is included with:</p> - <code type="erl"> --include_lib("orber/COSS/CosNaming/CosNaming_NamingContext.hrl"). - </code> - </description> - <funcs> - <func> - <name>bind(NamingContext, Name, Object) -> Return</name> - <fsummary>Bind a Name to an Object</fsummary> - <type> - <v>NameContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Object = #objref</v> - <v>Return = ok</v> - </type> - <desc> - <p>Creates a binding of a name and an object in the naming context. - Naming contexts that are bound using <em>bind()</em> do not participate - in name resolution.</p> - </desc> - </func> - <func> - <name>rebind(NamingContext, Name, Object) -> Return</name> - <fsummary>Bind an Object to the Name even if the Name already is bound</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Object = #objref</v> - <v>Return = ok</v> - </type> - <desc> - <p>Creates a binding of a name and an object in the naming context even - if the name is already bound. Naming contexts that are bound using - <em>rebind()</em> do not participate in name resolution.</p> - </desc> - </func> - <func> - <name>bind_context(NamingContext1, Name, NamingContex2) -> Return</name> - <fsummary>Bind a Name to an NamingContext</fsummary> - <type> - <v>NamingContext1 = NamingContext2 =#objref</v> - <v>Name = [NameComponent]</v> - <v>Return = ok</v> - </type> - <desc> - <p>The bind_context function creates a binding of a name and a naming context in - the current context. - Naming contexts that are bound using <em>bind_context()</em> participate - in name resolution.</p> - </desc> - </func> - <func> - <name>rebind_context(NamingContext1, Name, NamingContex2) -> Return</name> - <fsummary>Bind an NamingContext to the Name even if the Name already is bound</fsummary> - <type> - <v>NamingContext1 = NamingContext2 =#objref</v> - <v>Name = [NameComponent]</v> - <v>Return = ok</v> - </type> - <desc> - <p>The rebind_context function creates a binding of a name and a naming context in - the current context even if the name already is bound. - Naming contexts that are bound using <em>rebind_context()</em> participate - in name resolution.</p> - </desc> - </func> - <func> - <name>resolve(NamingContext, Name) -> Return</name> - <fsummary>Retrieve an Object bound to Name</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Return = Object</v> - <v>Object = #objref</v> - </type> - <desc> - <p>The resolve function is the way to retrieve an object bound to a name in - the naming context. The given name must match exactly the bound name. The - type of the object is not returned, clients are responsible for narrowing - the object to the correct type.</p> - </desc> - </func> - <func> - <name>unbind(NamingContext, Name) -> Return</name> - <fsummary>Remove the binding for a Name</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Return = ok</v> - </type> - <desc> - <p>The unbind operation removes a name binding from the naming context.</p> - </desc> - </func> - <func> - <name>new_context(NamingContext) -> Return</name> - <fsummary>Create a new NamingContext</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Return = #objref</v> - </type> - <desc> - <p>The new_context operation creates a new naming context.</p> - </desc> - </func> - <func> - <name>bind_new_context(NamingContext, Name) -> Return</name> - <fsummary>Create a new NamingContext and bind it to a Name</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Return = #objref</v> - </type> - <desc> - <p>The new_context operation creates a new naming context and binds it to - Name in the current context.</p> - </desc> - </func> - <func> - <name>destroy(NamingContext) -> Return</name> - <fsummary>Destroy a NamingContext</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>Return = ok</v> - </type> - <desc> - <p>The destroy operation disposes the NamingContext object and removes it from the - name server. The context must be empty e.g. not contain any bindings to be - removed.</p> - </desc> - </func> - <func> - <name>list(NamingContext, HowMany) -> Return</name> - <fsummary>List returns a all bindings in the context</fsummary> - <type> - <v>NamingContext = #objref</v> - <v>HowMany = int()</v> - <v>Return = {ok, BindingList, BindingIterator}</v> - <v>BindingList = [Binding]</v> - <v>BindingIterator = #objref</v> - </type> - <desc> - <p>The list operation returns a BindingList with a number of bindings up-to - HowMany from the context. It also returns a BindinIterator which can be used to - step through the list. If the total number of existing bindings are less - than, or equal to, the <c>HowMany</c> parameter a NIL object reference - is returned.</p> - <p></p> - <note> - <p>One must destroy the BindingIterator, unless it is a NIL object - reference, by using 'BindingIterator':destroy(). Otherwise one can get - dangling objects.</p> - </note> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/CosNaming_NamingContextExt.xml b/lib/orber/doc/src/CosNaming_NamingContextExt.xml deleted file mode 100644 index 2af3deadda..0000000000 --- a/lib/orber/doc/src/CosNaming_NamingContextExt.xml +++ /dev/null @@ -1,102 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>2000</year><year>2017</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>CosNaming_NamingContextExt</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>2000-08-16</date> - <rev>A</rev> - </header> - <module>CosNaming_NamingContextExt</module> - <modulesummary>This interface contains operation for converting a Name sequence to a string and back.</modulesummary> - <description> - <p>To get access to the record definitions for the structures use: <br></br> -</p> - <code type="erl"> --include_lib("orber/COSS/CosNaming/CosNaming.hrl"). - </code> - <p>This module also exports the functions described in:</p> - <list type="bulleted"> - <item> - <p><seealso marker="CosNaming_NamingContext">CosNaming_NamingContext</seealso></p> - </item> - </list> - </description> - <funcs> - <func> - <name>to_string(NamingContext, Name) -> Return</name> - <fsummary>Stringify a <c>Name</c>sequence to a string</fsummary> - <type> - <v>NameContext = #objref</v> - <v>Name = [NameComponent]</v> - <v>Return = string() | {'EXCEPTION', NamingContext::InvalidName{}}</v> - </type> - <desc> - <p>Stringifies a <c>Name</c> sequence to a string.</p> - </desc> - </func> - <func> - <name>to_name(NamingContext, NameString) -> Return</name> - <fsummary>Convert a stringified <c>Name</c>to a <c>Name</c>sequence</fsummary> - <type> - <v>NameContext = #objref</v> - <v>NameString = string()</v> - <v>Return = [NameComponent] | {'EXCEPTION', NamingContext::InvalidName{}}</v> - </type> - <desc> - <p>Converts a stringified <c>Name</c> to a <c>Name</c> sequence.</p> - </desc> - </func> - <func> - <name>to_url(NamingContext, AddressString, NameString) -> Return</name> - <fsummary>Return an URL string constructed from the given Address and Name strings</fsummary> - <type> - <v>NameContext = #objref</v> - <v>Address = NameString = string()</v> - <v>Return = URLString | {'EXCEPTION', NamingContext::InvalidName{}} | {'EXCEPTION', NamingContextExt::InvalidAddress{}}</v> - </type> - <desc> - <p>This operation takes a <c>corbaloc</c> string and a stringified <c>Name</c> - sequence as input and returns a fully formed URL string.</p> - </desc> - </func> - <func> - <name>resolve_str(NamingContext, NameString) -> Return</name> - <fsummary>Return the object associated, if any, with the given name string</fsummary> - <type> - <v>NameContext = #objref</v> - <v>NameString = string()</v> - <v>Return = #objref | {'EXCEPTION', NamingContext::InvalidName{}} | {'EXCEPTION', NamingContext::NotFound{why, rest_of_name}} | {'EXCEPTION', NamingContext::CannotProceed{cxt, rest_of_name}}</v> - </type> - <desc> - <p>This operation takes a stringified <c>Name</c> sequence as input and - returns the associated, if any, object.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/Makefile b/lib/orber/doc/src/Makefile deleted file mode 100644 index c77345f12b..0000000000 --- a/lib/orber/doc/src/Makefile +++ /dev/null @@ -1,172 +0,0 @@ -# -# %CopyrightBegin% -# -# Copyright Ericsson AB 1997-2017. All Rights Reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. -# -# %CopyrightEnd% -# -# -include $(ERL_TOP)/make/target.mk -include $(ERL_TOP)/make/$(TARGET)/otp.mk - -# ---------------------------------------------------- -# Application version -# ---------------------------------------------------- -include ../../vsn.mk -VSN=$(ORBER_VSN) -APPLICATION=orber - -# ---------------------------------------------------- -# Release directory specification -# ---------------------------------------------------- -RELSYSDIR = $(RELEASE_PATH)/lib/$(APPLICATION)-$(VSN) - -# ---------------------------------------------------- -# Target Specs -# ---------------------------------------------------- -XML_APPLICATION_FILES = ref_man.xml -XML_REF3_FILES = \ - any.xml \ - corba.xml \ - corba_object.xml \ - orber.xml \ - CosNaming.xml \ - CosNaming_NamingContext.xml \ - CosNaming_NamingContextExt.xml \ - CosNaming_BindingIterator.xml \ - lname.xml \ - lname_component.xml \ - orber_ifr.xml \ - orber_tc.xml \ - Module_Interface.xml \ - interceptors.xml \ - fixed.xml \ - orber_diagnostics.xml \ - orber_acl.xml - -XML_PART_FILES = \ - part.xml - -XML_CHAPTER_FILES = \ - ch_contents.xml \ - ch_introduction.xml \ - ch_orber_kernel.xml \ - ch_ifr.xml \ - ch_install.xml \ - ch_idl_to_erlang_mapping.xml \ - ch_naming_service.xml \ - ch_stubs.xml \ - ch_security.xml \ - notes.xml \ - ch_exceptions.xml \ - ch_interceptors.xml \ - ch_orberweb.xml \ - ch_debugging.xml - -BOOK_FILES = book.xml - -XML_FILES = $(BOOK_FILES) $(XML_APPLICATION_FILES) $(XML_REF3_FILES) \ - $(XML_PART_FILES) $(XML_CHAPTER_FILES) - -TECHNICAL_DESCR_FILES = - -GIF_FILES = \ - name.gif \ - orbs.gif \ - theORB.gif \ - iiop.gif \ - dependent.gif \ - interceptor_operations.gif \ - menuframe.gif \ - dataframe1.gif \ - dataframe2.gif \ - dataframe3.gif \ - dataframe4.gif \ - dataframe5.gif \ - dataframe6.gif \ - dataframe7.gif \ - dataframe8.gif \ - firewall_nat.gif - -# ---------------------------------------------------- - -INTERNAL_HTML_FILES = $(TECHNICAL_DESCR_FILES:%.xml=$(HTMLDIR)/%.html) - -HTML_FILES = $(XML_APPLICATION_FILES:%.xml=$(HTMLDIR)/%.html) \ - $(XML_CHAPTER_FILES:%.xml=$(HTMLDIR)/%.html) \ - $(XML_PART_FILES:%.xml=$(HTMLDIR)/%.html) - -INFO_FILE = ../../info -EXTRA_FILES = \ - $(DEFAULT_GIF_FILES) \ - $(DEFAULT_HTML_FILES) \ - $(XML_REF3_FILES:%.xml=$(HTMLDIR)/%.html) - -MAN3_FILES = $(XML_REF3_FILES:%.xml=$(MAN3DIR)/%.3) - -HTML_REF_MAN_FILE = $(HTMLDIR)/index.html - -TOP_PDF_FILE = $(PDFDIR)/$(APPLICATION)-$(VSN).pdf - -# ---------------------------------------------------- -# FLAGS -# ---------------------------------------------------- -XML_FLAGS += -DVIPS_FLAGS += - -# ---------------------------------------------------- -# Targets -# ---------------------------------------------------- -$(HTMLDIR)/%.gif: %.gif - $(INSTALL_DATA) $< $@ - - -docs: pdf html man - -$(TOP_PDF_FILE): $(XML_FILES) - -pdf: $(TOP_PDF_FILE) - -html: gifs $(HTML_REF_MAN_FILE) - -clean clean_docs: - rm -rf $(HTMLDIR)/* - rm -f $(MAN3DIR)/* - rm -f $(TOP_PDF_FILE) $(TOP_PDF_FILE:%.pdf=%.fo) - rm -f errs core *~ - rm -f $(JD_HTML) $(JD_PACK) - -man: $(MAN3_FILES) - -gifs: $(GIF_FILES:%=$(HTMLDIR)/%) - -debug opt: - -# ---------------------------------------------------- -# Release Target -# ---------------------------------------------------- -include $(ERL_TOP)/make/otp_release_targets.mk - -release_docs_spec: docs - $(INSTALL_DIR) "$(RELSYSDIR)/doc/pdf" - $(INSTALL_DATA) $(TOP_PDF_FILE) "$(RELSYSDIR)/doc/pdf" - $(INSTALL_DIR) "$(RELSYSDIR)/doc/html" - $(INSTALL_DATA) $(HTMLDIR)/* \ - "$(RELSYSDIR)/doc/html" - $(INSTALL_DATA) $(INFO_FILE) "$(RELSYSDIR)" - $(INSTALL_DIR) "$(RELEASE_PATH)/man/man3" - $(INSTALL_DATA) $(MAN3DIR)/* "$(RELEASE_PATH)/man/man3" - -release_spec: diff --git a/lib/orber/doc/src/Module_Interface.xml b/lib/orber/doc/src/Module_Interface.xml deleted file mode 100644 index a809bcf02f..0000000000 --- a/lib/orber/doc/src/Module_Interface.xml +++ /dev/null @@ -1,356 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1999</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>Module_Interface</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>1999-09-03</date> - <rev>A</rev> - </header> - <module>Module_Interface</module> - <modulesummary>Orber generated stubs/skeletons.</modulesummary> - <description> - <p>This module contains the stub/skeleton functions generated by IC.</p> - <p>Starting a Orber server can be done in three ways:</p> - <list type="bulleted"> - <item>Normal - when the server dies Orber forgets all knowledge of the server.</item> - <item>Supervisor child - adding the configuration parameter <c>{sup_child, true}</c> - the <c>oe_create_link/2</c> function returns <c>{ok, Pid, ObjRef}</c> which - can be handled by the application <em>supervisor/stdlib-1.7</em> or later. </item> - <item>Persistent object reference - adding the configuration parameters <c>{persistent, true}</c> - and <c>{regname, {global, term()}}</c> Orber will remember the object reference until the - server terminates with reason <em>normal</em> or <em>shutdown</em>. Hence, - if the server is started as a <em>transient</em> supervisor child we do not - receive a 'OBJECT_NOT_EXIST' exception when it has crashed and is being restarted.</item> - </list> - <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation. - A pseudo object introduce some limitations:</p> - <list type="bulleted"> - <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e., - no link can or will be created.</item> - <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item> - <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back - functions must be implemented in a file called <c>M_I_impl.erl</c></item> - <item>The <c>IC</c> option <c>from</c> has no effect. </item> - <item>The call-back functions must be implemented as if the <c>IC</c> option - <c>{this, "M::I"}</c> was used.</item> - <item>Server <c>State</c> changes have no effect. The user can provide information via - the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State - passed in following invocations.</item> - <item>If a call-back function replies with the <c>Timeout</c> parameter set it have no effect.</item> - <item>Operations defined as <c>oneway</c> are blocking until the operation replies.</item> - <item>The option <c>{pseudo, true}</c> overrides all other start options.</item> - <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and - <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item> - </list> - <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c> - to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the - option <c>{pseudo, true}</c>, without changing the call-back module. - </p> - <p>If you start a object without <c>{regname, RegName}</c> it can only be accessed through the returned object key. - Started with a <c>{regname, RegName}</c> the name is registered locally or globally. - </p> - <warning> - <p>To avoid flooding Orber with old object references start erlang using the flag - <em>-orber objectkeys_gc_time Time</em>, which will remove all object references - related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing - garbage collect if no persistent objects are started, the objectkeys_gc_time default value - is <em>infinity</em>. For more information, see the orber and corba documentation.</p> - </warning> - </description> - <funcs> - <func> - <name>Module_Interface:typeID() -> TypeId</name> - <fsummary>Return the Type ID related to this stub/skeleton</fsummary> - <type> - <v>TypeId = string(), e.g., "IDL:Module/Interface:1.0"</v> - </type> - <desc> - <p>Returns the Type ID related to this stub/skeleton</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create() -> ObjRef</name> - <fsummary>Start a Orber server.</fsummary> - <type> - <v>ObjRef = #object reference</v> - </type> - <desc> - <p>Start a Orber server.</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create_link() -> ObjRef</name> - <fsummary>Start a linked Orber server.</fsummary> - <type> - <v>ObjRef = #object reference</v> - </type> - <desc> - <p>Start a linked Orber server.</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create(Env) -> ObjRef</name> - <fsummary>Start a Orber server.</fsummary> - <type> - <v>Env = term()</v> - <v>ObjRef = #object reference</v> - </type> - <desc> - <p>Start a Orber server passing Env to <c>init/1</c>.</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create_link(Env) -> ObjRef</name> - <fsummary>Start a linked Orber server.</fsummary> - <type> - <v>Env = term()</v> - <v>ObjRef = #object reference</v> - </type> - <desc> - <p>Start a linked Orber server passing Env to <c>init/1</c>.</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create(Env, Options) -> ObjRef</name> - <fsummary>Start a Orber stub/skeleton</fsummary> - <type> - <v>Env = term()</v> - <v>ObjRef = #object reference</v> - <v>Options = [{sup_child, false} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} | {create_options, [CreateOpts]}]</v> - <v>Bool = true | false</v> - <v>RegName = {global, term()} | {local, atom()}</v> - <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v> - <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v> - </type> - <desc> - <p>Start a Orber server passing Env to <c>init/1</c>.</p> - <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden. - As default, this option is set to false.</p> - <p>This function cannot be used for starting a server as supervisor child. - If started as <c>persistent</c>, the options <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used and - Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>.</p> - <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the - <seealso marker="ch_install#flags">Local Typechecking</seealso> - environment flag, turns on or off typechecking. If activated, - parameters, replies and raised exceptions will be checked to ensure that - the data is correct, when invoking operations on CORBA Objects within - the same Orber domain. Due to the extra overhead, this option - <em>MAY ONLY</em> be used during testing and development.</p> - <p><c>{survive_exit, boolean()}</c> overrides the - <seealso marker="ch_install#flags">EXIT Tolerance</seealso> - environment flag. If activated, the server will not terminate, even though - the call-back module returns EXIT.</p> - <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to - spend initializing. For more information about the <c>Dbg</c> options, - see the <c>sys</c> module.</p> - </desc> - </func> - <func> - <name>Module_Interface:oe_create_link(Env, Options) -> Return</name> - <fsummary>Start a Orber stub/skeleton</fsummary> - <type> - <v>Env = term()</v> - <v>Return = ObjRef | {ok, Pid, ObjRef}</v> - <v>ObjRef = #object reference</v> - <v>Options = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool} | {survive_exit, Bool} | {create_options, [CreateOpts]}]</v> - <v>Bool = true | false</v> - <v>RegName = {global, term()} | {local, atom()}</v> - <v>CreateOpts = {debug, [Dbg]} | {timeout, Time}</v> - <v>Dbg = trace | log | statistics | {log_to_file, FileName}</v> - <v></v> - <v></v> - <v></v> - </type> - <desc> - <p>Start a linked Orber server passing Env to <c>init/1</c>.</p> - <p>If the option <c>{pseudo, true}</c> is used, all other options are overridden and no link will be created. - As default, this option is set to false.</p> - <p>This function can be used for starting a server as persistent or supervisor child. At the moment - <c>[{persistent, true}, {regname, {global, term()}}]</c> must be used to start - a server as persistent, i.e., if a server died and is in the process of being restarted - a call to the server will not raise <c>'OBJECT_NOT_EXIST'</c> exception. - Orber will only forget the object reference if it terminates with reason <em>normal</em> or <em>shutdown</em>, - hence, the server must be started as <em>transient</em> (for more information see the - supervisor documentation).</p> - <p>The options <c>{local_typecheck, boolean()}</c> and <c>{survive_exit, boolean()}</c> - behaves in the same way as for <c>oe_create/2</c>.</p> - <p><c>Time</c> specifies how long time, in milliseconds, the server is allowed to - spend initializing. For more information about the <c>Dbg</c> options, - see the <c>sys</c> module.</p> - </desc> - </func> - <func> - <name>Module_Interface:own_functions(ObjRef, Arg1, ..., ArgN) -> Reply</name> - <name>Module_Interface:own_functions(ObjRef, Options, Arg1, ..., ArgN) -> Reply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>ObjRef = #object reference</v> - <v>Options = [Option] | Timeout</v> - <v>Option = {timeout, Timeout} | {context, [Context]}</v> - <v>Timeout = infinity | integer(milliseconds)</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_verify | ssl_client_depth | ssl_client_certfile | ssl_client_cacertfile | - ssl_client_password | ssl_client_keyfile | ssl_client_ciphers | ssl_client_cachetimeout</v> - <v>Value = allowed value associated with the given key</v> - <v>ArgX = specified in the IDL-code.</v> - <v>Reply = specified in the IDL-code.</v> - </type> - <desc> - <p>The default value for the <c>Timeout</c> option is <c>infinity</c>. - IPv4 or IPv6 addresses are accepted as local Interface.</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <p>To gain access to <c>#'IOP_ServiceContext'{}</c> record and the - <c>?ORBER_GENERIC_CTX_ID</c> macro, you must add - <c>-include_lib("orber/include/corba.hrl").</c> to your module.</p> - </desc> - </func> - </funcs> - - <section> - <title>CALLBACK FUNCTIONS</title> - <p>The following functions should be exported from a <c>CORBA</c> - callback module. Note, a complete template of the call-back module can - be generated automatically by compiling the IDL-file with the IC option - <c>{be,erl_template}</c>. One should also add - the same compile options, for example <c>this</c> or <c>from</c>, - used when generating the stub/skeleton modules.</p> - </section> - <funcs> - <func> - <name>Module_Interface_impl:init(Env) -> CallReply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>Env = term()</v> - <v>CallReply = {ok, State} | {ok, State, Timeout} | ignore | {stop, StopReason}</v> - <v>State = term()</v> - <v>Timeout = int() >= 0 | infinity</v> - <v>StopReason = term()</v> - </type> - <desc> - <p>Whenever a new server is started, <em>init/1</em> is the first function called in the specified call-back module.</p> - </desc> - </func> - <func> - <name>Module_Interface_impl:terminate(Reason, State) -> ok</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>Reason = term()</v> - <v>State = term()</v> - </type> - <desc> - <p>This call-back function is called whenever the server is about to terminate.</p> - </desc> - </func> - <func> - <name>Module_Interface_impl:code_change(OldVsn, State, Extra) -> CallReply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>OldVsn = undefined | term()</v> - <v>State = term()</v> - <v>Extra = term()</v> - <v>CallReply = {ok, NewState}</v> - <v>NewState = term()</v> - </type> - <desc> - <p>Update the internal <c>State</c>.</p> - </desc> - </func> - <func> - <name>Module_Interface_impl:handle_info(Info, State) -> CallReply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>Info = term()</v> - <v>State = term()</v> - <v>CallReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v> - <v>Timeout = int() >= 0 | infinity</v> - <v>StopReason = normal | shutdown | term()</v> - </type> - <desc> - <p>If the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em> - is passed to IC and <em>process_flag(trap_exit,true)</em> is set in the <em>init()</em> - call-back this function must be exported. </p> - <note> - <p>To be able to handle the <c>Timeout</c> option in <c>CallReply</c> in the call-back - module the configuration parameter <em>{{handle_info, "Module::Interface"}, true}</em> must - be passed to IC. </p> - </note> - </desc> - </func> - <func> - <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CallReply</name> - <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CallReply</name> - <name>Module_Interface_impl:own_functions(This, From, State, Arg1, ..., ArgN) -> ExtCallReply</name> - <name>Module_Interface_impl:own_functions(From, State, Arg1, ..., ArgN) -> ExtCallReply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>This = the servers #object reference</v> - <v>State = term()</v> - <v>ArgX = specified in the IDL-code.</v> - <v>CallReply = {reply, Reply, State} | {reply, Reply, State, Timeout} | {stop, StopReason, Reply, State} | {stop, StopReason, State} | corba:raise(Exception)</v> - <v>ExtCallReply = CallReply | corba:reply(From, Reply), {noreply, State} | corba:reply(From, Reply), {noreply, State, Timeout}</v> - <v>Reply = specified in the IDL-code.</v> - <v>Timeout = int() >= 0 | infinity</v> - <v>StopReason = normal | shutdown | term()</v> - </type> - <desc> - <p>All two-way functions must return one of the listed replies or raise any of - the exceptions listed in the IDL code (i.e. raises(...)). - If the IC compile options <em>this</em> and/or <em>from</em> are used, - the implementation must accept the <em>This</em> and/or <em>From</em> - parameters.</p> - </desc> - </func> - <func> - <name>Module_Interface_impl:own_functions(State, Arg1, ..., ArgN) -> CastReply</name> - <name>Module_Interface_impl:own_functions(This, State, Arg1, ..., ArgN) -> CastReply</name> - <fsummary>User defined function which is not a part of Orber</fsummary> - <type> - <v>This = the servers #object reference</v> - <v>State = term()</v> - <v>CastReply = {noreply, State} | {noreply, State, Timeout} | {stop, StopReason, State}</v> - <v>ArgX = specified in the IDL-code.</v> - <v>Reply = specified in the IDL-code.</v> - <v>Timeout = int() >= 0 | infinity</v> - <v>StopReason = normal | shutdown | term()</v> - </type> - <desc> - <p>All one-way functions must return one of the listed replies. - If the IC compile option <em>this</em> is used, - the implementation must accept the <em>This</em> parameter.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/Orber/InitialReference.java b/lib/orber/doc/src/Orber/InitialReference.java deleted file mode 100644 index 35a8c2437b..0000000000 --- a/lib/orber/doc/src/Orber/InitialReference.java +++ /dev/null @@ -1,131 +0,0 @@ -/* - * %CopyrightBegin% - * - * Copyright Ericsson AB 1997-2016. All Rights Reserved. - * - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - * - * %CopyrightEnd% - * - */ -/** - * InitialReference is a class which generates the INIT reference - * which can be used by the InitialReferences interface. - */ -package Orber; - -public class InitialReference -{ - - /** - * Constructor. - */ - public InitialReference(){;} - - /** - * Returns the stringified objectreference to the initial reference server - */ - public String stringified_ior(String host, int port) - { - String iorByteString; - String profileData; - String iorString; - - // byte_order followed by ' {"", [{0, ' - // char iorBytesFirstPart[] = {0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,1,0,0,0,0}; - char iorBytesFirstPart[] = {0,0,0,0,0,0,0,32,73,68,76,58,79,114,98,101,114,47,73,110,105,116,105,97,108,82,101,102,101,114,101,110,99,101,115,58,49,46,48,0,0,0,0,1,0,0,0,0}; - // the objectkey "INIT - char iorBytesLastPart[] = {0,0,0,4,73,78,73,84}; - - // Fix the ProfileData struct. - char pdPrefix[] = {0,1,0,0}; - char nullbyte[] = {0}; - profileData = new String(pdPrefix) + enc_ulong(host.length() + 1) + host + new String(nullbyte); - profileData = align(profileData, 2); - profileData += enc_ushort(port); - profileData = align(profileData, 4); - profileData += new String(iorBytesLastPart); - // Fix the whole IOR - iorByteString = new String(iorBytesFirstPart) + enc_ulong(profileData.length()) + - profileData; - - // System.out.print("Start[" + profileData.length() + "]"); - // System.out.print("["); - // for(int x = 0; x < iorByteString.length(); x++) - // { - // System.out.print((int) iorByteString.charAt(x) + ","); - // } - // System.out.println("]"); - - iorString = createIOR(iorByteString); - // System.out.println(iorString); - return iorString; - } - - - private String enc_ushort(int s) - { - char byteArray[] = {(char) ((s >>> 8) & 0xFF), - (char) ((s >>> 0) & 0xFF)}; - - return new String(byteArray); - } - - private String enc_ulong(int l) - { - char byteArray[] = {(char) ((l >>> 24) & 0xFF), - (char) ((l >>> 16) & 0xFF), - (char) ((l >>> 8) & 0xFF), - (char) ((l >>> 0) & 0xFF)}; - - return new String(byteArray); - - } - - private String createIOR(String bytes) - { - int i; - StringBuffer sb = new StringBuffer("IOR:"); - - for(i = 0; i < bytes.length(); i++) - { - int b = bytes.charAt(i); - if(b<0) b+= 256; - int n1 = b / 16; - int n2 = b % 16; - int c1 = (n1 < 10) ? ('0' + n1) : ('a' + (n1 - 10)); - int c2 = (n2 < 10) ? ('0' + n2) : ('a' + (n2 - 10)); - sb.append((char)c1); - sb.append((char)c2); - } - - return sb.toString(); - } - - private String align(String buffer, int alignment) - { - String s = buffer; - char nullbyte[] = {0}; - - int remainder = alignment - (buffer.length() % alignment); - if (remainder == alignment) return s; - - for (int i = 0; i < remainder; i++) - { - s += new String(nullbyte); - } - return s; - } - - -} diff --git a/lib/orber/doc/src/Orber/Makefile b/lib/orber/doc/src/Orber/Makefile deleted file mode 100644 index 16a3994499..0000000000 --- a/lib/orber/doc/src/Orber/Makefile +++ /dev/null @@ -1,71 +0,0 @@ -# -# %CopyrightBegin% -# -# Copyright Ericsson AB 1997-2016. All Rights Reserved. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. -# -# %CopyrightEnd% -# -# -include $(ERL_TOP)/make/target.mk - -include $(ERL_TOP)/make/$(TARGET)/otp.mk - -# ---------------------------------------------------- -# Application version -# ---------------------------------------------------- -include ../../vsn.mk -VSN=$(ORBER_VSN) - -# ---------------------------------------------------- -# Release directory specification -# ---------------------------------------------------- -RELSYSDIR = $(RELEASE_PATH)/lib/orber-$(VSN) - -# -# JAVA macros -# -JAVA_CLASSES = \ - InitialReference - -JAVA_FILES= $(JAVA_CLASSES:%=%.java) - -CLASSPATH = ../.. - -# ---------------------------------------------------- -# Flags -# ---------------------------------------------------- -JAVA_OPTIONS = - -# ---------------------------------------------------- -# Make Rules -# ---------------------------------------------------- - -debug opt: - -clean: - -docs: - -# ---------------------------------------------------- -# Release Targets -# ---------------------------------------------------- -include $(ERL_TOP)/make/otp_release_targets.mk - -release_spec: opt - $(INSTALL_DIR) $(RELSYSDIR)/java_src/Orber - $(INSTALL_DATA) $(JAVA_FILES) $(RELSYSDIR)/java_src/Orber - -release_docs_spec: - diff --git a/lib/orber/doc/src/any.xml b/lib/orber/doc/src/any.xml deleted file mode 100644 index c94a2132d8..0000000000 --- a/lib/orber/doc/src/any.xml +++ /dev/null @@ -1,114 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1998</year><year>2017</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>any</title> - <prepared></prepared> - <docno></docno> - <checked></checked> - <date>1998-04-20</date> - <rev>A</rev> - </header> - <module>any</module> - <modulesummary>the corba any type</modulesummary> - <description> - <p>This module contains functions that gives an interface to the CORBA any type.</p> - <p>Note that the <c>any</c> interface in orber does not contain a destroy - function because the any type is represented as an Erlang record and - therefor will be removed by the garbage collector when not in use.</p> - <p>The type <c>TC</c> used below describes an IDL type and is a tuple according - to the to the Erlang language mapping.</p> - <p>The type <c>Any</c> used below is defined as:</p> - <code type="erl">-record(any, {typecode, value}).</code> - <p>where <c>typecode</c> is a TC tuple and <c>value</c> is an Erlang term of - the type defined by the typecode field.</p> - </description> - <funcs> - <func> - <name>create() -> Result</name> - <name>create(Typecode, Value) -> Result</name> - <fsummary>Create an any record</fsummary> - <type> - <v>Typecode = TC</v> - <v>Value = term()</v> - <v>Result = Any</v> - </type> - <desc> - <p>The create/0 function creates an empty any record and the create/2 - function creates an initialized record.</p> - </desc> - </func> - <func> - <name>set_typecode(A, Typecode) -> Result</name> - <fsummary>Set the typecode field</fsummary> - <type> - <v>A = Any</v> - <v>Typecode = TC</v> - <v>Result = Any</v> - </type> - <desc> - <p>This function sets the typecode of <em>A</em> and returns a - new any record.</p> - </desc> - </func> - <func> - <name>get_typecode(A) -> Result</name> - <fsummary>Fetch the typecode</fsummary> - <type> - <v>A = Any</v> - <v>Result = TC</v> - </type> - <desc> - <p>This function returns the typecode of <em>A</em>.</p> - </desc> - </func> - <func> - <name>set_value(A, Value) -> Result</name> - <fsummary>Set the value field</fsummary> - <type> - <v>A = Any</v> - <v>Value = term()</v> - <v>Result = Any</v> - </type> - <desc> - <p>This function sets the value of <em>A</em> and returns a - new any record.</p> - </desc> - </func> - <func> - <name>get_value(A) -> Result</name> - <fsummary>Fetch the value</fsummary> - <type> - <v>A = Any</v> - <v>Result = term()</v> - </type> - <desc> - <p>This function returns the value of <em>A</em>. - </p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/book.xml b/lib/orber/doc/src/book.xml deleted file mode 100644 index 81bd5a8f65..0000000000 --- a/lib/orber/doc/src/book.xml +++ /dev/null @@ -1,49 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE book SYSTEM "book.dtd"> - -<book xmlns:xi="http://www.w3.org/2001/XInclude"> - <header titlestyle="normal"> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>orber</title> - <prepared></prepared> - <docno></docno> - <date>1998-04-25</date> - <rev>2.0</rev> - </header> - <insidecover> - </insidecover> - <pagetext>Orber</pagetext> - <preamble> - <contents level="2"></contents> - </preamble> - <parts lift="no"> - <xi:include href="part.xml"/> - </parts> - <applications> - <xi:include href="ref_man.xml"/> - </applications> - <releasenotes> - <xi:include href="notes.xml"/> - </releasenotes> - <listofterms></listofterms> - <index></index> -</book> - diff --git a/lib/orber/doc/src/ch_contents.xml b/lib/orber/doc/src/ch_contents.xml deleted file mode 100644 index b783e63aee..0000000000 --- a/lib/orber/doc/src/ch_contents.xml +++ /dev/null @@ -1,173 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>The Orber Application</title> - <prepared></prepared> - <docno></docno> - <date>1998-05-05</date> - <rev>B</rev> - <file>ch_contents.xml</file> - </header> - - <section> - <title>Content Overview</title> - <p>The Orber documentation is divided into three sections: - </p> - <list type="bulleted"> - <item> - <p>PART ONE - The User's Guide - <br></br> -Description of the Orber Application including IDL-to-Erlang - language mapping, services and a small tutorial demonstrating - the development of a simple service.</p> - </item> - <item> - <p>PART TWO - Release Notes - <br></br> -A concise history of Orber.</p> - </item> - <item> - <p>PART THREE - The Reference Manual - <br></br> - A quick reference guide, including a - brief description, to all the functions available in Orber.</p> - </item> - </list> - </section> - - <section> - <title>Brief Description of the User's Guide</title> - <p>The User's Guide contains the following parts:</p> - <list type="bulleted"> - <item> - <p>ORB kernel and IIOP support</p> - </item> - <item> - <p>Interface Repository</p> - </item> - <item> - <p>IDL to Erlang mapping</p> - </item> - <item> - <p>CosNaming Service</p> - </item> - <item> - <p>Resolving initial reference from Java or C++</p> - </item> - <item> - <p>Tutorial - creating a simple service </p> - </item> - <item> - <p>CORBA Exceptions </p> - </item> - <item> - <p>Interceptors</p> - </item> - <item> - <p>OrberWeb</p> - </item> - <item> - <p>Debugging - </p> - </item> - </list> - - <section> - <title>ORB Kernel and IIOP Support</title> - <p>The ORB kernel which has IIOP support will allow the creation - of persistent server objects in Erlang. These objects can also - be accessed via Erlang and Java environments. For the moment a - Java enabled ORB is needed to generate Java from IDL to use - Java server objects (this has been tested using OrbixWeb).</p> - </section> - - <section> - <title>Interface Repository</title> - <p>The IFR is an interface repository used for some type-checking - when coding/decoding IIOP. The IFR is capable of storing all - interfaces and declarations of OMG IDL.</p> - </section> - - <section> - <title>IDL to Erlang Mapping</title> - <p>The OMG IDL mapping for Erlang, which is necessary to access the - functionality of Orber, is described, The mapping structure is - included as the basic and the constructed OMG IDL types - references, invocations and Erlang characteristics. An example is - also provided.</p> - </section> - - <section> - <title>CosNaming Service</title> - <p>Orber contains a CosNaming compliant service.</p> - </section> - - <section> - <title>Resolving Initial References from Java or C++</title> - <p>A couple of classes are added to Orber to simplify initial - reference access from Java or C++. - </p> - <p><em>Resolving initial reference from Java</em> <br></br> - A class with only one method which returns an <term id="IOR"><termdef>Interoperable Object Reference</termdef></term>on the - external string format to the INIT object (see "Interoperable - Naming Service" specification).</p> - <p><em>Resolving initial reference from C++</em> <br></br> - - A class (and header file) with only one method which returns - an IOR on the external string format to the INIT object (see - "Interoperable Naming Service" specification).</p> - </section> - - <section> - <title>Orber Stub/Skeleton</title> - <p>An example which describes the API and behavior of Orber stubs and skeletons. </p> - </section> - - <section> - <title>CORBA Exceptions</title> - <p>A listing of all system exceptions supported by Orber and how one should - handle them. This chapter also describe how to generate user defined - exceptions.</p> - </section> - - <section> - <title>Interceptors</title> - <p>Descibes how to implement and activate interceptors.</p> - </section> - - <section> - <title>OrberWeb</title> - <p>Offers the possibility to administrate and supervise Orber via a GUI.</p> - </section> - - <section> - <title>Debugging</title> - <p>Describes how to use different tools when debugging and/or developing - new applications using Orber. Also includes a FAQ, which deal with - the most common mistakes when using Orber. - </p> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_debugging.xml b/lib/orber/doc/src/ch_debugging.xml deleted file mode 100644 index debac4313e..0000000000 --- a/lib/orber/doc/src/ch_debugging.xml +++ /dev/null @@ -1,210 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>2001</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Debugging</title> - <prepared></prepared> - <docno></docno> - <date>2001-11-29</date> - <rev></rev> - <file>ch_debugging.xml</file> - </header> - - <section> - <title>Tools and FAQ</title> - <p>Persons who use Orber for the first time may find it hard to tell what goes - wrong when trying to setup communication between an Orber-ORB and ORB:s supplied - by another vendor or another Orber-ORB. The purpose of this chapter is to inform - about the most common mistakes and what tools one can use to overcome these - problems. </p> - - <section> - <title>Tools</title> - <p>To begin with, Orber can be configured to run in debug mode. There are four ways - to set this parameter:</p> - <list type="bulleted"> - <item><em>erl -orber orber_debug_level 10</em> - can be added to a start-script.</item> - <item><em>corba:orb_init([{orber_debug_level, 10}])</em> - this operation must - be invoked <em>before</em> starting Orber.</item> - <item><em>orber:configure(orber_debug_level, 10)</em> - this operation can - be invoked at any time.</item> - <item><em>OrberWeb</em> - via the <c>Configuration</c> menu one can easily change - the configuration. For more information, see the OrberWeb chapter in this - User's Guide.</item> - </list> - <p>When Orber runs i debug mode, printouts will be generated if anything abnormal occurs - (not necessarily an error). An error message typically looks like:</p> - <code type="none"> -=ERROR REPORT==== 29-Nov-2001::14:09:55 === -=================== Orber ================= -[410] corba:common_create(orber_test_server, [{pseudo,truce}]); -not a boolean(truce). -=========================================== - </code> - <p>In the example above, we tried to create an object with an incorrect option (i.e. should - have been <c>{pseudo,true}</c>).</p> - <p>If you are not able to solve the problem, you should include all generated reports when - contacting support or using the erlang-questions mailing list.</p> - <p>It is easy to forget to, for example, set all fields in a struct, which - one may not discover when developing an application using Orber. When using - a typed language, such faults would cause a compile time error. To avoid - these mistakes, Orber allows the user to activate automatic typechecking - of all local invocations of CORBA Objects. For this feature to be really - useful, the user must create test suites which cover as much as - possible. For example, invoking an operation with invalid or incorrect - arguments should also be tested. This option can be activated for one object - or all object via:</p> - <list type="bulleted"> - <item><em>'MyModuyle_MyInterface':oe_create(Env, [{local_typecheck, true}])</em> - - This approach will only activate, or deactivate, typechecking for - the returned instance. Naturally, this option can also be passed - to <c>oe_create_link/2</c>, <c>corba:create/4</c> and - <c>corba:create_link/4</c>.</item> - <item><em>erl -orber flags 2</em> - can be added to a start-script. - All object invocations will be typechecked, unless overridden by the - previous option.</item> - <item><em>corba:orb_init([{flags, 16#0002}])</em> - this operation must - be invoked <em>before</em> starting Orber. Behaves as the previous - option.</item> - </list> - <p>If incorrect data is passed or returned, Orber uses the <c>error_logger</c> - to generate logs, which can look like:</p> - <code type="none"> -=ERROR REPORT==== 10-Jul-2002::12:36:09 === -========= Orber Typecheck Request ========= -Invoked......: MyModule_MyInterface:foo/1 -Typecode.....: [{tk_enum,"IDL:MyModule/enumerant:1.0", - "enumerant", - ["one","two"]}] -Arguments....: [three] -Result.......: {'EXCEPTION',{'MARSHAL',[],102,'COMPLETED_NO'}} -=========================================== - </code> - <p>Note, that the arity is equivalent to the IDL-file. In the example above, - an undefined enumerant was used. In most cases, it is useful to set the - configuration parameter <c>orber_debug_level 10</c> as well. Due to the - extra overhead, this option <em>MAY ONLY</em> be used during testing and - development. - For more information, see also - <seealso marker="ch_install#config">configuration settings</seealso>.</p> - <p>It is also possible to trace all communication between an Orber-ORB and, for example, - a Java-ORB, communicating via IIOP. All you need to do is to activate an - <seealso marker="ch_interceptors">interceptor</seealso>. Normally, the users must - implement the interceptor themselves, but for your convenience Orber includes three - pre-compiled interceptors called <c>orber_iiop_tracer</c>, - <c>orber_iiop_tracer_silent</c> and <c>orber_iiop_tracer_stealth</c>.</p> - <warning> - <p>Logging all traffic is <em>expensive</em>. Hence, only use the supplied - interceptors during test and development.</p> - </warning> - <p>The <c>orber_iiop_tracer</c> and <c>orber_iiop_tracer_silent</c> interceptors - uses the <c>error_logger</c> module to generate the logs. If the traffic - is intense you probably want to write the reports to a log-file. - This is done by, for example, invoking:</p> - <code type="erl"> -erl> error_logger:tty(false). -erl> error_logger:logfile({open, "/tmp/IIOPTrace"}). - </code> - <p>The <c>IIOPTrace</c> file will contain, if you use the <c>orber_iiop_tracer</c> - interceptor, reports which looks like:</p> - <code type="none"> -=INFO REPORT==== 13-Jul-2005::18:22:39 === -=============== new_out_connection ======= -Node : myNode@myHost -From : 192.0.0.10:47987 -To : 192.0.0.20:4001 -========================================== - -=INFO REPORT==== 29-Nov-2001::15:26:28 === -=============== out_request ============== -Connection: {"192.0.0.20",4001,"192.0.0.10",47987} -Operation : resolve -Parameters: [[{'CosNaming_NameComponent', - "AIK","SwedishIcehockeyChampions"}]] -Context : [{'IOP_ServiceContext',1, - {'CONV_FRAME_CodeSetContext',65537,65801}}] -========================================== - </code> - <p>The <c>orber_iiop_tracer_silent</c> will not log GIOP encoded data. To activate - one the interceptors, you have two options:</p> - <list type="bulleted"> - <item><em>erl -orber interceptors "{native,[orber_iiop_tracer]}"</em> - can be added to a start-script.</item> - <item><em>corba:orb_init([{interceptors, {native, [orber_iiop_tracer_silent]}}])</em> - this operation must - be invoked <em>before</em> starting Orber.</item> - </list> - <p>It is also possible to active and deactivate an interceptor during - run-time, but this will only affect currently existing connections. - For more information, consult Orber's Reference Manual regarding the - operations <c>orber:activate_audit_trail/0/1</c> and - <c>orber:activate_audit_trail/0/1.</c></p> - </section> - - <section> - <title>FAQ</title> - <p><em>Q: When my client, typically written in C++ or Java, invoke narrow on an Orber object reference it fails?</em></p> - <p>A: You must register your application in the IFR by invoking <c>oe_register()</c>. - If the object was created by a COS-application, you must run install - (e.g. <c>cosEventApp:install()</c>).</p> - <p>A: Confirm, by consulting the IDL specifications, that the received object reference really - inherit from the interface you are trying to narrow it to.</p> - <br></br> - <p><em>Q: I am trying to register my application in the IFR but it fails. Why?</em></p> - <p>A: If one, or more, interface in your IDL-specification inherits from - other interface(s), you must register them before registering your - application. Note, this also apply when you inherit interfaces - supported by a COS-application. Hence, they must be installed prior to - registration of your application.</p> - <br></br> - <p><em>Q: I have a Orber client and server residing on two different Orber instances but I only get the 'OBJECT_NOT_EXIST' exception, even though I am sure that the object is still alive?</em></p> - <p>A: If the two Orber-ORB's are not intended to be a part of multi-node ORB, make sure that the - two Orber-ORB's have different <em>domain</em> names set (see - <seealso marker="ch_install#config">configuration settings</seealso>). The easiest way - to confirm this is to invoke <c>orber:info()</c> on each node.</p> - <br></br> - <p><em>Q: When I'm trying to install and/or start Orber it fails?</em></p> - <p>A: Make sure that no other Orber-ORB is already running on the same node. If so, - change the <c>iiop_port</c> configuration parameter (see - <seealso marker="ch_install#config">configuration settings</seealso>).</p> - <br></br> - <p><em>Q: My Orber server is invoked via IIOP but Orber cannot marshal the reply?</em></p> - <p>A: Consult your IDL file to confirm that your replies are of the correct - type. If it is correct and the return type is, for example, - a struct, make sure you have set every field in the struct. If - you do not do that it will be set to the atom 'undefined', which - most certainly is not correct.</p> - <br></br> - <p>A: Check that you handle <c>inout</c> and <c>out</c> parameters correctly - (see the IDL specification). For example, a function which have one - out-parameter and should return void, then your call-back module - should return <c>{reply, {ok, OutParam}, State}</c>. Note, even though - the return value is void (IDL) you must reply with ok.</p> - <br></br> - <p><em>Q: I cannot run Orber as a multi-node ORB?</em></p> - <p>A: Make sure that the Erlang distribution have been started for each - node and the <c>cookies</c> are correct. For more information, - consult the <c>System Documentation</c></p> - <br></br> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_exceptions.xml b/lib/orber/doc/src/ch_exceptions.xml deleted file mode 100644 index 17657d0d4a..0000000000 --- a/lib/orber/doc/src/ch_exceptions.xml +++ /dev/null @@ -1,238 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>2001</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>CORBA System and User Defined Exceptions</title> - <prepared></prepared> - <docno></docno> - <date>2000-12-19</date> - <rev></rev> - <file>ch_exceptions.xml</file> - </header> - - <section> - <title>System Exceptions</title> - <p><c>Orber</c>, or any other <c>ORB</c>, may raise a <c>System Exceptions</c>. - These exceptions contain status- and minor-fields and may not appear in the - operations raises exception IDL-definition.</p> - - <section> - <title>Status Field</title> - <p>The status field indicates if the request was completed or not and will be - assigned one of the following Erlang atoms:</p> - <table> - <row> - <cell align="center" valign="middle"><em>Status</em></cell> - <cell align="center" valign="middle"><em>Description</em></cell> - </row> - <row> - <cell align="left" valign="middle">'COMPLETED_YES'</cell> - <cell align="left" valign="middle">The operation was invoked on the target object but an error occurred after the object replied. This occur, for example, if a server replies but Orber is not able to marshal and send the reply to the client ORB.</cell> - </row> - <row> - <cell align="left" valign="middle">'COMPLETED_NO'</cell> - <cell align="left" valign="middle">Orber failed to invoke the operation on the target object. This occur, for example, if the object no longer exists.</cell> - </row> - <row> - <cell align="left" valign="middle">'COMPLETED_MAYBE'</cell> - <cell align="left" valign="middle">Orber invoked the operation on the target object but an error occurred and it is impossible to decide if the request really reached the object or not.</cell> - </row> - <tcaption>System Exceptions Status</tcaption> - </table> - </section> - - <section> - <title>Minor Field</title> - <p>The minor field contains an integer (VMCID), which is related to a more - specific reason why an invocation failed. The function - <c>orber:exception_info/1</c> can be used to map the minor code to a string. - Note, for VMCID:s not assigned by the OMG or Orber, the documentation - for that particular ORB must be consulted.</p> - </section> - - <section> - <title>Supported System Exceptions</title> - <p>The OMG CORBA specification defines the following exceptions:</p> - <list type="bulleted"> - <item><em>'BAD_CONTEXT'</em> - if a request does not contain a correct - context this exception is raised.</item> - <item><em>'BAD_INV_ORDER'</em> - this exception indicates that operations - has been invoked operations in the wrong order, which would cause, - for example, a dead-lock.</item> - <item><em>'BAD_OPERATION'</em> - raised if the target object exists, but - that the invoked operation is not supported.</item> - <item><em>'BAD_PARAM'</em> - is thrown if, for example, a parameter is out - of range or otherwise considered illegal.</item> - <item><em>'BAD_TYPECODE'</em> - if illegal type code is passed, for example, - encapsulated in an any data type the <c>'BAD_TYPECODE'</c> exception - will be raised.</item> - <item><em>'BAD_QOS'</em> - raised whenever an object cannot support the - required quality of service.</item> - <item><em>'CODESET_INCOMPATIBLE'</em> - raised if two ORB's cannot - communicate due to different representation of, for example, - <c>char</c> and/or <c>wchar</c>.</item> - <item><em>'COMM_FAILURE'</em> - raised if an ORB is unable to setup - communication or it is lost while an operation is in progress.</item> - <item><em>'DATA_CONVERSION'</em> - raised if an ORB cannot convert data - received to the native representation. See also the - <c>'CODESET_INCOMPATIBLE'</c> exception.</item> - <item><em>'FREE_MEM'</em> - the ORB failed to free dynamic memory and - failed.</item> - <item><em>'IMP_LIMIT'</em> - an implementation limit was exceeded in the - ORB at run time. A object factory may, for example, limit the - number of object clients are allowed to create.</item> - <item><em>'INTERNAL'</em> - an internal failure occurred in an ORB, which - is unrecognized. You may consider contacting the ORB providers - support.</item> - <item><em>'INTF_REPOS'</em> - the ORB was not able to reach the interface - repository, or some other failure relating to the interface - repository is detected.</item> - <item><em>'INITIALIZE'</em> - the ORB initialization failed due to, for - example, network or configuration error.</item> - <item><em>'INVALID_TRANSACTION'</em> - is raised if the request carried an - invalid transaction context.</item> - <item><em>'INV_FLAG'</em> - an invalid flag was passed to an operation, - which caused, for example, a connection to be closed.</item> - <item><em>'INV_IDENT'</em> - this exception indicates that an IDL - identifier is incorrect.</item> - <item><em>'INV_OBJREF'</em> - this exception is raised if an object - reference is malformed or a nil reference (see - also corba:create_nil_objref/0).</item> - <item><em>'INV_POLICY'</em> - the invocation cannot be made due to an - incompatibility between policy overrides that apply to the - particular invocation.</item> - <item><em>'MARSHAL'</em> - this exception may be raised by the client- or - server-side when either ORB is unable to marshal/unmarshal requests or - replies.</item> - <item><em>'NO_IMPLEMENT'</em> - if the operation exists but no implementation - exists, this exception is raised.</item> - <item><em>'NO_MEMORY'</em> - the ORB has run out of memory.</item> - <item><em>'NO_PERMISSION'</em> - the caller has insufficient privileges, - such as, for example, bad <c>SSL</c> certificate.</item> - <item><em>'NO_RESOURCES'</em> - a general platform resource limit - exceeded.</item> - <item><em>'NO_RESPONSE'</em> - no response available of a deferred - synchronous request.</item> - <item><em>'OBJ_ADAPTER'</em> - indicates administrative mismatch; the object - adapter is not able to associate an object with the implementation - repository.</item> - <item><em>'OBJECT_NOT_EXIST'</em> - the object have been disposed or - terminated; clients should remove all copies of the object reference - and initiate desired recovery process.</item> - <item><em>'PERSIST_STORE'</em> - the ORB was not able to establish a - connection to its persistent storage or data contained in the - the storage is corrupted.</item> - <item><em>'REBIND'</em> - a request resulted in, for example, a - <c>'LOCATION_FORWARD'</c> message; if the policies are incompatible - this exception is raised.</item> - <item><em>'TIMEOUT'</em> - raised if a request fail to complete within the - given time-limit.</item> - <item><em>'TRANSACTION_MODE'</em> - a transaction policy mismatch detected.</item> - <item><em>'TRANSACTION_REQUIRED'</em> - a transaction is required for the - invoked operation but the request contained no transaction context.</item> - <item><em>'TRANSACTION_ROLLEDBACK'</em> - the transaction associated with - the request has already been rolled back or will be.</item> - <item><em>'TRANSACTION_UNAVAILABLE'</em> - no transaction context can be - supplied since the ORB is unable to contact the Transaction - Service.</item> - <item><em>'TRANSIENT'</em> - the ORB could not determine the current status - of an object since it could not be reached. The error may be - temporary.</item> - <item><em>'UNKNOWN'</em> - is thrown if an implementation throws a - non-CORBA, or unrecognized, exception.</item> - </list> - </section> - </section> - - <section> - <title>User Defined Exceptions</title> - <p>User exceptions is defined in IDL-files and is listed in operations raises - exception listing. For example, if we have the following IDL code:</p> - <code type="none"> -module MyModule { - - exception MyException {}; - exception MyExceptionMsg { string ExtraInfo; }; - - interface MyInterface { - - void foo() - raises(MyException); - - void bar() - raises(MyException, MyExceptionMsg); - - void baz(); - }; -}; - </code> - </section> - - <section> - <title>Throwing Exceptions</title> - <p>To be able to raise <c>MyException</c> or <c>MyExceptionMsg</c> exceptions, - the generated <c>MyModule.hrl</c> must be included, and typical usage is:</p> - <code type="erl"> --module('MyModule_MyInterface_impl'). --include("MyModule.hrl"). - -bar(State) -> - case TestingSomething of - ok -> - {reply, ok, State}; - {error, Reason} when list(Reason) -> - corba:raise(#'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason}); - error -> - corba:raise(#'MyModule_MyException'{}) - end. - </code> - </section> - - <section> - <title>Catching Exceptions</title> - <p>Depending on which operation we invoke we must be able to handle:</p> - <list type="bulleted"> - <item>foo - <c>MyException</c> or a system exception.</item> - <item>bar - <c>MyException</c>, <c>MyExceptionMsg</c> or a system - exception.</item> - <item>baz - a system exception.</item> - </list> - <p>Catching and matching exceptions can bee done in different ways:</p> - <code type="none"> - case catch 'MyModule_MyInterface':bar(MIReference) of - ok -> - %% The operation raised no exception. - ok; - {'EXCEPTION', #'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason}} -> - %% If we want to log the Reason we must extract 'ExtraInfo'. - error_logger:error_msg("Operation 'bar' raised: ~p~n", [Reason]), - ... do something ...; - {'EXCEPTION', E} when record(E, 'OBJECT_NOT_EXIST') -> - ... do something ...; - {'EXCEPTION', E} -> - ... do something ... - end. - </code> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml b/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml deleted file mode 100644 index eaa88f24f1..0000000000 --- a/lib/orber/doc/src/ch_idl_to_erlang_mapping.xml +++ /dev/null @@ -1,1504 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>OMG IDL to Erlang Mapping</title> - <prepared></prepared> - <docno></docno> - <date>1998-10-10</date> - <rev></rev> - <file>ch_idl_to_erlang_mapping.xml</file> - </header> - - <section> - <title>OMG IDL to Erlang Mapping - Overview</title> - <p>The purpose of OMG IDL, <em>Interface Definition Language</em>, mapping - is to act as translator between platforms and languages. An IDL - specification is supposed to describe data types, object types etc.</p> - <p>CORBA is independent of the programming language used to construct - clients or implementations. In order to use the ORB, it is - necessary for programmers to know how to access ORB functionality - from their programming languages. It translates different IDL constructs - to a specific programming language. This chapter - describes the mapping of OMG IDL constructs to the Erlang programming - language.</p> - </section> - - <section> - <title>OMG IDL Mapping Elements</title> - <p>A complete language mapping will allow the programmer to have - access to all ORB functionality in a way that is convenient for - a specified programming language. - </p> - <p>All mapping must define the following elements: - </p> - <list type="bulleted"> - <item>All OMG IDL basic and constructed types</item> - <item>References to constants defined in OMG IDL</item> - <item>References to objects defined in OMG IDL</item> - <item>Invocations of operations, including passing of - parameters and receiving of results</item> - <item>Exceptions, including what happens when an operation - raises an exception and how the exception parameters are - accessed</item> - <item>Access to attributes</item> - <item>Signatures for operations defined by the ORB, such as - dynamic invocation interface, the object adapters etc.</item> - <item>Scopes; - OMG IDL has several levels of scopes, which are mapped to Erlang's - two scopes.</item> - </list> - </section> - - <section> - <title>Getting Started</title> - <p>To begin with, we should decide which type of objects (i.e. servers) we - need and if two, or more, should export the same functionality. Let us - assume that we want to create a system for DB (database) access for different - kind of users. For example, anyone with a valid password may extract - data, but only a few may update the DB. Usually, an application - is defined within a <c>module</c>, and all global datatypes are defined - on the top-level. To begin with we create a module and the interfaces we - need:</p> - <code type="none"> -// DB IDL -#ifndef _DB_IDL_ -#define _DB_IDL_ -// A module is simply a container -module DB { - - // An interface maps to a CORBA::Object. - interface CommonUser { - - }; - - // Inherit the Consumer interface - interface Administrator : CommonUser { - - }; - - interface Access { - - }; - -}; -#endif </code> - <p>Since the <c>Administrator</c> should be able to do the same things as the - <c>CommonUser</c>, the previous inherits from the latter. The <c>Access</c> - interface will grant access to the DB. - Now we are ready to define the functionality and data types we need. But, this - requires that we know a little bit more about the OMG IDL.</p> - <note> - <p>The OMG defines a set of reserved case insensitive key-words, which may - <em>NOT</em> be used as identifiers (e.g. module name). For more - information, see - <seealso marker="#key_words">Reserved Compiler Names and Keywords</seealso></p> - </note> - </section> - - <section> - <title>Basic OMG IDL Types</title> - <p>The OMG IDL mapping is strongly typed and, even if you have a good knowledge - of CORBA types, it is essential to read carefully the following mapping to - Erlang types.</p> - <p>The mapping of basic types is straightforward. Note that the - OMG IDL double type is mapped to an Erlang float which does not - support the full double value range.</p> - <table> - <row> - <cell align="left" valign="middle">OMG IDL type</cell> - <cell align="left" valign="middle">Erlang type</cell> - <cell align="left" valign="middle">Note</cell> - </row> - <row> - <cell align="left" valign="middle">float</cell> - <cell align="left" valign="middle">Erlang float</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">double</cell> - <cell align="left" valign="middle">Erlang float</cell> - <cell align="left" valign="middle">value range not supported</cell> - </row> - <row> - <cell align="left" valign="middle">short</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">-2^15 .. 2^15-1</cell> - </row> - <row> - <cell align="left" valign="middle">unsigned short</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">0 .. 2^16-1</cell> - </row> - <row> - <cell align="left" valign="middle">long</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">-2^31 .. 2^31-1</cell> - </row> - <row> - <cell align="left" valign="middle">unsigned long</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">0 .. 2^32-1</cell> - </row> - <row> - <cell align="left" valign="middle">long long</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">-2^63 .. 2^63-1</cell> - </row> - <row> - <cell align="left" valign="middle">unsigned long long</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">0 .. 2^64-1</cell> - </row> - <row> - <cell align="left" valign="middle">char</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">ISO-8859-1</cell> - </row> - <row> - <cell align="left" valign="middle">wchar</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle">UTF-16 (ISO-10646-1:1993)</cell> - </row> - <row> - <cell align="left" valign="middle">boolean</cell> - <cell align="left" valign="middle">Erlang atom</cell> - <cell align="left" valign="middle">true/false</cell> - </row> - <row> - <cell align="left" valign="middle">octet</cell> - <cell align="left" valign="middle">Erlang integer</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">any</cell> - <cell align="left" valign="middle">Erlang record</cell> - <cell align="left" valign="middle">#any{typecode, value}</cell> - </row> - <row> - <cell align="left" valign="middle">long double</cell> - <cell align="left" valign="middle">Not supported</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">Object</cell> - <cell align="left" valign="middle">Orber object reference</cell> - <cell align="left" valign="middle">Internal Representation</cell> - </row> - <row> - <cell align="left" valign="middle">void</cell> - <cell align="left" valign="middle">Erlang atom</cell> - <cell align="left" valign="middle">ok</cell> - </row> - <tcaption>OMG IDL basic types</tcaption> - </table> - <p>The <c>any</c> value is written as a record with the field typecode which - contains the <term id="Type Code"><termdef>Type Code is a full definition of a type </termdef></term>representation, - <seealso marker="#tk_values">see also the Type Code table</seealso>, - and the value field itself.</p> - <p>Functions with return type <c>void</c> will return the atom <c>ok</c>.</p> - </section> - - <section> - <title>Template OMG IDL Types and Complex Declarators</title> - <p>Constructed types all have native mappings as shown in the table - below.</p> - <table> - <row> - <cell align="left" valign="middle"><em>Type</em></cell> - <cell align="left" valign="middle"><em>IDL code</em></cell> - <cell align="left" valign="middle"><em>Maps to</em></cell> - <cell align="left" valign="middle"><em>Erlang code</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>string</em></cell> - <cell align="left" valign="middle">typedef string S; <br></br> -void op(in S a);</cell> - <cell align="left" valign="middle">Erlang string</cell> - <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>wstring</em></cell> - <cell align="left" valign="middle">typedef wstring S; <br></br> -void op(in S a);</cell> - <cell align="left" valign="middle">Erlang list of Integers</cell> - <cell align="left" valign="middle">ok = op(Obj, "Hello World"),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>sequence</em></cell> - <cell align="left" valign="middle">typedef sequence <long, 3> S; <br></br> -void op(in S a);</cell> - <cell align="left" valign="middle">Erlang list</cell> - <cell align="left" valign="middle">ok = op(Obj, [1, 2, 3]),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>array</em></cell> - <cell align="left" valign="middle">typedef string S[2]; <br></br> -void op(in S a);</cell> - <cell align="left" valign="middle">Erlang tuple</cell> - <cell align="left" valign="middle">ok = op(Obj, {"one", "two"}),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>fixed</em></cell> - <cell align="left" valign="middle">typedef fixed<3,2> myFixed; <br></br> -void op(in myFixed a);</cell> - <cell align="left" valign="middle">Erlang tuple</cell> - <cell align="left" valign="middle">MF = fixed:create(3, 2, 314), <br></br> -ok = op(Obj, MF),</cell> - </row> - <tcaption>OMG IDL Template and Complex Declarators</tcaption> - </table> - - <section> - <title>String/WString Data Types</title> - <p>A <c>string</c> consists of all possible 8-bit quantities except null. - Most ORB:s uses, including Orber, the character set Latin-1 (ISO-8859-1). - The <c>wstring</c> type is represented as a list of integers, where - each integer represents a wide character. In this case Orber uses, as - most other ORB:s, the UTF-16 (ISO-10646-1:1993) character set.</p> - <p>When defining a a string or wstring they can be of limited length or - null terminated:</p> - <code type="none"><![CDATA[ -// Null terminated -typedef string myString; -typedef wstring myWString; -// Maximum length 10 -typedef string<10> myString10; -typedef wstring<10> myWString10; - ]]></code> - <p>If we want to define a char/string or wchar/wstring constant, we can - use octal (\OOO - one, two or three octal digits), - hexadecimal (\xHH - one or two hexadecimal digits) and unicode (\uHHHH - - one, two, three or four hexadecimal digits.) representation as well. - For example:</p> - <code type="none"> -const string SwedensBestSoccerTeam = "\101" "\x49" "\u004B"; -const wstring SwedensBestHockeyTeam = L"\101\x49\u004B"; -const char aChar = '\u004B'; -const wchar aWchar = L'\u004C'; - </code> - <p>Naturally, we can use <c>"Erlang"</c>, <c>L"Rocks"</c>, <c>'A'</c> - and <c>L'A'</c> as well.</p> - </section> - - <section> - <title>Sequence Data Type</title> - <p>A sequence can be defined to be of a maximum length or unbounded, and may - contain Basic and Template types and scoped names:</p> - <code type="none"><![CDATA[ -typedef sequence <short, 1> aShortSequence; -typedef sequence <long> aLongSequence; -typedef sequence <aLongSequence> anEvenLongerSequence; - ]]></code> - </section> - - <section> - <title>Array Data Type</title> - <p>Arrays are multidimensional, fixed-size arrays. The indices is language - mapping specific, which is why one should not pass them as arguments - to another ORB.</p> - <code type="none"> -typedef long myMatrix[2][3]; - </code> - </section> - - <section> - <title>Fixed Data Type</title> - <p>A Fixed Point literal consists of an integer part (decimal digits), - decimal point and a fraction part (decimal digits), - followed by a <c>D</c> or <c>d</c>. Either the integer part or the - fraction part may be missing; the decimal point may be missing, - but not d/D. The integer part must be a positive integer less than 32. - The Fraction part must be a positive integer less than or equal to - the Integer part.</p> - <code type="none"> -const fixed myFixed1 = 3.14D; -const fixed myFixed2 = .14D; -const fixed myFixed3 = 0.14D; -const fixed myFixed4 = 3.D; -const fixed myFixed5 = 3D; - </code> - <p>It is also possible to use unary (+-) and binary (+-*/) operators:</p> - <code type="none"> -const fixed myFixed6 = 3D + 0.14D; -const fixed myFixed7 = -3.14D; - </code> - <p>The Fixed Point examples above are, so called, <em>anonymous</em> - definitions. In later CORBA specifications these have been deprecated - as function parameters or return values. Hence, we strongly recommend that - you do not use them. Instead, you should use:</p> - <code type="none"><![CDATA[ -typedef fixed<5,3> myFixed53; -const myFixed53 myFixed53constant = 03.140d; -typedef fixed<3,2> myFixed32; -const myFixed32 myFixed32constant = 3.14d; - -myFixed53 foo(in myFixed32 MF); // OK -void bar(in fixed<5,3> MF); // Illegal - ]]></code> - </section> - <p>For more information, see <seealso marker="fixed">Fixed</seealso> in - Orber's Reference Manual.</p> - <p>Now we continue to work on our IDL specification. To begin with, we want - to limit the size of the logon parameters (Id and password). Since the - <c>UserID</c> and <c>Password</c> parameters, only will be used when - invoking operations on the <c>Access</c> interface, we may choose to define - them within the scope that interface. To keep it simple our DB will contain - employee information. Hence, as the DB key we choose an integer - (<c>EmployeeNo</c>).</p> - <code type="none"><![CDATA[ -// DB IDL -#ifndef _DB_IDL_ -#define _DB_IDL_ -module DB { - - typedef unsigned long EmployeeNo; - - interface CommonUser { - - any lookup(in EmployeeNo ENo); - - }; - - interface Administrator : CommonUser { - - void delete(in EmployeeNo ENo); - - }; - - interface Access { - - typedef string<10> UserID; - typedef string<10> Password; - - CommonUser logon(in UserID ID, in Password PW); - - }; - -}; -#endif ]]></code> - <p>But what should, for example, the <c>lookup</c> operation return? One option - is to use the <c>any</c> data type. But, depending on what kind of data it - encapsulates, this datatype can be rather expensive to use. We might find a - solution to our problems among the <c>Constructed</c> IDL types.</p> - </section> - - <section> - <title>Constructed OMG IDL Types</title> - <p>Constructed types all have native mappings as shown in the table - below.</p> - <table> - <row> - <cell align="left" valign="middle"><em>Type</em></cell> - <cell align="left" valign="middle"><em>IDL code</em></cell> - <cell align="left" valign="middle"><em>Maps to</em></cell> - <cell align="left" valign="middle"><em>Erlang code</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>struct</em></cell> - <cell align="left" valign="middle">struct myStruct { <br></br> -long a; <br></br> -short b; <br></br> -}; <br></br> -void op(in myStruct a);</cell> - <cell align="left" valign="middle">Erlang record</cell> - <cell align="left" valign="middle">ok = op(Obj, #'myStruct'{a=300, b=127}),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>union</em></cell> - <cell align="left" valign="middle">union myUnion switch(long) { <br></br> -case 1: long a; <br></br> -}; <br></br> -void op(in myUnion a);</cell> - <cell align="left" valign="middle">Erlang record</cell> - <cell align="left" valign="middle">ok = op(Obj, #'myUnion'{label=1, value=66}),</cell> - </row> - <row> - <cell align="left" valign="middle"><em>enum</em></cell> - <cell align="left" valign="middle">enum myEnum {one, two}; <br></br> -void op(in myEnum a);</cell> - <cell align="left" valign="middle">Erlang atom</cell> - <cell align="left" valign="middle">ok = op(Obj, one),</cell> - </row> - <tcaption>OMG IDL constructed types</tcaption> - </table> - - <section> - <title>Struct Data Type</title> - <p>A <c>struct</c> may have Basic, Template, Scoped Names and Constructed - types as members. By using forward declaration we can define a recursive struct:</p> - <code type="none"><![CDATA[ -struct myStruct; // Forward declaration -typedef sequence<myStruct> myStructSeq; -struct myStruct { - myStructSeq chain; -}; - -// Deprecated definition (anonymous) not supported by IC -struct myStruct { - sequence<myStruct> chain; -}; - ]]></code> - </section> - - <section> - <title>Enum Data Type</title> - <p>The maximum number of identifiers which may defined in an enumeration - is 2³². The order in which the identifiers are named in the - specification of an enumeration defines the relative order of the - identifiers.</p> - </section> - - <section> - <title>Union Data Type</title> - <p>A <c>union</c> may consist of:</p> - <list type="bulleted"> - <item>Identifier</item> - <item>Switch - may be an integer, char, boolean, enum or scoped name.</item> - <item>Body - with or without a <c>default</c> case; may appear at - most once.</item> - </list> - <p>A case label must match the defined type of the discriminator, and may only - contain a default case if the values given in the non-default labels do - not cover the entire range of the union's discriminant type. For example:</p> - <code type="none"> -// Illegal default; all cases covered by -// non-default cases. -union BooleanUnion switch(boolean) { - case TRUE: long TrueValue; - case FALSE: long FalseValue; - default: long DefaultValue; -}; -// OK -union BooleanUnion2 switch(boolean) { - case TRUE: long TrueValue; - default: long DefaultValue; -}; - </code> - <p>It is not necessary to list all possible values of the union discriminator - in the body. Hence, the value of a union is the value of the discriminator - and, in given order, one of the following:</p> - <list type="ordered"> - <item>If the discriminator match a label, explicitly listed in a - case statement, the value must be of the same type.</item> - <item>If the union contains a default label, the value must match the - type of the default label.</item> - <item>No value. Orber then inserts the Erlang atom <c>undefined</c> - in the value field when receiving a union from an external - ORB.</item> - </list> - <p>The above can be summed up to:</p> - <code type="none"> -// If the discriminator equals 1 or 2 the value -// is a long. Otherwise, the atom undefined. -union LongUnion switch(long) { - case 1: - case 2: long TrueValue; -}; -// If the discriminator equals 1 or 2 the value -// is a long. Otherwise, a boolean. -union LongUnion2 switch(long) { - case 1: - case 2: long TrueValue; - default: boolean DefaultValue; -}; - </code> - <p>In the same way as structs, unions can be recursive if forward - declaration is used (anonymous types is deprecated and not supported):</p> - <code type="none"><![CDATA[ -// Forward declaration -union myUnion; -typedef sequence<myUnion>myUnionSeq; -union myUnion switch (long) { - case 1 : myUnionSeq chain; - default: boolean DefaultValue; -}; - ]]></code> - - <note> - <p>Recursive types (union and struct) require Light IFR. I.e. the - IC option {light_ifr, true} is used and that Orber is configured in such a way that - Light IFR is activated. Recursive TypeCode is currently not supported, which is - why these cannot be encapsulated in an any data type.</p> - </note> - - </section> - <warning> - <p>Every field in, for example, a struct must be initiated. Otherwise - it will be set to the atom <c>undefined</c>, which Orber cannot - encode when communicating via IIOP. In the example above, invoking - the operation with #'myStruct'{a=300} will fail (equal to - #'myStruct'{a=300, b=undefined})</p> - </warning> - <p>Now we can continue to work on our IDL specification. To begin with, we should - determine the return value of the <c>lookup</c> operation. Since the <c>any</c> - type can be rather expensive we can use a <c>struct</c> or a <c>union</c> instead. - If we intend to return the same information about a employee every time we can - use a struct. Let us assume that the DB contains the name, address, employee - number and department.</p> - <code type="none"><![CDATA[ -// DB IDL -#ifndef _DB_IDL_ -#define _DB_IDL_ -module DB { - - typedef unsigned long EmployeeNo; - - enum Department {Department1, Department2}; - - struct employee { - EmployeeNo No; - string Name; - string Address; - Department Dpt; - }; - - typedef employee EmployeeData; - - interface CommonUser { - - EmployeeData lookup(in EmployeeNo ENo); - - }; - - interface Administrator : CommonUser { - - void delete(in EmployeeNo ENo); - - }; - - interface Access { - - typedef string<10> UserID; - typedef string<10> Password; - - // Since Administrator inherits from CommonUser - // the returned Object can be of either type. - CommonUser logon(in UserID ID, in Password PW); - - }; - -}; -#endif ]]></code> - <p>We can also define exceptions (i.e. not system exception) thrown by - each interface. Since exceptions are thoroughly described in the chapter - <seealso marker="ch_exceptions">System and User Defined Exceptions</seealso>, - we choose not to. Hence, we are now ready to compile our IDL-file by - invoking:</p> - <pre> -$ <input>erlc DB.idl</input> - </pre> - <p>or:</p> - <pre> -$ <input>erl</input> -Erlang (BEAM) emulator version 5.1.1 [threads:0] - -Eshell V5.1.1 (abort with ^G) -1> <input>ic:gen('DB').</input> -ok -2> <input>halt().</input> - </pre> - <p>The next step is to implement our servers. But, to be able to do that, - we need to know how we can access data type definitions. For example, - since a struct is mapped to an Erlang record we must include an hrl-file - in our callback module.</p> - </section> - - <section> - <title>Scoped Names and Generated Files</title> - - <section> - <title>Scoped Names</title> - <p>Within a scope all identifiers must be unique. The following kinds of - definitions form scopes in the OMG IDL:</p> - <list type="bulleted"> - <item><em>module</em></item> - <item><em>interface</em></item> - <item><em>operation</em></item> - <item><em>valuetype</em></item> - <item><em>struct</em></item> - <item><em>union</em></item> - <item><em>exception</em></item> - </list> - <p>For example, since enumerants do not form a scope, the following IDL code - is not valid:</p> - <code type="none"> -module MyModule { - // 'two' is not unique - enum MyEnum {one, two}; - enum MyOtherEnum {two, three}; -}; - </code> - <p>But, since Erlang only has two levels of scope, <em>module</em> and - <em>function</em>, the OMG IDL scope is mapped as follows:</p> - <list type="bulleted"> - <item><em>Function Scope</em> - used for constants, operations and attributes.</item> - <item><em>Erlang Module Scope</em> - the Erlang module scope - handles the remaining OMG IDL scopes.</item> - </list> - <p>An Erlang module, corresponding to an IDL global name, is derived by - converting occurrences of "::" to underscore, and eliminating - the leading "::". Hence, accessing <c>MyEnum</c> from another module, one - use <c>MyModule::MyEnum</c></p> - <p>For example, an operation <c>foo</c> defined in interface <c>I</c>, which - is defined in module <c>M</c>, would be written in IDL as <c>M::I::foo</c> - and as <c>'M_I':foo</c> in Erlang - <c>foo</c> is the function - name and <c>'M_I'</c> is the name of the Erlang module. Applying this - knowledge to a stripped version of the DB.idl gives:</p> - <code type="none"><![CDATA[ -// DB IDL -#ifndef _DB_IDL_ -#define _DB_IDL_ -// ++ topmost scope ++ -// IC generates oe_XX.erl and oe_XX.hrl. -// XX is equal to the name of the IDL-file. -// Tips: create one IDL-file for each top module -// and give the file the same name (DB.idl). -// The oe_XX.erl module is used to register data -// in the IFR. -module DB { - - // ++ Module scope ++ - // To access 'EmployeeNo' from another scope, use: - // DB::EmployeeNo, DB::Access etc. - typedef unsigned long EmployeeNo; - - enum Department {Department1, Department2}; - - // Definitions of this struct is contained in: - // DB.hrl - // Access functions exported by: - // DB_employee.erl - struct employee { - ... CUT ... - }; - - typedef employee EmployeeData; - - ... CUT ... - - // If this interface should inherit an interface - // in another module (e.g. OtherModule) use: - // interface Access : OtherModule::OtherInterface - interface Access { - - // ++ interface scope ++ - // Types within this scope is accessible via: - // DB::Access::UserID - // The Stub/Skeleton for this interface is - // placed in the module: - // DB_Access.erl - typedef string<10> UserID; - typedef string<10> Password; - - // Since Administrator inherits from CommonUser - // the returned Object can be of either type. - // This operation is exported from: - // DB_Access.erl - CommonUser logon(in UserID ID, in Password PW); - - }; - -}; -#endif ]]></code> - <p>Using underscores in IDL names can lead to ambiguities - due to the name mapping described above. It is advisable to - avoid the use of underscores in identifiers. For example, the following - definition would generate two structures named <c>x_y_z</c>.</p> - <code type="none"> -module x { - - struct y_z { - ... - }; - - interface y { - - struct z { - ... - }; - }; -}; - </code> - </section> - - <section> - <title>Generated Files</title> - <p>Several files can be generated for each scope.</p> - <list type="bulleted"> - <item>An Erlang source code file (<c>.erl</c>) is generated - for top level scope as well as the Erlang header file.</item> - <item>An Erlang header file (<c>.hrl</c>) will be generated for - each scope. The header file will contain record definitions - for all <c>struct</c>, <c>union</c> and <c>exception</c> - types in that scope.</item> - <item>Modules that contain at least one constant definition, - will produce Erlang source code files (<c>.erl</c>). - That Erlang file will contain constant functions for - that scope. - Modules that contain no constant definitions are considered - empty and no code will be produced for them, but only for - their included modules/interfaces.</item> - <item>Interfaces will produce Erlang source code files (<c>.erl</c>), - this code will contain all operation stub code and implementation - functions.</item> - <item>In addition to the scope-related files, an Erlang source file will - be generated for each definition of the types <c>struct</c>, - <c>union</c> and <c>exception</c> (these are the types that - will be represented in Erlang as records). - This file will contain special access functions for that record.</item> - <item>The top level scope will produce two files, one header file - (<c>.hrl</c>) and one Erlang source file (<c>.erl</c>). - These files are named as the IDL file, prefixed with <c>oe_</c>.</item> - </list> - <p>After compiling DB.idl, the following files have been generated:</p> - <list type="bulleted"> - <item><c>oe_DB.hrl</c> and <c>oe_DB.erl</c> for the top scope level.</item> - <item><c>DB.hrl</c> for the module <c>DB</c>.</item> - <item><c>DB_Access.hrl</c> and <c>DB_Access.erl</c> for the interface - <c>DB_Access</c>.</item> - <item><c>DB_CommonUser.hrl</c> and <c>DB_CommonUser.erl</c> for the interface - <c>DB_CommonUser</c>.</item> - <item><c>DB_Administrator.hrl</c> and <c>DB_Administrator.erl</c> for the interface - <c>DB_Administrator</c>.</item> - <item><c>DB_employee.erl</c> for the structure <c>employee</c> in module - <c>DB</c>.</item> - </list> - <p>Since the <c>employee</c> struct is defined in the top level scope, - the Erlang record definition is found in <c>DB.hrl</c>. IC also generates - stubs/skeletons (e.g. <c>DB_CommonUser.erl</c>) and access functions for - some datatypes (e.g. <c>DB_employee.erl</c>). How the stubs/skeletons are - used is thoroughly described in - <seealso marker="ch_stubs">Stubs/Skeletons</seealso> and - <seealso marker="Module_Interface">Module_Interface</seealso>.</p> - </section> - </section> - - <section> - <title>Typecode, Identity and Name Access Functions</title> - <p>As mentioned in a previous section, <c>struct</c>, <c>union</c> and - <c>exception</c> types yield record definitions and access code - for that record. - For <c>struct</c>, <c>union</c>, <c>exception</c>, <c>array</c> and - <c>sequence</c> types, a special file is generated that holds access - functions for <c>TypeCode</c>, <c>Identity</c> and <c>Name</c>. - These functions are put in the file corresponding to the scope where - they are defined. For example, the module <c>DB_employee.erl</c>, - representing the <c>employee</c> struct, exports the following functions:</p> - <list type="bulleted"> - <item>tc/0 - returns the type code for the struct.</item> - <item>id/0 - returns the IFR identity of the struct. In this case - the returned value is <c>"IDL:DB/employee:1.0"</c>, but - if the struct was defined in the scope of <c>CommonUser</c>, - the result would be <c>"IDL:DB/CommonUser/employee:1.0"</c>. - However, the user usually do not need to know the Id, just - which Erlang module contains the correct Id.</item> - <item>name/0 - returns the scoped name of the struct. The <c>employee</c> - struct name is <c>"DB_employee"</c>.</item> - </list> - <p><term id="Type Codes"><termdef>Type codes give a complete description of the type including all its components and structure.</termdef></term>are, for example, used in <seealso marker="any">Any</seealso> values. - Hence, we can encapsulate the <c>employee</c> struct in an <c>any</c> - type by:</p> - <code type="erl"> -%% Erlang code -.... -AnEmployee = #'DB_employee'{'No' = 1, - 'Name' = "Adam Ivan Kendall", - 'Address' = "Rasunda, Solna", - 'Dpt' = 'Department1'}, -EmployeeTC = 'DB_employee':tc(), -EmployeeAny = any:create(EmployeeTC, AnEmployee), -.... - </code> - <p>For more information, see the - <seealso marker="#tk_values">Type Code listing</seealso>.</p> - </section> - - <section> - <title>References to Constants</title> - <p>Constants are generated as Erlang functions, and are accessed by a - single function call. The functions are put in the file - corresponding to the scope where they are defined. There is no - need for an object to be started to access a constant.</p> - <p>Example:</p> - <code type="none"> -// m.idl -module m { - const float pi = 3.14; - - interface i { - const float pi = 3.1415; - }; -}; - </code> - <p>Since the two constants are defined in different scopes, the IDL code - above is valid, but not necessarily a good approach. After compiling - <c>m.idl</c>, the constant definitions can be extracted by invoking:</p> - <pre> -$ <input>erlc m.idl</input> -$ <input>erlc m.erl</input> -$ <input>erl</input> -Erlang (BEAM) emulator version 5.1.1 [threads:0] - -Eshell V5.1.1 (abort with ^G) -1> <input>m:pi().</input> -3.14 -2> <input>m_i:pi().</input> -3.1415 -3> <input>halt().</input> - </pre> - </section> - - <section> - <title>References to Objects Defined in OMG IDL</title> - <p>Objects are accessed by object references. An object reference - is an opaque Erlang term created and maintained by the ORB.</p> - <p>Objects are implemented by providing implementations for all - operations and attributes of the Object, <seealso marker="#op_impl">see operation implementation</seealso>.</p> - </section> - - <section> - <title>Exceptions</title> - <p>Exceptions are handled as Erlang catch and throws. Exceptions - are translated to messages over an IIOP bridge but converted - back to a throw on the receiving side. Object implementations - that invoke operations on other objects must be aware of the - possibility of a non-local return. This includes invocation of - ORB and IFR services. See also the - <seealso marker="ch_exceptions">Exceptions</seealso> section.</p> - <p>Exception parameters are mapped as an Erlang record and accessed - as such.</p> - <p>An object implementation that raises an exception will use the - <c>corba:raise/1</c> function, passing the exception record as - parameter.</p> - </section> - - <section> - <title>Access to Attributes</title> - <p>Attributes are accessed through their access functions. An - attribute implicitly defines the <c>_get</c> and <c>_set</c> - operations. These operations are handled in the same way as - normal operations. The <c>_get</c> operation is defined as a <c>readonly</c> - attribute.</p> - <code type="none"> -readonly attribute long RAttribute; -attribute long RWAttribute; - </code> - <p>The <c>RAttribute</c> requires that you implement, in your call-back module, - <c>_get_RAttribute</c>. For the <c>RWAttribute</c> it is necessary to implement - <c>_get_RWAttribute</c> and <c>_set_RWAttribute</c>.</p> - </section> - - <section> - <title>Invocations of Operations</title> - <marker id="op_impl"></marker> - <p>A standard Erlang <c>gen_server</c> behavior is used for - object implementation. The <c>gen_server</c> state is then - used as the object internal state. Implementation of the object - function is achieved by implementing its methods and attribute operations. - These functions will usually have the internal state as their first parameter, - followed by any <c>in</c> and <c>inout</c> parameters. </p> - <p>Do not confuse the - object internal state with its object reference. The object internal state is - an Erlang term which has a format defined by the user.</p> - <note> - <p>It is not always the case that the internal state will be the first parameter, as stubs can use their own object reference as the first parameter (see the IC documentation).</p> - </note> - <p>A function call will invoke an operation. The first - parameter of the function should be the object reference and then - all <c>in</c> and <c>inout</c> parameters follow in the same - order as specified in the IDL specification. The result will be a return value - unless the function has <c>inout</c> or <c>out</c> parameters specified; - in which case, a tuple of the return value, followed by the parameters will - be returned.</p> - <p>Example:</p> - <code type="none"> -// IDL -module m { - interface i { - readonly attribute long RAttribute; - attribute long RWAttribute; - long foo(in short a); - long bar(in char c, inout string s, out long count); - void baz(out long Id); - }; -}; - </code> - <p>Is used in Erlang as :</p> - <code type="none"> -%% Erlang code -.... -Obj = ... %% get object reference -RAttr = m_i:'_get_RAttribute'(Obj), -RWAttr = m_i:'_get_RWAttribute'(Obj), -ok = m_i:'_set_RWAttribute'(Obj, Long), -R1 = m_i:foo(Obj, 55), -{R2, S, Count} = m_i:bar(Obj, $a, "hello"), -.... - </code> - <p>Note how the <c>inout</c> parameter is passed <em>and</em> - returned. There is no way to use a single occurrence of a - variable for this in Erlang. Also note, that <c>ok</c>, Orber's - representation of the IDL-type <c>void</c>, must be returned by - <c>baz</c> and <c>'_set_RWAttribute'</c>. - These operations can be implemented in the call-back module as:</p> - <code type="erl"> -'_set_RWAttribute'(State, Long) -> - {reply, ok, State}. - -'_get_RWAttribute'(State) -> - {reply, Long, State}. - -'_get_RAttribute'(State) -> - {reply, Long, State}. - -foo(State, AShort) -> - {reply, ALong, State}. - -bar(State, AShort, AString) -> - {reply, {ALong, "MyString", ALong}, State}. - -baz(State) -> - {reply, {ok, AId}, State}. - </code> - <p>The operations may require more arguments (depends on IC options used). For - more information, see <seealso marker="ch_stubs">Stubs/Skeletons</seealso> - and <seealso marker="Module_Interface">Module_Interface</seealso>.</p> - <warning> - <p>A function can also be defined to be <c>oneway</c>, i.e. - asynchronous. But, since the behavior of a oneway operation is not - defined in the OMG specifications (i.e. the behavior can differ depending on - which other ORB Orber is communicating with), one should avoid using it.</p> - </warning> - </section> - - <section> - <title>Implementing the DB Application</title> - <p>Now we are ready to implement the call-back modules. There are three modules - we must create:</p> - <list type="bulleted"> - <item>DB_Access_impl.erl</item> - <item>DB_CommonUser_impl.erl</item> - <item>DB_Administrator_impl.erl</item> - </list> - <p>An easy way to accomplish that, is to use the IC backend <c>erl_template</c>, - which will generate a complete call-back module. One should also add - the same compile options, for example <c>this</c> or <c>from</c>, - used when generating the stub/skeleton modules:</p> - <code type="none"> -$> erlc +"{be,erl_template}" DB.idl - </code> - <p>We begin with implementing the <c>DB_Access_impl.erl</c> module, which, - if we used <c>erl_template</c>, will look like the following. All we need - to do is to add the logic to the <c>logon</c> operation.</p> - <code type="erl"><![CDATA[ -%%---------------------------------------------------------------------- -%% <LICENSE> -%% -%% $Id$ -%% -%%---------------------------------------------------------------------- -%% Module : DB_Access_impl.erl -%% -%% Source : /home/user/example/DB.idl -%% -%% Description : -%% -%% Creation date: 2005-05-20 -%% -%%---------------------------------------------------------------------- --module('DB_Access_impl'). - --export([logon/3]). - -%%---------------------------------------------------------------------- -%% Internal Exports -%%---------------------------------------------------------------------- --export([init/1, - terminate/2, - code_change/3, - handle_info/2]). - -%%---------------------------------------------------------------------- -%% Include Files -%%---------------------------------------------------------------------- - - -%%---------------------------------------------------------------------- -%% Macros -%%---------------------------------------------------------------------- - - -%%---------------------------------------------------------------------- -%% Records -%%---------------------------------------------------------------------- --record(state, {}). - -%%====================================================================== -%% API Functions -%%====================================================================== -%%---------------------------------------------------------------------- -%% Function : logon/3 -%% Arguments : State - term() -%% ID = String() -%% PW = String() -%% Returns : ReturnValue = OE_Reply -%% OE_Reply = Object_Ref() -%% Raises : -%% Description: -%%---------------------------------------------------------------------- -logon(State, ID, PW) -> - %% Check if the ID/PW is valid and what - %% type of user it is (Common or Administrator). - OE_Reply - = case check_user(ID, PW) of - {ok, administrator} -> - 'DB_Administrator':oe_create(); - {ok, common} -> - 'DB_CommonUser':oe_create(); - error -> - %% Here we should throw an exception - corba:raise(....) - end, - {reply, OE_Reply, State}. - -%%====================================================================== -%% Internal Functions -%%====================================================================== -%%---------------------------------------------------------------------- -%% Function : init/1 -%% Arguments : Env = term() -%% Returns : {ok, State} | -%% {ok, State, Timeout} | -%% ignore | -%% {stop, Reason} -%% Raises : - -%% Description: Initiates the server -%%---------------------------------------------------------------------- -init(_Env) -> - {ok, #state{}}. - - -%%---------------------------------------------------------------------- -%% Function : terminate/2 -%% Arguments : Reason = normal | shutdown | term() -%% State = term() -%% Returns : ok -%% Raises : - -%% Description: Invoked when the object is terminating. -%%---------------------------------------------------------------------- -terminate(_Reason, _State) -> - ok. - - -%%---------------------------------------------------------------------- -%% Function : code_change/3 -%% Arguments : OldVsn = undefined | term() -%% State = NewState = term() -%% Extra = term() -%% Returns : {ok, NewState} -%% Raises : - -%% Description: Invoked when the object should update its internal state -%% due to code replacement. -%%---------------------------------------------------------------------- -code_change(_OldVsn, State, _Extra) -> - {ok, State}. - - -%%---------------------------------------------------------------------- -%% Function : handle_info/2 -%% Arguments : Info = normal | shutdown | term() -%% State = NewState = term() -%% Returns : {noreply, NewState} | -%% {noreply, NewState, Timeout} | -%% {stop, Reason, NewState} -%% Raises : - -%% Description: Invoked when, for example, the server traps exits. -%%---------------------------------------------------------------------- -handle_info(_Info, State) -> - {noreply, State}. - ]]></code> - <p>Since <c>DB_Administrator</c> inherits from <c>DB_CommonUser</c>, - we must implement <c>delete</c> in the <c>DB_Administrator_impl.erl</c> - module, and <c>lookup</c> in <c>DB_Administrator_impl.erl</c><em>and</em><c>DB_CommonUser_impl.erl</c>. But wait, is that really necessary? Actually, - it is not. We simple use the IC compile option <em>impl</em>:</p> - <pre> -$ <input>erlc +'{{impl, "DB::CommonUser"}, "DBUser_impl"}'\ - +'{{impl, "DB::Administrator"}, "DBUser_impl"}' DB.idl</input> -$ <input>erlc *.erl</input> - </pre> - <p>Instead of creating, and not the least, maintaining two call-back modules, - we only have to deal with <c>DBUser_impl.erl</c>. If we generated the - templates, we simply rename <c>DB_Administrator_impl.erl</c> to - <c>DBUser_impl.erl</c>. See also the - <seealso marker="ch_exceptions">Exceptions</seealso> chapter. - In the following example, only the implementation of the API functions - are shown:</p> - <code type="erl"> -%%====================================================================== -%% API Functions -%%====================================================================== -%%---------------------------------------------------------------------- -%% Function : delete/2 -%% Arguments : State - term() -%% ENo = unsigned_Long() -%% Returns : ReturnValue = ok -%% Raises : -%% Description: -%%---------------------------------------------------------------------- -delete(State, ENo) -> - %% How we access the DB, for example mnesia, is not shown here. - case delete_employee(No) of - ok -> - {reply, ok, State}; - error -> - %% Here we should throw an exception if - %% there is no match. - corba:raise(....) - end. - -%%---------------------------------------------------------------------- -%% Function : lookup/2 -%% Arguments : State - term() -%% ENo = unsigned_Long() -%% Returns : ReturnValue = OE_Reply -%% OE_Reply = #'DB_employee'{No,Name,Address,Dpt} -%% No = unsigned_Long() -%% Name = String() -%% Address = String() -%% Dpt = Department -%% Department = 'Department1' | 'Department2' -%% Raises : -%% Description: -%%---------------------------------------------------------------------- -lookup(State, ENo) -> - %% How we access the DB, for example mnesia, is not shown here. - case lookup_employee(ENo) of - %% We assume that we receive a 'DB_employee' struct - {ok, Employee} -> - OE_Reply = Employee, - {reply, OE_Reply, State}; - error -> - %% Here we should throw an exception if - %% there is no match. - corba:raise(....) - end. - </code> - <p>After you have compiled both call-back modules, and implemented the missing - functionality (e.g. lookup_employee/1), we can test our application:</p> - <code type="none"> -%% Erlang code -.... -%% Create an Access object -Acc = 'DB_Access':oe_create(), - -%% Login is Common user and Administrator -Adm = 'DB_Access':logon(A, "admin", "pw"), -Com = 'DB_Access':logon(A, "comm", "pw"), - -%% Lookup existing employee -Employee = 'DB_Administrator':lookup(Adm, 1), -Employee = 'DB_CommonUser':lookup(Adm, 1), - -%% If we try the same using the DB_CommonUser interface -%% it result in an exit since that operation is not exported. -{'EXIT', _} = (catch 'DB_CommonUser':delete(Adm, 1)), - -%% Try to delete the employee via the CommonUser Object -{'EXCEPTION', _} = (catch 'DB_Administrator':delete(Com, 1)), - -%% Invoke delete operation on the Administrator object -ok = 'DB_Administrator':delete(Adm, 1), -.... - </code> - </section> - - <section> - <title>Reserved Compiler Names and Keywords</title> - <marker id="key_words"></marker> - <p>The use of some names is strongly discouraged due to - ambiguities. However, the use of some names is prohibited - when using the Erlang mapping , as they are strictly reserved for IC.</p> - <p>IC reserves all identifiers starting with <c>OE_</c> and <c>oe_</c> - for internal use.</p> - <p>Note also, that an identifier in IDL can contain alphabetic, - digits and underscore characters, but the first character - <em>must</em> be alphabetic. - </p> - <p>The OMG defines a set of reserved words, shown below, for use as keywords. - These may <em>not</em> be used as, for example, identifiers. The keywords - which are not in bold face was introduced in the OMG CORBA-3.0 - specification.</p> - <table> - <row> - <cell align="left" valign="middle"><em>abstract</em></cell> - <cell align="left" valign="middle"><em>exception</em></cell> - <cell align="left" valign="middle"><em>inout</em></cell> - <cell align="left" valign="middle">provides</cell> - <cell align="left" valign="middle"><em>truncatable</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>any</em></cell> - <cell align="left" valign="middle">emits</cell> - <cell align="left" valign="middle"><em>interface</em></cell> - <cell align="left" valign="middle"><em>public</em></cell> - <cell align="left" valign="middle"><em>typedef</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>attribute</em></cell> - <cell align="left" valign="middle"><em>enum</em></cell> - <cell align="left" valign="middle"><em>local</em></cell> - <cell align="left" valign="middle">publishes</cell> - <cell align="left" valign="middle">typeid</cell> - </row> - <row> - <cell align="left" valign="middle"><em>boolean</em></cell> - <cell align="left" valign="middle">eventtype</cell> - <cell align="left" valign="middle"><em>long</em></cell> - <cell align="left" valign="middle"><em>raises</em></cell> - <cell align="left" valign="middle">typeprefix</cell> - </row> - <row> - <cell align="left" valign="middle"><em>case</em></cell> - <cell align="left" valign="middle"><em>factory</em></cell> - <cell align="left" valign="middle"><em>module</em></cell> - <cell align="left" valign="middle"><em>readonly</em></cell> - <cell align="left" valign="middle"><em>unsigned</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>char</em></cell> - <cell align="left" valign="middle"><em>FALSE</em></cell> - <cell align="left" valign="middle">multiple</cell> - <cell align="left" valign="middle">setraises</cell> - <cell align="left" valign="middle"><em>union</em></cell> - </row> - <row> - <cell align="left" valign="middle">component</cell> - <cell align="left" valign="middle">finder</cell> - <cell align="left" valign="middle"><em>native</em></cell> - <cell align="left" valign="middle"><em>sequence</em></cell> - <cell align="left" valign="middle">uses</cell> - </row> - <row> - <cell align="left" valign="middle"><em>const</em></cell> - <cell align="left" valign="middle"><em>fixed</em></cell> - <cell align="left" valign="middle"><em>Object</em></cell> - <cell align="left" valign="middle"><em>short</em></cell> - <cell align="left" valign="middle"><em>ValueBase</em></cell> - </row> - <row> - <cell align="left" valign="middle">consumes</cell> - <cell align="left" valign="middle"><em>float</em></cell> - <cell align="left" valign="middle"><em>octet</em></cell> - <cell align="left" valign="middle"><em>string</em></cell> - <cell align="left" valign="middle"><em>valuetype</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>context</em></cell> - <cell align="left" valign="middle">getraises</cell> - <cell align="left" valign="middle"><em>oneway</em></cell> - <cell align="left" valign="middle"><em>struct</em></cell> - <cell align="left" valign="middle"><em>void</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>custom</em></cell> - <cell align="left" valign="middle">home</cell> - <cell align="left" valign="middle"><em>out</em></cell> - <cell align="left" valign="middle"><em>supports</em></cell> - <cell align="left" valign="middle"><em>wchar</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>default</em></cell> - <cell align="left" valign="middle">import</cell> - <cell align="left" valign="middle">primarykey</cell> - <cell align="left" valign="middle"><em>switch</em></cell> - <cell align="left" valign="middle"><em>wstring</em></cell> - </row> - <row> - <cell align="left" valign="middle"><em>double</em></cell> - <cell align="left" valign="middle"><em>in</em></cell> - <cell align="left" valign="middle"><em>private</em></cell> - <cell align="left" valign="middle"><em>TRUE</em></cell> - <cell align="left" valign="middle"></cell> - </row> - <tcaption>OMG IDL keywords</tcaption> - </table> - <p>The keywords listed above must be written exactly as shown. Any usage - of identifiers that collide with a keyword is illegal. For example, - <em>long</em> is a valid keyword; <em>Long</em> and <em>LONG</em> are - illegal as keywords and identifiers. But, since the OMG must be able - to expand the IDL grammar, it is possible to use <em>Escaped Identifiers</em>. For example, it is not unlikely that <c>native</c> - have been used in IDL-specifications as identifiers. One option is to - change all occurrences to <c>myNative</c>. Usually, it is necessary - to change programming language code that depends upon that IDL as well. - Since Escaped Identifiers just disable type checking (i.e. if it is a reserved - word or not) and leaves everything else unchanged, it is only necessary to - update the IDL-specification. To escape an identifier, simply prefix it - with <em>_</em>. The following IDL-code is illegal:</p> - <code type="none"> -typedef string native; -interface i { - void foo(in native Arg); - }; -}; - </code> - <p>With Escaped Identifiers the code will look like:</p> - <code type="none"> -typedef string _native; -interface i { - void foo(in _native Arg); - }; -}; - </code> - </section> - - <section> - <title>Type Code Representation</title> - <marker id="tk_values"></marker> - <p>Type Codes are used in <c>any</c> values. To avoid mistakes, you should - use access functions exported by the Data Types modules - (e.g. struct, union etc) or the <seealso marker="orber_tc">orber_tc</seealso> - module.</p> - <table> - <row> - <cell align="left" valign="middle"><em>Type Code</em></cell> - <cell align="left" valign="middle"><em>Example</em></cell> - </row> - <row> - <cell align="left" valign="middle">tk_null</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_void</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_short</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_long</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_longlong</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_ushort</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_ulong</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_ulonglong</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_float</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_double</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_boolean</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_char</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_wchar</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_octet</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_any</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_TypeCode</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">tk_Principal</cell> - <cell align="left" valign="middle"></cell> - </row> - <row> - <cell align="left" valign="middle">{tk_objref, IFRId, Name}</cell> - <cell align="left" valign="middle">{tk_objref, "IDL:M1\I1:1.0", "I1"}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_struct, IFRId, Name, [{ElemName, ElemTC}]}</cell> - <cell align="left" valign="middle">{tk_struct, "IDL:M1\S1:1.0", "S1", [{"a", tk_long}, {"b", tk_char}]}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_union, IFRId, Name, DiscrTC, DefaultNr, [{Label, ElemName, ElemTC}]} <br></br> -Note: DefaultNr tells which of tuples in the case list that is default, or -1 if no default</cell> - <cell align="left" valign="middle">{tk_union, "IDL:U1:1.0", "U1", tk_long, 1, [{1, "a", tk_long}, {default, "b", tk_char}]}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_enum, IFRId, Name, [ElemName]}</cell> - <cell align="left" valign="middle">{tk_enum, "IDL:E1:1.0", "E1", ["a1", "a2"]}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_string, Length}</cell> - <cell align="left" valign="middle">{tk_string, 5}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_wstring, Length}</cell> - <cell align="left" valign="middle">{tk_wstring, 7}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_fixed, Digits, Scale}</cell> - <cell align="left" valign="middle">{tk_fixed, 3, 2}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_sequence, ElemTC, Length}</cell> - <cell align="left" valign="middle">{tk_sequence, tk_long, 4}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_array, ElemTC, Length}</cell> - <cell align="left" valign="middle">{tk_array, tk_char, 9}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_alias, IFRId, Name, TC}</cell> - <cell align="left" valign="middle">{tk_alias, "IDL:T1:1.0", "T1", tk_short}</cell> - </row> - <row> - <cell align="left" valign="middle">{tk_except, IFRId, Name, [{ElemName, ElemTC}]}</cell> - <cell align="left" valign="middle">{tk_except, "IDL:Exc1:1.0", "Exc1", [{"a", tk_long}, {"b", {tk_string, 0}}]}</cell> - </row> - <tcaption>Type Code tuples</tcaption> - </table> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_ifr.xml b/lib/orber/doc/src/ch_ifr.xml deleted file mode 100644 index 09302ab6cc..0000000000 --- a/lib/orber/doc/src/ch_ifr.xml +++ /dev/null @@ -1,50 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Interface Repository</title> - <prepared></prepared> - <docno></docno> - <date>1998-10-10</date> - <rev></rev> - <file>ch_ifr.xml</file> - </header> - - <section> - <title>Interface Repository(IFR)</title> - <p>The IFR is an interface repository built on the Mnesia - application. Orber uses the IFR for some type-checking - when coding/decoding IIOP. The IFR is capable of storing all - interfaces and declarations of OMG IDL. - </p> - <p>The interface repository is mainly used for dynamical - interfaces, and as none are currently supported this function - is only really used for retrieving information about interfaces.</p> - <p>Functions relating to the manipulation of the IFR including, - initialization of the IFR, as well as, locating, creating and - destroying initial references are detailed further in the Manual - Pages. - </p> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_install.xml b/lib/orber/doc/src/ch_install.xml deleted file mode 100644 index 65faa91ccf..0000000000 --- a/lib/orber/doc/src/ch_install.xml +++ /dev/null @@ -1,1001 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Installing Orber</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1998-09-28</date> - <rev></rev> - <file>ch_install.xml</file> - </header> - - <section> - <title>Installation Process </title> - <p>This chapter describes how to install Orber in an Erlang - Environment.</p> - - <section> - <title>Preparation</title> - <p>To begin with, you must decide if you want to run Orber as a:</p> - <list type="bulleted"> - <item><em>Single node (non-distributed)</em> - all communication with other - Orber instances and ORB's supplied by other vendors use the OMG - GIOP protocol.</item> - <item><em>Multi node (distributed)</em> - all Orber nodes, within the same - <c>domain</c>, communicate via the Erlang distribution protocol. - For all other Orber instances, i.e. not part of the same <c>domain</c>, - and ORB's supplied by other vendors, the OMG GIOP protocol - is used.</item> - </list> - <p>Which approach to use is highly implementation specific, but a few - things you should consider:</p> - <list type="bulleted"> - <item>All nodes within an Orber domain should have the same - security level.</item> - <item>If the capacity is greater than load (volume of traffic) - a single-node Orber might be a good solution.</item> - <item>In some cases the distributed system architecture requires a - single-node <term id="Orber installation"><termdef>is the structure of the ORB or ORBs as defined during the install process is called the "installation".</termdef></term>.</item> - <item>A multi-node Orber makes it possible to load balance - and create a more fault tolerant system. The Objects - can also have a uniform view if you use distributed - Mnesia tables.</item> - <item>Since the GIOP protocol creates a larger overhead than the - Erlang distribution protocol, the performance will be better - when communicating with Objects within the same Orber domain - compared with inter ORB communication (GIOP).</item> - </list> - <p>You also have to decide if you want Orber to store internal data using - <c>disc_copies</c> and/or <c>ram_copies</c>. Which storage type you should - depends if/how you intend to use Mnesia in your application. If you - intend to use <c>disc_copies</c> you must start with creating a Mnesia - schema, which contain information about the location of the Erlang nodes - where Orber is planned to be run. For more background information, - see the Mnesia documentation.</p> - <p>In some cases it is absolutely necessary to change the default configuration - of Orber. For example, if two Orber-ORB's shall be able to communicate - via GIOP, they must have a unique <c>domain</c> domain. Consult the - <seealso marker="ch_install#config">configuration settings</seealso> - section. If you encounter any problems; see the chapter about - <em>Debugging</em> in this User's Guide.</p> - </section> - - <section> - <title>Jump Start Orber</title> - <p>The easiest way to start Orber is to use <c>orber:jump_start(Port)</c>, - which start a single-node ORB with (most likely) a unique - domain (i.e. "IP-number:Port"). This function may only be used - during development and testing. For any other situation, install and - start Orber as described in the following sections. - The listen port, i.e. iiop_port configuration parameter, is set to - the supplied Port.</p> - <warning> - <p>How Orber is configured when using <c>orber:jump_start(Port)</c> - may change at any time without warning. Hence, this operation must - not be used in systems delivered to a customer.</p> - </warning> - </section> - - <section> - <title>Install Single Node Orber</title> - <p>Since a single node Orber communicate via the OMG GIOP protocol it is not - necessary to start the Erlang distribution (i.e. using <c>-name/-sname</c>).</p> - <p>If we use <c>ram_copies</c> there is no need for creating a disk based - schema. Simply use:</p> - <code type="erl"> -erl> mnesia:start(). -erl> corba:orb_init([{domain, "MyRAMSingleNodeORB"}]). -erl> orber:install([node()], [{ifr_storage_type, ram_copies}]). -erl> orber:start(). - </code> - <p>If you installation requires <c>disc_copies</c> you must begin with - creating a Mnesia schema. Otherwise, the installation is similar - to a RAM installation:</p> - <code type="erl"> -erl> mnesia:create_schema([node()]). -erl> mnesia:start(). -erl> corba:orb_init([{domain, "MyDiskSingleNodeORB"}]). -erl> orber:install([node()], [{ifr_storage_type, disc_copies}, - {nameservice_storage_type, disc_copies}]). -erl> orber:start(). - </code> - <p>You can still choose to store the IFR data as ram_copies, but then - the data must be re-installed (i.e. invoke <c>orber:install/2</c>) - if the node is restarted. Hence, since the IFR data is rather static - you should use <c>disc_copies</c>. For more information see the - <c>orber</c> section in the reference manual.</p> - <p>If you do not need to change Orber's configuration you can skip - <seealso marker="corba">orb_init/1</seealso>. - But, you <em>should</em> at least set the IIOP timeout parameters.</p> - </section> - - <section> - <title>Install RAM Based Multi Node Orber</title> - <p>Within a domain Orber uses the Erlang distribution protocol. Hence, you - <em>must</em> start it first by, for example, using:</p> - <code type="erl"> -hostA> erl -sname nodeA - </code> - <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and - <c>nodeB</c>. Since Mnesia must know which other nodes should a part - of the distribution we either need to add the Mnesia configuration - parameter <c>extra_db_nodes</c> or use <c>mnesia:change_config/2</c>. To - begin with, Mnesia must be started on all nodes before we can install - Orber:</p> - <code type="erl"> -nodeA@hostA> mnesia:start(). -nodeA@hostA> mnesia:change_config(extra_db_nodes, - [nodeA@hostA, nodeB@hostB]). - </code> - <p>After that the above have been repeated on <c>nodeB</c> we must - first make sure that both nodes will use the same domain name, then - we can install Orber:</p> - <code type="erl"> -nodeA@hostA> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]). -nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB], - [{ifr_storage_type, ram_copies}]). -nodeA@hostA> orber:start(). - </code> - <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the - nodes. Now we can start Orber on the other node:</p> - <code type="erl"> -nodeB@hostB> corba:orb_init([{domain, "MyRAMMultiNodeORB"}]). -nodeB@hostB> orber:start(). - </code> - </section> - - <section> - <title>Install Disk Based Multi Node Orber</title> - <p>As for RAM based multi-node Orber installations, the Erlang distribution - must be started (e.g. erl -sname nodeA). The major difference is that - when it is disk based a Mnesia schema must be created:</p> - <code type="erl"> -nodeA@hostA> mnesia:create_schema([nodeA@hostA, nodeB@hostB]). -nodeA@hostA> mnesia:start(). - </code> - <p>In this example, we assume that we want to use two nodes; <c>nodeA</c> and - <c>nodeB</c>. Since it is not possible to create a schema on more than - one node. Hence, all we have to do is to start Mnesia (i.e. invoke - <c>mnesia:start()</c>) on <c>nodeB</c>.</p> - <p>After Mnesia have been started on all nodes, you must confirm that all - nodes have the same domain name, then Orber is ready to be installed:</p> - <code type="erl"> -nodeA@hostA> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]). -nodeA@hostA> orber:install([nodeA@hostA, nodeB@hostB], - [{ifr_storage_type, disc_copies}]). -nodeA@hostA> orber:start(). - </code> - <p>Note that you can only invoke <c>orber:install/1/2</c> on one of the - nodes. Now we can start Orber on the other node:</p> - <code type="erl"> -nodeB@hostB> corba:orb_init([{domain, "MyDiskMultiNodeORB"}]). -nodeB@hostB> orber:start(). - </code> - </section> - - </section> - - <section> - <title>Configuration</title> - <marker id="config"></marker> - <p>It is essential that one configure Orber properly, to avoid, for example, - malicious attacks and automatically terminate IIOP connections no longer - in use. An easy way to extract information about Orber's configuration - parameters is to invoke the operation - <seealso marker="orber">orber:info/1/2</seealso>. - Orber offer the following configuration parameters:</p> - <table> - <row> - <cell align="center" valign="middle"><em>Key</em></cell> - <cell align="center" valign="middle"><em>Range</em></cell> - <cell align="center" valign="middle"><em>Default</em></cell> - </row> - <row> - <cell align="left" valign="middle">domain</cell> - <cell align="left" valign="middle">string()</cell> - <cell align="left" valign="middle">"ORBER"</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_port</cell> - <cell align="left" valign="middle">integer() >= 0</cell> - <cell align="left" valign="middle">4001</cell> - </row> - <row> - <cell align="left" valign="middle">nat_iiop_port</cell> - <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell> - <cell align="left" valign="middle">The same as <c>iiop_port</c></cell> - </row> - <row> - <cell align="left" valign="middle">iiop_out_ports</cell> - <cell align="left" valign="middle">0 | {integer(),integer()}</cell> - <cell align="left" valign="middle">0</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_out_ports_attempts</cell> - <cell align="left" valign="middle">integer() > 0</cell> - <cell align="left" valign="middle">1</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_out_ports_random</cell> - <cell align="left" valign="middle">true | false</cell> - <cell align="left" valign="middle">false</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_max_fragments</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_max_in_requests</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_max_in_connections</cell> - <cell align="left" valign="middle">integer() > 0</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_backlog</cell> - <cell align="left" valign="middle">integer() > 0</cell> - <cell align="left" valign="middle">5</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_packet_size</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">ip_address</cell> - <cell align="left" valign="middle">string() | {multiple, [string()]}</cell> - <cell align="left" valign="middle">All interfaces</cell> - </row> - <row> - <cell align="left" valign="middle">ip_address_local</cell> - <cell align="left" valign="middle">string()</cell> - <cell align="left" valign="middle">Defined by the underlying system</cell> - </row> - <row> - <cell align="left" valign="middle">nat_ip_address</cell> - <cell align="left" valign="middle">string() | {multiple, [string()]} | {local, string(), [{string(), string()}]}</cell> - <cell align="left" valign="middle">The same as <c>ip_address</c></cell> - </row> - <row> - <cell align="left" valign="middle">objectkeys_gc_time</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">giop_version</cell> - <cell align="left" valign="middle">{1,0} | {1,1} | {1,2}</cell> - <cell align="left" valign="middle">{1,1}</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_setup_connection_timeout</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_connection_timeout</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_in_connection_timeout</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_out_keepalive</cell> - <cell align="left" valign="middle">true | false</cell> - <cell align="left" valign="middle">false</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_in_keepalive</cell> - <cell align="left" valign="middle">true | false</cell> - <cell align="left" valign="middle">false</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_timeout</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">interceptors</cell> - <cell align="left" valign="middle">{native, [atom()]}</cell> - <cell align="left" valign="middle">-</cell> - </row> - <row> - <cell align="left" valign="middle">local_interceptors</cell> - <cell align="left" valign="middle">{native, [atom()]}</cell> - <cell align="left" valign="middle">-</cell> - </row> - <row> - <cell align="left" valign="middle">orbInitRef</cell> - <cell align="left" valign="middle">[string()] | undefined</cell> - <cell align="left" valign="middle">undefined</cell> - </row> - <row> - <cell align="left" valign="middle">orbDefaultInitRef</cell> - <cell align="left" valign="middle">string() | undefined</cell> - <cell align="left" valign="middle">undefined</cell> - </row> - <row> - <cell align="left" valign="middle">orber_debug_level</cell> - <cell align="left" valign="middle">0 - 10</cell> - <cell align="left" valign="middle">0</cell> - </row> - <row> - <cell align="left" valign="middle">flags</cell> - <cell align="left" valign="middle">integer() >= 0</cell> - <cell align="left" valign="middle">0</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_acl</cell> - <cell align="left" valign="middle">[{atom(), string()}] | [{atom(), string(), [string()]}]</cell> - <cell align="left" valign="middle">[]</cell> - </row> - <row> - <cell align="left" valign="middle">secure</cell> - <cell align="left" valign="middle">no | ssl</cell> - <cell align="left" valign="middle">no</cell> - </row> - <row> - <cell align="left" valign="middle">ssl_generation</cell> - <cell align="left" valign="middle">2 | 3</cell> - <cell align="left" valign="middle">2</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_port</cell> - <cell align="left" valign="middle">integer() >= 0</cell> - <cell align="left" valign="middle">4002</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_accept_timeout</cell> - <cell align="left" valign="middle">integer() > 0 | infinity</cell> - <cell align="left" valign="middle">infinity</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_backlog</cell> - <cell align="left" valign="middle">integer() > 0</cell> - <cell align="left" valign="middle">5</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_ip_address_local</cell> - <cell align="left" valign="middle">string()</cell> - <cell align="left" valign="middle">Defined by the underlying system</cell> - </row> - <row> - <cell align="left" valign="middle">nat_iiop_ssl_port</cell> - <cell align="left" valign="middle">integer() > 0 | {local, integer(), [{integer(), integer()}]}</cell> - <cell align="left" valign="middle">The same as <c>iiop_ssl_port</c></cell> - </row> - <row> - <cell align="left" valign="middle">ssl_server_options</cell> - <cell align="left" valign="middle">list()</cell> - <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso> - for valid options.</cell> - </row> - <row> - <cell align="left" valign="middle">ssl_client_options</cell> - <cell align="left" valign="middle">list()</cell> - <cell align="left" valign="middle">See the <seealso marker="ssl:ssl">SSL application</seealso> - for valid options.</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_out_keepalive</cell> - <cell align="left" valign="middle">true | false</cell> - <cell align="left" valign="middle">false</cell> - </row> - <row> - <cell align="left" valign="middle">iiop_ssl_in_keepalive</cell> - <cell align="left" valign="middle">true | false</cell> - <cell align="left" valign="middle">false</cell> - </row> - <tcaption>Orber Configuration Parameters</tcaption> - </table> - <br></br> - <br></br> - <p><em>Comments on the table 'Orber Configuration Parameters':</em></p> - <taglist> - <tag><em>domain</em></tag> - <item>Since Orber domains, they are supposed to communicate via IIOP, - <em>MUST</em> have unique names, communication will - fail if two domains have the same name. The domain name <em>MAY NOT</em> - contain <c>^G</c> (i.e. <c>\007</c>).</item> - <tag><em>iiop_port</em></tag> - <item>If set to 0 the OS will pick any vacant port. - <br></br> -<em>Note:</em>On a UNIX system it is preferable to - have a IIOP port higher than 1023, since it is not recommended to - run Erlang as a root user.</item> - <tag><em>nat_iiop_port</em></tag> - <item>The value is either an integer or <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also - <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item> - <tag><em>iiop_out_ports</em></tag> - <item>When set to 0 any available port will be used. - If a range is specified, Orber will only - use the local ports within the interval when trying to connect to - another ORB (Orber acts as a client ORB). If all ports are in use - communication will fail. Hence, it is <em>absolutely necessary</em> to - set <c>iiop_connection_timeout</c> as well. Otherwise, connections - no longer in use will block further communication. If one use, for - example, <c>erl -orber iiop_out_ports "{5000,5020}"</c>, Orber - will only use port 5000 to 5020 when connecting. - If communicating via SSL, make sure you use a version that supports - the local <c>{port, Port}</c> option. See also - <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item> - <tag><em>iiop_out_ports_random</em></tag> - <item>Requires that <c>iiop_out_ports</c> define a port range. If that is the - case Orber will select a port randomly from that sequence.</item> - <tag><em>iiop_out_ports_attempts</em></tag> - <item>Requires that <c>iiop_out_ports</c> define a port range. If so Orber will - accept a number of timeouts, defined by this parameter, when trying to connect - to another ORB.</item> - <tag><em>iiop_max_fragments</em></tag> - <item>Limits the number of IIOP fragments allowed per request.</item> - <tag><em>iiop_max_in_requests</em></tag> - <item>Limits the number of concurrent incoming requests per incoming connection.</item> - <tag><em>iiop_max_in_connections</em></tag> - <item>Limits the number of concurrent incoming connections.</item> - <tag><em>iiop_backlog</em></tag> - <item>Defines the maximum length the queue of pending incoming - connections may grow to.</item> - <tag><em>iiop_packet_size</em></tag> - <item>Defines the maximum size of incoming requests. - If this limit is exceeded, the connection is closed.</item> - <tag><em>ip_address</em></tag> - <item>This option is used if orber only should - listen on a specific ip interface on a multi-interface host or if - exported IOR:s should contain multiple components. The value is - the IPv4 or IPv6 address as a string or <c>{multiple, IPList}</c>. - The latter requires that the object is available via the all IP addresses - found in the list.</item> - <tag><em>ip_address_local</em></tag> - <item>This option defines the default local interface Orber will - use when connecting to another ORB via IIOP, i.e., Orber act as the - client side ORB. The value is a IPv4 or IPv6 address as a string. - It is possible to override <c>ip_address_local</c> by defining - <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context. - If this option is not used, the underlying OS will choose which interface to - use. For more information, see the - <seealso marker="ch_install#interfaces">Interface Configuration</seealso> - section.</item> - <tag><em>nat_ip_address</em></tag> - <item>The value is the ip address as - a string (IPv4 or IPv6), <c>{multiple, IPList}</c> or - <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c>. See also - <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item> - <tag><em>objectkeys_gc_time</em></tag> - <item>This option should be set if objects are started - using the option <c>{persistent, true}</c>. - The value is <c>integer()</c> seconds.</item> - <tag><em>giop_version</em></tag> - <item>Defines the default GIOP protocol version.</item> - <tag><em>iiop_setup_connection_timeout</em></tag> - <item>The value is an integer (seconds) or the atom infinity. - This option is only valid for client-side - connections. If this option is set, attempts to connect to other ORB's - will timeout after the given time limit. Note, if the time limit is large - the TCP protocol may timeout before the supplied value.</item> - <tag><em>iiop_connection_timeout</em></tag> - <item>The value is an integer (timeout in seconds between 0 and 1000000) - or the atom infinity. This option is only valid for client object - connections, i.e., will have no effect on server connections. Setting this - option will cause client connections to be terminated, if and only if, - there are no pending requests. If there are a client still waiting for - a reply, Orber will try again after the given seconds have passed. The main - purpose for this option is to reduce the number of open connections; it is, - for example, not necessary to keep a connection, only used once a day, - open at all time.</item> - <tag><em>iiop_in_connection_timeout</em></tag> - <item>The same as for <c>iiop_connection_timeout</c>. The only difference is - that this option only affects incoming connections (i.e. Orber act as - server-side ORB).</item> - <tag><em>iiop_out_keepalive</em></tag> - <item>Enables periodic transmission on a connected socket, when no other - data is being exchanged. If the other end does not respond, the - connection is considered broken and will be terminated. - When enabled the SO_KEEPALIVE socket level option is set.</item> - <tag><em>iiop_in_keepalive</em></tag> - <item>The same as for <c>iiop_out_keepalive</c>. The only difference is - that this option only affects incoming connections.</item> - <tag><em>iiop_timeout</em></tag> - <item>The value is an integer (timeout in seconds between 0 and 1000000) - or the atom infinity. This option is only valid on the client side. - Setting this option, cause all intra-ORB requests to timeout and - raise a system exception, e.g. <c>TIMEOUT</c>, if no replies are delivered - within the given time limit.</item> - <tag><em>interceptors</em></tag> - <item>If one set this parameter, e.g., - <c>erl -orber interceptors "{native, ['myInterceptor']}"</c>, - Orber will use the supplied interceptor(s) for all inter-ORB - communication. <c>'myInterceptor'</c> is the module name of the - interceptor. For more information, see the interceptor chapter - in the User's Guide and the Reference Manual.</item> - <tag><em>local_interceptors</em></tag> - <item>If defined, its value will be - used when activating local interceptors via - <seealso marker="ch_install#flags">Orber Environment Flags</seealso>. - If not defined, but the flag is set, Orber will use the value of - the <c>interceptors</c> parameter.</item> - <tag><em>orbInitRef</em></tag> - <item>Setting this option, e.g., - <c>erl -orber orbInitRef [\"NameService=corbaloc::host.com/NameService\"]</c>, - will alter the location from where <c>corba:resolve_initial_references(Key)</c> - tries to find an object matching the given Key. The keys will also appear when - invoking <c>corba:list_initial_services()</c>. This variable overrides - <c>orbDefaultInitRef</c></item> - <tag><em>orbDefaultInitRef</em></tag> - <item>If a matching Key for <c>orbInitRef</c> is not - found, and this variable is set, it determines the location from where - <c>orber:resolve_initial_references(Key)</c> tries to find an object - matching the given Key. Usage: - <c>erl -orber orbDefaultInitRef \"corbaloc::host.com\"</c>.</item> - <tag><em>orber_debug_level</em></tag> - <item>The range is 0 to 10. - Using level 10 is the most verbose configuration. - This option will generate reports, using the <c>error_logger</c>, - for abnormal situations. It is not recommended to use this option - for delivered systems since some of the reports is not to be considered - as errors. The main purpose is to assist during development.</item> - <tag><em>flags</em></tag> - <item>No flags are activated in the default case. - The available configuration settings are described in - <seealso marker="ch_install#flags">Orber Environment Flags</seealso>.</item> - <tag><em>iiop_acl</em></tag> - <item>This option must be activated by setting - <seealso marker="ch_install#flags">Orber Environment Flags</seealso> parameter. - The value of this parameter shall be a list of <c>[{Direction, Filter}]</c> - and/or <c>[{Direction, Filter, [Interfaces]}]</c>. The <c>Direction</c>, - <c>tcp_in</c>, <c>ssl_in</c>, <c>tcp_out</c> or <c>ssl_out</c>, determines if - the Access Control List (ACL) applies to incoming or outgoing connections - and IIOP or IIOP over SSL. The <c>Filter</c> uses a extended format of - Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits - the connection to that particular host, while <c>"123.123.123.10/17"</c> allows - connections to or from any host equal to the 17 most significant bits. Orber - also allow the user to specify a certain port or port range, for example, - <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c> - respectively. IPv4 or none compressed IPv6 strings are accepted. <br></br> - - The list of <c>Interfaces</c>, IPv4 or IPv6 strings, may only contain - <em>one</em> address for outgoing connections. For incoming connections, - the <c>Interfaces</c> list may contain several IP strings. If set for - outgoing connections, and access is granted, Orber will use that local - interface when connecting to the server-side ORB. For incoming connections, - the client-side ORB is required to use one of the listed interfaces locally. - If it fail to do so, access will be denied. The module - <seealso marker="orber_acl">orber_acl</seealso> provides operations for - evaluating the access control for filters and addresses. See also the - <seealso marker="ch_install#interfaces">Interface Configuration</seealso> - and - <seealso marker="ch_install#firewall">Firewall Configuration</seealso> - chapters.</item> - <tag><em>secure</em></tag> - <item>Determines the security mode Orber will use, which is either - <c>no</c> if it is an insecure domain or the type of security - mechanism used. Currently, per default, Orber is compliant with - <c>CSIv1</c> level 0, which means IIOP via SSL/TLS. - The security chapter later in this manual describes how to get security - in Orber and how the options are used.</item> - <tag><em>ssl_generation</em></tag> - <item>Defines which SSL version, i.e. available API, is installed. The - default value, <c>2</c>, refers to SSL-3.1 or later, but earlier than SSL-4.0. - If set to <c>3</c> SSL-4.0, or later, must be available. Currently it not possible - to use <c>1</c>, it is only reserved for future use.</item> - <tag><em>iiop_ssl_port</em></tag> - <item>If set, the value must be an - integer greater than zero and not equal to <em>iiop_port</em>.</item> - <tag><em>iiop_ssl_accept_timeout</em></tag> - <item>The value is an integer (timeout in seconds) or the atom infinity and - determine how long the SSL handshake may take. This option should - be set to avoid if a client never initiate the handshake.</item> - <tag><em>iiop_ssl_backlog</em></tag> - <item>Defines the maximum length the queue of pending incoming - connections may grow to.</item> - <tag><em>iiop_ssl_ip_address_local</em></tag> - <item>This option defines the default local interface Orber will - use when connecting to another ORB via IIOP SSL, i.e., Orber act as the - client side ORB. The value is a IPv4 or IPv6 address as a string. - It is possible to override <c>iiop_ssl_ip_address_local</c> by defining - <c>iiop_acl</c> or passing the Orber generic <c>interface</c> Context. - If this option is not used, the underlying OS will choose which interface to - use. For more information, see the - <seealso marker="ch_install#interfaces">Interface Configuration</seealso> - section.</item> - <tag><em>nat_iiop_ssl_port</em></tag> - <item>If set, the value must be an integer greater than zero or - <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>. See also - <seealso marker="ch_install#firewall">Firewall Configuration</seealso>.</item> - <tag><em>ssl_server_options</em></tag> - <item>A list of the SSL options when Orber is the server. - In general it's just to remove the 'ssl_server_' prefix from the old options, - i.e. <c>ssl_server_verify</c> will just be <c>verify</c> in this option list. - See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible - options and their values. - </item> - <tag><em>ssl_client_options</em></tag> - <item>A list of the SSL options when Orber is the client. - In general it's just to remove the <c>ssl_client_</c> prefix from the old options, - i.e. <c>ssl_client_depth</c> will just be <c>depth</c> in this option list. - See the <seealso marker="ssl:ssl">SSL application</seealso> for the correct list of possible - options and their values. - </item> - <tag><em>iiop_ssl_out_keepalive</em></tag> - <item>Enables periodic transmission on a connected socket, when no other - data is being exchanged. If the other end does not respond, the - connection is considered broken and will be terminated. - When enabled the SO_KEEPALIVE socket level option is set. Requires that - the installed SSL version support the <em>keepalive</em> option - and that the <em>ssl_generation</em> points to this version.</item> - <tag><em>iiop_ssl_in_keepalive</em></tag> - <item>The same as for <c>iiop_ssl_out_keepalive</c>. The only difference is - that this option only affects incoming connections.</item> - </taglist> - <p>It is possible to invoke operations using the extra timeout parameter:</p> - <pre> -erl> module_interface:function(ObjRef, Timeout, ..Arguments..). -erl> module_interface:function(ObjRef, [{timeout, Timeout}], ..Arguments..). -erl> module_interface:function(ObjRef, ..Arguments..). </pre> - <p>The extra Timeout argument will override the configuration parameter - <c>iiop_timeout</c>. It is, however, not possible to use <c>infinity</c> - to override the Timeout parameter. The Timeout option is also valid for - objects which resides within the same <term id="Orber domain"><termdef>A domain containing several Erlang nodes, which are communicating by using the Erlang internal format. An Orber domain looks as one ORB from the environment.</termdef></term>.</p> - <p>The <c>iiop_setup_connection_timeout</c>, <c>iiop_timeout</c>, - <c>iiop_connection_timeout</c> and <c>iiop_in_connection_timeout</c> - variables should be used. The specified values is implementation specific, - i.e., WAN or LAN, but they should range from - <c>iiop_setup_connection_timeout</c> to <c>iiop_connection_timeout</c>.</p> - <p>To change these settings in the configuration file, the - <c>-config</c> flag must be added to the erl command. See the - Reference Manual - <em>config(4)</em> for further information. The values can also - be sent separately as - options to the Erlang node when it is started, see the Reference - Manual - <em>erl(1)</em> for further information. </p> - - <section> - <marker id="flags"></marker> - <title>Orber Environment Flags</title> - <p>The <c>Environment Flags</c> allows the user to activate debugging - facilities or change Orber's behavior. The latter may result in that - Orber is no longer compliant with the OMG standard, which may be necessary - when communicating with a non-compliant ORB.</p> - <table> - <row> - <cell align="left" valign="middle"><em>Hexadecimal Value</em></cell> - <cell align="left" valign="middle"><em>OMG Compliant</em></cell> - <cell align="left" valign="middle"><em>Description</em></cell> - </row> - <row> - <cell align="left" valign="middle">0001</cell> - <cell align="left" valign="middle">no</cell> - <cell align="left" valign="middle">Exclude CodeSet Component</cell> - </row> - <row> - <cell align="left" valign="middle">0002</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Local Typechecking</cell> - </row> - <row> - <cell align="left" valign="middle">0004</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Use Host Name in IOR</cell> - </row> - <row> - <cell align="left" valign="middle">0008</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Enable NAT</cell> - </row> - <row> - <cell align="left" valign="middle">0020</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Local Interceptors</cell> - </row> - <row> - <cell align="left" valign="middle">0080</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Light IFR</cell> - </row> - <row> - <cell align="left" valign="middle">0100</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Use IPv6</cell> - </row> - <row> - <cell align="left" valign="middle">0200</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">EXIT Tolerance</cell> - </row> - <row> - <cell align="left" valign="middle">0400</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Enable Incoming ACL</cell> - </row> - <row> - <cell align="left" valign="middle">0800</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Enable Outgoing ACL</cell> - </row> - <row> - <cell align="left" valign="middle">1000</cell> - <cell align="left" valign="middle">yes</cell> - <cell align="left" valign="middle">Use Current Interface in IOR</cell> - </row> - <tcaption>Orber Environment Flags</tcaption> - </table> - <p>Any combination of the flags above may be used and changes the - behavior as follows:</p> - <list type="bulleted"> - <item><em>Exclude CodeSet Component</em> - instruct Orber to exclude - the CodeSet component in exported IOR:s. When activated, no - negotiating regarding character and wide character conversions - between the client and the server will occur. This flag will, - most likely, cause problems if your IDL specification contains - the data types wchar and/or wstring.</item> - <item><em>Local Typechecking</em> - - If activated, parameters, replies and raised exceptions - will be checked to ensure that the data is correct. If an error - occurs, the <c>error_logger</c> is used to generate reports. - One <em>MAY NOT</em> use this option for delivered systems due - to the extra overhead. Since this option activates typechecking - for all objects generated on the target node, it is also possible - to use the option <c>{local_typecheck, boolean()}</c>, when - invoking <c>oe_create/2</c>, <c>oe_create_link/2</c>, - <c>corba:create/4</c> or <c>corba:create_link/4</c>, to override - the configuration parameter.</item> - <item><em>Use Host Name in IOR</em> - normally Orber inserts the IP-number - in IOR:s when they are exported. In some cases, this will cause - the clients to open two connections instead of one.</item> - <item><em>Enable NAT</em> - if this flag is set, it is possible to use - the NAT (Network Address Translation) configuration parameters - (<c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and - <c>nat_ip_address</c>).</item> - <item><em>Local Interceptors</em> - use interceptors for local - invocations.</item> - <item><em>Light IFR</em> - if the IFR is not explicitly used and this - flag is set, Orber will use a minimal IFR to reduce memory usage - and installation time.</item> - <item><em>Use IPv6</em> - when this option is activated, Orber will use - <c>IPv6</c> for inter-ORB communication.</item> - <item><em>EXIT Tolerance</em> - servers will survive even though the - call-back module caused an EXIT.</item> - <item><em>Enable Incoming ACL</em> - activates access control for incoming - connections.</item> - <item><em>Enable Outgoing ACL</em> - activates access control for outgoing - connections.</item> - <item><em>Use Current Interface in IOR</em> - when set, Orber will add - the interface the request came via to exported local IOR:s.</item> - </list> - <p>Invoking the operation - <seealso marker="orber">orber:info/1/2</seealso> will display the currently - set flags in a readable way.</p> - </section> - </section> - - <section> - <title>Firewall Configuration</title> - <marker id="firewall"></marker> - <p>Firewalls are used to protect objects from clients in other networks or - sub-networks, but also to restrict which hosts internal objects may connect to - (i.e. <c>inbound protection</c> and <c>outbound protection</c>). A firewall - can limit access based on:</p> - <list type="bulleted"> - <item><em>Transport Level</em> - performs access control decisions based on - address information in TCP headers.</item> - <item><em>Application Level</em> - understands GIOP messages and the specific - transport level inter-ORB Protocol supported e.g. IIOP.</item> - </list> - <p>This section describes how to configure a <c>Transport Level</c> firewall. It - must have prior knowledge of the source to destination mappings, and - conceptually has a configuration table containing tuples of the form: - <c>({inhost:inport}, {outhost:outport})</c>. If there are no port restrictions - it is rather easy to configure the firewall. Otherwise, we must consider the - following alternatives:</p> - <list type="bulleted"> - <item><em>Incoming Requests</em> - Orber only uses the port-numbers specified - by the configuration parameters <em>iiop_port</em> and - <em>iiop_ssl_port</em>. Other ORB's may use several ports but it should - be possible to change this behavior. Consult the other ORBs - documentation.</item> - <item><em>Outgoing Requests</em> - Most ORB's, Orber included, - ask the OS to supply a vacant local port when connecting to the - server-side ORB. It is possible to change this behavior when using - Orber (i.e. set the configuration parameter <em>iiop_out_ports</em>).</item> - </list> - <warning> - <p>Using the option <c>iiop_out_ports</c> may result in that Orber runs out of - valid ports numbers. For example, other applications may steal some of the - ports or the number of concurrent outgoing connections to other ORBs may be - higher than expected. To reduce, but not eliminate, the risk you should use - <c>iiop_connection_timeout</c>.</p> - </warning> - <p>Firewall configuration example:</p> - <pre> -# "Plain" IIOP -To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X -To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port) - -# IIOP via SSL -To: Orber-IPNo:(iiop_port) From: ORB-IPNo:X -To: Orber-IPNo:(iiop_ssl_port) From: ORB-IPNo:Y -To: ORB-IPNo:Z From: Orber-IPNo:(iiop_out_ports | Any Port) - </pre> - <p>If the communication take place via a - <seealso marker="ch_install#firewall_nat">TCP Firewall with NAT</seealso> - (Network Address Translation), we must activate this behavior and define - the external address and/or ports.</p> - <marker id="firewall_nat"></marker> - <image file="firewall_nat.gif"> - <icaption> -TCP Firewall With NAT</icaption> - </image> - <p>Using NAT makes it possible to use different host data for different network - domains. This way we can share Internet Protocol address resources or - obscure resources. To enable this feature the - <seealso marker="ch_install#flags">Enable NAT</seealso> flag must be set and - <c>nat_iiop_port</c>, <c>nat_iiop_ssl_port</c> and <c>nat_ip_address</c> - configured, which maps to <c>iiop_port</c>, <c>iiop_ssl_port</c> and - <c>ip_address</c> respectively. Hence, the firewall must be configured to - translate the external to the internal representation correctly. If these NAT parameters - are assigned a single port number or IP address, only those will be used when - an IOR is exported to another ORB. When <c>ip_address</c> is set to - <c>{multiple, [IPAddress]}</c>, <c>nat_ip_address</c> should be configured in the same - way, so that each NAT IP address can be translated to a valid address by the firewall. - If objects are supposed to be accessible via different interfaces and port, see also - <seealso marker="ch_install#interfaces">Interface Configuration</seealso>, - the options <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or - <c>{local, DefaultNATPort, [{Port, NATPort}]}</c> shall be used. The default NAT IP address - and port, should be translated to the value of <c>ip_address_local</c> and the default - listen port by the firewall. If the IP address and/or port is not found in the list, - the default values will be inserted in the IOR. The firewall must be able to translate - these correctly.</p> - <p>If it is necessary to limit the access to an ORB within a secure network, - but other applications running on the same host may not be blocked out, - one can use a <em>Application Level</em> firewall or Orber Access Control - List (ACL). The latter makes it possible for the user to define which hosts - may communicate, either as server or client, with Orber. This is achieved by - defining the configuration parameter - <seealso marker="ch_install#config">iiop_acl</seealso>. The Classless Inter - Domain Routing (CIDR) <c>Filter</c> determines which peer interfaces and - ports the other ORB may use.</p> - <table> - <row> - <cell align="left" valign="middle"><em>Filter</em></cell> - <cell align="left" valign="middle"><em>Peer Interface(s)</em></cell> - <cell align="left" valign="middle"><em>Peer Port(s)</em></cell> - </row> - <row> - <cell align="left" valign="middle">"10.1.1.1"</cell> - <cell align="left" valign="middle">10.1.1.1</cell> - <cell align="left" valign="middle">any</cell> - </row> - <row> - <cell align="left" valign="middle">"10.1.1.1/8"</cell> - <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell> - <cell align="left" valign="middle">any</cell> - </row> - <row> - <cell align="left" valign="middle">"10.1.1.1/8#4001"</cell> - <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell> - <cell align="left" valign="middle">4001</cell> - </row> - <row> - <cell align="left" valign="middle">"10.1.1.1/8#4001/5001"</cell> - <cell align="left" valign="middle">10.0.0.0-10.255.255.255</cell> - <cell align="left" valign="middle">4001-5001</cell> - </row> - <tcaption>Orber ACL Filters</tcaption> - </table> - <p>Orber ACL, also allows the user to define which local interface(s) may be used, - but will not detect <c>spoofing</c>. The operation - <seealso marker="orber_acl">orber_acl:match/2/3</seealso> makes it easy to - verify whether access would be granted or not. For example, if Orber would - be started with the ACL <c>[{tcp_out, "10.1.1.1/8#4001/5001"}]</c>, then - <c>orber_acl:match/2</c> would behave as follows:</p> - <code type="erl"> -erl> orber_acl:match({11,1,1,1}, tcp_out). -false - -erl> orber_acl:match({10,1,1,1}, tcp_out). -true - -erl> orber_acl:match({11,1,1,1}, tcp_out, true). -{false,[],0} - -erl> orber_acl:match({10,1,1,1}, tcp_out, true). -{true,[],{4001,5001}} - </code> - <p>Only if the returned boolean is true the extra return values makes a - difference. In the example above, <c>{true,[],{4001,5001}}</c> means that - Orber may connect to <c>"10.1.1.1"</c>, using any local interface, - if the server-side ORB listens for incoming connect requests on a port - within the range 4001-5001. Note, invoking the <c>orber_acl:match/2/3</c> - operation, will not result in a connect attempt by Orber. The reason for - this, is that this function may be used on a live node as well as in test - environment. Hence, if a local interface is currently not available or no - server-side ORB available via the given host/port(s), will not be detected - by Orber.</p> - </section> - - <section> - <title>Interface Configuration</title> - <marker id="interfaces"></marker> - <p>In many cases it is sufficient to simply configure the underlying OS which - local interfaces shall be used for all applications. But, in some cases - it is required, due to, for example, the firewall configuration, that different - local interfaces are used for different applications. Some times, it is even - necessary to use a specific interface for a single CORBA object. This section - describe how one can alter this in different ways.</p> - <p>The default behavior is that Orber lets the OS configuration decide which interface - will be added in IOR:s exported to another ORB and the local interface used - when connecting to another ORB (Orber act as client side ORB). The latter can be - overridden by setting the configuration parameters <c>iiop_ssl_ip_address_local</c> - and/or <c>ip_address_local</c>, which will affect IIOP via SSL and IIOP - respectively. These parameters can be overridden by using the Orber generic - <c>interface</c> Context or defining an ACL (Access Control List). The latter - always takes precedence if a local interface is included (e.g. - <c>[{tcp_out, "10.0.0.0/8", ["10.0.0.1"]}]</c>). If the interface is excluded - (e.g. <c>[{tcp_out, "10.0.0.0/8"}]</c>), the interface chosen will, in the following - order, be determined by - <c>#'IOP_ServiceContext'{}</c>, <c>ip_address_local/iiop_ssl_ip_address_local</c> or - the configuration of the underlying system.</p> - <p>Adding the interface context, for generated stubs/skeletons, is done in the - following way:</p> - <code type="erl"> -Ctx = #'IOP_ServiceContext'{context_id = ?ORBER_GENERIC_CTX_ID, - context_data = {interface, "10.0.0.1"}}, -'CosNaming_NamingContext':resolve(NS, [{context, [Ctx]}], Name), - </code> - <p>It is also possible to add the context to - <c>corba:string_to_object/2, corba:resolve_initial_references/2, corba:resolve_initial_references_remote/3, corba:list_initial_services_remote/2, corba_object:not_existent/2, corba_object:non_existent/2</c> and <c>corba_object:is_a/3</c>. - The operations exported by <c>corba_object</c> are affected - if the supplied IOR is external. The function <c>corba:string_to_object/2</c> - might require the interface context if a <c>corbaloc</c> or a <c>corbaloc</c> - string is passed (See the - <seealso marker="ch_naming_service#interop_ns">INS</seealso> chapter), - while <c>corba:resolve_initial_references_remote/3</c> and - <c>corba:list_initial_services_remote/2</c> always connect to another ORB and - it might be necessary to add the context. - The remaining <c>corba</c> operations are affected if calls are re-directed - by setting the <c>orbInitRef</c> and/or <c>orbDefaultInitRef</c> configuration - parameters. For more information, see the Reference Manual for each module.</p> - <p>Configuring which interface(s) that shall be used when exporting an IOR to - another ORB, is determined by <c>nat_ip_address</c>, setting the flag - <seealso marker="ch_install#flags">16#1000</seealso> - and <c>ip_address</c>, in that order. Orber listens for incoming connections - either via all interfaces or the interface defined by <c>ip_address</c>. It is - also possible to add and remove extra listen interfaces by using - <c>orber:add_listen_interface/2/3</c> and <c>orber:remove_listen_interface/1</c>. - In this case one should set the 16#1000 flag and, if necessary, set the - configuration parameters - <c>{local, DefaultNATIPAddress, [{IPAddress, NATIPAddress}]}</c> and/or - <c>{local, DefaultNATPort, [{Port, NATPort}]}</c>.</p> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_interceptors.xml b/lib/orber/doc/src/ch_interceptors.xml deleted file mode 100644 index 4a9f8e69ca..0000000000 --- a/lib/orber/doc/src/ch_interceptors.xml +++ /dev/null @@ -1,278 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>2001</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Orber Interceptors</title> - <prepared>Nick</prepared> - <docno></docno> - <date>2001-08-16</date> - <rev></rev> - <file>ch_interceptors.xml</file> - </header> - - <section> - <title>Using Interceptors</title> - <p>For Inter-ORB communication, e.g., via <c>IIOP</c>, it is possible - to intercept requests and replies. To be able to use <c>Interceptors</c> - Orber the configuration parameter <c>interceptors</c> must be defined.</p> - - <section> - <title>Configure Orber to Use Interceptors</title> - <p>The configuration parameter <c>interceptors</c> must be defined, e.g., - as command line option:</p> - <code type="none"> -erl -orber interceptors "{native, ['myInterceptor']}" - </code> - <p>It is possible to use more than one interceptor; simply add them to the - list and they will be invoked in the same order as they appear in the list.</p> - <p>One can also active and deactivate an interceptor during - run-time, but this will only affect currently existing connections. - For more information, consult Orber's Reference Manual regarding the - operations <c>orber:activate_audit_trail/0/1</c> and - <c>orber:activate_audit_trail/0/1.</c></p> - </section> - - <section> - <title>Creating Interceptors</title> - <p>Each supplied interceptor <em>must</em> export the following functions:</p> - <list type="bulleted"> - <item><em>new_out_connection/3/5</em> - one of these operations is called when - a client application calls an object residing on remote ORB. - If an interceptor exports both versions, arity 3 and 5, which - operation that will be invoked is Orber internal.</item> - <item><em>new_in_connection/3/5</em> - one of these operations is invoked - when a client side ORB tries to set up a connection to the target ORB. - If an interceptor exports both versions, arity 3 and 5, which - operation that will be invoked is Orber internal.</item> - <item><em>out_request/6</em> - supplies all request data on the client side - ORB.</item> - <item><em>out_request_encoded/6</em> - similar to <c>out_request</c> - but the request body is encode.</item> - <item><em>in_request_encoded/6</em> - after a new request arrives at the - target ORB the request data is passed to the interceptor in - encoded format.</item> - <item><em>in_request/6</em> - prior to invoking the operation on the - target object, the interceptor <c>in_request</c> is called.</item> - <item><em>out_reply/6</em> - after the target object replied the - <c>out_reply</c> operation is called with the result of the object - invocation.</item> - <item><em>out_reply_encoded/6</em> - before sending a reply back to the - client side ORB this operation is called with the result in - encoded format.</item> - <item><em>in_reply_encoded/6</em> - after the client side ORB receives - a reply this function is called with the reply in encoded - format.</item> - <item><em>in_reply/6</em> - before delivering the reply to the client - this operation is invoked.</item> - <item><em>closed_in_connection/1</em> - when a connection is terminated - on the client side this function is called.</item> - <item><em>closed_out_connection/1</em> - if an outgoing connection is - terminated this operation will be invoked.</item> - </list> - <p>The operations <c>new_out_connection</c>, <c>new_in_connection</c>, - <c>closed_in_connection</c> and <c>closed_out_connection</c> operations - are only invoked <em>once</em> per connection. The remaining operations - are called, as shown below, for every Request/Reply to/from remote - CORBA Objects.</p> - <marker id="interceptor_operations"></marker> - <image file="interceptor_operations.gif"> - <icaption> -The Invocation Order of Interceptor Functions.</icaption> - </image> - </section> - </section> - - <section> - <title>Interceptor Example</title> - <p>Assume we want to create a simple access service which purpose is to:</p> - <list type="bulleted"> - <item>Only allow incoming request from ORB's residing on a certain set of - nodes.</item> - <item>Restrict the objects any client may invoke operations on.</item> - <item>Only allow outgoing requests to call a limited set of external - ORB's.</item> - <item>Add a checksum to each binary request/reply body.</item> - </list> - <p>To restricts the access we use a <c>protected</c> and <c>named</c> ets-table - holding all information. How the ets-table is initiated and maintained - is implementation specific, but it contain - <c>{Node, ObjectTable, ChecksumModule}</c> where <c>Node</c> is used as - ets-key, <c>ObjectTable</c> is a reference to another ets-table in which - we store which objects the clients are allowed to invoke operations on - and <c>ChecksumModule</c> determines which module we should use to handle - the checksums. </p> - <code type="erl"> -new_in_connection(Arg, Host, Port) -> - %% Since we only use one interceptor we do not care about the - %% input Arg since it is set do undefined by Orber. - case ets:lookup(in_access_table, Host) of - [] -> - %% We may want to log the Host/Port to see if someone tried - %% to hack in to our system. - exit("Access not granted"); - [{Host, ObjTable, ChecksumModule}] -> - {ObjTable, ChecksumModule} - end. - </code> - <p>The returned tuple, i.e., {ObjTable, ChecksumModule}, will be passed - as the first argument whenever invoking one of the interceptor functions. - Unless the connection attempt did not fail we are now ready for receiving - requests from the client side ORB.</p> - <p>When a new request comes in the first interceptor function to be invoked is - <c>in_request_encoded</c>. We will remove the checksum from the coded - request body in the following way:</p> - <code type="erl"> -in_request_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:remove_checksum(Bin), - {NewBin, Extra}. - </code> - <p>If the checksum check fails the <c>ChecksumModule</c> should invoke exit/1. - But if the check succeeded we are now ready to check if the client-ORB - objects are allowed to invoke operations on the target object. Please note, - it is possible to run both checks in <c>in_request_encoded</c>. Please - note, the checksum calculation must be relatively fast to ensure a - good throughput.</p> - <p>If we want to we can restrict any clients to only use a subset of operations - exported by a server:</p> - <code type="erl"> -in_request({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Params, Extra) -> - case ets:lookup(ObjTable, {ObjKey, Op}) of - [] -> - exit("Client tried to invoke illegal operation"); - [SomeData] -> - {Params, Extra} - end. - </code> - <p>At this point Orber are now ready to invoke the operation on the target - object. Since we do not care about what the reply is the <c>out_reply</c> - function do nothing, i.e.:</p> - <code type="erl"> -out_reply(_, _, _, _, Reply, Extra) -> - {Reply, Extra}. - </code> - <p>If the client side ORB expects a checksum to be added to the reply we - add it by using:</p> - <code type="erl"> -out_reply_encoded({ObjTable, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:add_checksum(Bin), - {NewBin, Extra}. - </code> - <warning> - <p>If we manipulate the binary as above the behavior <em>must</em> - be <c>Bin == remove_checksum(add_checksum(Bin))</c>.</p> - </warning> - <p>For outgoing requests the principle is the same. Hence, it is not further - described here. The complete interceptor module would look like:</p> - <code type="erl"> --module(myInterceptor). - -%% Interceptor functions. --export([new_out_connection/3, - new_in_connection/3, - closed_in_connection/1, - closed_out_connection/1, - in_request_encoded/6, - in_reply_encoded/6, - out_reply_encoded/6, - out_request_encoded/6, - in_request/6, - in_reply/6, - out_reply/6, - out_request/6]). - -new_in_connection(Arg, Host, Port) -> - %% Since we only use one interceptor we do not care about the - %% input Arg since it is set do undefined by Orber. - case ets:lookup(in_access_table, Host) of - [] -> - %% We may want to log the Host/Port to see if someone tried - %% to hack in to our system. - exit("Access not granted"); - [{Host, ObjTable, ChecksumModule}] -> - {ObjTable, ChecksumModule} - end. - -new_out_connection(Arg, Host, Port) -> - case ets:lookup(out_access_table, Host) of - [] -> - exit("Access not granted"); - [{Host, ObjTable, ChecksumModule}] -> - {ObjTable, ChecksumModule} - end. - -in_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:remove_checksum(Bin), - {NewBin, Extra}. - -in_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) -> - case ets:lookup(ObjTable, {ObjKey, Op}) of - [] -> - exit("Client tried to invoke illegal operation"); - [SomeData] -> - {Params, Extra} - end. - -out_reply(_, _, _, _, Reply, Extra) -> - {Reply, Extra}. - -out_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:add_checksum(Bin), - {NewBin, Extra}. - -out_request({ObjTable, _}, ObjKey, Ctx, Op, Params, Extra) -> - case ets:lookup(ObjTable, {ObjKey, Op}) of - [] -> - exit("Client tried to invoke illegal operation"); - [SomeData] -> - {Params, Extra} - end. - -out_request_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:add_checksum(Bin), - {NewBin, Extra}. - -in_reply_encoded({_, ChecksumModule}, ObjKey, Ctx, Op, Bin, Extra) -> - NewBin = ChecksumModule:remove_checksum(Bin), - {NewBin, Extra}. - -in_reply(_, _, _, _, Reply, Extra) -> - {Reply, Extra}. - -closed_in_connection(Arg) -> - %% Nothing to clean up. - Arg. - -closed_out_connection(Arg) -> - %% Nothing to clean up. - Arg. - </code> - <note> - <p>One can also use interceptors for debugging purposes, e.g., - print which objects and operations are invoked with which arguments - and the outcome of the operation. In conjunction with the configuration - parameter <c>orber_debug_level</c> it is rather easy to find out what - went wrong or just to log the traffic. </p> - </note> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_introduction.xml b/lib/orber/doc/src/ch_introduction.xml deleted file mode 100644 index f04fedd0a7..0000000000 --- a/lib/orber/doc/src/ch_introduction.xml +++ /dev/null @@ -1,145 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Introduction to Orber</title> - <prepared>Megan Lynch</prepared> - <docno></docno> - <date>1998-09-21</date> - <rev></rev> - <file>ch_introduction.xml</file> - </header> - - <section> - <title>Overview</title> - <p>The Orber application is a CORBA compliant Object Request Brokers - (ORB), which provides CORBA functionality in an Erlang - environment. Essentially, the ORB channels communication or - transactions between nodes in a - heterogeneous environment. - </p> - <p><term id="CORBA"><termdef>Common Object Request Broker Architecture is a common communication standard developed by the OMG (Object Management Group)</termdef></term>(Common Object Request Broker - Architecture) provides an interface definition language allowing - efficient system integration and also supplies standard - specifications for some services. - </p> - <p>The Orber application contains the following parts:</p> - <list type="bulleted"> - <item> - <p>ORB kernel and IIOP support</p> - </item> - <item> - <p>Interface Repository</p> - </item> - <item> - <p>Interface Definition Language Mapping for Erlang</p> - </item> - <item> - <p>CosNaming Service</p> - </item> - </list> - - <section> - <title>Benefits</title> - <p>Orber provides CORBA functionality in an Erlang environment that enables: - </p> - <list type="bulleted"> - <item> - <p><em>Platform interoperability and transparency</em></p> - <p>Orber enables communication between - OTP applications or Erlang environment applications and - other platforms; for example, Windows NT, Solaris - etc, allowing platform transparency. This is especially helpful in situations where there - are many users with different platforms. For example, - booking airline tickets would require the airline database - and hundreds of travel agents (who may not have the same - platform) to book seats on flights. </p> - </item> - <item> - <p><em>Application level interoperability and transparency</em></p> - <p>As Orber is a CORBA compliant application, its purpose is - to provide interoperability and transparency on the application - level. - Orber simplifies the distributed system software by defining the - environment as objects, which in effect, views - everything as identical regardless of programming - languages. <br></br> - Previously, time-consuming programming was - required to facilitate communication between different languages. - However, with CORBA compliant Orber the Application - Programmer is relieved of this task. This makes - communication on an application level relatively transparent to the user.</p> - </item> - </list> - </section> - - <section> - <title>Purpose and Dependencies</title> - <p>The system architecture and OTP dependencies of Orber are illustrated in figure 1 below:</p> - <marker id="dependent"></marker> - <image file="dependent.gif"> - <icaption> -Figure 1: Orber Dependencies and Structure.</icaption> - </image> - <p>Orber is dependent on Mnesia (see the Mnesia - documentation) - an Erlang database management application - used to store object information.</p> - <note> - <p>Although Orber does not have a run-time - application dependency to IC (an <term id="IDL"><termdef>Interface Definition Language - IDL is the OMG specified interface definition language, used to define the CORBA object interfaces.</termdef></term>compiler for - Erlang), it is necessary when building - services and applications. See the IC documentation for - further details.</p> - </note> - <marker id="orbs"></marker> - <image file="orbs.gif"> - <icaption> -Figure 2: ORB interface between Java and Erlang Environment Nodes.</icaption> - </image> - <p>This simplified illustration in figure 2 demonstrates how Orber can facilitate communication in a heterogeneous environment. The Erlang Nodes running - OTP and the other Node running applications written in Java can - communicate via an <term id="ORB"><termdef>Object Request Broker - ORB open software bus architecture specified by the OMG which allows object components to communicate in a heterogeneous environment.</termdef></term>(Object Request Broker). Using - Orber means that CORBA functions can be used to achieve this - communication. - </p> - <p>For example, if one of the above nodes requests an object, it does not - need to know if that object is located on the same, or - different, Erlang or Java nodes. The ORB will channel the - information creating platform and application transparency for - the user. - </p> - </section> - - <section> - <title>Prerequisites</title> - <p>To fully understand the concepts presented in the - documentation, it is recommended that the user is familiar - with distributed programming and CORBA (Common Object Request - Broker Architecture). - </p> - <p>Recommended reading includes <em>Open Telecom Platform Documentation Set</em> and <em>Concurrent Programming in Erlang</em>. - </p> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_naming_service.xml b/lib/orber/doc/src/ch_naming_service.xml deleted file mode 100644 index 991402ae86..0000000000 --- a/lib/orber/doc/src/ch_naming_service.xml +++ /dev/null @@ -1,465 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>CosNaming Service</title> - <prepared></prepared> - <docno></docno> - <date>1998-10-10</date> - <rev></rev> - <file>ch_naming_service.xml</file> - </header> - - <section> - <title>Overview of the CosNaming Service</title> - <p>The CosNaming Service is a service developed to help users and - programmers identify objects by human readable names rather than by a - reference. By binding a name to a naming context (another object), a - contextual reference is formed. This is helpful when navigating in the - object space. In addition, identifying objects by name allows you to evolve - and/or relocate objects without client code modification.</p> - <p>The CosNaming service has some concepts that are important:</p> - <list type="bulleted"> - <item> - <p><em>name binding</em> - a name to object association.</p> - </item> - <item> - <p><em>naming context</em> - is an object that contains a set of - name bindings in which each name is unique. Different names can be - bound to the same object. - </p> - </item> - <item> - <p><em>to bind a name</em> - is to create a name binding in a given - context.</p> - </item> - <item> - <p><em>to resolve a name</em> - is to determine the object associated - with the name in a given context.</p> - </item> - </list> - <p>A name is always resolved in a context, there no absolute names exist. - Because a context is like any other object, it can also be bound to - a name - in a naming context. - This will result in a naming graph (a directed graph with notes and - labeled edges). The graph allows more complex names to refer to an - object. Given a context, you can use a sequence to reference an object. - This sequence is henceforth referred to as <em>name</em> and the - individual - elements in the sequence as <em>name components</em>. All but the - last name component are bound to naming contexts. - </p> - <p>The diagram in figure 1 illustrates how the Naming Service provides a - contextual relationship between objects, NamingContexts and - NameBindings to create an object locality, as the - object itself, has no name. - </p> - <marker id="name"></marker> - <image file="name.gif"> - <icaption> -Figure 1: Contextual object relationships using the Naming Service.</icaption> - </image> - <p>The naming contexts provide a directory of contextual - reference and naming for objects (an object can appear to - have more than one name). - </p> - <p>In figure 1 the object to the right can either be - called <c>alpha</c> from one context or <c>gamma</c> from another. - </p> - <p>The Naming Service has an initial naming context, which is shown - in the diagram as the top-most object in the naming graph. - It has two names <c>beta</c> and <c>epsilon</c>, which are bound to other - naming contexts. The initial naming context is a well known location - used to share a common name space between multiple programs. - You can traverse the naming graph until you reach a name, which is - bound to an object, which is not a naming context. - </p> - <p>We recommend reading <em>chapter 12, CORBA Fundamentals and Programming</em>, for detailed information regarding the - Naming Service. </p> - </section> - - <section> - <title>The Basic Use-cases of the Naming Service</title> - <p>The basic use-cases of the Naming Service are: - </p> - <list type="bulleted"> - <item>Fetch initial reference to the naming service.</item> - <item>Creating a naming context.</item> - <item>Binding and unbinding names to objects.</item> - <item>Resolving a name to an object.</item> - <item>Listing the bindings of a naming context.</item> - <item>Destroying a naming context.</item> - </list> - - <section> - <title>Fetch Initial Reference to the Naming Service</title> - <p>In order to use the naming service you have to fetch an - initial reference to it. This is done with:</p> - <code type="erl"> -NS = corba:resolve_initial_references("NameService"). - </code> - <note> - <p>NS in the other use-cases refers to this initial reference.</p> - </note> - </section> - - <section> - <title>Creating a Naming Context</title> - <p>There are two functions for creating a naming context. - The first function, which only creates a naming context object is:</p> - <code type="erl"> -NC = 'CosNaming_NamingContext':new_context(NS). - </code> - <p>The other function creates a naming context and binds it to a name in - an already existing naming context (the initial context in this - example): - </p> - <code type="erl"> -NC = 'CosNaming_NamingContext':bind_new_context(NS, lname:new(["new"])). - </code> - </section> - - <section> - <title>Binding and Unbinding Names to Objects</title> - <p>The following steps illustrate how to bind/unbind an object reference - to/from a name. For the example below, assume that the NamingContexts - in the path are already bound to the name <c>/workgroup/services</c>, - and that reference to the services context are in the variable - <c>Sc</c>.</p> - <list type="ordered"> - <item> - <p>Use the naming library functions to create a name</p> - <code type="erl"> -Name = lname:new(["object"]). - </code> - </item> - <item> - <p>Use CosNaming::NamingContext::bind() to bind a name to an object</p> - <code type="erl"> -'CosNaming_NamingContext':bind(Sc, Name, Object). - </code> - </item> - <item> - <p>Use CosNaming::NamingContext::unbind() to remove the NameBinding from an object</p> - <code type="erl"> -'CosNaming_NamingContext':unbind(Sc, Name). - </code> - </item> - </list> - <note> - <p>Objects can have more than one name, to indicate different paths to - the same object.</p> - </note> - </section> - - <section> - <title>Resolving a Name to an Object</title> - <p>The following steps show how to retrieve the object reference to the service context - above (/workgroup/services). </p> - <list type="ordered"> - <item> - <p>Use the naming library functions to create a name path:</p> - <code type="erl"> -Name = lname:new(["workgroup", "services"]). - </code> - </item> - <item> - <p>Use CosNaming::NamingContext::resolve() to to resolve the name to an object</p> - <code type="erl"> -Sc = 'CosNaming_NamingContext':resolve(NS, Name). - </code> - </item> - </list> - <p>An alternative is to use:</p> - <code type="erl"> -Sc = corba:string_to_object("corbaname:rir:/NameService#workgroup/services/"). - </code> - <p>The <c>corbaname</c> schema is described further in the Interoperable - Naming Service section.</p> - </section> - - <section> - <title>Listing the Bindings in a NamingContext</title> - <list type="ordered"> - <item> - <p>Use CosNaming::NamingContext::list() to list all the bindings in a context</p> - <p>The following code retrieves and lists up to 10 bindings from a context.</p> - <code type="erl"> -{BList, BIterator} = 'CosNaming_NamingContext':list(Sc, 10). - -lists:foreach(fun({{Id, Kind},BindingType}) -> case BindingType of - nobject -> - io:format("id: %s, kind: %s, type: object~n", [Id, Kind]); - _ -> - io:format("id: %s, kind: %s, type: ncontext~n", [Id, Kind]) - end end, - Blist). - </code> - </item> - </list> - <note> - <p>Normally a <term id="BindingIterator"><termdef>The binding iterator (Like a book mark) indicates which objects have been read from the list.</termdef></term>is helpful in situations where you have a large number of objects - in a list, as the programmer then can traverse it more easily. - In Erlang it is not needed, because lists are easily handled in the - language itself.</p> - </note> - <warning> - <p>Remember that the BindingIterator (BIterator in the example) is an object and therefore - <em>must be removed</em> otherwise dangling processes will occur. - Use <c>CosNaming::BindingIterator::destroy()</c> to remove it.</p> - </warning> - <code type="erl"> -'CosNaming_NamingContext':destroy(BIterator). - </code> - </section> - - <section> - <title>Destroying a Naming Context</title> - <p>The naming contexts are persistent and must be explicitly removed. - (they are also removed if all Orber nodes in the domain are stopped).</p> - <list type="ordered"> - <item> - <p>Use CosNaming::NamingContext::destroy() to remove a NamingContext</p> - <code type="erl"> -'CosNaming_NamingContext':destroy(Sc). - </code> - </item> - </list> - </section> - </section> - - <section> - <title>Interoperable Naming Service</title> - <marker id="interop_ns"></marker> - <p>The OMG specifies URL schemes, which represent a CORBA object and a CORBA object - bound in a NamingContext, for resolving references from other ORB:s. As of today, - three schemes are defined:</p> - <list type="bulleted"> - <item>IOR</item> - <item>corbaloc</item> - <item>corbaname</item> - </list> - - <section> - <title>IOR</title> - <p>A stringified IOR is a valid URL format but difficult for humans to handle - through non-electronic means. This URL format does not depend on a specific - Name Service and, thus, is robust and insulates the client from the encapsulated - transport information and object key used to reference the object.</p> - </section> - - <section> - <title>corbaloc</title> - <p>The notation of this scheme is similar to the more well known URL <c>HTTP</c>, and - the full <c>corbaloc</c> BNF is:</p> - <code type="none"><![CDATA[ -<corbaloc> = "corbaloc:"<obj_addr_list>["/"<key_string>] -<obj_addr_list> = [<obj_addr>","]*<obj_addr> -<obj_addr> = <prot_addr> | <future_prot_addr> -<prot_addr> = <rir_prot_addr> | <iiop_prot_addr> -<rir_prot_addr> = <rir_prot_token>":" -<rir_prot_token> = rir -<future_prot_addr> = <future_prot_id><future_prot_addr> -<future_prot_id> = <future_prot_token>":" -<iiop_prot_addr> = <iiop_id><iiop_addr> -<iiop_id> = <iiop_default> | <iiop_prot_token>":" -<iiop_default> = ":" -<iiop_prot_token> = "iiop" -<iiop_addr> = <version><host>[":"<port>] -<host> = <DNS-style Host Name> | <ip_v4_address> | "["<ip_v6_address>"]" -<version> = <major>"."<minor>"@" | empty_string -<port> = number -<major> = number -<minor> = number -<DNS-style Host Name> = string -<ip_v4_address> = string -<ip_v6_address> = string -<key_string> = for example NameService - ]]></code> - <p>The <c>corbaloc</c> scheme consists of 3 parts:</p> - <list type="bulleted"> - <item>Protocol - as of today <c>iiop</c> or <c>rir</c> is supported. - Using <c>rir</c> means that we will resolve the given Key locally, i.e., - the same as using <c>corba:resolve_initial_references("NameService").</c></item> - <item>IIOP address - this address can be divided into <c>Version</c>, <c>Host</c> - and <c>Port</c>. If the version or port are left out they will be set to the default - values <c>1.0</c> and <c>2809</c> respectively.</item> - <item>KeyString - an object key, e.g., "NameService". If no Key is - supplied the default value "NameService" will be used.</item> - </list> - <p>A <c>corbaloc</c> can be passed used together with - <c>corba:string_to_object("corbaloc::[email protected]:4001/NameService")</c> or set as the - configuration variables <c>orbInitilRef</c> or <c>orbDefaultInitilRef</c> and calling - <c>corba:resolve_initial_references("NameService")</c>. For more information see the Orber - installation chapter. <c>corbaloc</c> can also be used together with <c>corbaname</c> - to gain an easy access to a Name Service.</p> - <p>Currently, the OMG defines a set of reserved keys and the type of object, - listed below, they should be associated with. The <c>NameService</c> - key may <em>not</em> be changed in Orber. If you want to add one of the - reserved keys as an initial service, simply use:</p> - <code type="erl"> -1> Factory = cosNotificationApp:start_global_factory(). -2> corba:add_initial_service("NotificationService", Factory). - </code> - <p>This object can then be easily resolved by any other ORB, supporting - the Interoperable Naming Service, by using:</p> - <code type="erl"> -3> NF = corba:string_to_object("corbaloc::[email protected]:4001/NotificationService"). - </code> - <table> - <row> - <cell align="center" valign="middle"><em>String Name</em></cell> - <cell align="center" valign="middle"><em>Object Type</em></cell> - </row> - <row> - <cell align="left" valign="middle">RootPOA</cell> - <cell align="left" valign="middle">PortableServer::POA</cell> - </row> - <row> - <cell align="left" valign="middle">POACurrent</cell> - <cell align="left" valign="middle">PortableServer::Current</cell> - </row> - <row> - <cell align="left" valign="middle">InterfaceRepository</cell> - <cell align="left" valign="middle">CORBA::Repository</cell> - </row> - <row> - <cell align="left" valign="middle">NameService</cell> - <cell align="left" valign="middle">CosNaming::NamingContext</cell> - </row> - <row> - <cell align="left" valign="middle">TradingService</cell> - <cell align="left" valign="middle">CosTrading::Lookup</cell> - </row> - <row> - <cell align="left" valign="middle">SecurityCurrent</cell> - <cell align="left" valign="middle">SecurityLevel1::Current/SecurityLevel2::Current</cell> - </row> - <row> - <cell align="left" valign="middle">TransactionCurrent</cell> - <cell align="left" valign="middle">CosTransaction::Current</cell> - </row> - <row> - <cell align="left" valign="middle">DynAnyFactory</cell> - <cell align="left" valign="middle">DynamicAny::DynAnyFactory</cell> - </row> - <row> - <cell align="left" valign="middle">ORBPolicyManager</cell> - <cell align="left" valign="middle">CORBA::PolicyManager</cell> - </row> - <row> - <cell align="left" valign="middle">PolicyCurrent</cell> - <cell align="left" valign="middle">CORBA::PolicyCurrent</cell> - </row> - <row> - <cell align="left" valign="middle">NotificationService</cell> - <cell align="left" valign="middle">CosNotifyChannelAdmin::EventChannelFactory</cell> - </row> - <row> - <cell align="left" valign="middle">TypedNotificationService</cell> - <cell align="left" valign="middle">CosTypedNotifyChannelAdmin::TypedEventChannelFactory</cell> - </row> - <row> - <cell align="left" valign="middle">CodecFactory</cell> - <cell align="left" valign="middle">IOP::CodecFactory</cell> - </row> - <row> - <cell align="left" valign="middle">PICurrent</cell> - <cell align="left" valign="middle">PortableInterceptors::Current</cell> - </row> - <tcaption>Currently reserved key strings</tcaption> - </table> - </section> - - <section> - <title>corbaname</title> - <p>The <c>corbaname</c> URL scheme is an extension of the <c>corbaloc</c> scheme, and - the full <c>corbaname</c> BNF is:</p> - <code type="none"><![CDATA[ -<corbaname> = "corbaname:"<obj_addr_list>["/"<key_string>]["#"<string_name>] -<obj_addr_list> = as described above. -<key_string> = as described above. - ]]></code> - <p>The <c>string_name</c>, concatenated to the <c>corbaloc</c> string, identifies - a binding in a naming context. A name component consists of two parts, i.e., - <c>id</c> and <c>kind</c>, which is represented as follows:</p> - <table> - <row> - <cell align="center" valign="middle"><em>String Name</em></cell> - <cell align="center" valign="middle"><em>Name Sequence</em></cell> - <cell align="center" valign="middle"><em>Comment</em></cell> - </row> - <row> - <cell align="left" valign="middle">"id1/./id3.kind3"</cell> - <cell align="left" valign="middle">[{"id1",""},{"",""},{"id3","kind3"}]</cell> - <cell align="left" valign="middle">The first component has no kind defined while the second component's both fields are empty.</cell> - </row> - <row> - <cell align="left" valign="middle">"id1//id3.kind3"</cell> - <cell align="left" valign="middle">ERROR</cell> - <cell align="left" valign="middle">Not allowed, must insert a '.' between the '//'.</cell> - </row> - <row> - <cell align="left" valign="middle">"id1.kind1/."</cell> - <cell align="left" valign="middle">[{"id1","kind1"},{"",""}]</cell> - <cell align="left" valign="middle">The first component's fields are both set while the second component's both fields are empty.</cell> - </row> - <row> - <cell align="left" valign="middle">"id1.kind1/id2."</cell> - <cell align="left" valign="middle">ERROR</cell> - <cell align="left" valign="middle">An Id with a trailing '.' is not allowed.</cell> - </row> - <row> - <cell align="left" valign="middle">"i\\/d1/i\\.d2"</cell> - <cell align="left" valign="middle">[{"i/d1",""},{"i.d2",""}]</cell> - <cell align="left" valign="middle">Since '.' and '/' are used to separate the components, these tokens must be escaped to be correctly converted.</cell> - </row> - <tcaption>Stringified Name representation</tcaption> - </table> - <p>After creating a stringified Name we can either use:</p> - <code type="erl"> -NameStr = "org.erlang", -NS = corba:resolve_initial_references("NameService"), -Obj = 'CosNaming_NamingContextExt':resolve_str(NS, NameStr), - </code> - <p>or concatenate the Name String using:</p> - <code type="erl"> -NameStr = "Swedish/Soccer/Champions", -Address = "corbaname:iiop:[email protected]:2000/NameService", -NS = corba:resolve_initial_references("NameService"), -URLStr = 'CosNaming_NamingContextExt':to_url(NS, Address, NameStr), -Obj = corba:string_to_object(URLStr), - </code> - <p>Using the first alternative, the configuration variables <c>orbInitilRef</c> and - <c>orbDefaultInitilRef</c>, will determine which other ORB's or the local - Name Service Orber will try to resolve the given string from. The second - alternative allows us to override any settings of the configuration variables.</p> - <p>The function <c>to_url/3</c> will perform any necessary escapes compliant with - IETF/RFC 2396. US-ASCII alphanumeric characters and - <c><![CDATA["," | "/" | ":" | "?" | "@" | "&" | "=" | "+" | "$" | ";" | "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"]]></c> - are not escaped.</p> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_orber_kernel.xml b/lib/orber/doc/src/ch_orber_kernel.xml deleted file mode 100644 index 396e1360fd..0000000000 --- a/lib/orber/doc/src/ch_orber_kernel.xml +++ /dev/null @@ -1,103 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>The Orber Application</title> - <prepared></prepared> - <docno></docno> - <date>1998-10-05</date> - <rev></rev> - <file>ch_orber_kernel.xml</file> - </header> - - <section> - <title>ORB Kernel and IIOP </title> - <p>This chapter gives a brief overview of the ORB and its relation - to objects in a distributed environment and the usage of Domains - in Orber. - Also Internet-Inter ORB Protocol (<term id="IIOP"><termdef>Internet-Inter ORB Protocol</termdef></term>) is discussed and how this - protocol facilitates communication between ORBs to - allow the accessory of persistent server objects in Erlang. </p> - </section> - - <section> - <title>The Object Request Broker (ORB)</title> - <p>An ORB kernel can be best described as the middle-ware, which - creates relationships between clients and servers, but is - defined by its interfaces. This allows transparency for the - user, as they do not have to be aware of where the requested - object is located. Thus, the programmer can work with any other - platform provided that an IDL mapping and interfaces exist. - </p> - <p>The IDL mapping which is described in a later chapter is the - translator between other platforms, and languages. However, it - is the ORB, which provides objects with a structure by which - they can communicate with other objects. - </p> - <p>ORBs intercept and direct messages from one object, pass this - message using IIOP to another ORB, which then directs the - message to the indicated object. - </p> - <p>An ORB is the base on which interfaces, communication stubs - and mapping can be built to enable communication between - objects. Orber uses <term id="domains"><termdef>A domain allows a more efficient communication protocol to be used between objects not on the same node without the need of an ORB</termdef></term>to group objects of different nodes - </p> - <p>How the ORB provides communication is shown very simply in figure 1 below: </p> - <marker id="theORB"></marker> - <image file="theORB.gif"> - <icaption> -Figure 1: How the Object Request Broker works.</icaption> - </image> - <p>The domain in Orber gives an extra aspect to the distributed object - environment as each domain has one ORB, but it is distributed over - a number of object in different nodes. The domain binds objects on - nodes more closely than distributed objects in different domains. The - advantage of a domain is that a faster communication exists between - nodes and objects of the same domain. An internal communication protocol - (other than IIOP) allows a - more efficient communication between these objects. </p> - <note> - <p>Unlike objects, domains can only have one name - so that no communication ambiguities exist between domains.</p> - </note> - </section> - - <section> - <title>Internet Inter-Object Protocol (IIOP)</title> - <p>IIOP is a communication protocol developed by the OMG to - facilitate communication in a distributed object-oriented - environment. - </p> - <p>Figure 2 below demonstrates how IIOP works between objects:</p> - <marker id="iiop"></marker> - <image file="iiop.gif"> - <icaption> -Figure 2: IIOP communication between domains and objects.</icaption> - </image> - <note> - <p>Within the Orber domains the objects communicate without - using the IIOP. However, the user is unaware of the difference in protocols, as this difference is not visible. </p> - </note> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_orberweb.xml b/lib/orber/doc/src/ch_orberweb.xml deleted file mode 100644 index c9dcc382e6..0000000000 --- a/lib/orber/doc/src/ch_orberweb.xml +++ /dev/null @@ -1,221 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>2001</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>OrberWeb</title> - <prepared>Nick</prepared> - <docno></docno> - <date>2001-11-22</date> - <rev></rev> - <file>ch_orberweb.xml</file> - </header> - - <section> - <title>Using OrberWeb</title> - <p><c>OrberWeb</c> is intended to make things easier when developing and - testing applications using <c>Orber</c>. The user is able to interact - with <c>Orber</c> via a GUI by using a web browser.</p> - <p><c>OrberWeb</c> requires that the application <c>WebTool</c> is available and - started on at least one node; if so <c>OrberWeb</c> can usually be used to - to access <c>Orber</c> nodes supporting the Interoperable Naming - Service. How to start OrberWeb is described in - <seealso marker="ch_orberweb#startorberweb">Starting OrberWeb</seealso></p> - <p>The <c>OrberWeb</c> GUI consists of a <em>Menu Frame</em> and a - <em>Data Frames</em>.</p> - - <section> - <title>The Menu Frame</title> - <p>The menu frame consists of:</p> - <list type="bulleted"> - <item><em>Node List</em> - which node to access.</item> - <item><em>Configuration</em> - see how Orber on the current node is configured.</item> - <item><em>Name Service</em> - browse the NameService and add/remove a Context/Object.</item> - <item><em>IFR Types</em> - see which types are registered in IFR.</item> - <item><em>Create Object</em> - create a new object and, possibly, store it in the NameService.</item> - </list> - <p></p> - <marker id="menuframe"></marker> - <image file="menuframe.gif"> - <icaption>The Menu Frame.</icaption> - </image> - <p>Which nodes we can access is determined by what is returned when invoking <c>[node()|nodes()]</c>. - If you cannot see a desired node in the list, you have to call <c>net_adm:ping(Node)</c>. - But this requires that the node is started with the distribution switched on - (e.g. <c>erl -sname myNode</c>); this also goes for the node <c>OrberWeb</c> is running on.</p> - </section> - - <section> - <title>The Configuration Data Frame</title> - <p>When accessing the <em>Configuration</em> page OrberWeb presents a table containing the - <seealso marker="ch_install#config">configuration settings</seealso> for the target node.</p> - <p></p> - <marker id="dataframe3"></marker> - <image file="dataframe3.gif"> - <icaption>Configuration Settings.</icaption> - </image> - <p>It is also possible to change those configuration parameters which can be changed when Orber - is already started. The Key-Value pairs is given as a list of tuples, e.g., - <em>[{orber_debug_level, 5}, {iiop_timeout, 60}, {giop_version, {1,2}}]</em>. If one tries to update a parameter - which may not be changed an error message will be displayed.</p> - </section> - - <section> - <title>The IFR Data Frame</title> - <p>All types registered in the IFR (Interface Repository) which have an associated IFR-id - can be viewed via the IFR Data Frame. This gives the user an easy way to confirm that - all necessary IDL-specifications have been properly registered. All available types are - listed when choosing <c>IFR Types</c> in the menu frame:</p> - <p></p> - <marker id="dataframe1"></marker> - <image file="dataframe1.gif"> - <icaption>Select Type.</icaption> - </image> - <p>After selecting a type all definitions of that particular type will be displayed. If no such - bindings exists the table will be empty.</p> - <p>Since Orber adds definitions to the IFR when it is installed (e.g. CosNaming), not only - types defined by the user will show up in the table. In the figure below you find the - the NameService exceptions listed.</p> - <p></p> - <marker id="dataframe2"></marker> - <image file="dataframe2.gif"> - <icaption>List Registered Exceptions.</icaption> - </image> - </section> - - <section> - <title>The NameService Data Frame</title> - <p>The NameService main purpose is to make possible to bind object references, which - can client applications can resolve and invoke operations on. Initially, the NameService - is empty. The most common scenario, is that user applications create Contexts and add objects - in the NameService. OrberWeb allows the user to do the very same thing.</p> - <p>When referencing an object or context you must use stringified NameComponents. - For more information see the <seealso marker="ch_naming_service">Interoperable Naming Service</seealso>. - In the following example we will use the string <em>org/erlang/TheObjectName</em>, where - <em>org</em> and <em>erlang</em> will be contexts and <em>TheObjectName</em> - the name the object will be bound to.</p> - <p>Since the NameService is empty in the beginning, the only thing we can do is creating - a new context. Simply write <em>org</em> in the input field and press <c>New Context</c>. - If OrberWeb was able to create the context or not, is shown in the completion message. - If successful, just press the <c>Go Back</c> button. Now, a link named <em>org</em> should - be listed in the table. In the right column the context type is displayed. Contexts are - associated with <em>ncontext</em> and objects with <em>nobject</em>.</p> - <p></p> - <marker id="dataframe5"></marker> - <image file="dataframe5.gif"> - <icaption>Add a New Context.</icaption> - </image> - <p>To create the next level context (i.e. erlang), simply follow the link and repeat the procedure. - If done correctly, a table containing the same data as the following figure should be the result - if you follow the <em>erlang</em> link. Note, that the path is displayed in the yellow - field.</p> - <p></p> - <p>If a context does not contain any sub-contexts or object bindings, it is possible to - delete the context. If these requirements are met, a <c>Delete Context</c> button will appear. - A completion status message will be displayed after deleting the context.</p> - <p></p> - <marker id="dataframe6"></marker> - <image file="dataframe6.gif"> - <icaption>Delete Context.</icaption> - </image> - <p>Now it is possible to bind an object using the complete name string. To find out how this is - done using OrberWeb see <seealso marker="ch_orberweb#create">Object Creation</seealso>. - For now, we will just assume that an object have been created and bound as <em>TheObjectName</em>. </p> - <p></p> - <marker id="dataframe7"></marker> - <image file="dataframe7.gif"> - <icaption>Object Stored in the NameService.</icaption> - </image> - <p>If you follow the <em>TheObjectName</em> link, data about the bound object will be - presented. Note, depending on which type of object it is, the information given differs. - It would, for example, not be possible to display a Pid for all types of objects since - it might reside on a Java-ORB. In the figure below a CosNotification FilterFactory have - been bound under the name <em>org/erlang/TheObjectName</em>.</p> - <p></p> - <marker id="dataframe8"></marker> - <image file="dataframe8.gif"> - <icaption>Object Data.</icaption> - </image> - <p>OrberWeb also makes it possible to remove a binding and dispose the associated object. - Pressing <em>Unbind</em> the binding will be removed but the object will still exist. - But, if the <em>Unbind and Dispose</em> button is pressed, the binding will be removed - and the object terminated.</p> - </section> - - <section> - <title>The Object Creation Data Frame</title> - <marker id="create"></marker> - <p>This part makes it possible to create a new object and, if wanted, store it the - NameService.</p> - <p></p> - <marker id="dataframe4"></marker> - <image file="dataframe4.gif"> - <icaption>Create a New Object.</icaption> - </image> - <list type="bulleted"> - <item><em>Module</em> - simply type the name of the module of the object type - you want to create. If the module begins with a capital letter, we normally must - write <c>'Module_Interface'</c>. But, when using OrberWeb, you shall <em>NOT</em>. - Since we cannot create linked objects this is not an option.</item> - <item><em>Arguments</em> - the supplied arguments must be written as a single Erlang term. - That is, as a list or tuple containing other Erlang terms. The arguments will be - passed to the <c>init</c> function of the object. It is, however, not possible - to use Erlang records. If OrberWeb is not able to parse the arguments, an error message - will be displayed. If left empty, an empty list will be passed.</item> - <item><em>Options</em> - the options can be the ones listed under - <seealso marker="Module_Interface">Module_Interface</seealso> in Orber's Reference manual. - Hence, they are not further described here. But, as an example, in the figure above - we started the object as globally registered. If no options supplied the object - will be started as default.</item> - <item><em>Name String</em> - if left empty the object will <em>not</em> be registered in the - NameService. Hence, it is important that you can access the object in another way, - otherwise a zombie process is created. In the previous section we used the name string - <em>org/erlang/TheObjectName</em>. If we choose the same name here, the listed contexts - (i.e. <em>org</em> and <em>erlang</em>) must be created <em>before</em> we can create - and bind the object to <em>TheObjectName</em>. If this requirement is not met, OrberWeb - cannot bind the object. Hence, the object will be terminated and an error message - displayed.</item> - <item><em>Operation to use</em> - which option choosed will determine the behavior of OrberWeb. - If you choose <em>bind</em> and a binding already exists an error message will be - displayed and the newly started object terminated. But if you choose <em>rebind</em> - any existing binding will over-written.</item> - </list> - </section> - </section> - - <section> - <title>Starting OrberWeb</title> - <marker id="startorberweb"></marker> - <p>You may choose to start OrberWeb on node, on which Orber is running or not. But - the Erlang distribution must be started (e.g. by using -sname aNodeName). Now, all - you have to do is to invoke:</p> - <code type="none"> -erl> webtool:start(). -WebTool is available at http://localhost:8888/ -Or http://127.0.0.1:8888/ - </code> - <p>Type one of the URL:s in your web-browser. If you want to access the WebTool application - from different machine, just replace <c>localhost</c> with its name. For more information, - see the WebTool documentation.</p> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_security.xml b/lib/orber/doc/src/ch_security.xml deleted file mode 100644 index 151e417079..0000000000 --- a/lib/orber/doc/src/ch_security.xml +++ /dev/null @@ -1,96 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>How to use security in Orber</title> - <prepared></prepared> - <docno></docno> - <date>1999-09-01</date> - <rev></rev> - <file>ch_security.xml</file> - </header> - - <section> - <title>Security in Orber</title> - - <section> - <title>Introduction</title> - <p>Orber SSL provides authentication, privacy and integrity for your - Erlang applications. Based on the Secure Sockets Layer protocol, the - Orber SSL ensures that your Orber clients and servers can - communicate securely over any network. - This is done by tunneling IIOP through an SSL connection. To get - the node secure you will also need to have a firewall which - only lets through connections to certain ports.</p> - </section> - - <section> - <title>Enable Usage of Secure Connections</title> - <p>To enable a secure Orber domain you have to set the configuration variable - <em>secure</em> which currently only can have one of two values; - <em>no</em> if no security for IIOP should be used and <em>ssl</em> if - secure connections is needed (<em>ssl</em> is currently the only supported - security mechanism).</p> - <p>The default is no security.</p> - </section> - - <section> - <title>Configurations when Orber is Used on the Server Side</title> - <p>There is a variable to conficure Orber's SSL behavior on the server side.</p> - <list type="bulleted"> - <item><em>ssl_server_options</em> - which is a list of options to ssl. - See the <seealso marker="ssl:ssl">SSL</seealso> application for further - descriptions on these options.</item> - </list> - <p>There also exist an API function for accessing the value of this variable:</p> - <list type="bulleted"> - <item>orber:ssl_server_options/0</item> - </list> - </section> - - <section> - <title>Configurations when Orber is Used on the Client Side</title> - <p>When the Orber enabled application is the client side in the secure connection the - different configurations can be set per client process instead and not for the whole domain - as for incoming calls.</p> - <p>There is a variable to set default values for the domain but they can be changed - per client process.</p> - <list type="bulleted"> - <item><em>ssl_client_options</em> - which is a list of options to ssl. - See the <seealso marker="ssl:ssl">SSL</seealso> application for further - descriptions on these options.</item> - </list> - <p>There also exist two API functions for accessing and changing the values of this - variable in the client processes.</p> - <p>Access function:</p> - <list type="bulleted"> - <item>orber:ssl_client_options/0</item> - </list> - <p>Modify function:</p> - <list type="bulleted"> - <item>orber:set_ssl_client_options/1</item> - </list> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/ch_stubs.xml b/lib/orber/doc/src/ch_stubs.xml deleted file mode 100644 index 9290c127f9..0000000000 --- a/lib/orber/doc/src/ch_stubs.xml +++ /dev/null @@ -1,284 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1999</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Orber Stubs/Skeletons</title> - <prepared></prepared> - <docno></docno> - <date>1999-09-03</date> - <rev>A</rev> - <file>ch_stubs.xml</file> - </header> - - <section> - <title>Orber Stubs and Skeletons Description</title> - <p>This example describes the API and behavior of Orber stubs and skeletons. - </p> - - <section> - <title>Server Start</title> - <p>Orber servers can be started in several ways. The chosen start functions determines - how the server can be accessed and its behavior. - </p> - <p>Using <c>Module_Interface:oe_create()</c> or <c>oe_create_link()</c>: - </p> - <list type="bulleted"> - <item>No initial data can be passed.</item> - <item>Cannot be used as a supervisor child start function.</item> - <item>Only accessible through the object reference returned by the start function. - The object reference is no longer valid if the server dies and is restarted.</item> - </list> - <p>Using <c>Module_Interface:oe_create(Env)</c> or <c>oe_create_link(Env)</c>:</p> - <list type="bulleted"> - <item>Initial data can be passed using <c>Env</c>.</item> - <item>Cannot be used as a supervisor child start function.</item> - <item>Only accessible through the object reference returned by the start function. - The object reference is no longer valid if the server dies and is restarted.</item> - </list> - <p>Using <c>Module_Interface:oe_create(Env, Options)</c>:</p> - <list type="bulleted"> - <item>Initial data can be passed using <c>Env</c>.</item> - <item>Cannot be used as a supervisor child start function.</item> - <item>Accessible through the object reference returned by the start function. If the option - <c>{regname, RegName}</c> is used the object reference stays valid even if the - server has been restarted.</item> - <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used, - the result from an object invocation will be the exception 'OBJECT_NOT_EXIST' - only if the object has terminated with reason - <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result - will be <c>{error, Reason}</c> or a system exception is raised.</item> - <item>The option <c>{pseudo, true}</c> makes it possible to start create non-server objects. - There are, however, some limitations, which are further described in the - <c>Pseudo objects</c> section.</item> - </list> - <p>Using <c>Module_Interface:oe_create_link(Env, Options)</c>:</p> - <list type="bulleted"> - <item>Initial data can be passed using <c>Env</c>.</item> - <item>Can be used as a supervisor child start function if the option <c>{sup_child, true}</c> used.</item> - <item>Accessible through the object reference returned by the start function. If the option - <c>{regname, RegName}</c> is used the object reference stays valid even if the - server has been restarted.</item> - <item>If the options <c>{persistent, true}</c> and <c>{regname, {global, Name}}</c> is used, - the result from an object invocation will be the exception 'OBJECT_NOT_EXIST' - only if the object has terminated with reason - <c>normal</c> or <c>shutdown</c>. If the object is in the process of restarting, the result - will be <c>{error, Reason}</c> or a system exception is raised.</item> - <item>For starting a server as a supervisor child you should use the options - <c>[{persistent, true}, {regname, {global, Name}}, {sup_child, true}]</c> and of type <em>transient</em>. - This configuration allows you to delegate restarts to the supervisor and still be able to - use the same object reference and be able to see if the server is permanently terminated. - Please note you must use <em>supervisor/stdlib-1.7</em> or later and that the it returns - <c>{ok, Pid, Object}</c> instead of just <c>Object</c>.</item> - <item>Using the option <c>{pseudo, true}</c> have the same effect as using - <c>oe_create/2</c>.</item> - </list> - <warning> - <p>To avoid flooding Orber with old object references start erlang using the flag - <em>-orber objectkeys_gc_time Time</em>, which will remove all object references - related to servers being dead for Time seconds. To avoid extra overhead, i.e., performing - garbage collect if no persistent objects are started, the objectkeys_gc_time default value - is <em>infinity</em>. For more information, see the orber and corba documentation.</p> - </warning> - <warning> - <p>Orber still allow <c>oe_create(Env, {Type,RegName})</c> and <c>oe_create_link(Env, {Type,RegName})</c> to be used, - but may not in future releases.</p> - </warning> - </section> - - <section> - <title>Pseudo Objects</title> - <p>This section describes Orber pseudo objects. - </p> - <p>The Orber stub can be used to start a <c>pseudo object</c>, which will create a non-server implementation. - A pseudo object introduce some limitations:</p> - <list type="bulleted"> - <item>The functions <c>oe_create_link/2</c> is equal to <c>oe_create/2</c>, i.e., - no link can or will be created.</item> - <item>The <c>BIF:s self()</c> and <c>process_flag(trap_exit,true)</c> behaves incorrectly.</item> - <item>The <c>IC</c> option <c>{{impl, "M::I"}, "other_impl"}</c> has no effect. The call-back - functions must be implemented in a file called <c>M_I_impl.erl</c></item> - <item>The call-back functions must be implemented as if the <c>IC</c> option - <c>{this, "M::I"}</c> was used.</item> - <item>The gen_server <c>State</c> changes have no effect. The user can provide information via - the <c>Env</c> start parameter and the State returned from <c>init/2</c> will be the State - passed in following invocations.</item> - <item>The server reply <c>Timeout</c> has no effect.</item> - <item>The compile option <c>from</c> has no effect.</item> - <item>The option <c>{pseudo, true}</c> overrides all other start options.</item> - <item>Only the functions, besides own definitions, <c>init/2</c> (called via oe_create*/2) and - <c>terminate/2</c> (called via corba:dispose/1) must be implemented.</item> - </list> - <p>By adopting the rules for <c>pseudo</c> objects described above we can use <c>oe_create/2</c> - to create <c>server</c> or <c>pseudo</c> objects, by excluding or including the - option <c>{pseudo, true}</c>, without changing the call-back module.</p> - <p>To create a pseudo object do the following:</p> - <code type="none"> -fingolfin 127> erl -Erlang (BEAM) emulator version 4.9 - -Eshell V4.9 (abort with ^G) -1> ic:gen(myDefinition, [{this, "MyModule::MyInterface"}]). -Erlang IDL compiler version 20 -ok -2> make:all(). -Recompile: oe_MyDefinition -Recompile: MyModule_MyInterface -Recompile: MyModule_MyInterface_impl -up_to_date -3> PseudoObj = MyModule_MyInterface:oe_create(Env, [{pseudo, true}]). - </code> - <p>The call-back functions must be implemented as <c>MyFunction(OE_THIS, State, Args)</c>, - and called by <c>MyModule_MyInterface:MyFunction(PseudoObj, Args)</c>.</p> - </section> - - <section> - <title>Call-back Module</title> - <p>This section provides an example of how a call-back module may be implemented.</p> - <note> - <p>Arguments and Replies are determined by the IDL-code and, hence, not - further described here.</p> - </note> - <code type="erl"> -%%%----------------------------------------------------------- -%%% File : Module_Interface_impl.erl -%%% Author : -%%% Purpose : -%%% Created : -%%%----------------------------------------------------------- - --module('Module_Interface_impl'). - -%%--------------- INCLUDES ----------------------------------- --include_lib("orber/include/corba.hrl"). --include_lib(".. .."). - -%%--------------- EXPORTS------------------------------------- -%% Arity depends on IC configuration parameters and the IDL -%% specification. --export([own_function/X]). - - -%%--------------- gen_server specific ------------------------ --export([init/1, terminate/2, code_change/3, handle_info/2]). - -%%------------------------------------------------------------ -%% function : server specific -%%------------------------------------------------------------ -init(InitialData) -> - %% 'trap_exit' optional (have no effect if pseudo object). - process_flag(trap_exit,true), - - %%--- Possible replies --- - %% Reply and await next request - {ok, State}. - - %% Reply and if no more requests within Time the special - %% timeout message should be handled in the - %% Module_Interface_impl:handle_info/2 call-back function (use the - %% IC option {{handle_info, "Module::Interface"}, true}). - {ok, State, Timeout} - - %% Return ignore in order to inform the parent, especially if it is a - %% supervisor, that the server, as an example, did not start in - %% accordance with the configuration data. - ignore - %% If the initializing procedure fails, the reason - %% is supplied as StopReason. - {stop, StopReason} - -terminate(Reason, State) -> - ok. - -code_change(OldVsn, State, Extra) -> - {ok, NewState}. - -%% If use IC option {{handle_info, "Module::Interface"}, true}. -%% (have no effect if pseudo object). -handle_info(Info, State) -> - %%--- Possible replies --- - %% Await the next invocation. - {noreply, State}. - %% Stop with Reason. - {stop, Reason, State}. - -%%--- two-way ------------------------------------------------ -%% If use IC option {this, "Module:Interface"} -%% (Required for pseudo objects) -own_function(This, State, .. Arguments ..) -> -%% IC options this and from -own_function(This, From, State, .. Arguments ..) -> -%% IC option from -own_function(From, State, .. Arguments ..) -> - %% Send explicit reply to client. - corba:reply(From, Reply), - %%--- Possible replies --- - {noreply, State} - {noreply, State, Timeout} - - -%% If not use IC option {this, "Module:Interface"} -own_function(State, .. Arguments ..) -> - %%--- Possible replies --- - %% Reply and await next request - {reply, Reply, State} - - %% Reply and if no more requests within Time the special - %% timeout message should be handled in the - %% Module_Interface_impl:handle_info/2 call-back function (use the - %% IC option {{handle_info, "Module::Interface"}, true}). - {reply, Reply, State, Timeout} - - %% Stop the server and send Reply to invoking object. - {stop, StopReason, Reply, State} - - %% Stop the server and send no reply to invoking object. - {stop, StopReason, State} - - %% Raise exception. Any changes to the internal State is lost. - corba:raise(Exception). - -%%--- one-way ------------------------------------------------ -%% If use IC option {this, "Module:Interface"} -%% (Required for pseudo objects) -own_function(This, State, .. Arguments ..) -> - -%% If not use IC option {this, "Module:Interface"} -own_function(State, .. Arguments ..) -> - %%--- Possible results --- - {noreply, State} - - %% Release and if no more requests within Time the special - %% timeout message should be handled in the - %% Module_Interface_impl:handle_info/2 call-back function (use the - %% IC option {{handle_info, "Module::Interface"}, true}). - {noreply, State, Timeout} - - %% Stop the server with StopReason. - {stop, StopReason, State} - -%%--------------- END OF MODULE ------------------------------ - </code> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/corba.xml b/lib/orber/doc/src/corba.xml deleted file mode 100644 index fbfb55f2f2..0000000000 --- a/lib/orber/doc/src/corba.xml +++ /dev/null @@ -1,454 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>corba</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>corba</module> - <modulesummary>The functions on CORBA module level</modulesummary> - <description> - <p>This module contains functions that are specified on the CORBA module - level. It also contains some functions for creating and disposing - objects.</p> - </description> - <funcs> - <func> - <name>create(Module, TypeID) -> Object</name> - <name>create(Module, TypeID, Env) -> Object</name> - <name>create(Module, TypeID, Env, Optons1) -> Object</name> - <name>create_link(Module, TypeID) -> Object</name> - <name>create_link(Module, TypeID, Env) -> Object</name> - <name>create_link(Module, TypeID, Env, Options2) -> Reply</name> - <fsummary>Create and start a new server object</fsummary> - <type> - <v>Module = atom()</v> - <v>TypeID = string()</v> - <v>Env = term()</v> - <v>Options1 = [{persistent, Bool} | {regname, RegName} | {local_typecheck, Bool}]</v> - <v>Options2 = [{sup_child, Bool} | {persistent, Bool} | {regname, RegName} | {pseudo, Bool} | {local_typecheck, Bool}]</v> - <v>RegName = {local, atom()} | {global, term()}</v> - <v>Reply = #objref | {ok, Pid, #objref}</v> - <v>Bool = true | false</v> - <v>Object = #objref</v> - </type> - <desc> - <p>These functions start a new server object. If you start it - without <em>RegName</em> it can only be accessed through the - returned object key. Started with a <em>RegName</em> the name is - registered locally or globally. </p> - <p><em>TypeID</em> is the repository ID of the server object type and - could for example look like "IDL:StackModule/Stack:1.0". </p> - <p><em>Module</em> is the name of the interface API module. </p> - <p><em>Env</em> is the arguments passed which will be passed to the - implementations <em>init</em> call-back function.</p> - <p>A server started with create/2, create/3 or create/4 does not care - about the parent, which means that the parent is not handled - explicitly in the generic process part. </p> - <p>A server started with create_link2, create_link/3 or create_link/4 - is initially linked to the caller, the parent, and it will - terminate whenever the parent process terminates, and with the same - reason as the parent. If the server traps exits, the terminate/2 - call-back function is called in order to clean up before the - termination. These functions should be used if the server is a - worker in a supervision tree.</p> - <p>If you use the option <c>{sup_child, true}</c> create_link/4 will return - <c>{ok, Pid, #objref}</c>, otherwise <c>#objref</c>, and make it possible - to start a server as a supervisor child (stdlib-1.7 or later).</p> - <p>If you use the option <c>{persistent, true}</c> you also must use the option - <c>{regname, {global, Name}}</c>. This combination makes it possible to tell - the difference between a server permanently terminated or in the process of restarting.</p> - <p>The option <c>{pseudo, true}</c>, allow us to create an object which is not a - server. Using <c>{pseudo, true}</c> overrides all other start options. - For more information see section <c>Module_Interface</c>.</p> - <p>If a server is started using the option <c>{persistent, true}</c> the object key - will not be removed unless it terminates with reason <em>normal</em> or <em>shutdown</em>. - Hence, if persistent servers is used as supervisor children they should be <em>transient</em> - and the <em>objectkeys_gc_time</em> should be modified (default equals <c>infinity</c>).</p> - <p>The option <c>{local_typecheck, boolean()}</c>, which overrides the - <seealso marker="ch_install#flags">Local Typechecking</seealso> - environment flag, turns on or off typechecking. If activated, - parameters, replies and raised exceptions will be checked to ensure that - the data is correct, when invoking operations on CORBA Objects within - the same Orber domain. Due to the extra overhead, this option - <em>MAY ONLY</em> be used during testing and development.</p> - <code type="none"> -Example: - - corba:create('StackModule_Stack', "IDL:StackModule/Stack:1.0", {10, test}) - </code> - </desc> - </func> - <func> - <name>dispose(Object) -> ok</name> - <fsummary>Stop a server object</fsummary> - <type> - <v>Object = #objref</v> - </type> - <desc> - <p>This function is used for terminating the execution of a - server object. Invoking this operation on a NIL object reference, - e.g., the return value of <c>corba:create_nil_objref/0</c>, always - return ok. For valid object references, invoking this operation - more than once, will result in a system exception.</p> - </desc> - </func> - <func> - <name>create_nil_objref() -> Object</name> - <fsummary>Stop a server object</fsummary> - <type> - <v>Object = #objref representing NIL.</v> - </type> - <desc> - <p>Creates an object reference that represents the NIL value. - Attempts to invoke operations using the returned object reference - will return a system exception.</p> - </desc> - </func> - <func> - <name>create_subobject_key(Object, Key) -> Result</name> - <fsummary>Add an Erlang term to a private key field</fsummary> - <type> - <v>Object = #objref</v> - <v>Key = term()</v> - <v>Result = #objref</v> - </type> - <desc> - <p>This function is used to create a subobject in a server object. - It can for example be useful when one wants unique access to - separate rows in a mnesia or an ETS table. The <em>Result</em> is - an object reference that will be seen as a unique reference to - the outside world but will access the same server object where one - can use the <em>get_subobject_key/1</em> function to get the private - key value.</p> - <p><em>Key</em> is stored in the object reference <em>Object</em>. - If it is a binary it will be stored as is and otherwise it is - converted to a binary before storage.</p> - </desc> - </func> - <func> - <name>get_subobject_key(Object) -> Result</name> - <fsummary>Fetch the contents of the private key field</fsummary> - <type> - <v>Object = #objref</v> - <v>Result = #binary</v> - </type> - <desc> - <p>This function is used to fetch a subobject key from the object - reference <em>Object</em>. The result is a always a binary, if it - was an Erlang term that was stored with <em>create_subobject_key/2</em> - one can to do <em>binary_to_term/1</em> to get the real value. </p> - </desc> - </func> - <func> - <name>get_pid(Object) -> Result</name> - <fsummary>Get the process id from an object key</fsummary> - <type> - <v>Object = #objref</v> - <v>Result = #pid | {error, Reason} | {'EXCEPTION',E}</v> - </type> - <desc> - <p>This function is to get the process id from an object, which is a - must when CORBA objects is started/handled in a supervisor tree. - The function will throw exceptions if the key is not found or - some other error occurs.</p> - </desc> - </func> - <func> - <name>raise(Exception)</name> - <fsummary>Generate an Erlang throw</fsummary> - <type> - <v>Exception = record()</v> - </type> - <desc> - <p>This function is used for raising corba exceptions as an - Erlang user generated exit signal. It will throw the tuple - <c>{'EXCEPTION', </c><em>Exception</em><c>}</c>.</p> - </desc> - </func> - <func> - <name>reply(To, Reply) -> true</name> - <fsummary>Send explicit reply to client</fsummary> - <type> - <v>To = client reference</v> - <v>Reply = IDL type</v> - </type> - <desc> - <p>This function can be used by a CORBA object to explicitly send - a reply to a client that invoked a two-way operation. If this operation - is used, it is <em>not</em> possible to return a reply in the call-back - module. - <br></br> -<em>To</em> must be the <em>From</em> argument provided to the - callback function, which requires that the IC option <em>from</em> - was used when compiling the IDL-file.</p> - </desc> - </func> - <func> - <name>resolve_initial_references(ObjectId) -> Object</name> - <name>resolve_initial_references(ObjectId, Contexts) -> Object</name> - <fsummary>Return the object reference for the given object id</fsummary> - <type> - <v>ObjectId = string()</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Object = #objref</v> - </type> - <desc> - <p>This function returns the object reference associated with the given - object id. Initially, only <c>"NameService"</c> is available. To add or remove - services use <c>add_initial_service/2</c> or <c>remove_initial_service/1</c>.</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - </desc> - </func> - <func> - <name>add_initial_service(ObjectId, Object) -> boolean()</name> - <fsummary>Add a new initial service and associate it with the given id</fsummary> - <type> - <v>ObjectId = string()</v> - <v>Object = #objref</v> - </type> - <desc> - <p>This operation allows us to add initial services, which can be accessed by - using <c>resolve_initial_references/1</c> or the <c>corbaloc</c> schema. - If using an Id defined by the OMG, the given object must be of the - correct type; for more information see the - <seealso marker="ch_naming_service#interop_ns">Interoperable Naming Service</seealso>. - Returns <c>false</c> if the given id already exists.</p> - </desc> - </func> - <func> - <name>remove_initial_service(ObjectId) -> boolean()</name> - <fsummary>Remove association between the given id and service</fsummary> - <type> - <v>ObjectId = string()</v> - </type> - <desc> - <p>If we don not want a certain service to be accessible, invoking this function - will remove the association. Returns <c>true</c> if able to terminate the - binding. If no such binding existed <c>false</c> is returned.</p> - </desc> - </func> - <func> - <name>list_initial_services() -> [ObjectId]</name> - <fsummary>Return a list of supported object id's</fsummary> - <type> - <v>ObjectId = string()</v> - </type> - <desc> - <p>This function returns a list of allowed object id's.</p> - </desc> - </func> - <func> - <name>resolve_initial_references_remote(ObjectId, Address) -> Object</name> - <name>resolve_initial_references_remote(ObjectId, Address, Contexts) -> Object</name> - <fsummary>Return the object reference for the given object id</fsummary> - <type> - <v>ObjectId = string()</v> - <v>Address = [RemoteModifier]</v> - <v>RemoteModifier = string()</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Object = #objref</v> - </type> - <desc> - <p>This function returns the object reference for the object id asked - for. - The remote modifier string has the following format: - <c>"iiop://"<host>":"<port></c> where <c><host> = <DNS hostname> | - <IPv4 address> | "["<IPv6 address>"]"</c>. - </p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <warning> - <p>This operation is not supported by most ORB's. Hence, use - <c>corba:string_to_object/1</c> instead.</p> - </warning> - </desc> - </func> - <func> - <name>list_initial_services_remote(Address) -> [ObjectId]</name> - <name>list_initial_services_remote(Address, Contexts) -> [ObjectId]</name> - <fsummary>Return a list of supported object id's</fsummary> - <type> - <v>Address = [RemoteModifier]</v> - <v>RemoteModifier = string()</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>ObjectId = string()</v> - </type> - <desc> - <p>This function returns a list of allowed object id's. - The remote modifier string has the following format: - <c>"iiop://"<host>":"<port></c> where <c><host> = <DNS hostname> | - <IPv4 address> | "["<IPv6 address>"]"</c>. - </p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <warning> - <p>This operation is not supported by most ORB's. Hence, avoid - using it.</p> - </warning> - </desc> - </func> - <func> - <name>object_to_string(Object) -> IOR_string</name> - <fsummary>Convert the object reference to the external string representation</fsummary> - <type> - <v>Object = #objref</v> - <v>IOR_string = string()</v> - </type> - <desc> - <p>This function returns the object reference as the external string - representation of an IOR.</p> - </desc> - </func> - <func> - <name>string_to_object(IOR_string) -> Object</name> - <name>string_to_object(IOR_string, Contexts) -> Object</name> - <fsummary>Convert the external string representation to an object reference</fsummary> - <type> - <v>IOR_string = string()</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Object = #objref</v> - </type> - <desc> - <p>This function takes a <c>corbaname</c>, <c>corbaloc</c> or an IOR on the - external string representation and returns the object reference.</p> - <p>To lookup the NameService reference, simply use:</p> - <code>corbaloc:iiop:[email protected]:4001/NameService</code> - <p>We can also resolve an object from the NameService by using:</p> - <code>corbaname:iiop:[email protected]:4001/NameService#org/Erlang/MyObj</code> - <p>To lookup the NameService reference with an IPv6 address, simply use:</p> - <code>corbaloc:iiop:1.2@[FEC1:0:3:0:0312:44AF:FAB1:3D01]:4001/NameService</code> - <p>For more information about <c>corbaname</c> and <c>corbaloc</c>, see - the User's Guide (Interoperable Naming Service).</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <p>How to handle the interface context is further described in the User's Guide.</p> - </desc> - </func> - <func> - <name>print_object(Data [, Type]) -> ok | {'EXCEPTION', E} | {'EXIT', R} | string()</name> - <fsummary>Print the supplied object</fsummary> - <type> - <v>Data = IOR_string | #objref (local or external) | corbaloc/corbaname string</v> - <v>Type = IoDevice | error_report | {error_report, Reason} | info_msg | {info_msg, Comment} | string</v> - <v>IoDevice = see the io-module</v> - <v>Reason = Comment = string()</v> - </type> - <desc> - <p>The object represented by the supplied data is dissected and presented - in a more readable form. The Type parameter is optional; if not supplied - standard output is used. For <c>error_report</c> and <c>info_msg</c> - the <c>error_logger</c> module is used, with or without Reason or Comment. - If the atom <c>string</c> is supplied this function will return a flat - list. The <c>IoDevice</c> is passed to the operation <c>io:format/2</c>.</p> - <p>If the supplied object is a local reference, the output is equivalent - to an object exported from the node this function is invoked on.</p> - </desc> - </func> - <func> - <name>add_alternate_iiop_address(Object, Host, Port) -> NewObject | {'EXCEPTION', E}</name> - <fsummary>Add ALTERNATE_IIOP_ADDRESS component to the supplied local object</fsummary> - <type> - <v>Object = NewObject = local #objref</v> - <v>Host = string()</v> - <v>Port = integer()</v> - </type> - <desc> - <p>This operation creates a new instance of the supplied object - containing an ALTERNATE_IIOP_ADDRESS component. Only the new instance - contains the new component. When this object is passed to another - ORB, which supports the ALTERNATE_IIOP_ADDRESS, requests will be routed - to the alternate address if it is not possible to communicate with - the main address.</p> - <p>The ALTERNATE_IIOP_ADDRESS component requires that IIOP-1.2 is used. - Hence, make sure both Orber and the other ORB is correctly configured.</p> - <p></p> - <note> - <p>Make sure that the given <c>Object</c> is accessible via the - alternate Host/port. For example, if the object is correctly started as - <c>local</c> or <c>pseudo</c>, the object should be available on all - nodes within a multi-node Orber installation. Since only one instance - exists for other object types, it will not be possible to access it - if the node it was started on terminates.</p> - </note> - </desc> - </func> - <func> - <name>orb_init(KeyValueList) -> ok | {'EXIT', Reason}</name> - <fsummary>Configure Orber before starting it</fsummary> - <type> - <v>KeyValueList = [{Key, Value}]</v> - <v>Key = any key listed in the configuration chapter</v> - <v>Value = allowed value associated with the given key</v> - </type> - <desc> - <p>This function allows the user to configure Orber in, for example, - an Erlang shell. Orber may <em>NOT</em> be started prior to invoking - this operation. For more information, see - <seealso marker="ch_install#config">configuration settings</seealso> - in the User's Guide.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/corba_object.xml b/lib/orber/doc/src/corba_object.xml deleted file mode 100644 index 09a4b0bc3c..0000000000 --- a/lib/orber/doc/src/corba_object.xml +++ /dev/null @@ -1,194 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>corba_object</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-11-10</date> - <rev>A</rev> - </header> - <module>corba_object</module> - <modulesummary>The CORBA Object interface functions</modulesummary> - <description> - <p>This module contains the CORBA Object interface functions that can be - called for all objects.</p> - </description> - <funcs> - <func> - <name>get_interface(Object) -> InterfaceDef</name> - <fsummary>Fetch the interface description</fsummary> - <type> - <v>Object = #objref</v> - <v>InterfaceDef = term()</v> - </type> - <desc> - <p>This function returns the full interface description for an object.</p> - </desc> - </func> - <func> - <name>is_nil(Object) -> boolean()</name> - <fsummary>Return true, if the given object is a NIL object reference, otherwise false</fsummary> - <type> - <v>Object = #objref</v> - </type> - <desc> - <p>This function checks if the object reference has a nil object value, - which denotes no object. It is the reference that is tested and no - object implementation is involved in the test. </p> - </desc> - </func> - <func> - <name>is_a(Object, Logical_type_id) -> Return</name> - <name>is_a(Object, Logical_type_id, Contexts) -> Return</name> - <fsummary>Return true if the target object is an, or inherit from, object of the given type</fsummary> - <type> - <v>Object = #objref</v> - <v>Logical_type_id = string()</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Return = boolean() | {'EXCEPTION', E}</v> - </type> - <desc> - <p>The <em>Logical_type_id</em> is a string that is a share type - identifier (repository id). The function returns true if the object - is an instance of that type or an ancestor of the "most derived" - type of that object.</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <p>Note: Other ORB suppliers may not support this function completely - according to the OMG specification. Thus, a <em>is_a</em> call may - raise an exception or respond unpredictable if the Object is - located on a remote node.</p> - </desc> - </func> - <func> - <name>is_remote(Object) -> boolean()</name> - <fsummary>Determine whether or not an object reference is remote</fsummary> - <type> - <v>Object = #objref</v> - </type> - <desc> - <p>This function returns true if an object reference is remote - otherwise false. </p> - </desc> - </func> - <func> - <name>non_existent(Object) -> Return</name> - <name>non_existent(Object, Contexts) -> Return</name> - <fsummary>Return false if the target object do not exist, otherwise true</fsummary> - <type> - <v>Object = #objref</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Return = boolean() | {'EXCEPTION', E}</v> - </type> - <desc> - <p>This function can be used to test if the object has been destroyed. - It does this without invoking any application level code. The ORB - returns true if it knows that the object is destroyed otherwise - false.</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - <p>Note: The OMG have specified two different operators, <c>_not_existent</c> (CORBA version 2.0 and 2.2) and - <c>_non_existent</c> (CORBA version 2.3), to be used for this function. It is not mandatory to support - both versions. Thus, a <em>non_existent</em> call may raise an exception or respond unpredictable - if the Object is located on a remote node. Depending on which version, ORB:s you intend to - communicate with supports, you can either use this function or <c>not_existent/1</c>.</p> - </desc> - </func> - <func> - <name>not_existent(Object) -> Return</name> - <name>not_existent(Object, Contexts) -> Return</name> - <fsummary>Return false if the target object do not exist, otherwise true</fsummary> - <type> - <v>Object = #objref</v> - <v>Contexts = [Context]</v> - <v>Context = #'IOP_ServiceContext'{context_id = CtxId, context_data = CtxData}</v> - <v>CtxId = ?ORBER_GENERIC_CTX_ID</v> - <v>CtxData = {interface, Interface} | {userspecific, term()} | {configuration, Options}</v> - <v>Interface = string()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = ssl_client_options</v> - <v>Value = allowed value associated with the given key</v> - <v>Return = boolean() | {'EXCEPTION', E}</v> - </type> - <desc> - <p>This function is implemented due to Interoperable purposes. Behaves as - <c>non_existent</c> except the operator <c>_not_existent</c> is used when - communicating with other ORB:s.</p> - <p>The <em>configuration</em> context is used to override the global - SSL client side - <seealso marker="ch_install#config">configuration</seealso>.</p> - </desc> - </func> - <func> - <name>is_equivalent(Object, OtherObject) -> boolean()</name> - <fsummary>Return true if the target object and the supplied object easily can be determined to be equal, otherwise false</fsummary> - <type> - <v>Object = #objref</v> - <v>OtherObject = #objref</v> - </type> - <desc> - <p>This function is used to determine if two object references are - equivalent so far the ORB easily can determine. It returns - <em>true</em> if the target object reference is equal to the - other object reference and <em>false</em> otherwise.</p> - </desc> - </func> - <func> - <name>hash(Object, Maximum) -> int()</name> - <fsummary>Return a hash value based on the target object</fsummary> - <type> - <v>Object = #objref</v> - <v>Maximum = int()</v> - </type> - <desc> - <p>This function returns a hash value based on the object reference - that not will change during the lifetime of the object. - The <em>Maximum</em> parameter denotes the upper bound of the value.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/dataframe1.gif b/lib/orber/doc/src/dataframe1.gif Binary files differdeleted file mode 100644 index 21bd0afbc5..0000000000 --- a/lib/orber/doc/src/dataframe1.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe2.gif b/lib/orber/doc/src/dataframe2.gif Binary files differdeleted file mode 100644 index 26778932b4..0000000000 --- a/lib/orber/doc/src/dataframe2.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe3.gif b/lib/orber/doc/src/dataframe3.gif Binary files differdeleted file mode 100644 index db8ffef7d1..0000000000 --- a/lib/orber/doc/src/dataframe3.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe4.gif b/lib/orber/doc/src/dataframe4.gif Binary files differdeleted file mode 100644 index f64c7f3733..0000000000 --- a/lib/orber/doc/src/dataframe4.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe5.gif b/lib/orber/doc/src/dataframe5.gif Binary files differdeleted file mode 100644 index 80e17945a2..0000000000 --- a/lib/orber/doc/src/dataframe5.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe6.gif b/lib/orber/doc/src/dataframe6.gif Binary files differdeleted file mode 100644 index fb1c5d7827..0000000000 --- a/lib/orber/doc/src/dataframe6.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe7.gif b/lib/orber/doc/src/dataframe7.gif Binary files differdeleted file mode 100644 index 1e18078f0a..0000000000 --- a/lib/orber/doc/src/dataframe7.gif +++ /dev/null diff --git a/lib/orber/doc/src/dataframe8.gif b/lib/orber/doc/src/dataframe8.gif Binary files differdeleted file mode 100644 index ef95c9a11f..0000000000 --- a/lib/orber/doc/src/dataframe8.gif +++ /dev/null diff --git a/lib/orber/doc/src/dependent.gif b/lib/orber/doc/src/dependent.gif Binary files differdeleted file mode 100644 index c65c427421..0000000000 --- a/lib/orber/doc/src/dependent.gif +++ /dev/null diff --git a/lib/orber/doc/src/example_part.xml b/lib/orber/doc/src/example_part.xml deleted file mode 100644 index 61c9524cc3..0000000000 --- a/lib/orber/doc/src/example_part.xml +++ /dev/null @@ -1,36 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE part SYSTEM "part.dtd"> - -<part> - <header> - <copyright> - <year>2002</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Service Implementation</title> - <prepared>Niclas Eklund</prepared> - <docno></docno> - <date>2002-06-25</date> - <rev>A</rev> - </header> - <description> - <p>This chapter describe how to implement Orber based CORBA services.</p> - </description> - <include file="ch_stubs"></include> -</part> - diff --git a/lib/orber/doc/src/firewall_nat.gif b/lib/orber/doc/src/firewall_nat.gif Binary files differdeleted file mode 100644 index 3a80aac724..0000000000 --- a/lib/orber/doc/src/firewall_nat.gif +++ /dev/null diff --git a/lib/orber/doc/src/fixed.xml b/lib/orber/doc/src/fixed.xml deleted file mode 100644 index ef4d1bd604..0000000000 --- a/lib/orber/doc/src/fixed.xml +++ /dev/null @@ -1,160 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>2002</year><year>2017</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>fixed</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>2002-05-22</date> - <rev>A</rev> - </header> - <module>fixed</module> - <modulesummary>the corba fixed type</modulesummary> - <description> - <p>This module contains functions that gives an interface to the CORBA fixed type.</p> - <p>The type <c>Fixed</c> used below is defined as:</p> - <code type="erl"> --record(fixed, {digits, scale, value}). - </code> - <p>where <c>digits</c> is the total amount of digits it consists of and - <c>scale</c> is the number of fractional digits. The <c>value</c> field - contains the actual Fixed value represented as an integer. The limitations - of each field are:</p> - <list type="bulleted"> - <item>Digits - integer(), -1 > Digits < 32</item> - <item>Scale - integer(), -1 > Scale =< Digits</item> - <item>Value - integer(), range (31 digits): ±9999999999999999999999999999999</item> - </list> - <p>Since the Value part is represented by an integer, it is vital that the - Digits and Scale values are correct. This also means that trailing zeros - cannot be left out in some cases:</p> - <list type="bulleted"> - <item>fixed<5,3> eq. 03.140d eq. 3140</item> - <item>fixed<3,2> eq. 3.14d eq. 314</item> - </list> - <p>Leading zeros can be left out.</p> - <p>For your convenience, this module exports functions which handle - unary (<c>-</c>) and binary (<c>+-*/</c>) operations legal for the Fixed type. - Since a unary <c>+</c> have no effect, this module do not export such a - function. Any of the binary operations may cause an overflow (i.e. more than - 31 significant digits; leading and trailing zeros are not considered - significant). If this is the case, the Digit and Scale values are adjusted - and the Value truncated (no rounding performed). This behavior is - compliant with the OMG CORBA specification. Each binary operation have - the following upper bounds:</p> - <list type="bulleted"> - <item><em>Fixed1 + Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item> - <item><em>Fixed1 - Fixed2</em> - <c><![CDATA[fixed<max(d1-s1,d2-s2) + max(s1,s2) + 1, max(s1,s2)>]]></c></item> - <item><em>Fixed1 * Fixed2</em> - <c><![CDATA[fixed<d1+d2, s1+s2>]]></c></item> - <item><em>Fixed1 / Fixed2</em> - <c><![CDATA[fixed<(d1-s1+s2) + Sinf ,Sinf >]]></c></item> - </list> - <p>A quotient may have an arbitrary number of decimal places, which is - denoted by a scale of Sinf.</p> - </description> - <funcs> - <func> - <name>create(Digits, Scale, Value) -> Result</name> - <fsummary>Create a fixed type</fsummary> - <type> - <v>Result = Fixed Type | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>This function creates a new instance of a <c>Fixed Type</c>. If - the limitations is not fulfilled (e.g. overflow) an exception is - raised.</p> - </desc> - </func> - <func> - <name>get_typecode(Fixed) -> Result</name> - <fsummary>Create TypeCode representing the supplied fixed type</fsummary> - <type> - <v>Result = TypeCode | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Returns the TypeCode which represents the supplied Fixed type. - If the parameter is not of the correct type, an exception is raised.</p> - </desc> - </func> - <func> - <name>add(Fixed1, Fixed2) -> Result</name> - <fsummary>Add the supplied Fixed types</fsummary> - <type> - <v>Result = Fixed1 + Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Performs a Fixed type addition. - If the parameters are not of the correct type, an exception is raised.</p> - </desc> - </func> - <func> - <name>subtract(Fixed1, Fixed2) -> Result</name> - <fsummary>Subtract Fixed2 from Fixed1</fsummary> - <type> - <v>Result = Fixed1 - Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Performs a Fixed type subtraction. - If the parameters are not of the correct type, an exception is raised.</p> - </desc> - </func> - <func> - <name>multiply(Fixed1, Fixed2) -> Result</name> - <fsummary>Multiply Fixed1 with Fixed2</fsummary> - <type> - <v>Result = Fixed1 * Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Performs a Fixed type multiplication. - If the parameters are not of the correct type, an exception is raised.</p> - </desc> - </func> - <func> - <name>divide(Fixed1, Fixed2) -> Result</name> - <fsummary>Divide Fixed1 with Fixed2</fsummary> - <type> - <v>Result = Fixed1 / Fixed2 | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Performs a Fixed type division. - If the parameters are not of the correct type, an exception is raised.</p> - </desc> - </func> - <func> - <name>unary_minus(Fixed) -> Result</name> - <fsummary>Negate the supplied Fixed Type</fsummary> - <type> - <v>Result = -Fixed | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Negates the supplied Fixed type. - If the parameter is not of the correct type, an exception is raised.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/ifr_notes.txt b/lib/orber/doc/src/ifr_notes.txt deleted file mode 100644 index 54f79be8cd..0000000000 --- a/lib/orber/doc/src/ifr_notes.txt +++ /dev/null @@ -1,53 +0,0 @@ --*-Mode: Outline;-*- - -* Transactions. - Transaction handling (or the use of mnesia:async_dirty) is not very - good at error checking. Code to handle errors from transactions must - be added. Right now it is not possible to mix atomic transactions - with dirty 'transactions' (i.e. async_dirty) and still check the - results consistently. This must be fixed if we are to read with - async_dirty instead of transaction, since we still want to do all - the writes with transaction and not async_dirty. - (This point might be moot. Simple reads are now done with - mnesia:dirty_read/1 outside of transactions). - -* Unresolved issues. - There are some places in the source code marked with '***' where the - code should be verified. It mostly concerns minor unresolved - unclarities in the specification. - -** orber_ifr_contained.erl - In move/4 there is a call to orber_ifr_contained:lookup_name/5. The - third argument, Levels_to_search, is set to -1, which means search - all contained objects. This is probably correct. - -** orber_ifr_interfacedef.erl - The function describe_interface/1 describes the interface without - its inherited interfaces. It is not clear whether this is correct or - not. It is possible to get a description of the inherited interfaces - by mapping describe_interface/1 on the list if interfaces returned - by get_base_interfaces/1. Also, since the structs - InterfaceDescription and FullInterfaceDescription both have a field - named base_interfaces, it is possible to get a description of the - inherited attributes by examining that field and applying a describe - function. - -** orber_ifr_orb.erl - create_union_tc/4 sets the fifth element in the typecode tuple to - -1, meaning no default case. - -** orber_ifr_repository.erl - The PrimitiveDef with kind pk_objref has an empty Id and an empty - Name. This is perhaps not correct. - -** orber_ifr_typecode.erl - None of the functions in this module are fully implemented and they - should not be used. - -** orber_ifr_uniondef.erl -*** '_set_members'/2 - What should the value of the discriminator-typecode be when updating - the type attribute? (CORBA 2.0, p 6-20). For now we just leave it - unchanged, but this is perhaps not the right thing to do. - -* Exceptions should give more information about the failure. diff --git a/lib/orber/doc/src/iiop.gif b/lib/orber/doc/src/iiop.gif Binary files differdeleted file mode 100644 index d2f2fd128c..0000000000 --- a/lib/orber/doc/src/iiop.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/GridBagEx.gif b/lib/orber/doc/src/images/GridBagEx.gif Binary files differdeleted file mode 100644 index 16c326d88c..0000000000 --- a/lib/orber/doc/src/images/GridBagEx.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/OpenBookIcon.gif b/lib/orber/doc/src/images/OpenBookIcon.gif Binary files differdeleted file mode 100644 index 86384f7733..0000000000 --- a/lib/orber/doc/src/images/OpenBookIcon.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/blue-ball-small.gif b/lib/orber/doc/src/images/blue-ball-small.gif Binary files differdeleted file mode 100644 index d4c5cde5b0..0000000000 --- a/lib/orber/doc/src/images/blue-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/blue-ball.gif b/lib/orber/doc/src/images/blue-ball.gif Binary files differdeleted file mode 100644 index edc29b786c..0000000000 --- a/lib/orber/doc/src/images/blue-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/class-index.gif b/lib/orber/doc/src/images/class-index.gif Binary files differdeleted file mode 100644 index 7f276bcb24..0000000000 --- a/lib/orber/doc/src/images/class-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/constructor-index.gif b/lib/orber/doc/src/images/constructor-index.gif Binary files differdeleted file mode 100644 index 435cac4238..0000000000 --- a/lib/orber/doc/src/images/constructor-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/constructors.gif b/lib/orber/doc/src/images/constructors.gif Binary files differdeleted file mode 100644 index d1a6ae507c..0000000000 --- a/lib/orber/doc/src/images/constructors.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/cyan-ball-small.gif b/lib/orber/doc/src/images/cyan-ball-small.gif Binary files differdeleted file mode 100644 index 7f74357443..0000000000 --- a/lib/orber/doc/src/images/cyan-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/cyan-ball.gif b/lib/orber/doc/src/images/cyan-ball.gif Binary files differdeleted file mode 100644 index 97ca1f2b6e..0000000000 --- a/lib/orber/doc/src/images/cyan-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/error-index.gif b/lib/orber/doc/src/images/error-index.gif Binary files differdeleted file mode 100644 index 22835ff8c6..0000000000 --- a/lib/orber/doc/src/images/error-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/exception-index.gif b/lib/orber/doc/src/images/exception-index.gif Binary files differdeleted file mode 100644 index e3830d9c52..0000000000 --- a/lib/orber/doc/src/images/exception-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/green-ball-small.gif b/lib/orber/doc/src/images/green-ball-small.gif Binary files differdeleted file mode 100644 index 17fea5b32b..0000000000 --- a/lib/orber/doc/src/images/green-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/green-ball.gif b/lib/orber/doc/src/images/green-ball.gif Binary files differdeleted file mode 100644 index 71e1b2ec2d..0000000000 --- a/lib/orber/doc/src/images/green-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/interface-index.gif b/lib/orber/doc/src/images/interface-index.gif Binary files differdeleted file mode 100644 index bf93dda9e3..0000000000 --- a/lib/orber/doc/src/images/interface-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/magenta-ball-small.gif b/lib/orber/doc/src/images/magenta-ball-small.gif Binary files differdeleted file mode 100644 index bd0584b3c6..0000000000 --- a/lib/orber/doc/src/images/magenta-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/magenta-ball.gif b/lib/orber/doc/src/images/magenta-ball.gif Binary files differdeleted file mode 100644 index 5da03b84d2..0000000000 --- a/lib/orber/doc/src/images/magenta-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/method-index.gif b/lib/orber/doc/src/images/method-index.gif Binary files differdeleted file mode 100644 index a05e705116..0000000000 --- a/lib/orber/doc/src/images/method-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/methods.gif b/lib/orber/doc/src/images/methods.gif Binary files differdeleted file mode 100644 index 949e01b8a3..0000000000 --- a/lib/orber/doc/src/images/methods.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/package-index.gif b/lib/orber/doc/src/images/package-index.gif Binary files differdeleted file mode 100644 index f894d4210d..0000000000 --- a/lib/orber/doc/src/images/package-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/red-ball-small.gif b/lib/orber/doc/src/images/red-ball-small.gif Binary files differdeleted file mode 100644 index f6b3c372ca..0000000000 --- a/lib/orber/doc/src/images/red-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/red-ball.gif b/lib/orber/doc/src/images/red-ball.gif Binary files differdeleted file mode 100644 index dca9296014..0000000000 --- a/lib/orber/doc/src/images/red-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/variable-index.gif b/lib/orber/doc/src/images/variable-index.gif Binary files differdeleted file mode 100644 index 65cc029e72..0000000000 --- a/lib/orber/doc/src/images/variable-index.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/variables.gif b/lib/orber/doc/src/images/variables.gif Binary files differdeleted file mode 100644 index e8a735399a..0000000000 --- a/lib/orber/doc/src/images/variables.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/yellow-ball-small.gif b/lib/orber/doc/src/images/yellow-ball-small.gif Binary files differdeleted file mode 100644 index 8e5f57cdfc..0000000000 --- a/lib/orber/doc/src/images/yellow-ball-small.gif +++ /dev/null diff --git a/lib/orber/doc/src/images/yellow-ball.gif b/lib/orber/doc/src/images/yellow-ball.gif Binary files differdeleted file mode 100644 index 2b8c0bb3d6..0000000000 --- a/lib/orber/doc/src/images/yellow-ball.gif +++ /dev/null diff --git a/lib/orber/doc/src/interceptor_operations.gif b/lib/orber/doc/src/interceptor_operations.gif Binary files differdeleted file mode 100644 index cd72f7fcb7..0000000000 --- a/lib/orber/doc/src/interceptor_operations.gif +++ /dev/null diff --git a/lib/orber/doc/src/interceptors.xml b/lib/orber/doc/src/interceptors.xml deleted file mode 100644 index 0aade8ffb4..0000000000 --- a/lib/orber/doc/src/interceptors.xml +++ /dev/null @@ -1,284 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>2001</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>interceptors</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1999-09-03</date> - <rev>A</rev> - </header> - <module>interceptors</module> - <modulesummary>Describe the functions which must be exported by any supplied Orber native interceptor.</modulesummary> - <description> - <p>This module contains the mandatory functions for user supplied native - interceptors and their intended behavior. See also the User's Guide.</p> - <warning> - <p>Using <c>Interceptors</c> may reduce the through-put significantly - if the supplied interceptors invoke expensive operations. Hence, - one should always supply interceptors which cause as little overhead - as possible.</p> - </warning> - <warning> - <p>It is possible to alter the <c>Data</c>, <c>Bin</c> and <c>Args</c> - parameter for the <c>in_reply</c> and <c>out_reply</c>, - <c>in_reply_encoded</c>, <c>in_request_encoded</c>, - <c>out_reply_encoded</c> and <c>out_request_encoded</c>, - <c>in_request</c> and <c>out_request</c> respectively. But, - if it is done incorrectly, the consequences can be serious.</p> - </warning> - <note> - <p>The <c>Extra</c> parameter is set to 'undefined' by Orber when calling - the first interceptor and may be set to any Erlang term. If an - interceptor change this parameter it will be passed on to the next - interceptor in the list uninterpreted.</p> - </note> - <note> - <p>The <c>Ref</c> parameter is set to 'undefined' by Orber when calling - <c>new_in_connection</c> or <c>new_out_connection</c> using - the first interceptor. The user supplied interceptor may set <c>NewRef</c> - to any Erlang term. If an interceptor change this parameter it will be - passed on to the next interceptor in the list uninterpreted.</p> - </note> - </description> - <funcs> - <func> - <name>new_in_connection(Ref, PeerHost, PeerPort) -> NewRef</name> - <name>new_in_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name> - <fsummary>Invoke when a new client ORB wants to setup a connection</fsummary> - <type> - <v>Ref = term() | undefined</v> - <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v> - <v>PeerPort = SocketPort = integer()</v> - <v>NewRef = term() | {'EXIT', Reason}</v> - </type> - <desc> - <p>When a new connection is requested by a client side ORB this operation - is invoked. If more than one interceptor is supplied, e.g., - <c>{native, ['myInterceptor1', 'myInterceptor2']}</c>, the return value - from 'myInterceptor1' is passed to 'myInterceptor2' as <c>Ref</c>. - Initially, Orber uses the atom 'undefined' as <c>Ref</c> parameter - when calling the first interceptor. The return value from the last - interceptor, in the example above 'myInterceptor2', is passed - to all other functions exported by the interceptors. Hence, - the <c>Ref</c> parameter can, for example, be used as a unique - identifier to mnesia or ets where information/restrictions for - this connection is stored.</p> - <p>The PeerHost and PeerPort variables supplied data of - the client ORB which requested a new connection. SocketHost - and SocketPort are the local interface and port the client - connected to.</p> - <p>If, for some reason, we do not allow the client ORB to connect - simply invoke <c>exit(Reason)</c>.</p> - </desc> - </func> - <func> - <name>new_out_connection(Ref, PeerHost, PeerPort) -> NewRef</name> - <name>new_out_connection(Ref, PeerHost, PeerPort, SocketHost, SocketPort) -> NewRef</name> - <fsummary>Invoke when setting up a new connection to a server side ORB</fsummary> - <type> - <v>Ref = term() | undefined</v> - <v>PeerHost = SocketHost = string(), e.g., "myHost@myServer" or "192.0.0.10"</v> - <v>PeerPort = SocketPort = integer()</v> - <v>NewRef = term() | {'EXIT', Reason}</v> - </type> - <desc> - <p>When a new connection is set up this function is invoked. Behaves - just like <c>new_in_connection</c>; the only difference is that - the PeerHost and PeerPort variables identifies the target ORB's bootstrap - data and SocketHost and SocketPort are the local interface and port - the client ORB connected via.</p> - </desc> - </func> - <func> - <name>closed_in_connection(Ref) -> NewRef</name> - <fsummary>Invoke when an existing connection to a client side ORB have been terminated</fsummary> - <type> - <v>Ref = term()</v> - <v>NewRef = term()</v> - </type> - <desc> - <p>When an existing connection is terminated this operation is invoked. - The main purpose of this function is to make it possible for a user - to clean up all data associated with the associated connection.</p> - <p>The input parameter <c>Ref</c> is the return value from - <c>new_in_connection/3</c>.</p> - </desc> - </func> - <func> - <name>closed_out_connection(Ref) -> NewRef</name> - <fsummary>Invoke when an existing connection to a server side ORB have been terminated</fsummary> - <type> - <v>Ref = term()</v> - <v>NewRef = term()</v> - </type> - <desc> - <p>When an existing connection is terminated this operation is invoked. - The main purpose of this function is to make it possible for a user - to clean up all data associated with the associated connection.</p> - <p>The input parameter <c>Ref</c> is the return value from - <c>new_out_connection/3</c>.</p> - </desc> - </func> - <func> - <name>in_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name> - <fsummary>Invoke when replies arrives at the client side ORB</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Data = [Result, OutParameter1, ..., OutPramaterN]</v> - <v>Reply = {NewData, NewExtra}</v> - </type> - <desc> - <p>When replies are delivered from the server side ORB to the client side - ORB this operation is invoked. The <c>Data</c> parameter is a list in which - the first element is the return value value from the target object and - the rest is a all parameters defined as <c>out</c> or <c>inout</c> in - the IDL-specification.</p> - </desc> - </func> - <func> - <name>in_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name> - <fsummary>Invoke when replies arrives at the client side ORB with undecoded reply body</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Bin = #binary</v> - <v>Reply = {NewBin, NewExtra}</v> - </type> - <desc> - <p>When replies are delivered from the server side ORB to the client side - ORB this operation is invoked. The <c>Bin</c> parameter is the reply - body still uncoded.</p> - </desc> - </func> - <func> - <name>in_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name> - <fsummary>Invoke when requests arrive at the server side ORB</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Args = [Argument] - defined in the IDL-specification</v> - <v>Reply = {NewArgs, NewExtra}</v> - </type> - <desc> - <p>When a new request arrives at the server side ORB this operation is - invoked.</p> - </desc> - </func> - <func> - <name>in_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name> - <fsummary>Invoke when requests arrive at the server side ORB with undecoded request body</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Bin = #binary</v> - <v>Reply = {NewBin, NewExtra}</v> - </type> - <desc> - <p>When a new request arrives at the server side ORB this operation is - invoked before decoding the request body.</p> - </desc> - </func> - <func> - <name>out_reply(Ref, Obj, Ctx, Op, Data, Extra) -> Reply</name> - <fsummary>Invoke after the target object replied</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Data = [Result, OutParameter1, ..., OutPramaterN]</v> - <v>Reply = {NewData, NewExtra}</v> - </type> - <desc> - <p>After the target object have been invoked this operation is invoked - with the result. The <c>Data</c> parameter is a list in which - the first element is the return value value from the target object and - the rest is a all parameters defined as <c>out</c> or <c>inout</c> in - the IDL-specification.</p> - </desc> - </func> - <func> - <name>out_reply_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name> - <fsummary>Invoke after the target object replied with the reply encoded</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Bin = #binary</v> - <v>Reply = {NewBin, NewExtra}</v> - </type> - <desc> - <p>This operation is similar to <c>out_reply</c>; the only difference is - that the reply body have been encoded.</p> - </desc> - </func> - <func> - <name>out_request(Ref, Obj, Ctx, Op, Args, Extra) -> Reply</name> - <fsummary>Invoke on the client side ORB before encoding and sending the request</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Args = [Argument] - defined in the IDL-specification</v> - <v>Reply = {NewArgs, NewExtra}</v> - </type> - <desc> - <p>Before a request is sent to the server side ORB, <c>out_request</c> is - invoked.</p> - </desc> - </func> - <func> - <name>out_request_encoded(Ref, Obj, Ctx, Op, Bin, Extra) -> Reply</name> - <fsummary>Invoke on the client side ORB before sending the request</fsummary> - <type> - <v>Ref = term()</v> - <v>Obj = #objref</v> - <v>Ctx = [#'IOP_ServiceContext'{}]</v> - <v>Op = atom()</v> - <v>Bin = #binary</v> - <v>Reply = {NewBin, NewExtra}</v> - </type> - <desc> - <p>This operation is similar to <c>out_request</c>; the only - difference is that the request body have been encoded.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/intro_part.xml b/lib/orber/doc/src/intro_part.xml deleted file mode 100644 index 7e5520e42e..0000000000 --- a/lib/orber/doc/src/intro_part.xml +++ /dev/null @@ -1,41 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE part SYSTEM "part.dtd"> - -<part> - <header> - <copyright> - <year>2002</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>Introduction to Orber and the IFR</title> - <prepared>Niclas Eklund</prepared> - <docno></docno> - <date>2002-06-25</date> - <rev>A</rev> - </header> - <description> - <p>This chapter contains an introduction to Orber and the IFR - (Interface Repository).</p> - </description> - <include file="ch_introduction"></include> - <include file="ch_orber_kernel"></include> - <include file="ch_ifr"></include> -</part> - diff --git a/lib/orber/doc/src/lname.xml b/lib/orber/doc/src/lname.xml deleted file mode 100644 index c0c9be1a85..0000000000 --- a/lib/orber/doc/src/lname.xml +++ /dev/null @@ -1,166 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>lname</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>lname</module> - <modulesummary>Interface that supports the name pseudo-objects.</modulesummary> - <description> - <p>This interface is a part of the names library which is used to hide the - representation of names. In Orbers Erlang mapping the pseudo-object names - and the real IDL names have the same representation but it is desirable that - the clients uses the names library so they will not be dependent of the representation. - The lname interface supports handling of names e.g. adding and removing name - components.</p> - <p>Note that the lname interface in orber does not contain a destroy function because - the Names are represented as standard Erlang lists and therefor will be removed - by the garbage collector when not in use.</p> - <p>The type <c>NameComponent</c> used below is defined as:</p> - <code type="erl"> --record('CosNaming_NameComponent', {id, kind=""}). - </code> - <p><c>id</c> and <c>kind</c> are strings. </p> - <p>The record is defined in the file <c>CosNaming.hrl</c> and it - is included with:</p> - <code type="erl"> --include_lib("orber/COSS/CosNaming/CosNaming.hrl"). - </code> - </description> - <funcs> - <func> - <name>create() -> Return</name> - <fsummary>Create a new name</fsummary> - <type> - <v>Return = [NameComponent]</v> - </type> - <desc> - <p>This function returns a new name.</p> - </desc> - </func> - <func> - <name>insert_component(Name, N, NameComponent) -> Return</name> - <fsummary>Insert a new name component in a name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>N = int()</v> - <v>Return = Name</v> - </type> - <desc> - <p>This function returns a name where the new name component has been inserted as - component <c>N</c> in Name.</p> - </desc> - </func> - <func> - <name>get_component(Name, N) -> Return</name> - <fsummary>Get a name component from a name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>N = int()</v> - <v>Return = NameComponent</v> - </type> - <desc> - <p>This function returns the <c>N:th</c> name component in Name.</p> - </desc> - </func> - <func> - <name>delete_component(Name, N) -> Return</name> - <fsummary>Delete a name component from a name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>N = int()</v> - <v>Return = Name</v> - </type> - <desc> - <p>This function deletes the <c>N:th</c> name component from Name and returns - the new name.</p> - </desc> - </func> - <func> - <name>num_component(Name) -> Return</name> - <fsummary>Count the number of name components in a name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>Return = int()</v> - </type> - <desc> - <p>This function returns a the number of name components in Name.</p> - </desc> - </func> - <func> - <name>equal(Name1, Name2) -> Return</name> - <fsummary>Test if two names are equal</fsummary> - <type> - <v>Name1 = Name2 = [NameComponent]</v> - <v>Return = bool()</v> - </type> - <desc> - <p>This function returns true if the two names are equal and false otherwise.</p> - </desc> - </func> - <func> - <name>less_than(Name1, Name2) -> Return</name> - <fsummary>Test if one name is lesser than the other</fsummary> - <type> - <v>Name1 = Name2 = [NameComponent]</v> - <v>Return = bool()</v> - </type> - <desc> - <p>This function returns true if Name1 are lesser than Name2 and false otherwise.</p> - </desc> - </func> - <func> - <name>to_idl_form(Name) -> Return</name> - <fsummary>Transform a pseudo name to an IDL name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>Return = Name</v> - </type> - <desc> - <p>This function just checks if Name is a correct IDL name before returning it - because the name representation is the same for pseudo and IDL names in orber.</p> - </desc> - </func> - <func> - <name>from_idl_form(Name) -> Return</name> - <fsummary>Transform an IDL name to a pseudo name</fsummary> - <type> - <v>Name = [NameComponent]</v> - <v>Return = Name</v> - </type> - <desc> - <p>This function just returns the Name because the name representation is the - same for pseudo and IDL names in orber.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/lname_component.xml b/lib/orber/doc/src/lname_component.xml deleted file mode 100644 index 8b8001c0fb..0000000000 --- a/lib/orber/doc/src/lname_component.xml +++ /dev/null @@ -1,113 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2017</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>lname_component</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>lname_component</module> - <modulesummary>Interface that supports the name pseudo-objects.</modulesummary> - <description> - <p>This interface is a part of the name library, which is used to hide the - representation of names. In Orbers Erlang mapping the pseudo-object names - and the real IDL names have the same representation but it is desirable that - the clients uses the names library so they will not be dependent of the representation. - The lname_component interface supports handling of name components e.g. set and get - of the struct members.</p> - <p>Note that the lname_component interface in orber does not contain a destroy - function because the NameComponents are represented as Erlang records and - therefor will be removed by the garbage collector when not in use.</p> - <p>The type <c>NameComponent</c> used below is defined as:</p> - <code type="erl"> --record('CosNaming_NameComponent', {id, kind=""}). - </code> - <p><c>id</c> and <c>kind</c> are strings. </p> - <p>The record is defined in the file <c>CosNaming.hrl</c> and it - is included with:</p> - <code type="erl"> --include_lib("orber/COSS/CosNaming/CosNaming.hrl"). - </code> - </description> - <funcs> - <func> - <name>create() -> Return</name> - <fsummary>Create a new name component</fsummary> - <type> - <v>Return = NameComponent</v> - </type> - <desc> - <p>This function returns a new name component.</p> - </desc> - </func> - <func> - <name>get_id(NameComponent) -> Return</name> - <fsummary>Get the id field of a name component</fsummary> - <type> - <v>Return = string()</v> - </type> - <desc> - <p>This function returns the id string of a name component.</p> - </desc> - </func> - <func> - <name>set_id(NameComponent, Id) -> Return</name> - <fsummary>Set the id field of a name component</fsummary> - <type> - <v>Id = string()</v> - <v>Return = NameComponent</v> - </type> - <desc> - <p>This function sets the id string of a name component and returns the component.</p> - </desc> - </func> - <func> - <name>get_kind(NameComponent) -> Return</name> - <fsummary>Get the kind field of a name component</fsummary> - <type> - <v>Return = string()</v> - </type> - <desc> - <p>This function returns the id string of a name component.</p> - </desc> - </func> - <func> - <name>set_kind(NameComponent, Kind) -> Return</name> - <fsummary>Set the kind field of a name component</fsummary> - <type> - <v>Kind = string()</v> - <v>Return = NameComponent</v> - </type> - <desc> - <p>This function sets the kind string of a name component and returns the component.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/menuframe.gif b/lib/orber/doc/src/menuframe.gif Binary files differdeleted file mode 100644 index 57a437e6b0..0000000000 --- a/lib/orber/doc/src/menuframe.gif +++ /dev/null diff --git a/lib/orber/doc/src/name.gif b/lib/orber/doc/src/name.gif Binary files differdeleted file mode 100644 index d2df460092..0000000000 --- a/lib/orber/doc/src/name.gif +++ /dev/null diff --git a/lib/orber/doc/src/notes.xml b/lib/orber/doc/src/notes.xml deleted file mode 100644 index 35da4f73da..0000000000 --- a/lib/orber/doc/src/notes.xml +++ /dev/null @@ -1,860 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE chapter SYSTEM "chapter.dtd"> - -<chapter> - <header> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Orber Release Notes</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>99-02-12</date> - <rev>A</rev> - <file>notes.xml</file> - </header> - - <section><title>Orber 3.8.4</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> Removed all old unused files in the documentation. - </p> - <p> - Own Id: OTP-14475 Aux Id: ERL-409, PR-1493 </p> - </item> - <item> - <p> Removed the man warnings by using the code tag - instead of c tag. </p> - <p> - Own Id: OTP-14673</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.8.3</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> - Fix some dialyzer warnings</p> - <p> - Own Id: OTP-14006</p> - </item> - </list> - </section> - - </section> - - <section><title>Orber 3.8.2</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> - Internal changes</p> - <p> - Own Id: OTP-13551</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.8.1</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> Suppress Dialyzer warnings. </p> - <p> - Own Id: OTP-12862</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.8</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> Remove the usage of erlang:now() from all Corba - applications and use the new rand module instead of - random. </p> - <p> - Own Id: OTP-12687</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.7.1</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> Fixed problem with IPv6 addresses in Service Context - when orber is default configured for IPv4. </p> - <p> - Own Id: OTP-12193</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.7</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> The following functions have been corrected so they - work properly with IPv6 addresses. </p> <list> - <item><c>corba:resolve_initial_references_remote/2/3</c></item> - <item><c>corba:list_initial_references_remote/1/2</c></item> - <item><c>corba:string_to_object/1/2</c></item> </list> - <p> - Own Id: OTP-12016</p> - </item> - <item> - <p> A couple of macros were malformed, missing commas: - PROFILEBODY_1_1_TYPEDEF and PROFILEBODY_1_2_TYPEDEF. - Thanks to Vlad Dumitrescu. </p> - <p> - Own Id: OTP-12062</p> - </item> - </list> - </section> - - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> It is now possible to add listen interfaces for IPv6 - when orber is default configured for IPv4 and the other - way around. For more information, consult the User's - Guide and the orber module Reference Manual. </p> - <p> - Own Id: OTP-12007</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.6.27</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> - Some local implementations of removing the last element - from a list are replaced by <c>lists:droplast/1</c>. Note - that this requires at least <c>stdlib-2.0</c>, which is - the stdlib version delivered in OTP 17.0. (Thanks to Hans - Svensson)</p> - <p> - Own Id: OTP-11678</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.6.26.1</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> Postscript files no longer needed for the generation - of PDF files have been removed. </p> - <p> - Own Id: OTP-11016</p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.6.26</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> - Fix bug in corbaloc/corbaname over ssl.</p> - <p> - Own Id: OTP-10675</p> - </item> - </list> - </section> - - </section> - - <section><title>Orber 3.6.25</title> - - <section><title>Improvements and New Features</title> - <list> - <item> - <p> Some examples overflowing the width of PDF pages have - been corrected. </p> - <p> - Own Id: OTP-10665</p> - </item> - </list> - </section> - - <section><title>Known Bugs and Problems</title> - <list> - <item> - <p> - Own Id: OTP-10675 Aux Id: seq12154 - </p> - </item> - </list> - </section> -</section> - -<section><title>Orber 3.6.24</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> - Fix number of arguments in orber dbg printout</p> - <p> - Own Id: OTP-9887</p> - </item> - <item> - <p> The descriptions of <c>ssl_server_options</c> and - <c>ssl_client_options</c> are corrected.<br/> Seq. Id: - seq12018 </p> - <p> - Own Id: OTP-9966 Aux Id: OTP-9773 </p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.6.23</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> Remove usage of ssl:seed/1 in orber test cases. </p> - <p> - Own Id: OTP-9728</p> - </item> - </list> - </section> - - - <section><title>Improvements and New Features</title> - <list> - <item> - <p>Erlang/OTP can now be built using parallel make if you - limit the number of jobs, for instance using '<c>make - -j6</c>' or '<c>make -j10</c>'. '<c>make -j</c>' does not - work at the moment because of some missing - dependencies.</p> - <p> - Own Id: OTP-9451</p> - </item> - <item> - <p> The SSL option handling has been changed. There are - now two new orber options <c>ssl_server_options</c> and - <c>ssl_client_options</c> which takes a list of options - to the socket. </p> <p> The old options are now - deprecated and removed from the documentation but they - can still be used for backward compatibility as long as - the two new options not are used. </p> <p> If - <c>ssl_server_options</c> and <c>ssl_client_options</c> - contain an TCP option that <c>orber</c> needs to set to a - specific value it will be skipped and a warning will be - written to the error_log. </p> - <p> - Own Id: OTP-9773 Aux Id: seq11932 </p> - </item> - </list> - </section> - -</section> - -<section><title>Orber 3.6.22</title> - - <section><title>Fixed Bugs and Malfunctions</title> - <list> - <item> - <p> XML files have been corrected. </p> - <p> - Own Id: OTP-9550 Aux Id: OTP-9541 </p> - </item> - </list> - </section> - -</section> - -<section> - <title>Orber 3.6.21</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Eliminated Dialyzer warnings.</p> - <p> - Own Id: OTP-9326 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.20</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Eliminated Dialyzer warnings when using exit or throw.</p> - <p> - Own Id: OTP-9050 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.19</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Partial support for recursive structs and unions. - Only available for the erl_corba backend and requires - that Light IFR is used. I.e. the IC option {light_ifr, true} - and that Orber is configured in such a way that Light IFR - is activated. Recursive TypeCode is currently not supported.</p> - <p> - Own Id: OTP-8868 Aux Id: seq11633</p> - </item> - </list> - </section> - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>The SSL option {ssl_imp, old} was not used if ssl_generation was - set to 2. Only R14B was affected by this.</p> - <p>Own Id: OTP-8994 Aux Id: seq11747</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.18</title> - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>A corbaloc http string could return an EXIT message, instead - of a system exception, if the HTTP server closed the socket - without returning a complete message. I.e. header and a body - containing a stringified IOR.</p> - <p>Own Id: OTP-8900 Aux Id: seq11704</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.17</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Eliminated warnings for auto-imported BIF clashes.</p> - <p> - Own Id: OTP-8840</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.16</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Test suites published.</p> - <p> - Own Id: OTP-8543O Aux Id:</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>Added missing trailing bracket to define in hrl-file.</p> - <p>Own Id: OTP-8489 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.15</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - Added the configuration parameters iiop_out_ports_attempts and - iiop_out_ports_random.</p> - <p> - Own Id: OTP-8448 Aux Id: seq11498</p> - </item> - <item> - <p> - Removed obsolete SSL dependency.</p> - <p> - Own Id: OTP-8374 Aux Id:</p> - </item> - <item> - <p> - Removed the usage of the codeinclude tag in the documentation.</p> - <p> - Own Id: OTP-8409 Aux Id:</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>Removed superfluous VT in the documentation.</p> - <p>Own Id: OTP-8353 Aux Id:</p> - </item> - <item> - <p>Removed superfluous backslash in the documentation.</p> - <p>Own Id: OTP-8354 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.14</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p> - The documentation is now built with open source tools (xsltproc and fop) - that exists on most platforms. One visible change is that the frames are removed.</p> - <p> - Own Id: OTP-8201 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.13</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Obsolete guards, e.g. record vs is_record, has been changed - to avoid compiler warnings.</p> - <p>Own Id: OTP-7987</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.12</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Only the source instance of InitialReference.java is now - included. Users are adviced to use the Interoperable - Naming Service (INS) instead. INS is a part of the OMG - standard specification.</p> - <p>*** POTENTIAL INCOMPATIBILITY ***</p> - <p>Own Id: OTP-7906 Aux Id: seq11243</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.11</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Updated file headers.</p> - <p>Own Id: OTP-7837</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.10</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Documentation source included in open source releases.</p> - <p>Own Id: OTP-7595</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.9</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Updated file headers.</p> - <p>Own Id: OTP-7011</p> - </item> - <item> - <p>Now compliant with the new behavior of stdlib.</p> - <p>Own Id: OTP-7030 Aux Id: seq10827</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.8</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>When a local port range has been defined (i.e. iiop_out_ports), - Orber set the socket option reuseaddr to true and after one - timed out connection attempt no other port in the given range - is used for that particular connect attempt.</p> - <p>Own Id: OTP-6844 Aux Id: </p> - </item> - <item> - <p>Possible to override global SSL parameters when using - local interfaces.</p> - <p>Own Id: OTP-6869 Aux Id: seq10742</p> - </item> - </list> - </section> - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>The parameter ssl_client_ciphers was used on the server side as well - instead of ssl_server_ciphers.</p> - <p>Own Id: OTP-6868 Aux Id:</p> - </item> - <item> - <p>The configuration parameter iiop_max_in_requests was ignored, until - the first incoming request arrived, if iiop_packet_size was set.</p> - <p>Own Id: OTP-6912 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.7</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>The documentation source has been converted from SGML to XML.</p> - <p>Own Id: OTP-6754 Aux Id: </p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.6</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>It is now possible to configure incoming connections which - overrides some global configuration parameters. See - orber:add_listen_interface/2/3.</p> - <p>Own Id: OTP-6696 Aux Id: </p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.5</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Removed some unused code.</p> - <p>Own Id: OTP-6527 Aux Id: </p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.4</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Orber can now be configured so that different NAT parameters - can be specified for different interfaces.</p> - <p>Own Id: OTP-6165 Aux Id: </p> - </item> - <item> - <p>It is now possible to set the keepalive option for incoming - and outgoing IIOP connections. For more information, see the - Configuration chapter in the User's Guide.</p> - <p>Own Id: OTP-6370 Aux Id: seq10532</p> - </item> - <item> - <p>The new function orber:close_connection/1/2 allows a client - to close connections to an object residing on a remote ORB.</p> - <p>Own Id: OTP-6371 Aux Id: seq10532</p> - </item> - <item> - <p>Orber now use the SSL two-phase accept strategy to avoid - that new incoming connections via SSL are not blocked - by a previous connect attempt that never initiated the - SSL handshake. Note, the configuration parameter - iiop_ssl_accept_timeout should be set (default infinity). - For more information, see the Configuration chapter in the - User's Guide. If Orber is started in secure mode, the - installed SSL version must support ssl:ssl_accept/1/2 and - ssl:transport_accept/1/2.</p> - <p>Own Id: OTP-6372 Aux Id: seq10105</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>The operation orber_ifr:contents/2 could only handle dk_All.</p> - <p>Own Id: OTP-6385 Aux Id:</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.3</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>When installing Orber it is now possible to set the priority - for Orber internal Mnesia tables. For more information, see the - Reference Manual regarding orber:install/2.</p> - <p>Own Id: OTP-5907 Aux Id: seq10156</p> - </item> - <item> - <p>The operation corba_object:is_a/2/3 now only connect to a remote - ORB if necessary (i.e. the target object inherits from objects - associated with the given IFR id).</p> - <p>Own Id: OTP-5908</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>The operation corba_object:is_remote/1 always returned - true, which was introduced in orber-3.2.10.</p> - <p>Own Id: OTP-5909</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.2</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Native interceptors may now export new_in_connection and - new_out_connection operations with arity 5. If this is the - case, information about the local interface and port is - passed to the interceptor. Orber's built in interceptors - have been changed to include this information as well.</p> - <p>Own Id: OTP-5671</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>In some cases, e.g. incorrect GIOP headers or a CancelRequest - containing a non-existing RequestId, the incoming connection - would be terminated.</p> - <p>Own Id: OTP-5672 Aux Id: seq10037</p> - </item> - <item> - <p>If combining the 'Use Current Interface in IOR' and - 'Use IPv6' flags, exported IOR:s contained an incorrect - host address.</p> - <p>Own Id: OTP-5673</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6.1</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>Reduced overhead when using outgoing ACL with a local interface - defined.</p> - <p>Own Id: OTP-5659</p> - </item> - <item> - <p>Added guards to ensure that, when so required, a list - of IOP_ServiceContext's is passed instead of, for example, - just the context record.</p> - <p>Own Id: OTP-5660</p> - </item> - </list> - </section> - - <section> - <title>Fixed Bugs and Malfunctions</title> - <list type="bulleted"> - <item> - <p>The documentation referred to two different context definitions, - the incorrect ServiceContext and the correct IOP_ServiceContext. - The hrl file PATH/include/corba.hrl also contained the incorrect - record definition. This has now been updated so that only - IOP_ServiceContext is used and referred to.</p> - <p>Own Id: OTP-5658</p> - </item> - </list> - </section> - </section> - - <section> - <title>Orber 3.6</title> - - <section> - <title>Improvements and New Features</title> - <list type="bulleted"> - <item> - <p>It is now possible to define a Access Control List (ACL), - which limits the host and ports Orber may connect to or - accept connections from.</p> - <p>Own Id: OTP-5567</p> - </item> - <item> - <p>It is now possible to add, and remove, listen interfaces. - For more information, consult the User's Guide and the - orber module Reference Manual.</p> - <p>Own Id: OTP-5568</p> - </item> - <item> - <p>It is now possible to activate and deactivate Audit/Trail - logging. One of the three built in interceptors will be used - depending on the requested verbosity.</p> - <p>Own Id: OTP-5569</p> - </item> - <item> - <p>It is now possible to configure Orber to add the interface, - to exported local IOR:s, a Request came via.</p> - <p>Own Id: OTP-5570</p> - </item> - <item> - <p>It is now possible to instruct Orber which local interface an outgoing Request - shall be sent via. To accomplish this the Orber generic context must be - added added to each invocation.</p> - <p>Own Id: OTP-5571</p> - </item> - <item> - <p>It is now possible to define a default local interface, - which Orber will use when connecting to another ORB.</p> - <p>Own Id: OTP-5583</p> - </item> - </list> - </section> - </section> -</chapter> - diff --git a/lib/orber/doc/src/orber.xml b/lib/orber/doc/src/orber.xml deleted file mode 100644 index d8c6936515..0000000000 --- a/lib/orber/doc/src/orber.xml +++ /dev/null @@ -1,653 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>orber</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-06-10</date> - <rev>A</rev> - </header> - <module>orber</module> - <modulesummary>The main module of the Orber application</modulesummary> - <description> - <p>This module contains the functions for starting and stopping the - application. It also has some utility functions to get some of - the configuration information from running application.</p> - </description> - <funcs> - <func> - <name>start() -> ok</name> - <name>start(Type) -> ok</name> - <fsummary>Start the Orber application</fsummary> - <type> - <v>Type = temporary | permanent</v> - </type> - <desc> - <p>Starts the Orber application (it also starts mnesia if it is not running). - Which <c>Type</c> parameter is supplied determines the behavior. If not - supplied Orber is started as <c>temporary</c>. - See the Reference Manual <em>application(3)</em> for further information. </p> - </desc> - </func> - <func> - <name>jump_start(Attributes) -> ok | {'EXIT', Reason}</name> - <fsummary>Start the Orber application during tests</fsummary> - <type> - <v>Attributes = Port | Options</v> - <v>Port = integer()</v> - <v>Options = [{Key, Value}]</v> - <v>Key = any key listed in the configuration chapter</v> - <v>Value = allowed value associated with the given key</v> - </type> - <desc> - <p>Installs and starts the Orber and the Mnesia applications with the configuration - parameters <c>domain</c> and <c>iiop_port</c> set to <c>"IP-number:Port"</c> - and the supplied Port respectively. Theses settings are in most cases - sufficient to ensure that no clash with any other Orber instance occur. - If this operation fails, check if the listen port (iiop_port) is already - in use. This function <em>MAY ONLY</em> be used during development and - tests; how Orber is configured when using this operation may change - at any time without warning.</p> - </desc> - </func> - <func> - <name>stop() -> ok</name> - <fsummary>Stop the Orber application</fsummary> - <desc> - <p>Stops the Orber application.</p> - </desc> - </func> - <func> - <name>info() -> ok</name> - <name>info(IoType) -> ok | {'EXIT', Reason} | string()</name> - <fsummary>Generate Info Report, which contain Orber's configuration settings</fsummary> - <type> - <v>IoType = info_msg | string | io | {io, IoDevice}</v> - </type> - <desc> - <p>Generates an Info Report, which contain Orber's configuration settings. - If no <c>IoType</c> is supplied, <c>info_msg</c> is used (see the - error_logger documentation). When the atom string is supplied this - function will return a flat list. For <c>io</c> and <c>{io, IoDevice}</c>, - <c>io:format/1</c> and <c>io:format/3</c> is used respectively.</p> - </desc> - </func> - <func> - <name>exception_info(Exception) -> {ok, string()} | {error, Reason}</name> - <fsummary>Return a printable string, which describes the supplied exception</fsummary> - <desc> - <p>Returns a printable string, which describes the supplied exception - in greater detail. Note, this function is mainly intended for - system exceptions.</p> - </desc> - </func> - <func> - <name>is_system_exception(Exception) -> true | false</name> - <fsummary>Return true if the supplied exception is a system defined exception otherwise false</fsummary> - <desc> - <p>Returns true if the supplied exception is a system defined - exception, otherwise false.</p> - </desc> - </func> - <func> - <name>get_tables() -> [Tables]</name> - <fsummary>Get the Mnesia tables Orber uses.</fsummary> - <desc> - <p>Returns a list of the Orber specific Mnesia tables. This list is - required to restore Mnesia if it has been partitioned.</p> - </desc> - </func> - <func> - <name>get_ORBInitRef() -> string() | undefined</name> - <fsummary>Get the initial reference address.</fsummary> - <desc> - <p>This function returns undefined if we will resolve references locally, - otherwise a string describing which host we will contact if the Key given - to <c>corba:resolve_initial_references/1</c> matches the Key set - in this configuration variable. For more information - see the user's guide.</p> - </desc> - </func> - <func> - <name>get_ORBDefaultInitRef() -> string() | undefined</name> - <fsummary>Get the initial reference address.</fsummary> - <desc> - <p>This function returns undefined if we will resolve references locally, - otherwise a string describing which host, or hosts, from which we - will try to resolve the Key given to - <c>corba:resolve_initial_references/1</c>. For more information - see the user's guide.</p> - </desc> - </func> - <func> - <name>domain() -> string()</name> - <fsummary>Display the Orber domain name</fsummary> - <desc> - <p>This function returns the domain name of the current Orber domain - as a string.</p> - </desc> - </func> - <func> - <name>iiop_port() -> int()</name> - <fsummary>Display the IIOP port number</fsummary> - <desc> - <p>This function returns the port-number, which is used by the IIOP - protocol. It can be configured by setting the application variable - <em>iiop_port</em>, if it is not set it will have the default number - 4001.</p> - </desc> - </func> - <func> - <name>iiop_out_ports() -> 0 | {Min, Max}</name> - <fsummary>Display the ports Orber may use when connecting to another ORB</fsummary> - <desc> - <p>The return value of this operation is what the configuration - parameter <seealso marker="ch_install#config">iiop_out_ports</seealso> - has been set to.</p> - </desc> - </func> - - <func> - <name>iiop_out_ports_random() -> true | false</name> - <fsummary>Determine if Orber should select local ports randomly</fsummary> - <desc> - <p>Return the value of the configuration parameter - <seealso marker="ch_install#config">iiop_out_ports_random</seealso>.</p> - </desc> - </func> - - <func> - <name>iiop_out_ports_attempts() -> int()</name> - <fsummary>Display if Orber should accept more than one timeout connecting to another ORB</fsummary> - <desc> - <p>Return the value of the configuration parameter - <seealso marker="ch_install#config">iiop_out_ports_attempts</seealso>.</p> - </desc> - </func> - - - <func> - <name>iiop_ssl_port() -> int()</name> - <fsummary>Display the IIOP port number used for secure connections</fsummary> - <desc> - <p>This function returns the port-number, which is used by the secure IIOP - protocol. It can be configured by setting the application variable - <em>iiop_ssl_port</em>, if it is not set it will have the default number - 4002 if Orber is to configured to run in secure mode. Otherwise it returns -1.</p> - </desc> - </func> - <func> - <name>iiop_timeout() -> int() (milliseconds)</name> - <fsummary>Display the IIOP timeout value</fsummary> - <desc> - <p>This function returns the timeout value after which outgoing IIOP requests terminate. - It can be configured by setting the application variable - <em>iiop_timeout TimeVal (seconds)</em>, if it is not set it will have the default value - <em>infinity</em>. If a request times out a system exception, e.g. - <em>TIMEOUT</em>, is raised.</p> - <p>Note: the iiop_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. - Otherwise, the default value is used.</p> - <p>Note: Earlier IC versions required that the compile option <c>{timeout,"module::interface"}</c>, - was used, which allow the user to add an extra timeout parameter, e.g., - <c>module_interface:function(ObjRef, Timeout, ... Arguments ...)</c> or - <c>module_interface:function(ObjRef, [{timeout, Timeout}], ... Arguments ...)</c>, - instead of <c>module_interface:function(ObjRef, ... Arguments ...)</c>. - This is no longer the case and if the extra Timeout is used, - argument will override the configuration parameter <c>iiop_timeout</c>. - It is, however, not possible - to use <c>infinity</c> to override the Timeout parameter. The Timeout - option is also valid for objects which resides within the same Orber domain.</p> - </desc> - </func> - <func> - <name>iiop_connection_timeout() -> int() (milliseconds)</name> - <fsummary>Display the IIOP connection timeout value</fsummary> - <desc> - <p>This function returns the timeout value after which outgoing IIOP connections terminate. - It can be configured by setting the application variable - <em>iiop_connection_timeout TimeVal (seconds)</em>, if it is not set it will have the default value - <em>infinity</em>. The connection will not be terminated if there are - pending requests.</p> - <p>Note: the iiop_connection_timeout configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. - Otherwise, the default value is used.</p> - </desc> - </func> - <func> - <name>iiop_connections() -> Result</name> - <name>iiop_connections(Direction) -> Result</name> - <fsummary>List all existing connections to/from other ORB's</fsummary> - <type> - <v>Direction = in | out | inout</v> - <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v> - <v>Host = string()</v> - <v>Port = integer()</v> - <v>Interface = string()</v> - <v>Reason = term()</v> - </type> - <desc> - <p>The list returned by this operation contain tuples of remote hosts/ports - Orber is currently connected to. If no Direction is not supplied, both - incoming and outgoing connections are included.</p> - <p>If a specific local interface has been defined for the connection, - this will be added to the returned tuple.</p> - </desc> - </func> - <func> - <name>iiop_connections_pending() -> Result</name> - <fsummary>List all connections to another ORB currently being set up</fsummary> - <type> - <v>Result = [{Host, Port}] | [{Host, Port, Interface}] | {'EXIT',Reason}</v> - <v>Host = string()</v> - <v>Port = integer()</v> - <v>Interface = string()</v> - <v>Reason = term()</v> - </type> - <desc> - <p>In some cases a connection attempt (i.e. trying to communicate with - another ORB) may block due to a number of reasons. This operation - allows the user to check if this is the case. The returned list - contain tuples of remote hosts/ports. Normally, the list is empty.</p> - <p>If a specific local interface has been defined for the connection, - this will be added to the returned tuple.</p> - </desc> - </func> - <func> - <name>iiop_in_connection_timeout() -> int() (milliseconds)</name> - <fsummary>Display the IIOP connection timeout value for incoming connections</fsummary> - <desc> - <p>This function returns the timeout value after which incoming IIOP - connections terminate. It can be configured by setting the application - variable <em>iiop_in_connection_timeout TimeVal (seconds)</em>, if it is - not set it will have the default value <em>infinity</em>. The connection - will not be terminated if there are pending requests.</p> - <p>Note: the iiop_in_connection_timeout configuration parameter (TimeVal) may - only range between 0 and 1000000 seconds. Otherwise, the default value is - used.</p> - </desc> - </func> - <func> - <name>iiop_acl() -> Result</name> - <fsummary>Return the ACL configuration</fsummary> - <type> - <v>Result = [{Direction, Filter}] | [{Direction, Filter, [Interface]}]</v> - <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v> - <v>Filter = string()</v> - <v>Interface = string()</v> - </type> - <desc> - <p>Returns the ACL configuration. The <c>Filter</c> uses a extended format of - Classless Inter Domain Routing (CIDR). For example, <c>"123.123.123.10"</c> limits - the connection to that particular host, while <c>"123.123.123.10/17"</c> allows - connections to or from any host equal to the 17 most significant bits. Orber - also allow the user to specify a certain port or port range, for example, - <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c> - respectively. IPv4 or none compressed IPv6 strings are accepted. <br></br> - - The list of <c>Interfaces</c>, IPv4 or IPv6 strings, are currently only used - for outgoing connections and may only contain <em>one</em> address. If set and - access is granted, Orber will use that local interface when connecting to the - other ORB. The module <seealso marker="orber_acl">orber_acl</seealso> - provides operations for evaluating the access control for filters and addresses.</p> - </desc> - </func> - <func> - <name>activate_audit_trail() -> Result</name> - <name>activate_audit_trail(Verbosity) -> Result</name> - <fsummary>Activate IIOP audit/trail</fsummary> - <type> - <v>Verbosity = stealth | normal | verbose</v> - <v>Result = ok | {error, Reason}</v> - <v>Reason = string()</v> - </type> - <desc> - <p>Activates audit/trail for all existing incoming and outgoing IIOP - connections. The <c>Verbosity</c> parameter, <c>stealth</c>, - <c>normal</c> or <c>verbose</c>, determines which of the built in - interceptors is used (<c>orber_iiop_tracer_stealth</c>, - <c>orber_iiop_tracer_silent</c> or <c>orber_iiop_tracer</c> respectively). - If no verbosity level is supplied, then the <c>normal</c> will be used.</p> - <p>In case Orber is configured to use other interceptors, the audit/trail - interceptors will simply be added to that list.</p> - </desc> - </func> - <func> - <name>deactivate_audit_trail() -> Result</name> - <fsummary>Deactivate IIOP audit/trail</fsummary> - <type> - <v>Result = ok | {error, Reason}</v> - <v>Reason = string()</v> - </type> - <desc> - <p>Deactivates audit/trail for all existing incoming and outgoing IIOP - connections. In case Orber is configured to use other interceptors, - those will still be used.</p> - </desc> - </func> - <func> - <name>add_listen_interface(IP, Type) -> Result</name> - <name>add_listen_interface(IP, Type, Port) -> Result</name> - <name>add_listen_interface(IP, Type, ConfigurationParameters) -> Result</name> - <fsummary>Add a new listen process for incoming connection</fsummary> - <type> - <v>IP = string</v> - <v>Type = normal | ssl</v> - <v>Port = integer() > 0</v> - <v>ConfigurationParameters = [{Key, Value}]</v> - <v>Key = flags | ip_family | iiop_in_connection_timeout | iiop_max_fragments | iiop_max_in_requests | interceptors | iiop_port | iiop_ssl_port | ssl_server_options</v> - <v>Value = as described in the User's Guide or below</v> - <v>Result = {ok, Ref} | {error, Reason} | {'EXCEPTION', #'BAD_PARAM'{}}</v> - <v>Ref = #Ref</v> - <v>Reason = string()</v> - </type> - <desc> - <p>Create a new process that handle requests for creating a new incoming - IIOP connection via the given interface and port. If the latter is - excluded, Orber will use the value of the <c>iiop_port</c> or - <c>iiop_ssl_port</c> configuration parameters. - The <c>Type</c> parameter determines if it is - supposed to be IIOP or IIOP via SSL. If successful, the returned - <c>#Ref</c> shall be passed to <c>orber:remove_listen_interface/1</c> - when the connection shall be terminated.</p> - <p>It is also possible to supply configuration parameters that override - the global configuration. The <em>iiop_in_connection_timeout</em>, - <em>iiop_max_fragments</em>, <em>iiop_max_in_requests</em> and - <em>interceptors</em> parameters simply overrides the global - counterparts (See the - <seealso marker="ch_install#config">Configuration</seealso> chapter - in the User's Guide). - But for the following parameters there are a few restrictions:</p> - <list type="bulleted"> - <item><em>flags</em> - currently it is only possible to override the global - setting for the <c>Use Current Interface in IOR</c> and - <c>Exclude CodeSet Component</c> flags.</item> - <item><em>ip_family</em> - can be set to <c>inet</c> or <c>inet6</c> and is - used to get a listen interface that uses another IP version than the default - set with flags at startup.</item> - <item><em>iiop_port</em> - requires that <c>Use Current Interface in IOR</c> - is activated and the supplied <c>Type</c> is <c>normal</c>. If so, - exported IOR:s will contain the IIOP port defined by this configuration - parameter. Otherwise, the global setting will be used.</item> - <item><em>iiop_ssl_port</em> - almost equivalent to <c>iiop_port</c>. - The difference is that <c>Type</c> shall be <c>ssl</c> and that - exported IOR:s will contain the IIOP via SSL port defined by this configuration - parameter.</item> - </list> - <p>If it is not possible to add a listener based on the supplied interface - and port, the error message is one of the ones described in <c>inet</c> - and/or <c>ssl</c> documentation.</p> - </desc> - </func> - <func> - <name>remove_listen_interface(Ref) -> ok</name> - <fsummary>Terminate listen process for incoming connection</fsummary> - <type> - <v>Ref = #Ref</v> - </type> - <desc> - <p>Terminates the listen process, associated with the supplied <c>#Ref</c>, - for incoming a connection. The Ref parameter is the return value from - the <c>orber:add_listen_interface/2/3</c> operation. When terminating - the connection, all associated requests will not deliver a reply to - the clients.</p> - </desc> - </func> - <func> - <name>close_connection(Connection) -> Result</name> - <name>close_connection(Connection, Interface) -> Result</name> - <fsummary>Terminate outgoing connection(s)</fsummary> - <type> - <v>Connection = Object | [{Host, Port}]</v> - <v>Object = #objref (external)</v> - <v>Host = string()</v> - <v>Port = string()</v> - <v>Interface = string()</v> - <v>Result = ok | {'EXCEPTION', #'BAD_PARAM'{}}</v> - </type> - <desc> - <p>Will try to close all outgoing connections to the host/port combinations - found in the supplied object reference or the given list of hosts/ports. - If a <c>#'IOP_ServiceContext'{}</c> containing a local interface has been - used when communicating with the remote object - (see also <seealso marker="Module_Interface">Module_Interface</seealso>), - that interface shall be passed as the second argument. Otherwise, connections - via the default local interface, will be terminated.</p> - <p></p> - <note> - <p>Since several clients maybe communicates via the same connection, - they will be affected when invoking this operation. Other clients may - re-create the connection by invoking an operation on the target object.</p> - </note> - </desc> - </func> - <func> - <name>secure() -> no | ssl</name> - <fsummary>Display the security mode Orber is running in</fsummary> - <desc> - <p>This function returns the security mode Orber is running in, which is either no if it is an - insecure domain or the type of security mechanism used. For the moment the only security - mechanism is ssl. This is configured by setting the application variable - <em>secure</em>.</p> - </desc> - </func> - <func> - <name>ssl_server_options() -> list()</name> - <fsummary>Display the SSL server options</fsummary> - <desc> - <p>This function returns the list of SSL options set for the Orber domain as server. - This is configured by setting the application variable - <em>ssl_server_options</em>.</p> - </desc> - </func> - <func> - <name>ssl_client_options() -> list()</name> - <fsummary>Display the SSL client options</fsummary> - <desc> - <p>This function returns the list of SSL options used in outgoing calls in the current process. - The default value is configured by setting the application variable - <em>ssl_client_options</em>.</p> - </desc> - </func> - <func> - <name>set_ssl_client_options(Options) -> ok</name> - <fsummary>Set the SSL options for the client</fsummary> - <type> - <v>Options = list()</v> - </type> - <desc> - <p>This function takes a list of SSL options as parameter and sets - it for the current process.</p> - </desc> - </func> - <func> - <name>objectkeys_gc_time() -> int() (seconds)</name> - <fsummary>Display the Object Keys GC time value</fsummary> - <desc> - <p>This function returns the timeout value after which after which terminated object keys, - related to servers started with the configuration parameter <c>{persistent, true}</c>, - will be removed. - It can be configured by setting the application variable <em>objectkeys_gc_time TimeVal (seconds)</em>, - if it is not set it will have the default value <em>infinity</em>. </p> - <p>Objects terminating with reason <em>normal</em> or <em>shutdown</em> are removed automatically.</p> - <p>Note: the objectkeys_gc_time configuration parameter (TimeVal) may only range between 0 and 1000000 seconds. - Otherwise, the default value is used.</p> - </desc> - </func> - <func> - <name>orber_nodes() -> RetVal</name> - <fsummary>Displays which nodes that this orber domain consist of.</fsummary> - <type> - <v>RetVal = [node()]</v> - </type> - <desc> - <p>This function returns the list of node names that this orber - domain consists of. </p> - </desc> - </func> - <func> - <name>install(NodeList) -> ok</name> - <name>install(NodeList, Options) -> ok</name> - <fsummary>Install the Orber application</fsummary> - <type> - <v>NodeList = [node()]</v> - <v>Options = [Option]</v> - <v>Option = {install_timeout, Timeout} | {ifr_storage_type, TableType} | {nameservice_storage_type, TableType} | {initialreferences_storage_type, TableType} | {load_order, Priority}</v> - <v>Timeout = infinity | integer()</v> - <v>TableType = disc_copies | ram_copies</v> - <v>Priority = integer()</v> - </type> - <desc> - <p>This function installs all the necessary mnesia tables and - load default data in some of them. If one or more Orber tables - already exists the installation fails. The function - <em>uninstall</em> may be used, if it is safe, i.e., no other - application is running Orber.</p> - <p>Preconditions:</p> - <list type="bulleted"> - <item>a mnesia schema must exist before the installation</item> - <item>mnesia is running on the other nodes if the new installation - shall be a multi node domain</item> - </list> - <p>Mnesia will be started by the function if it is not already running on - the installation node and if it was started it will be stopped - afterwards.</p> - <p>The options that can be sent to the installation program is:</p> - <list type="bulleted"> - <item><c>{install_timeout, Timeout}</c> - this timeout is how long we - will wait for the tables to be created. The Timeout value can be - <em>infinity</em> or an integer number in milliseconds. - Default is infinity.</item> - <item><c>{ifr_storage_type, TableType}</c> - this option sets the - type of tables used for the interface repository. - The TableType can be disc_copies or ram_copies. Default is - disc_copies.</item> - <item><c>{initialreferences_storage_type, TableType}</c> - this option - sets the type of table used for storing initial references. - The TableType can be disc_copies or ram_copies. Default is - ram_copies.</item> - <item><c>{nameservice_storage_type, TableType}</c> - the default - behavior of Orber is to install the NameService as ram_copies. - This option makes it possible to change this to disc_copies. But - the user should be aware of that if a node is restarted, all - local object references stored in the NameService is not valid. - Hence, you cannot switch to disc_copies and expect exactly the same - behavior as before.</item> - <item><c>{load_order, Priority}</c> - per default the priority is set to 0. - Using this option it will change the priority of in which order - Mnesia will load Orber internal tables. For more information, - consult the Mnesia documentation.</item> - </list> - </desc> - </func> - <func> - <name>uninstall() -> ok</name> - <fsummary>Uninstall the Orber application</fsummary> - <desc> - <p>This function stops the Orber application, terminates all server - objects and removes all Orber related mnesia tables.</p> - <p>Note: Since other applications may be running on the same node - using mnesia <em>uninstall</em> will not stop the mnesia application.</p> - </desc> - </func> - <func> - <name>add_node(Node, Options) -> RetVal</name> - <fsummary>Add a new node to a group of Orber nodes.</fsummary> - <type> - <v>Node = node()</v> - <v>Options = IFRStorageType | [KeyValue] </v> - <v>IFRStorageType = StorageType</v> - <v>StorageType = disc_copies | ram_copies</v> - <v>KeyValue = {ifr_storage_type, StorageType} | {initialreferences_storage_type, StorageType} | {nameservice_storage_type, StorageType} | {type, Type} </v> - <v>Type = temporary | permanent</v> - <v>RetVal = ok | exit()</v> - </type> - <desc> - <p>This function add given node to a existing Orber node group and starts - Orber on the new node. <c>orber:add_node</c> is called from a member in the Orber - node group.</p> - <p>Preconditions for new node:</p> - <list type="bulleted"> - <item>Erlang started on the new node using the option <c>-mnesia extra_db_nodes</c>, e.g., - <c>erl -sname new_node_name -mnesia extra_db_nodes ConnectToNodes_List</c></item> - <item>The new node's <c>domain</c> name is the same for the nodes we want to connect to.</item> - <item>Mnesia is running on the new node (no new schema created).</item> - <item>If the new node will use <c>disc_copies</c> the schema type must be changed using: - <c>mnesia:change_table_copy_type(schema, node(), disc_copies).</c></item> - </list> - <p>Orber will be started by the function on the new node.</p> - <p>Fails if:</p> - <list type="bulleted"> - <item>Orber already installed on given node.</item> - <item>Mnesia not started as described above on the new node.</item> - <item>Impossible to copy data in Mnesia tables to the new node.</item> - <item>Not able to start Orber on the new node, due to, for example, the - <c>iiop_port</c> is already in use.</item> - </list> - <p>The function do not remove already copied tables after a failure. - Use <c>orber:remove_node</c> to remove these tables.</p> - </desc> - </func> - <func> - <name>remove_node(Node) -> RetVal</name> - <fsummary>Removes a node from a group of Orber nodes.</fsummary> - <type> - <v>Node = node()</v> - <v>RetVal = ok | exit()</v> - </type> - <desc> - <p>This function removes given node from a Orber node group. The Mnesia - application is not stopped.</p> - </desc> - </func> - <func> - <name>configure(Key, Value) -> ok | {'EXIT', Reason}</name> - <fsummary>Change Orber configuration.</fsummary> - <type> - <v>Key = orbDefaultInitRef | orbInitRef | giop_version | iiop_timeout | iiop_connection_timeout | iiop_setup_connection_timeout | iiop_in_connection_timeout | objectkeys_gc_time | orber_debug_level</v> - <v>Value = allowed value associated with the given key</v> - </type> - <desc> - <p>This function allows the user to configure Orber in, for example, - an Erlang shell. It is possible to invoke <c>configure</c> at any time - the keys specified above.</p> - <p>Any other key must be set before installing and starting Orber.</p> - <p>Trying to change the configuration in any other way is <em>NOT</em> - allowed since it may affect the behavior of Orber.</p> - <p>For more information regarding allowed values, see - <seealso marker="ch_install#config">configuration settings</seealso> - in the User's Guide.</p> - <p></p> - <note> - <p>Configuring the IIOP timeout values will not affect already - existing connections. If you want a guaranteed uniform behavior, you - must set these parameters from the start.</p> - </note> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/orber_acl.xml b/lib/orber/doc/src/orber_acl.xml deleted file mode 100644 index 5feda83ef6..0000000000 --- a/lib/orber/doc/src/orber_acl.xml +++ /dev/null @@ -1,107 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>2005</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>orber_acl</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>2005-05-19</date> - <rev>A</rev> - </header> - <module>orber_acl</module> - <modulesummary>Orber ACL operations</modulesummary> - <description> - <p>This module contains functions intended for analyzing Access - Control List (ACL) filters. The filters uses a extended format of - Classless Inter Domain Routing (CIDR). - For example, <c>"123.123.123.10"</c> limits - the connection to that particular host, while <c>"123.123.123.10/17"</c> allows - connections to or from any host equal to the 17 most significant bits. Orber - also allow the user to specify a certain port or port range, for example, - <c>"123.123.123.10/17#4001"</c> and <c>"123.123.123.10/17#4001/5001"</c> - respectively. IPv4 or none compressed IPv6 strings are accepted.</p> - </description> - <funcs> - <func> - <name>match(IP, Direction) -> boolean()</name> - <name>match(IP, Direction, GetInfo) -> Reply</name> - <fsummary>Verify if the IP address versus the current configuration</fsummary> - <type> - <v>IP = tuple() | [integer()]</v> - <v>Direction = tcp_in | ssl_in | tcp_out | ssl_out</v> - <v>GetInfo = boolean()</v> - <v>Reply = boolean() | {boolean(), [Interface], PortInfo}</v> - <v>Interface = string()</v> - <v>PortInfo = integer() | {integer(), integer()}</v> - </type> - <desc> - <p>If <c>GetInfo</c> is not supplied or set to false, this operation returns - a boolean which tells if the IPv4 or IPv6 address would pass the ACL - filter, defined by the <c>iiop_acl</c> configuration parameter, or not. - When <c>GetInfo</c> is set to true, a tuple which, besides the boolean - that tells if access was granted, also include the defined - interfaces and port(s). This operation requires that Orber is running and - can be used on a live node to determine if Orber has been properly configured.</p> - </desc> - </func> - <func> - <name>verify(IP, Filter, Family) -> Reply</name> - <fsummary>Verify if the IP address versus the Filter</fsummary> - <type> - <v>IP = string()</v> - <v>Filter = string()</v> - <v>Family = inet | inet6</v> - <v>Reply = true | {false, From, To} | {error, string()}</v> - <v>From = string()</v> - <v>To = string()</v> - </type> - <desc> - <p>This operation returns true if the IPv4 or IPv6 address would pass the - supplied ACL. If that is not the case, a tuple containing the accepted range - is returned. This operation should only be used for test purposes.</p> - </desc> - </func> - <func> - <name>range(Filter, Family) -> Reply</name> - <fsummary>Get range of Filter</fsummary> - <type> - <v>Filter = string()</v> - <v>Family = inet | inet6</v> - <v>Reply = {ok, From, To} | {error, string()}</v> - <v>From = string()</v> - <v>To = string()</v> - </type> - <desc> - <p>Returns the range of accepted IP addresses based on the supplied filter. - This operation should only be used for test purposes.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/orber_diagnostics.xml b/lib/orber/doc/src/orber_diagnostics.xml deleted file mode 100644 index 3aad304535..0000000000 --- a/lib/orber/doc/src/orber_diagnostics.xml +++ /dev/null @@ -1,81 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>2003</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>orber_diagnostics</title> - <prepared></prepared> - <responsible></responsible> - <docno></docno> - <approved></approved> - <checked></checked> - <date>2003-04-17</date> - <rev>A</rev> - </header> - <module>orber_diagnostics</module> - <modulesummary>Diagnostics API for Orber</modulesummary> - <description> - <p>This module contains functions which makes it possible to run simple - tests.</p> - <p></p> - <warning> - <p>Functions exported by this module may only be used during - test and development phase.</p> - </warning> - </description> - <funcs> - <func> - <name>nameservice() -> Result</name> - <name>nameservice(Flags) -> Result</name> - <fsummary>Display all objects stored in the Name Service</fsummary> - <type> - <v>Flags = integer()</v> - <v>Result = ok | {'EXCEPTION', E}</v> - </type> - <desc> - <p>Displays all objects stored in the NameService. Existent checks are, per - default, also performed on all local objects. This can also be activated - for external objects by setting the flag <c>16#01</c>. The displayed - information is the stringified Name described in - <seealso marker="CosNaming_NamingContextExt">CosNaming_NamingContextExt</seealso>, - non existent status (true | false | external | undefined) and the IFR-Id:</p> - <code type="none"> -host/ -host/resources/ -host/resources/MyObj/ [false] IDL:MyMod/MyIntf:1.0 </code> - </desc> - </func> - <func> - <name>missing_modules() -> Count</name> - <fsummary>Echo missing modules required by Orber</fsummary> - <type> - <v>Count = integer()</v> - </type> - <desc> - <p>This operation list missing modules generated by IC and required by - Orber. Requires that all API:s are registered in the IFR.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/orber_ifr.xml b/lib/orber/doc/src/orber_ifr.xml deleted file mode 100644 index a667d7d9e4..0000000000 --- a/lib/orber/doc/src/orber_ifr.xml +++ /dev/null @@ -1,1035 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>orber_ifr</title> - <prepared></prepared> - <docno></docno> - <approved></approved> - <checked></checked> - <date>1997-10-13</date> - <rev>A</rev> - </header> - <module>orber_ifr</module> - <modulesummary>The Interface Repository stores representations of IDL information</modulesummary> - <description> - <p>This module contains functions for managing the Interface - Repository (IFR). This documentation should be used in conjunction - with the documentation in chapter 6 of <term id="CORBA"></term>2.3. - Whenever the term IFR object is used in this manual page, it - refers to a pseudo object used only for interaction with the IFR - rather than a CORBA object.</p> - </description> - - <section> - <title>Initialization of the IFR</title> - <p>The following functions are used to initialize the Interface - Repository and to obtain the initial reference to the - repository.</p> - </section> - <funcs> - <func> - <name>init(Nodes,Timeout) -> ok</name> - <fsummary>Intialize the IFR</fsummary> - <type> - <v>Nodes = list()</v> - <v>Timeout = integer() | infinity</v> - </type> - <desc> - <p>This function should be called to initialize the IFR. It - creates the necessary mnesia-tables. A mnesia schema should - exist, and mnesia must be running.</p> - </desc> - </func> - <func> - <name>find_repository() -> #IFR_Repository_objref</name> - <fsummary>Find the IFR object reference for the Repository</fsummary> - <desc> - <p>Find the IFR object reference for the Repository. This - reference should be used when adding objects to the IFR, and - when extracting information from the IFR. - The first time this function is called, it will create the - repository and all the primitive definitions.</p> - </desc> - </func> - </funcs> - - <section> - <title>General methods</title> - <p>The following functions are the methods of the IFR. The first - argument is always an #IFR_objref, i.e. the IFR (pseudo)object - on which to apply this method. These functions are useful when - the type of IFR object is not know, but they are somewhat slower - than the specific functions listed below which only accept a - particular type of IFR object as the first argument.</p> - </section> - <funcs> - <func> - <name>get_def_kind(Objref) -> Return</name> - <fsummary>Return the definition kind of the IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v> - </type> - <desc> - <p>Objref is an IFR object of any kind. Returns the definition - kind of the IFR object.</p> - </desc> - </func> - <func> - <name>destroy(Objref) -> Return</name> - <fsummary>Destroy, except IRObject, Contained and Container, target object and its contents</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = tuple()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind except IRObject, - Contained and Container. Destroys that object and its - contents (if any). Returns whatever mnesia:transaction - returns.</p> - </desc> - </func> - <func> - <name>get_id(Objref) -> Return</name> - <fsummary>Return the target object's repository id</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the repository id of that object.</p> - </desc> - </func> - <func> - <name>set_id(Objref,Id) -> ok</name> - <fsummary>Set the target object's repository id</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Id = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Sets the repository id of that object.</p> - </desc> - </func> - <func> - <name>get_name(Objref) -> Return</name> - <fsummary>Return the name of the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the name of that object.</p> - </desc> - </func> - <func> - <name>set_name(Objref,Name) -> ok</name> - <fsummary>Set given name to target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Name = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Sets the name of that object.</p> - </desc> - </func> - <func> - <name>get_version(Objref) -> Return</name> - <fsummary>Return the version of the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the version of that object.</p> - </desc> - </func> - <func> - <name>set_version(Objref,Version) -> ok</name> - <fsummary>Set given version of the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Version = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Sets the version of that object.</p> - </desc> - </func> - <func> - <name>get_defined_in(Objref) -> Return</name> - <fsummary>Return the Container the target object is contained in</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = #IFR_Container_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the Container object that the object is - defined in.</p> - </desc> - </func> - <func> - <name>get_absolute_name(Objref) -> Return</name> - <fsummary>Return the absolute name of the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = string()</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the absolute (scoped) name of that - object.</p> - </desc> - </func> - <func> - <name>get_containing_repository(Objref) -> Return</name> - <fsummary>Get the most derived Contained object associated with the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = #IFR_Repository_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns the Repository that is eventually reached - by recursively following the object's defined_in attribute.</p> - </desc> - </func> - <func> - <name>describe(Objref) -> Return</name> - <fsummary>Return a tuple which describe the target object</fsummary> - <type> - <v>Objref = #IFR_object</v> - <v>Return = tuple() (a contained_description record) | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. Returns a tuple describing the object.</p> - </desc> - </func> - <func> - <name>move(Objref,New_container,New_name,New_version) -> Return</name> - <fsummary>Move the target object from its current location to given Container, name and version</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>New_container = #IFR_Container_objref</v> - <v>New_name = string()</v> - <v>New_version = string()</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Contained. New_container is an IFR object of any kind that - inherits from Container. Removes Objref from its current - Container, and adds it to New_container. The name attribute - is changed to New_name and the version attribute is changed - to New_version.</p> - </desc> - </func> - <func> - <name>lookup(Objref,Search_name) -> Return</name> - <fsummary>Return the IFR object identified by the given name</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Search_name = string()</v> - <v>Return = #IFR_object</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Returns an IFR object identified by search_name - (a scoped name).</p> - </desc> - </func> - <func> - <name>contents(Objref,Limit_type,Exclude_inherited) -> Return</name> - <fsummary>Return the content of the target object limited by the given constraints</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v> - <v>Exclude_inherited = atom() (true or false)</v> - <v>Return = list() (a list of IFR#_objects)</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Returns the contents of that IFR object.</p> - </desc> - </func> - <func> - <name>lookup_name(Objref,Search_name,Levels_to_search, Limit_type, Exclude_inherited) -> Return</name> - <fsummary>Return a list of IFR objects matching the given name</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Search_name = string()</v> - <v>Levels_to_search = integer()</v> - <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v> - <v>Exclude_inherited = atom() (true or false)</v> - <v>Return = list() (a list of #IFR_objects)</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Returns a list of #IFR_objects with an id - matching Search_name.</p> - </desc> - </func> - <func> - <name>describe_contents(Objref, Limit_type, Exclude_inherited, Max_returned_objs) -> Return</name> - <fsummary>Return a list of descriptions of the IFR objects contained by the target Container object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Limit_type = atom() (one of dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Wstring, dk_Fixed, dk_Sequence, dk_Array, dk_Repository)</v> - <v>Exclude_inherited = atom() (true or false)</v> - <v>Return = list() (a list of tuples (contained_description records) | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Returns a list of descriptions of the IFR objects - in this Container's contents.</p> - </desc> - </func> - <func> - <name>create_module(Objref,Id,Name,Version) -> Return</name> - <fsummary>Create an IFR object of given type</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Return = #IFR_ModuleDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type ModuleDef.</p> - </desc> - </func> - <func> - <name>create_constant(Objref,Id,Name,Version,Type,Value) -> Return</name> - <fsummary>Create a ConstantDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Type = #IFR_IDLType_objref</v> - <v>Value = any()</v> - <v>Return = #IFR_ConstantDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type ConstantDef.</p> - </desc> - </func> - <func> - <name>create_struct(Objref,Id,Name,Version,Members) -> Return</name> - <fsummary>Create a StructDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Members = list() (list of structmember records)</v> - <v>Return = #IFR_StructDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type StructDef.</p> - </desc> - </func> - <func> - <name>create_union(Objref,Id,Name,Version,Discriminator_type,Members) -> Return</name> - <fsummary>Create a UnionDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Discriminator_type = #IFR_IDLType_Objref</v> - <v>Members = list() (list of unionmember records)</v> - <v>Return = #IFR_UnionDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type UnionDef.</p> - </desc> - </func> - <func> - <name>create_enum(Objref,Id,Name,Version,Members) -> Return</name> - <fsummary>Create a EnumDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Members = list() (list of strings)</v> - <v>Return = #IFR_EnumDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type EnumDef.</p> - </desc> - </func> - <func> - <name>create_alias(Objref,Id,Name,Version,Original_type) -> Return</name> - <fsummary>Create a AliasDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Original_type = #IFR_IDLType_Objref</v> - <v>Return = #IFR_AliasDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type AliasDef.</p> - </desc> - </func> - <func> - <name>create_interface(Objref,Id,Name,Version,Base_interfaces) -> Return</name> - <fsummary>Create a InterfaceDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Base_interfaces = list() (a list of IFR_InterfaceDef_objrefs that this interface inherits from</v> - <v>Return = #IFR_InterfaceDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type InterfaceDef.</p> - </desc> - </func> - <func> - <name>create_exception(Objref,Id,Name,Version,Members) -> Return</name> - <fsummary>Create a ExceptionDef IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Members = list() (list of structmember records)</v> - <v>Return = #IFR_ExceptionDef_objref</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - Container. Creates an IFR object of the type ExceptionDef.</p> - </desc> - </func> - <func> - <name>get_type(Objref) -> Return</name> - <fsummary>Return the typecode of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = tuple() (a typecode tuple)</v> - </type> - <desc> - <p>Objref is an IFR object of any kind that inherits from - IDLType or an IFR object of the kind ConstantDef, - ExceptionDef or AttributeDef. Returns the typecode of the - IFR object.</p> - </desc> - </func> - <func> - <name>lookup_id(Objref,Search_id) -> Return</name> - <fsummary>Return the IFR object matching the given id</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Search_id = string()</v> - <v>Return = #IFR_objref</v> - </type> - <desc> - <p>Returns an IFR object matching the Search_id.</p> - </desc> - </func> - <func> - <name>get_primitive(Objref,Kind) -> Return</name> - <fsummary>Return a PrimitiveDef of the specified kind</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Kind = atom() (one of pk_null, pk_void, pk_short, pk_long, pk_ushort, pk_ulong, pk_float, pk_double, pk_boolean, pk_char, pk_octet, pk_any, pk_TypeCode, pk_Principal, pk_string, pk_wstring, pk_fixed, pk_objref)</v> - <v>Return = #IFR_PrimitiveDef_objref</v> - </type> - <desc> - <p>Returns a PrimitiveDef of the specified kind.</p> - </desc> - </func> - <func> - <name>create_string(Objref,Bound) -> Return</name> - <fsummary>Create an IFR objref of the type StringDef</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Bound = integer() (unsigned long /= 0)</v> - <v>Return = #IFR_StringDef_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type StringDef.</p> - </desc> - </func> - <func> - <name>create_wstring(Objref,Bound) -> Return</name> - <fsummary>Create an IFR objref of the type WstringDef</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Bound = integer() (unsigned long /= 0)</v> - <v>Return = #IFR_WstringDef_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type WstringDef.</p> - </desc> - </func> - <func> - <name>create_fixed(Objref,Digits,Scale) -> Return</name> - <fsummary>Create an IFR objref of the type FixedDef</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Digits = Scale = integer()</v> - <v>Return = #IFR_FixedDef_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type FixedDef.</p> - </desc> - </func> - <func> - <name>create_sequence(Objref,Bound,Element_type) -> Return</name> - <fsummary>Create an IFR objref of the type SequenceDef</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Bound = integer() (unsigned long)</v> - <v>Element_type = #IFR_IDLType_objref</v> - <v>Return = #IFR_SequenceDef_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type SequenceDef.</p> - </desc> - </func> - <func> - <name>create_array(Objref,Length,Element_type) -> Return</name> - <fsummary>Create an IFR objref of the type ArrayDef</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Bound = integer() (unsigned long)</v> - <v>Element_type = #IFR_IDLType_objref</v> - <v>Return = #IFR_ArrayDef_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type ArrayDef.</p> - </desc> - </func> - <func> - <name>create_idltype(Objref,Typecode) -> Return</name> - <fsummary>Create an IFR objref of the type IDLType</fsummary> - <type> - <v>Objref = #IFR_Repository_objref</v> - <v>Typecode = tuple() (a typecode tuple)</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Creates an IFR objref of the type IDLType.</p> - </desc> - </func> - <func> - <name>get_type_def(Objref) -> Return</name> - <fsummary>Return an IFR object of the type IDLType describing the type of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Objref is an IFR object of the kind ConstantDef or - AttributeDef. Returns an IFR object of the type IDLType - describing the type of the IFR object.</p> - </desc> - </func> - <func> - <name>set_type_def(Objref,TypeDef) -> Return</name> - <fsummary>Set given TypeDef of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>TypeDef = #IFR_IDLType_objref</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object of the kind ConstantDef or - AttributeDef. Sets the type_def of the IFR Object.</p> - </desc> - </func> - <func> - <name>get_value(Objref) -> Return</name> - <fsummary>Return the value attribute of the target ConstantDef object</fsummary> - <type> - <v>Objref = #IFR_ConstantDef_objref</v> - <v>Return = any()</v> - </type> - <desc> - <p>Returns the value attribute of an IFR Object of the type ConstantDef.</p> - </desc> - </func> - <func> - <name>set_value(Objref,Value) -> Return</name> - <fsummary>Set the value attribute of the target ConstantDef object</fsummary> - <type> - <v>Objref = #IFR_ConstantDef_objref</v> - <v>Value = any()</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the value attribute of an IFR Object of the type ConstantDef.</p> - </desc> - </func> - <func> - <name>get_members(Objref) -> Return</name> - <fsummary>Return the members of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = list()</v> - </type> - <desc> - <p>Objref is an IFR object the kind StructDef, UnionDef, - EnumDef or ExceptionDef. - For StructDef, UnionDef and ExceptionDef: Returns a list of - structmember records that are the constituent parts of the - object. - For EnumDef: Returns a list of strings describing the - enumerations.</p> - </desc> - </func> - <func> - <name>set_members(Objref,Members) -> Return</name> - <fsummary>Set the members attribute of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Members = list()</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object the kind StructDef, UnionDef, - EnumDef or ExceptionDef. - For StructDef, UnionDef and ExceptionDef: Members is a list - of structmember records. - For EnumDef: Members is a list of strings describing the - enumerations. - Sets the members attribute, which are the constituent parts of the - exception.</p> - </desc> - </func> - <func> - <name>get_discriminator_type(Objref) -> Return</name> - <fsummary>Get the discriminator typecode of the target object</fsummary> - <type> - <v>Objref = #IFR_UnionDef_objref</v> - <v>Return = tuple() (a typecode tuple)</v> - </type> - <desc> - <p>Returns the discriminator typecode of an IFR object of the type - UnionDef.</p> - </desc> - </func> - <func> - <name>get_discriminator_type_def(Objref) -> Return</name> - <fsummary>Return IDLType object describing the discriminator type of the target object</fsummary> - <type> - <v>Objref = #IFR_UnionDef_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Returns an IFR object of the type IDLType describing the - discriminator type of an IFR object of the type UnionDef.</p> - </desc> - </func> - <func> - <name>set_discriminator_type_def(Objref,TypeDef) -> Return</name> - <fsummary>Set the attribute discriminator_type_def for the target object to the given TypeDef</fsummary> - <type> - <v>Objref = #IFR_UnionDef_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Sets the attribute discriminator_type_def, an IFR object of - the type IDLType describing the discriminator type of an IFR - object of the type UnionDef.</p> - </desc> - </func> - <func> - <name>get_original_type_def(Objref) -> Return</name> - <fsummary>Return an IFR object of the type IDLType describing the original type</fsummary> - <type> - <v>Objref = #IFR_AliasDef_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Returns an IFR object of the type IDLType describing the - original type.</p> - </desc> - </func> - <func> - <name>set_original_type_def(Objref,TypeDef) -> Return</name> - <fsummary>Set the original_type_def attribute which describes the original type</fsummary> - <type> - <v>Objref = #IFR_AliasDef_objref</v> - <v>Typedef = #IFR_IDLType_objref</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the original_type_def attribute which describes the - original type.</p> - </desc> - </func> - <func> - <name>get_kind(Objref) -> Return</name> - <fsummary>Return an atom describing the primitive type</fsummary> - <type> - <v>Objref = #IFR_PrimitiveDef_objref</v> - <v>Return = atom()</v> - </type> - <desc> - <p>Returns an atom describing the primitive type (See CORBA 2.0 - p 6-21).</p> - </desc> - </func> - <func> - <name>get_bound(Objref) -> Return</name> - <fsummary>Get the maximum size of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = integer (unsigned long)</v> - </type> - <desc> - <p>Objref is an IFR object the kind StringDef or SequenceDef. - For StringDef: returns the maximum number of characters in - the string. - For SequenceDef: Returns the maximum number of elements in - the sequence. Zero indicates an unbounded sequence.</p> - </desc> - </func> - <func> - <name>set_bound(Objref,Bound) -> Return</name> - <fsummary>Set the maximum size of the target object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Bound = integer (unsigned long)</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object the kind StringDef or SequenceDef. - For StringDef: Sets the maximum number of characters in the - string. Bound must not be zero. - For SequenceDef: Sets the maximum number of elements in the - sequence. Zero indicates an unbounded sequence.</p> - </desc> - </func> - <func> - <name>get_element_type(Objref) -> Return</name> - <fsummary>Return the typecode of the elements in the IFR object</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = tuple() (a typecode tuple)</v> - </type> - <desc> - <p>Objref is an IFR object the kind SequenceDef or ArrayDef. - Returns the typecode of the elements in the IFR object.</p> - </desc> - </func> - <func> - <name>get_element_type_def(Objref) -> Return</name> - <fsummary>Return an IFR object of the type IDLType describing the type of the elements in Objref</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Objref is an IFR object the kind SequenceDef or ArrayDef. - Returns an IFR object of the type IDLType describing the - type of the elements in Objref.</p> - </desc> - </func> - <func> - <name>set_element_type_def(Objref,TypeDef) -> Return</name> - <fsummary>Set the element_type_def attribute of the target object to the given TypeDef</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>TypeDef = #IFR_IDLType_objref</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object the kind SequenceDef or ArrayDef. - Sets the element_type_def attribute, an IFR object of the - type IDLType describing the type of the elements in Objref.</p> - </desc> - </func> - <func> - <name>get_length(Objref) -> Return</name> - <fsummary>Return the number of elements in the array</fsummary> - <type> - <v>Objref = #IFR_ArrayDef_objref</v> - <v>Return = integer() (unsigned long)</v> - </type> - <desc> - <p>Returns the number of elements in the array.</p> - </desc> - </func> - <func> - <name>set_length(Objref,Length) -> Return</name> - <fsummary>Set the number of elements in the array</fsummary> - <type> - <v>Objref = #IFR_ArrayDef_objref</v> - <v>Length = integer() (unsigned long)</v> - </type> - <desc> - <p>Sets the number of elements in the array.</p> - </desc> - </func> - <func> - <name>get_mode(Objref) -> Return</name> - <fsummary>Get the mode of the target object (AttributeDef or OperationDef)</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Return = atom()</v> - </type> - <desc> - <p>Objref is an IFR object the kind AttributeDef or OperationDef. - For AttributeDef: Return is an atom ('ATTR_NORMAL' or - 'ATTR_READONLY') specifying the read/write access for this - attribute. - For OperationDef: Return is an atom ('OP_NORMAL' or - 'OP_ONEWAY') specifying the mode of the operation.</p> - </desc> - </func> - <func> - <name>set_mode(Objref,Mode) -> Return</name> - <fsummary>Set the mode of the target object (AttributeDef or OperationDef) to the given mode</fsummary> - <type> - <v>Objref = #IFR_objref</v> - <v>Mode = atom()</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Objref is an IFR object the kind AttributeDef or OperationDef. - For AttributeDef: Sets the read/write access for this - attribute. Mode is an atom ('ATTR_NORMAL' or - 'ATTR_READONLY'). - For OperationDef: Sets the mode of the operation. Mode is an - atom ('OP_NORMAL' or 'OP_ONEWAY').</p> - </desc> - </func> - <func> - <name>get_result(Objref) -> Return</name> - <fsummary>Return typecode describing the type of the value returned by the operation</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Return = tuple() (a typecode tuple)</v> - </type> - <desc> - <p>Returns a typecode describing the type of the value returned by the - operation.</p> - </desc> - </func> - <func> - <name>get_result_def(Objref) -> Return</name> - <fsummary>Return an IFR object of the type IDLType describing the type of the result</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Return = #IFR_IDLType_objref</v> - </type> - <desc> - <p>Returns an IFR object of the type IDLType describing the type of the - result.</p> - </desc> - </func> - <func> - <name>set_result_def(Objref,ResultDef) -> Return</name> - <fsummary>Set the type_def attribute of the target object to the given ResultDef</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>ResultDef = #IFR_IDLType_objref</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the type_def attribute, an IFR Object of the type IDLType - describing the result.</p> - </desc> - </func> - <func> - <name>get_params(Objref) -> Return</name> - <fsummary>Return a list of parameter description records describing the parameters of the target OperationDef</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Return = list() (list of parameter description records)</v> - </type> - <desc> - <p>Returns a list of parameter description records, which describes the - parameters of the OperationDef.</p> - </desc> - </func> - <func> - <name>set_params(Objref,Params) -> Return</name> - <fsummary>Set the params attribute of the target object to the given parameter description records</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Params = list() (list of parameter description records)</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the params attribute, a list of parameter description records.</p> - </desc> - </func> - <func> - <name>get_contexts(Objref) -> Return</name> - <fsummary>Return a list of context identifiers for the operation</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Return = list() (list of strings)</v> - </type> - <desc> - <p>Returns a list of context identifiers for the operation.</p> - </desc> - </func> - <func> - <name>set_contexts(Objref,Contexts) -> Return</name> - <fsummary>Set the context attribute for the operation</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Contexts = list() (list of strings)</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the context attribute for the operation.</p> - </desc> - </func> - <func> - <name>get_exceptions(Objref) -> Return</name> - <fsummary>Return a list of exception types that can be raised by the target object</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Return = list() (list of #IFR_ExceptionDef_objrefs)</v> - </type> - <desc> - <p>Returns a list of exception types that can be raised by this - operation.</p> - </desc> - </func> - <func> - <name>set_exceptions(Objref,Exceptions) -> Return</name> - <fsummary>Set the exceptions attribute for the target object</fsummary> - <type> - <v>Objref = #IFR_OperationDef_objref</v> - <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the exceptions attribute for this operation.</p> - </desc> - </func> - <func> - <name>get_base_interfaces(Objref) -> Return</name> - <fsummary>Return a list of InterfaceDefs from which the target InterfaceDef object inherit</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>Return = list() (list of #IFR_InterfaceDef_objrefs)</v> - </type> - <desc> - <p>Returns a list of InterfaceDefs from which this InterfaceDef inherits.</p> - </desc> - </func> - <func> - <name>set_base_interfaces(Objref,BaseInterfaces) -> Return</name> - <fsummary>Set the BaseInterfaces attribute</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>BaseInterfaces = list() (list of #IFR_InterfaceDef_objrefs)</v> - <v>Return = ok | {exception, _}</v> - </type> - <desc> - <p>Sets the BaseInterfaces attribute.</p> - </desc> - </func> - <func> - <name>is_a(Objref,Interface_id) -> Return</name> - <fsummary>Return a boolean if the target InterfaceDef match or inherit from the given id</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>Interface_id = #IFR_InterfaceDef_objref</v> - <v>Return = atom() (true or false)</v> - </type> - <desc> - <p>Returns true if the InterfaceDef either is identical to or - inherits from Interface_id.</p> - </desc> - </func> - <func> - <name>describe_interface(Objref) -> Return</name> - <fsummary>Return a full inter face description record describing the InterfaceDef</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>Return = tuple() (a fullinterfacedescription record)</v> - </type> - <desc> - <p>Returns a full inter face description record describing the InterfaceDef.</p> - </desc> - </func> - <func> - <name>create_attribute(Objref,Id,Name,Version,Type,Mode) -> Return</name> - <fsummary>Create an IFR object of the type AttributeDef contained in the target InterfaceDef object</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Type = #IFR_IDLType_objref</v> - <v>Mode = atom() ('ATTR_NORMAL' or 'ATTR_READONLY')</v> - <v>Return = #IFR_AttributeDef_objref</v> - </type> - <desc> - <p>Creates an IFR object of the type AttributeDef contained in this - InterfaceDef.</p> - </desc> - </func> - <func> - <name>create_operation(Objref,Id,Name,Version,Result,Mode,Params, Exceptions,Contexts) -> Return</name> - <fsummary>Create an IFR object of the type OperationDef contained in the target InterfaceDef object</fsummary> - <type> - <v>Objref = #IFR_InterfaceDef_objref</v> - <v>Id = string()</v> - <v>Name = string()</v> - <v>Version = string()</v> - <v>Result = #IFR_IDLType_objref</v> - <v>Mode = atom() ('OP_NORMAL' or 'OP_ONEWAY')</v> - <v>Params = list() (list of parameter description records)</v> - <v>Exceptions = list() (list of #IFR_ExceptionDef_objrefs)</v> - <v>Contexts = list() (list of strings)</v> - <v>Return = #IFR_OperationDef_objref</v> - </type> - <desc> - <p>Creates an IFR object of the type OperationDef contained in this - InterfaceDef.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/orber_tc.xml b/lib/orber/doc/src/orber_tc.xml deleted file mode 100644 index 0cab8a5e4b..0000000000 --- a/lib/orber/doc/src/orber_tc.xml +++ /dev/null @@ -1,259 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE erlref SYSTEM "erlref.dtd"> - -<erlref> - <header> - <copyright> - <year>1998</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>orber_tc</title> - <prepared>Lars Thorsén</prepared> - <responsible>Lars Thorsén</responsible> - <docno></docno> - <approved>Lars Thorsén</approved> - <checked></checked> - <date>1998-04-20</date> - <rev>A</rev> - </header> - <module>orber_tc</module> - <modulesummary>Help functions for IDL typecodes</modulesummary> - <description> - <p>This module contains some functions that gives support in creating - IDL typecodes that can be used in for example the any types typecode field. - For the simple types it is meaningless to use this API but the functions exist - to get the interface complete.</p> - <p>The type <c>TC</c> used below describes an IDL type and is a tuple according - to the to the Erlang language mapping.</p> - </description> - <funcs> - <func> - <name>null() -> TC</name> - <name>void() -> TC</name> - <name>short() -> TC</name> - <name>unsigned_short() -> TC</name> - <name>long() -> TC</name> - <name>unsigned_long() -> TC</name> - <name>long_long() -> TC</name> - <name>unsigned_long_long() -> TC</name> - <name>wchar() -> TC</name> - <name>float() -> TC</name> - <name>double() -> TC</name> - <name>boolean() -> TC</name> - <name>char() -> TC</name> - <name>octet() -> TC</name> - <name>any() -> TC</name> - <name>typecode() -> TC</name> - <name>principal() -> TC</name> - <fsummary>Return the IDL typecode</fsummary> - <desc> - <p>These functions return the IDL typecodes for simple types.</p> - </desc> - </func> - <func> - <name>object_reference(Id, Name) -> TC</name> - <fsummary>Return the object_reference IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the object</d> - </type> - <desc> - <p>Function returns the IDL typecode for object_reference.</p> - </desc> - </func> - <func> - <name>struct(Id, Name, ElementList) -> TC</name> - <fsummary>Return the struct IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the struct</d> - <v>ElementList = [{MemberName, TC}]</v> - <d>a list of the struct elements</d> - <v>MemberName = string()</v> - <d>the element name</d> - </type> - <desc> - <p>Function returns the IDL typecode for struct.</p> - </desc> - </func> - <func> - <name>union(Id, Name, DiscrTC, Default, ElementList) -> TC</name> - <fsummary>Return the union IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the union</d> - <v>DiscrTC = TC</v> - <d>the typecode for the unions discriminant</d> - <v>Default = integer()</v> - <d>a value that indicates which tuple in the element list that is default (value < 0 means no default)</d> - <v>ElementList = [{Label, MemberName, TC}]</v> - <d>a list of the union elements</d> - <v>Label = term()</v> - <d>the label value should be of the <em>DiscrTC</em>type</d> - <v>MemberName = string()</v> - <d>the element name</d> - </type> - <desc> - <p>Function returns the IDL typecode for union.</p> - </desc> - </func> - <func> - <name>enum(Id, Name, ElementList) -> TC</name> - <fsummary>Return the enum IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the enum</d> - <v>ElementList = [MemberName]</v> - <d>a list of the enums elements</d> - <v>MemberName = string()</v> - <d>the element name</d> - </type> - <desc> - <p>Function returns the IDL typecode for enum.</p> - </desc> - </func> - <func> - <name>string(Length) -> TC</name> - <fsummary>Return the string IDL typecode</fsummary> - <type> - <v>Length = integer()</v> - <d>the length of the string (0 means unbounded)</d> - </type> - <desc> - <p>Function returns the IDL typecode for string.</p> - </desc> - </func> - <func> - <name>wstring(Length) -> TC</name> - <fsummary>Return the wstring IDL typecode</fsummary> - <type> - <v>Length = integer()</v> - <d>the length of the wstring (0 means unbounded)</d> - </type> - <desc> - <p>Function returns the IDL typecode for wstring.</p> - </desc> - </func> - <func> - <name>fixed(Digits, Scale) -> TC</name> - <fsummary>Return the fixed IDL typecode</fsummary> - <type> - <v>Digits = Scale = integer()</v> - <d>the digits and scale parameters of a Fixed type</d> - </type> - <desc> - <p>Function returns the IDL typecode for fixed.</p> - </desc> - </func> - <func> - <name>sequence(ElemTC, Length) -> TC</name> - <fsummary>Return the sequence IDL typecode</fsummary> - <type> - <v>ElemTC = TC</v> - <d>the typecode for the sequence elements</d> - <v>Length = integer()</v> - <d>the length of the sequence (0 means unbounded)</d> - </type> - <desc> - <p>Function returns the IDL typecode for sequence.</p> - </desc> - </func> - <func> - <name>array(ElemTC, Length) -> TC</name> - <fsummary>Return the array IDL typecode</fsummary> - <type> - <v>ElemTC = TC</v> - <d>the typecode for the array elements</d> - <v>Length = integer()</v> - <d>the length of the array</d> - </type> - <desc> - <p>Function returns the IDL typecode for array.</p> - </desc> - </func> - <func> - <name>alias(Id, Name, AliasTC) -> TC</name> - <fsummary>Return the alias IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the alias</d> - <v>AliasTC = TC</v> - <d>the typecode for the type which the alias refer to</d> - </type> - <desc> - <p>Function returns the IDL typecode for alias.</p> - </desc> - </func> - <func> - <name>exception(Id, Name, ElementList) -> TC</name> - <fsummary>Return the exception IDL typecode</fsummary> - <type> - <v>Id = string()</v> - <d>the repository ID</d> - <v>Name = string()</v> - <d>the type name of the exception</d> - <v>ElementList = [{MemberName, TC}]</v> - <d>a list of the exception elements</d> - <v>MemberName = string()</v> - <d>the element name</d> - </type> - <desc> - <p>Function returns the IDL typecode for exception.</p> - </desc> - </func> - <func> - <name>get_tc(Object) -> TC</name> - <name>get_tc(Id) -> TC</name> - <fsummary>Fetch typecode</fsummary> - <type> - <v>Object = record()</v> - <d>an IDL specified struct, union or exception</d> - <v>Id = string()</v> - <d>the repository ID</d> - </type> - <desc> - <p>If the get_tc/1 gets a record that is and IDL specified - struct, union or exception as a parameter it returns the - typecode.</p> - <p>If the parameter is a repository ID it uses the Interface Repository - to get the typecode.</p> - </desc> - </func> - <func> - <name>check_tc(TC) -> boolean()</name> - <fsummary>Check syntax of an IDL typecode</fsummary> - <desc> - <p>Function checks the syntax of an IDL typecode.</p> - </desc> - </func> - </funcs> - -</erlref> - diff --git a/lib/orber/doc/src/orbs.gif b/lib/orber/doc/src/orbs.gif Binary files differdeleted file mode 100644 index 47f2c85441..0000000000 --- a/lib/orber/doc/src/orbs.gif +++ /dev/null diff --git a/lib/orber/doc/src/part.xml b/lib/orber/doc/src/part.xml deleted file mode 100644 index ef84b8c05a..0000000000 --- a/lib/orber/doc/src/part.xml +++ /dev/null @@ -1,49 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE part SYSTEM "part.dtd"> - -<part xmlns:xi="http://www.w3.org/2001/XInclude"> - <header> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Orber User's Guide</title> - <prepared></prepared> - <docno></docno> - <date>1998-04-26</date> - <rev>2.2</rev> - </header> - <description> - <p>The <em>Orber</em> application is an Erlang implementation of a - CORBA Object Request Broker.</p> - </description> - <xi:include href="ch_contents.xml"/> - <xi:include href="ch_introduction.xml"/> - <xi:include href="ch_orber_kernel.xml"/> - <xi:include href="ch_ifr.xml"/> - <xi:include href="ch_install.xml"/> - <xi:include href="ch_idl_to_erlang_mapping.xml"/> - <xi:include href="ch_naming_service.xml"/> - <xi:include href="ch_security.xml"/> - <xi:include href="ch_stubs.xml"/> - <xi:include href="ch_exceptions.xml"/> - <xi:include href="ch_interceptors.xml"/> - <xi:include href="ch_orberweb.xml"/> - <xi:include href="ch_debugging.xml"/> -</part> - diff --git a/lib/orber/doc/src/ref_man.xml b/lib/orber/doc/src/ref_man.xml deleted file mode 100644 index 6fa409538d..0000000000 --- a/lib/orber/doc/src/ref_man.xml +++ /dev/null @@ -1,53 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE application SYSTEM "application.dtd"> - -<application xmlns:xi="http://www.w3.org/2001/XInclude"> - <header> - <copyright> - <year>1997</year><year>2016</year> - <holder>Ericsson AB. All Rights Reserved.</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - </legalnotice> - - <title>Orber Reference Manual</title> - <prepared></prepared> - <docno></docno> - <date>1998-05-05</date> - <rev>2.0</rev> - </header> - <description> - <p>The <em>Orber</em> application is an Erlang implementation of a - CORBA Object Request Broker.</p> - </description> - <xi:include href="any.xml"/> - <xi:include href="fixed.xml"/> - <xi:include href="corba.xml"/> - <xi:include href="corba_object.xml"/> - <xi:include href="orber.xml"/> - <xi:include href="orber_ifr.xml"/> - <xi:include href="orber_tc.xml"/> - <xi:include href="orber_acl.xml"/> - <xi:include href="CosNaming.xml"/> - <xi:include href="CosNaming_NamingContext.xml"/> - <xi:include href="CosNaming_NamingContextExt.xml"/> - <xi:include href="CosNaming_BindingIterator.xml"/> - <xi:include href="lname.xml"/> - <xi:include href="lname_component.xml"/> - <xi:include href="Module_Interface.xml"/> - <xi:include href="interceptors.xml"/> - <xi:include href="orber_diagnostics.xml"/> -</application> - diff --git a/lib/orber/doc/src/theORB.gif b/lib/orber/doc/src/theORB.gif Binary files differdeleted file mode 100644 index 976672b8df..0000000000 --- a/lib/orber/doc/src/theORB.gif +++ /dev/null diff --git a/lib/orber/doc/src/tools_debugging_part.xml b/lib/orber/doc/src/tools_debugging_part.xml deleted file mode 100644 index 94af44833c..0000000000 --- a/lib/orber/doc/src/tools_debugging_part.xml +++ /dev/null @@ -1,40 +0,0 @@ -<?xml version="1.0" encoding="utf-8" ?> -<!DOCTYPE part SYSTEM "part.dtd"> - -<part> - <header> - <copyright> - <year>2002</year> - <year>2016</year> - <holder>Ericsson AB, All Rights Reserved</holder> - </copyright> - <legalnotice> - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. - - The Initial Developer of the Original Code is Ericsson AB. - </legalnotice> - - <title>Tools, Debugging and FAQ</title> - <prepared>Niclas Eklund</prepared> - <docno></docno> - <date>2002-06-25</date> - <rev>A</rev> - </header> - <description> - <p>This chapter describe the available tools and debugging facilities for Orber. - Also contain a FAQ listing of the most common mistakes.</p> - </description> - <include file="ch_orberweb"></include> - <include file="ch_debugging"></include> -</part> - |
