text:
# Key Concepts

Following are the key concepts with respect to the key
constructs/artifacts of WSO2 EI.

## Message entry points

### Proxy services

Proxy services are virtual services that receive messages and optionally
process them before forwarding them to a service at a given
[endpoint](https://docs.wso2.com/display/EI611/Working+with+Endpoints) .
This approach allows you to perform necessary transformations and
introduce additional functionality without changing your existing
service. Any available transport can be used to receive and send
messages from the proxy services. A proxy service is externally visible
and can be accessed using a URL similar to a normal web service address.

### REST APIs

A REST API in Enterprise Integrator is analogous to a web application
deployed in the Enterprise Integrator runtime. Each API is anchored at a
user-defined URL context, much like how a web application deployed in a
servlet container is anchored at a fixed URL context. An API will only
process requests that fall under its URL context. A REST API defines one
or more resources, which is a logical component of an API that can be
accessed by making a particular type of HTTP call.

A REST API resource is used by the WSO2 Enterprise Integrator mediation
engine to mediate incoming requests, forward them to a specified
endpoint, mediate the responses from the endpoint, and send the
responses back to the client that originally requested them. We can
create an API resource to process defined HTTP request method/s
that are sent to the back-end service. The In sequence handles incoming
requests and sends them to the back-end service, and the Out sequence
handles the responses from the back-end service and sends them back to
the requesting client.

REST APIs allow you to send messages directly into the Enterprise
Integrator using REST.

### Inbound endpoints

An inbound endpoint is a message entry point that can inject messages
directly from the transport layer to the mediation layer, without going
through the Axis2 engine. The following diagram illustrates the inbound
endpoint architecture.

Out of the existing transports only the HTTP transport supports
multi-tenancy, this is one limitation that is overcome with the
introduction of the inbound architecture. Another limitation when it
comes to conventional Axis2 based transports is that the transports do
not support dynamic configurations. With the ESB profile inbound
endpoints, it is possible to create inbound messaging channels
dynamically, and there is also built-in cluster coordination as well as
multi-tenancy support for all transports.

For detailed information on each type of inbound endpoint available with
the ESB profile, see WSO2 EI Inbound Endpoints.

**Synapse configuration**: Following is a sample inbound endpoint configuration:

```
<inboundEndpoint xmlns="http://ws.apache.org/ns/synapse"
                    name="HttpListenerEP"
                    sequence="TestIn"
                    onError="fault"
                    protocol="http"
                    suspend="false">
  <parameters>
    <parameter name="inbound.http.port">8085</parameter>
  </parameters>
</inboundEndpoint>
```

In an inbound endpoint configuration, the common inbound endpoint parameters are specified as attributes of the `<inboundEndpoint>` element whereas the protocol specific parameters are specified as `<parameter>` elements.

**Listening Inbound Endpoints**: A listening inbound endpoint listens on a given port for requests that
are coming in. When a request is available it is injected to a given
sequence. Listening inbound endpoints support two way operations and are synchronous.

**Polling Inbound Endpoints**: A polling inbound endpoint polls periodically for data and when data is
available the data is injected to a given sequence. For example,  the
JMS inbound endpoint checks the JMS queue periodically for messages and
when a message is available that message is injected to a specified
sequence. Polling inbound endpoints support one way operations and are
asynchronous.

**Event-Based Inbound Endpoints**: An event-based inbound endpoint polls only once to establish a
connection with the remote server and then consumes events.

#### File Inbound Protocol

The file inbound protocol is a multi-tenant capable alternative to the VFS transport. The file inbound protocol uses the [VFS transport](https://docs.wso2.com/display/EI650/VFS+Transport) to process files in a specified source directory. After processing the files, it moves them to a specified location or deletes them. Note that files cannot remain in the source directory after processing or they will be processed again, so if you need to maintain these files or keep track of the files that are processed, specify the option to move them instead of deleting them after processing.

#### Kafka Inbound Protocol

Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system. Kafka maintains feeds of messages in topics. Producers write data to topics and consumers read from topics. For more information on Apache Kafka, go to [Apache Kafka documentation](http://kafka.apache.org/documentation.html) .
			The kafka inbound endpoint acts as a message consumer. It creates a connection to ZooKeeper and requests messages for a topic, topics or topic filters. In order to use the kafka inbound endpoint, you need to download and install [Apache Kafka](http://kafka.apache.org/downloads.html) . The recommended version is `         kafka_2.9.2-<IP_ADDRESS>        ` .
			To configure the kafka inbound endpoint, copy the following client libraries from the `<KAFKA_HOME>/libs        ` directory to the `<EI_HOME>/lib` directory.
			-   `          kafka_2.9.2-<IP_ADDRESS>.jar         `
			-   `           scala-library-2.9.2.jar          `
			-   `           zkclient-0.3.jar          `
			-   `           zookeeper-3.3.4.jar          `
			-   `           metrics-core-2.2.0.jar          `
			**Note**:
			-   If you are using `          kafka_2.x.x-<IP_ADDRESS>         ` or later, you also need to add the `          kafka-clients-0.8.x.x.jar         ` file to the `          <EI_HOME>/lib         ` directory.
    		-   If you are using a newer version of ZooKeeper, follow the steps below:
        		1.  Create a directory named `             conf            ` inside the `             <EI_HOME>/repository            ` directory.
        		2.  Create a directory named identity inside the `             <EI_HOME>/repository/conf            ` directory.
        		3.  Add the [jaas.conf](attachments/119130492/119130493.conf) file to the `             <EI_HOME>/repository/conf/identity            ` directory. This is required because Kerberos authentication is enforced on newer versions of ZooKeeper.

#### JMS Inbound Protocol

The JMS inbound protocol is a multi-tenant capable alternative to the
JMS transport. The JMS inbound protocol implementation requires an
active JMS server instance to be able to receive messages, and you need
to place the client JARs for your JMS server in the ESB profile
classpath.

This section provides information on using the Broker Profile of WSO2 EI
or Apache ActiveMQ as the JMS server, but other implementations such as
Apache Qpid and Tibco are also supported.

Configuration parameters for a JMS inbound endpoint are XML fragments
that represent JMS connection factories.

#### HTTP Inbound Protocol

The HTTP inbound protocol is used to separate endpoint listeners for
each HTTP inbound endpoint so that messages are handle separately. The
HTTP inbound endpoint can bypass the inbound side axis2 layer and
directly inject messages to a given sequence or API. For proxy services,
messages will be routed through the axis2 transport layer in a manner
similar to normal transports. You can start dynamic HTTP inbound
endpoints without restarting the server.

Following is a sample HTTP inbound endpoint configuration:

!!! Note
    -   A sequence should be designed with a call/respond or send/receive sequence. It is not recommended to use a sequence that has in and out mediators.
    -   If a send mediator is used within the inbound endpoint sequence, specify a receiving sequence. If you do not specify a receiving sequence, the response will dispatch to the `           main          ` sequence.

#### HTTPS Inbound Protocol

The HTTPS inbound protocol is used to separate endpoint listeners for
each HTTPS inbound endpoint so that messages are handle separately. This
transport can bypass the inbound side axis2 layer and directly inject
messages to a given sequence or API. You can start dynamic HTTPS inbound
endpoints without restarting the server.

Configuration parameters for a HTTPS inbound endpoint are XML fragments
that represent various properties.

!!! Note
    -   A sequence should be designed with a call/respond or send/receive sequence. It is not recommended to use a sequence that has in and out mediators.
    -   If a send mediator is used within the inbound endpoint sequence, specify a receiving sequence . If you do not specify a receiving sequence, the response will dispatch to the `           main          ` sequence.

#### WebSocket Inbound Protocol

The ESB profile of WSO2 Enterprise Integrator (WSO2 EI) WebSocket
protocol implementation is based on the [WebSocket
protocol](http://tools.ietf.org/html/rfc6455) , and allows full-duplex
message mediation.

#### Secure WebSocket Inbound Protocol

The secure WebSocket inbound protocol implementation is based on the
[WebSocket protocol](http://tools.ietf.org/html/rfc6455) , and allows
full-duplex, secure message mediation.

#### HL7 Inbound Protocol

The ESB profile of WSO2 Enterprise Integrator (WSO2 EI) HL7 inbound
protocol is a multi-tenant capable alternative to the HL7 transport. The
HL7 inbound endpoint implementation is fully asynchronous and is based
on the **Minimal Lower Layer Protocol(MLLP)** implemented on top of
event driven I/O.

#### CXF WS-RM Inbound Protocol

WSReliableMessaging allows SOAP messages to be reliably delivered
between distributed applications, regardless of software or hardware
failures. The CXF WS-RM inbound endpoint allows a client (RM Source) to
communicate with the ESB profile of WSO2 EI (RM Destination) with a
guarantee that a message sent will be delivered.

!!! Note
    To configure the CXF WS-RM Inbound endpoint, you need to install the **CXF WS Reliable Messaging** feature.

#### RabbitMQ Inbound Protocol

[AMQP](http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol)
is a wire-level messaging protocol that describes the format of the data
that is sent across the network. If a system or application can read and
write AMQP, it can exchange messages with any other system or
application that understands AMQP regardless of the implementation
language.

Configuration parameters for a RabbitMQ inbound endpoint are XML
fragments that represent various properties.

#### MQTT Inbound Protocol

MQ Telemetry Transport (MQTT) is a lightweight broker-based
publish/subscribe messaging protocol, designed to be open, simple,
lightweight and easy to implement. These characteristics make it ideal
for use in constrained environments.

For example,

-   When the network is expensive, has low bandwidth or is unreliable.

-   When running on an embedded device with limited processor or memory
    resources.

To configure the MQTT inbound endpoint, you need to specify XML
fragments that represents various parameters.

 WSO2
Enterprise Integrator provides a default task implementation, which you
can use to inject a message to the Enterprise Integrator at a scheduled
interval. You can also write your own custom tasks by implementing a
Java interface.

## Message processing units

### Mediators

Mediators are individual processing units that perform a specific
function, such as sending, transforming, or filtering messages. WSO2
Enterprise Integrator includes a comprehensive mediator library that
provides functionality for implementing widely used [Enterprise
Integration Patterns
(EIPs)](https://docs.wso2.com/display/EI650/Enterprise+Integration+Patterns)
. You can also easily write a custom mediator to provide additional
functionality using various technologies such as Java, scripting, and
Spring.

### Sequences

A sequence is a set of mediators organized into a logical flow, allowing
you to implement pipes and filter patterns. You can add sequences to
proxy services and REST APIs.

### Message stores and processors

A **message store** is used to temporarily store messages before they
are delivered to their destination by a **message
processor**. This approach is useful for serving
traffic to back-end services that can only accept messages at a given
rate, whereas incoming traffic to the Micro Integrator arrives at different
rates. You must have added a message store before you can add a message processor.

To store incoming traffic in a message store, use the Store mediator, and then use a message processor to deliver messages to the back-end service at a
given rate. Using message processors and message stores allows you to
implement different messaging and integration patterns.

Multiple message processors can use the same message store. For example,
in a clustered environment, each of the nodes would have an instance of
the same message processor, each of which would connect to the same
message store and evenly consume messages. The message store
acts as a manager of these consumers and their connections and ensures
that messages are processed by only one message processor, preventing
message duplication. You can further control which nodes a message
processor runs on by specifying pinned servers.

!!! Info
    You can increase performance of message processors either by **increasing the member count** or by having multiple message processors. If you increase the member count, it will create multiple child processors of the message processor.

**Message Stores**

		Message Store Type
		Description

			JDBC Message Store

			The JDBC message store can be used to store and retrieve messages more efficiently in comparison with other message stores. The JDBC message store implementation is a variation of the already existing synapse message store implementation and is designed in a manner similar to the message store of the ESB profile. The JDBC message store uses a JDBC connector to connect to external relational databases.

			The advantages of using a JDBC message store instead of any other message store are as follows:

					Easy to connect: You only need to have a JDBC connector to connect to an external relational database.

					Quick transactions: JDBC message stores are capable of handling a large number of transactions per second.

					Ability to work with a high capacity for a long period of time: Since JDBC stores use databases as the medium to store data, it can store a large volume of data and is capable of handling data for a longer period of time.

			JMS Message Store

			The JMS message store persists messages in a JMS queue inside a JMS Broker. The JMS message store can be configured by specifying the class as  org.apache.synapse.message.store.impl.jms.JmsStore. Since the JMS message stores persist messages in a JMS queue in an ordered manner, JMS message stores can be used to implement the store-and-forward pattern.

			RabbitMQ Message Store

			RabbitMQ message store persists messages in a RabbitMQ queue inside a RabbitMQ broker. The RabbitMQ message store can be configured by specifying the class as org.apache.synapse.message.store.impl.rabbitmq.RabbitmqStore and then setting all other required parameters to connect to a RabbitMQ broker.

			Resequence Message Store

			The Resequence Message Store is used to store a stream of related but out-of-sequence messages to put them back into the correct order. It collects and re-orders the stored messages based on a defined sequence number derived from some part of the message, so that they can be published to the output channel in a specific order. This is advantageous specially when the order of message delivery is important to avoid some messages arriving earlier than others.

			The resequencing store is an extension of the existing JDBC-based message store. Hence, it inherits most of its properties from the **JDBC Message Store**.

			WSO2 MB Message Store

			WSO2 Enterprise Integrator (WSO2 EI) is shipped with a separate message broker profile (WSO2 MB). You can easily set up this WSO2 MB profile as the **message store** for the ESB. Explained below are the parameters you need to configure for a WSO2 MB Message Store. Also, find details of other configurations that are relevant to the WSO2 MB Message Store.

			In-Memory Message Store

			In memory message store is a basic **Message Store** that stores messages in an in-memory queue. Since the messages are stored in an in-memory queue in case of a ESB profile restart, all the messages stored will be lost.

			The in memory message store is lot faster than a persistent message store implementation, so it can be used to temporarily store messages for use cases such as the implementation of a high-speed store and forwarded pattern where message persistence is not a requirement.

			Note: In memory message stores are not recommended for use in production as well as in scenarios where large scale message storing is required. You can use an external message store (e.g., **JMS message store**) for such scenarios.

		Custom Message Store

			**Custom Message Store** allows users to create a message store with their own message store implementation. It can be configured using configuration by giving the fully qualified class name of the message store implementation as the class value.
			Messages will be stored as specified in the underlying message store implementation. Parameter configuration can be used to pass any configuration parameters that is needed by the message store implementation class.

**Message Processors**

		Message Processor

			Description

			Message Sampling Processor

			The message sampling processor consumes messages in a **message store** and sends them to a configured **sequence**. This process happens in a preconfigured interval. This message processor does not ensure reliable messaging.

		Scheduled Failover Message Forwarding Processor

			The scheduled failover message forwarding processor is a **message processor** that ensures reliable message delivery. This message processor is useful when it comes to scenarios where a message store failure takes place and it is necessary to ensure guaranteed message delivery.

			The only difference of the scheduled failover message forwarding processor from the scheduled message forwarding processor is that the scheduled message forwarding processor forwards messages to a defined endpoint, whereas the scheduled failover message forwarding processor forwards messages to a target message store.

		Scheduled Message Forwarding Processor'

			The scheduled message forwarding processor is a **message processor** that consumes messages in a message store and sends them to an **endpoint**. If a message is successfully delivered to the endpoint, the processor deletes the message from the message store. In case of a failure, it will retry after a specified interval.

		Custom Message Processor

			Existing message processor implementations are created using the [Quartz](http://quartz-scheduler.org/) enterprise job scheduler. If needed, you can create your own implementations of message processors by creating a Java class that implements the `MessageProcessor` interface. You then select the **Add Custom Message Processor** option when adding a message processor and specify your implementation class.
			Note that message processors go through several life-cycle stages, so you must take great care when creating your own implementation. Because existing implementations are tested and proven under high loads, the best practice is to use the existing implementations whenever possible.

### Templates

The synapse configuration language is a very powerful and robust way of driving enterprise data/messages through the Micro Integrator mediation engine. However, a large number of configuration files in the form of **sequences**, **endpoints**, **proxy services**, and transformations can be required to satisfy all the mediation requirements of your system. To keep your configurations manageable, it's important to avoid scattering configuration files across different locations and to avoid duplicating redundant configurations.

**Templates** help minimize this redundancy by creating prototypes that users can use and reuse when needed. This is very much analogous to classes and instances of classes: a template is a class that can be used to wield instance objects such as templates and endpoints. Thus, templates are an ideal way to improve reusability and readability of synapse configurations. Additionally, users can use predefined templates that reflect common **enterprise integration patterns** for rapid development of message/mediation flows in the Micro Integrator.

**Endpoint Template**: Defines a templated form of an endpoint. An endpoint template can parameterize an endpoint defined inline. An endpoint template would be useless without a template endpoint referring to it.

**Sequence Template**: A **Sequence Template** is a parametrized **sequence** providing an abstract or generic form of a sequence defined in the Micro Integrator. Parameters of a template are defined in the form of XPath statement/s. Callers can invoke the template by populating the parameters with static values/XPath expressions using the **Call Template** Mediator, which makes a sequence template into a concrete sequence.

!!! Info
    The **Call Template** mediator allows you to construct a sequence by passing values into a **sequence template**. This is currently only supported for special types of mediators such as the **Iterator** and **Aggregate Mediators**, where actual XPath operations are performed on a different SOAP message, and not on the message coming into the mediator.

Sequence template parameters can be referenced using an XPath expression defined inside the in-line sequence. For example, the parameter named "foo" can be referenced by the Property mediator (defined inside the in-line sequence of the template) in the following ways:

`<property name=”fooValue” expression=”$func:foo” />`

or

`<property name=”fooValue” expression=”get-property('foo','func')” />`

Using function scope or "?func?" in the XPath expression allows us to refer to a particular parameter value passed externally by an invoker
such as the Call Template mediator.

### Connectors

Connectos allow your message flows to connect to and interact with services such as Twitter and Salesforce. A connector is a collection of **templates** that define specific operations. Typically, connectors are used to wrap the API of an external service such as Twitter or a Google Spreadsheet. Each connector provides operations that perform different actions in that service. For example, the Twitter connector has operations for creating a tweet, getting a user's followers, and more.

To download a required connector, go to the [WSO2 Connector Store](https://store.wso2.com/store).

## Message exit points

A message exit point or an endpoint defines an external destination for a message. Typically, this is the address of a proxy service, which acts as the front end to the actual service. An endpoint can connect to any external service after
configuring it with any attributes or semantics needed for communicating with that service. For example, an endpoint could represent a URL,a mailbox, a JMS queue, or a TCP socket, along with the settings needed to connect to it.

An endpoint is defined independently of transports, allowing you to use the same endpoint with multiple transports. When you configure a message mediation sequence or a proxy service to handle the incoming message, you specify which transport to use and the endpoint where the message will be sent.

You can specify an endpoint as an [address
endpoint](https://docs.wso2.com/display/EI650/Address+Endpoint) , [WSDL
endpoint](https://docs.wso2.com/display/EI650/WSDL+Endpoint) , a load
balancing endpoint and more.

### Endpoints

 For example, the endpoint for the simple stock quote sample is `http://localhost:9000/services/SimpleStockQuoteService`.

**Named endpoints**: You can use the `name` attribute to create a named endpoint. You can reuse a named endpoint by referencing it in another endpoint using the `key` attribute. For example, if there is an endpoint named *foo* , you can reference the *foo* endpoint in any other endpoint where you want to use *foo*: `<endpoint key="foo"/>`. This approach allows you to reuse existing endpoints in multiple places.

Indirect and Resolving endpoints are endpoint configurations with a key
which refers to an existing endpoint.

**Indirect Endpoints**: The **Indirect Endpoint** refers to an actual
[endpoint](_Working_with_Endpoints_) by a key. This endpoint fetches the
actual endpoint at runtime. Then it delegates the message sending to the
actual endpoint. When endpoints are stored in the
[registry](https://docs.wso2.com/display/ADMIN44x/Working+with+the+Registry)
and referred, this endpoint can be used. The `         key        ` is a
static value for this endpoint.

**Resolving Endpoint**: The **Resolving Endpoint** refers to an actual endpoint using a dynamic key. The key is an XPath expression.

1. The XPath is evaluated against the current message and key is
calculated at run time.
2. Resolving endpoint fetches the actual endpoint using the calculated
key.
3. Resolving endpoint delegates the message sending it to the actual
endpoint.

When endpoints are stored in the registry and referred, this endpoint
can be used.

!!! Info
	The XPath expression specified in a Resolving endpoint configuration derives an existing [endpoint](_Working_with_Endpoints_) rather than the URL of the endpoint to which the message is sent. To derive the endpoint URL to which the message is sent via an XPath expression, use the [Header Mediator](https://docs.wso2.com/display/EI650/Header+Mediator#HeaderMediator-ToHeader).

**Load-balanced Group**: The **Load-balanced Group** distributes the messages (load) arriving at
it among a set of listed [endpoints](_Working_with_Endpoints_) or static
members by evaluating the load balancing policy and other relevant
parameters.

		Endpoint
		Description

		Address Endpoint

			Defined by specifying the EPR (Endpoint Reference) and other attributes of the configuration.

		Default Endpoint

			Defined for adding QoS and other configurations to the endpoint that is resolved by the To address of the message context. All the configurations such as the message format for the endpoint, the method to optimize attachments, and security policies for the endpoint can be specified as in the Address Endpoint. This endpoint differs from the address endpoint because the URI property is not present in the default endpoint.

		HTTP Endpoint

			Allows you to define REST endpoints using URI templates similar to the REST API. The URI templates allow a RESTful URI to contain variables that can be populated during mediation runtime using property values whose names have the uri.var. prefix. An HTTP endpoint can also define the particular HTTP method to use in the RESTful invocation. You can create HTTP endpoints by specifying values for the parameters given below. Alternatively, you can specify one parameter as the HTTP endpoint by using multiple other parameters, and then pass that to define the HTTP endpoint.

		Failover Endpoint

			With leaf endpoints, if an error occurs during message transmission, the message will be lost. The failed message will not be retried again. These errors occur very rarely, but still message failures can occur. With some applications, these message losses are acceptable, but if even rare message failures are not acceptable, use the **Failover** endpoint.

			A **Failover Group** is a list of leaf endpoints grouped together for the purpose of passing an incoming message from one endpoint to another if a failover occurs. The first endpoint in failover group is considered the primary endpoint. An incoming message is first directed to the primary endpoint, and all other endpoints in the group serve as back-ups.

			If the primary endpoint fails, the next active endpoint is selected as the primary endpoint, and the failed endpoint is marked as inactive. Thus, failover group ensures that a message is delivered as long as there is at least one active endpoint among the listed endpoints. The Micro Integrator switches back to the primary endpoint as soon as it becomes available. This behaviour is known as dynamic failover.
			Note: An endpoint failure occurs when an endpoint is unable to invoke a service. An endpoint, which responds with an error is not considered a failed endpoint.

		Dynamic Load-Balance Endpoint

			This endpoint distributes its messages (load) among application members by evaluating the load-balancing policy and any other relevant parameters. These application members will be discovered using the membershipHandler class, which generally uses a group communication mechanism to discover the application members. The class attribute of the membershipHandler element should be an implementation of org.apache.synapse.core.LoadBalanceMembershipHandler. You can specify membershipHandler properties using the property elements. The policy  attribute of the dynamicLoadbalance element specifies the load-balancing policy (algorithm) to be used for selecting the next member that will receive the message.

			Note: Currently only the roundRobin policy is supported. The failover attribute determines if the next member should be selected once the currently selected member has failed and defaults to true.

		Template Endpoint

			Template endpoints are created based on predefined Endpoint Templates. Parameters of the endpoint template used as the target are copied to the endpoint configuration. However, you can make modifications by removing some of the copied parameters and/or adding new parameters.

		WSDL Endpoint

			This definition is based on a specified WSDL document. The WSDL document can be specified in 2 ways:

As a URI.

As an inlined definition within the endpoint configuration.

		Recepient List Endpoint

			A Recipient List endpoint can contain multiple child endpoints or member elements. It routes cloned copies of messages to each child recipient. This will assume that all immediate child endpoints are identical in state (state is replicated) or state is not maintained at those endpoints.

#### Endpoint states

At any given time, the state of the endpoint can be one of the following:

		State
		Description

		Active

			Endpoint is running and handling requests.

			When the Micro Integrator starts, endpoints are in the "Active" state and ready to handle messages. If the user does not put the endpoint into the OFF state, it will be in the "Active" state until an error occurs.

			The endpoint can be configured to stay in the "Active" state or to go to "Timeout" or "Suspended" based on the error codes you configure for those states. When an error occurs, the endpoint checks to see whether it is a "Timeout" error first, and if not, it checks to see whether it is a "Suspended" error. If the error is not defined for either "Timeout" or "Suspended," the error will be ignored and the endpoint will stay Active.

		Timeout

			Endpoint encountered an error but can still send and receive messages. If it continues to encounter errors, it will be suspended.

			When an endpoint is in the "Timeout" state, it will continue to attempt to receive messages until one message succeeds or the maximum retry setting has been reached. If the maximum is reached at which point the endpoint is marked as "Suspended." If one message succeeds, the endpoint is marked as "Active".

			For example, let's assume the number of retries is set to 3. When an error occurs and the endpoint is set to the "Timeout" state, the Micro Integrator can try to send up to three more messages to the endpoint. If the next three messages sent to this endpoint result in an error, the endpoint is put in the "Suspended" state. If one of the messages succeeds before the retry maximum is met, the endpoint will be marked as "Active."

		Suspended

			Endpoint encountered errors and cannot send or receive messages. Incoming messages to a suspended endpoint result in a fault.

			A "Suspended" endpoint cannot send or receive messages. When an endpoint is put into this state, the Enterprise Integrator waits until after an initial duration has elapsed (default is 30 seconds) before attempting to send messages to this endpoint again. If the message succeeds, the endpoint is marked as "Active." If the next message fails, the endpoint is marked as "Suspended" or "Timeout" depending on the error, and the Enterprise Integrator waits before retrying messages using the following formula: Min(current suspension duration * progressionFactor, maximumDuration).

			You configure the initial suspension duration, progression factor, and maximum duration as part of the suspendOnFailure settings. On each retry, the suspension duration increases, up to the maximum duration.

		OFF

			Endpoint is not active. To put an endpoint into the OFF state, or to move it from OFF to Active, you must use JMX.

## Transports

A transport is responsible for carrying messages that are in a specific
format. The Enterprise Integrator supports all the widely used
transports including HTTP/s, JMS, VFS and domain-specific transports
like FIX. You can easily add a new transport using the Axis2 transport
framework and plug it into the Enterprise Integrator. Each transport
provides a receiver, which the Enterprise Integrator uses to receive
messages, and a sender, which it uses to send messages. The transport
receivers and senders are independent of the Enterprise Integrator core.

		Transport
		Description

		PassThrough

			This is a non-blocking HTTP transport implementation based on HTTP Core NIO, and is the default HTTP transport shipped with WSO2 Micro Integrator. Although the PassThrough transport is somewhat similar to the NHTTP transport, it overcomes all the limitations of the NHTTP transport and provides a significant performance gain. The PassThrough Transport also has a simpler and cleaner model for forwarding messages back and forth.

		HTTP-NIO

			This is a module of the Apache Synapse project. The transport implementation is based on Apache HTTP Core - NIO and uses a configurable pool of non-blocking worker threads to grab incoming HTTP messages off the wire.

		HTTPS-NIO

			HTTPS-NIO transport This is also a module that comes from the Apache Synapse code base. This transport simply extend the HTTP-NIO implementation by adding SSL support. Therefore, they support all the configuration parameters supported by the HTTP-NIO receiver and sender plus the parameters in the following table. The sender can also verify certification revocation.

		HTTP Servlet

			The transport receiver implementation of the HTTP transport is available in the Carbon core component. The transport sender implementation comes from the Tomcat http connector.

			Note:

Unlike other WSO2 products, WSO2 Micro Integrator does not use the HTTP servlet transport by default. Instead it uses the HTTP-NIO transport.

This is a non-blocking HTTP transport implementation, which means that I/O the threads does not get blocked while received messages are processed.

			The Virtual File System (VFS)

			This transport is used to process files in the specified source directory. After processing the files, it moves them to a specified location or deletes them. Note that files cannot remain in the source directory after processing or they will be processed again, so if you need to maintain these files or keep track of which files have been processed, specify the option to move them instead of deleting them after processing. If you want to move files into a database, use the VFS transport and the DBReport Mediator.

			Note: When you transfer a file to a remote FTP location via VFS, the integrator tries to detect the FTP location by navigating from the root folder first. If the integrator does not have at least list permission to the root (/), the file transfer fails.

		HTTPS Servlet

			Similar to the HTTP transport, the HTTPS transport consists of a receiver implementation which comes from the Carbon core component and a sender implementation which comes from the Apache Axis2 transport module. In fact, this transport uses exactly the same transport sender implementation as the HTTP transport. This is also a blocking transport implementation.

		RabbitMQ AMQP

			AMQP is a wire-level messaging protocol that describes the format of the data that is sent across the network. If a system or application can read and write AMQP, it can exchange messages with any other system or application that understands AMQP, regardless of the implementation language. The RabbitMQ AMQP transport is implemented using the RabbitMQ Java Client. It allows you to send or receive AMQP messages by directly calling an AMQP broker (RabbitMQ).

		TCP

			The TCP transport allows you to send and receive SOAP messages over the Transmission Control Protocol (TCP) to the TCP Proxy through the same TCP connection. The TCP transport is included with the WSO2 Micro Integrator distribution, but it must be enabled before use.

		MSMQ

			The msmq: component is a transport for working with Microsoft Message Queuing . This component natively sends and receives direct allocated ByteBuffer instances. This allows you to access the JNI layer without expensive memory copying. In fact, using ByteBuffer created with the method allocateDirect can be passed to the JNI layer, and the native code is able to directly access the memory. The URI format: msmq:msmqQueueName.

			Note:

The MSMQ examples only work on Windows, since they invoke Microsoft C++ API for MSMQ via JNDI invocation.

Download the `axis2-transport-msmq-2.0.0-wso2v2.jar` file and add it to the `MI_HOME/dropins` directory. This file provides the JNI invocation required by MSMQ bridging.

Make sure MQ installed and running. For more information, see <http://msdn.microsoft.com/en-us/library/aa967729.aspx>.

Make sure that you have installed Visual C++ 2008 (VC9) and that it works with Microsoft Visual Studio 2008 Express.

		MailTo

			When you use the Micro Integrator to mediate messages, the mediation sequence can be configured to send emails (over SMTP) or receive emails (Over POP3 or IMAP) by using the MailTo transport protocol.

		Local

			Apache Axis2's local transport implementation is used to make fast, in-VM (Virtual Machine) service calls and transfer data within proxy services. The transport does not have a receiver implementation.

			Note:

WS-Security cannot be used with the local transport. Since the local is mainly used to make calls within the same VM, WS-Security is generally not required in scenarios where it is used.

If you need to use local transport with callout mediator, you do not need to perform configuration mentioned in this section as callout mediator requires blocking local transport.

		HL7

			The HL7 transport allows you to handle Health Level 7 International (HL7) messages.

		Financial Information eXchang (FIX)

			This transport implementation is a module developed under the Apache Synapse project. This transport is mainly used in conjunction with proxy services. This transport supports JMX. FIX transport does not support any global parameters. All the FIX configuration parameters should be specified at service level. QuickFix 4J configuration parameters can be found here.

		MQ Telemetry Transport (MQTT)

			This is a simple and lightweight network protocol for device communication. This is an easy to implement protocol that is based on the publish/subscribe model. MQTT is ideal for use in constrained environments such as the following:

When the network is expensive, has low bandwidth, or is unreliable.

When running on an embedded device with limited processor or memory resources.

			The MQTT transport implementation requires an MQTT server instance to be able to send and receive messages. The recommended MQTT server is the Mosquitto message broker.

		Websocket

			The WebSocket transport implementation of WSO2 Micro Integrator is based on the WebSocket protocol and consists of an Axis2 sender implementation for WebSockets and secure WebSockets. WebSocket is a protocol that provides full-duplex communication channels over a single TCP connection, and can be used by any client or server application. This transport supports bi-directional message mediation.

		UDP

			The UDP transport allows WSO2 Micro Integrator to handle messages in user datagram protocol (UDP) format.

		JMS

			The Java Message Service (JMS) transport in WSO2 Micro Integrator allows you to easily send and receive messages to queues and topics of any JMS service that implements the JMS specification.

			Java Message Service (JMS) is a widely used API in Java-based Message Oriented Middleware(MOM) applications. It facilitates loosely coupled, reliable, and asynchronous communication between different components of a distributed application. It supports two asynchronous communication models for messaging as follows:

Point-to-point model - In this model message communication happens from one JMS client to another JMS client through a dedicated queue.

Publish and subscribe model -  In this model message communication happens from one JMS client(publisher) to many JMS clients(subscribers) through a topic.

			JMS supports two models for messaging as follows:

Queues : point-to-point.

Topics : publish and subscribe.

			The Micro Integrator supports the following messaging features introduced with JMS 2.0:

Shared Topic Subscription

JMSX Delivery Count

JMS Message Delivery Delay

			The JMS transport implementation comes from the WS-Commons Transports project, and it makes use of JNDI to connect to various JMS brokers. As a result, WSO2 Micro Integrator can work with any JMS broker that offers JNDI support.

		Multi-HTTPS

			This transport is similar to the HTTPS-NIO transport, but it allows you to have different SSL profiles with separate truststores and keystores for different hosts using the same WSO2 Micro Integrator. The Micro Integrator uses truststores and a keystores for SSL protocol implementation. It can listen to different host IPs and ports for incoming HTTPS connections, and each IP/Port will have a separate SSL profile configured.

## Message builders and formatters

When a message comes into the Enterprise Integrator, the receiving
transport selects a **message builder** based on the message's content
type. It uses that builder to process the message's raw payload data and
convert it into common XML, which the Enterprise Integrator mediation
engine can then read and understand. WSO2 Enterprise Integrator includes
message builders for text-based and binary content.

Conversely, before a transport sends a message out from the Enterprise
Integrator, a **message formatter** is used to build the outgoing stream
from the message back into its original format. As with message
builders, the message formatter is selected based on the message's
content type.

You can implement new message builders and formatters using the Axis2
framework.

## Applying security to artifacts

You can apply security to artifacts of the ESB profile using WSO2
Integration Studio. The Quality of Service (QoS) component implements
security.

## Logging messages

You can use the Log mediator to log mediated messages.

## Message tracing

Message tracing helps you to track issues after an integration process
finishes and thereby, allows you to identify and fix issues by
identifying the root cause. It is used to trace, track and visualize a
body of a message in each intermediate stage of its transmission. T his
is useful for a number of reasons, including auditing and debugging.

## Debugging mediation

Message mediation mode is one of the operational modes of WSO2 EI where
EI functions as an intermediate message router. A unit of the mediation
flow is a mediator. A sequence is a series of mediators, where each
mediator is a unit entity that can input a message, carry out a
predefined processing task on the message, and output the message for
further processing. Debugging is where you want to know if these units,
which function as separate entities are operating as intended, or if a
combination of these units are operating as a whole as intended.

## Load balancing

The load balancer automatically distributes incoming traffic across
multiple WSO2 product instances. It enables you to achieve greater
levels of fault tolerance in your cluster and provides the required
balancing of load needed to distribute traffic.

## Enterprise Integration Patterns

Enterprise Application Integration (EAI) enables you to connect business
applications with heterogeneous systems. The [EIP patterns
guide](https://docs.wso2.com/display/EIP/Enterprise+Integration+Patterns+with+WSO2+Enterprise+Integrator)
demonstrates how the patterns that are invented integration solution
architects over the years can be simulated using various constructs in
the ESB profile.

## WSO2 Integration Studio

You can use WSO2 Integration Studio to create various integration
artifacts that you can build and deploy to the ESB profile of WSO2 EI in
order to process requests.

## Data service

The data in your organization can be a complex pool of information that
is stored in heterogeneous systems, ranging from RDBMSs to Excel files,
and Google spreadsheets, etc. Data services are created for the purpose
of decoupling the data from its infrastructure. In other words, when you
create a data service in WSO2 EI, the data that is stored in a storage
system (such as an RDBMS) can be exposed in the form of a service. This
allows users (that may be any application or system) to access the data
without interacting with the original source of the data. Data services
are, thereby, a convenient interface for interacting with the database
layer in your organization.

A data service in WSO2 EI is a SOAP-based web service, by default.
However, you also have the option of creating REST resources. Therefore,
the applications and systems consuming the data service can have both
SOAP-based, and RESTful access to your data.

### Datasources

Your organization's data can be stored in various data storage systems,
which are thedatasources. Data services in WSO2 EI support the
followingdatasources: Relational databases, CSV files, Microsoft Excel
Sheets, Google Spreadsheets, RDF, MongoDB, Cassandra, and Web Resources.
Additionally, you can also useJNDIdatasources, and create
customdatasources. Read about using variousdatasourceswith data services
defined in WSO2 EI.

### RESTful data services

A data service exposes your data (stored in various data stores) as a
service. You can enable RESTful access to your data, by defining RESTful
resources, for the relevant data, in your data service. REST resources
in WSO2 EI support both JSON and XML media types out of the box.
Therefore, a resource can receive requests, and send responses in either
medium. Secure resources with HTTP(S) Basic Auth integrated to
enterprise identity systems (via [WSO2 Identity
Server](http://wso2.com/products/identity-server/) ).

### OData services

RESTful data services in WSO2 EI supports OData (
[OData](http://www.odata.org/) protocol version 4 - OASIS standards) ,
which makes RESTful data access easier. In a normal data service, you
will write SQL queries for CRUD operations that will be performed on the
data. In other words, to be able to GET, UPDATE, POST, or DELETE data in
a database, the data service should have separate SQL queries written
for each purpose. However, when you enable OData for your RESTful data
service, these CRUD operations will be enabled automatically, which
allows RESTful data access using CRUD operations out of the box.

Currently, OData support is only available for RDBMS datasources and
Cassandra datasources. Odata services will now be accessible from the
following endpoints:

-   For super tenant:
    http://localhost:9763/odata/{dataserviceName}/{datasourceId}/
-   For normal tenants:
    http://localhost:9763/odata/t/{tenantId}/{dataserviceName}/{datasourceId}/

### Data Federation

A data service defined in WSO2 EI has the ability to aggregate the data
that is stored in various, disparate datasources, and present the
aggregated data as a single output. For example, the data of employees
in a company may be stored in various data stores (details of employment
history, details of the physical office, contact information, etc.).
Data federation allows users to consume all this data through a single
request to the data service. The data service will aggregate the
relevant data from each of the disparate datasourcesand present it as
one response to the request. Data federation can be achieved in two
ways:

-   Expose multiple datasources using a single data service.
-   Use Nested Queries in your data service. This will allow you to feed
    the result you get from one query as input to another query. That
    is, data can be combined into a single response or resource.

### Distributed transactions

A distributed transaction is a set of operations that should be
performed on two or more, distributed RDBMS data stores. If the
operation on one data store (node) fails, the entire set of operations
will fail in all the data stores. In other words, a distributed
transaction is an example of a batch process, where multiple requests
are grouped into one server call and processed as one unit by the data
service.

Data services in WSO2 EI support distributed transactions, which allows
data consumers to perform such transactions easily by using one data
service as the interface. Note that distributed transactions can only be
performed for IN-ONLY operations that will insert, update, or delete
data in the data stores. These are not applicable to operations for
retrieving data.

A transaction manager is set up in the middle of these transactions for
effective coordination and management. This feature uses Java
Transaction API (JTA), which allows distributed transactions to be
carried out across multiple XA resources in a Java environment. You can
also override this transaction manager.

### Batch processing

A data service is an interface that receives requests from data
consumers and performs the requested tasks in the relevant data stores.
Batch processing allows a data service to group multiple requests into a
batch and process it as a single request. Batch processing can only be
used for IN-ONLY operations that will insert, update, or delete data in
the data stores, and not for operations that retrieve data.

Data services in WSO2 EI support two scenarios of batch requesting:
Client-side batch requests, and server-side batch requests.

For example, consider the task of entering details of new employees into
a database table. Typically, the client consuming the data can do this
by sending separate requests with each employee record. Alternatively,
the client can group the individual requests into a single batch, and
send one batch request to the data service. In this example, the data
service will have one operation defined for inserting data into the
database. However, when batch processing is enabled, it is possible to
insert multiple records into that database, using this operation.
Therefore, the client can invoke this operation using a single request,
to insert multiple records. This is client-side batch requesting.

Consider another example, where the client needs to enter the employee’s
bank details along with the personal details, but the bank details
should be insertedtoa different data store. In this example, the data
service will have two separate operations for inserting data into two
separate data stores, and the client is invoking both operations, using
a single request (also called a request box). This is server-side batch
requesting.

Note that batch requests are transactional if the data store is
anRDBMS, or another system that supports transactions. Transactional
requests succeed or fail as a batch. That is, if one individual request
fails, all the requests in the batch will fail to make sure that the
data is synchronized. Server-side batch requests work for local
transactions (performed on one node of the data store), as well as
distributed transactions (performed on multiple nodes of the data
store).

### Data transformation

XSLT transformation is used in data services to transform the result of
an already defined operation into a different result. The user can
define the transformation xslt and provide the url of the transformation
file in the result element.

### Managed data access

Most businesses require secure and managed data access across these
federated data stores .

### Streaming

Data service streaming helps manage large data chunks sent back to the
client by the data service as the response to a request. When streaming
is enabled, the data is sent to the client as it is generated, without
memory building up in the server. By default, streaming is enabled in
data services.

### Namespaces

The service namespace uniquely identifies a Web service and is specified
by the `         <targetNamespace>        ` element in the WSDL that
represents the service. A data service is simply a Web service with
specialized functionality. When developing a data service, you get to
apply namespaces at various levels. As a data service implementation is
based on XML, namespace handling is useful for making sure that there
are no conflicting element names in the XML. Although namespaces are
optional for data services, in some scenarios they are necessary. For
more information, see Defining Namespaces .

### Error Handling

The main role of WSO2 Enterprise Integrator (WSO2 EI) is to act as the
backbone of an organization’s service-oriented architecture. It is the
spine through which all the systems and applications within the
enterprise (and external applications that integrate with the
enterprise) communicate with each other. For example, an ESB (which is
contained in WSO2 EI) often has to deal with many wire-level protocols,
messaging standards, and remote APIs. But applications and networks can
be full of errors. Applications crash. Network routers and links get
into states where they cannot pass messages through with the expected
efficiency. These error conditions are very likely to cause a fault or
trigger a runtime exception in the ESB.

repository: AnuGayan/docs-ei

repo_name: AnuGayan/docs-ei


text:
---
title: Qianna
species: Theory Starling
text-keywords:
post_date: 2022-12-16 00:00:00
categories: FlockingAI
tags: FlockingAI Birds MidJourney
header      :
  teaser    : /public/uploads/flockingai/117-qianna.png
prompt: polyvagal theory bird , on a white background
midjourney: https://www.midjourney.com/app/jobs/eed4920d-feb5-406f-8804-8dac6719048a
instagram: https://www.instagram.com/p/CmO6oxvBGuq/
twitter:
facebook: https://www.facebook.com/FlockingAI/posts/pfbid024c6WxGPDy7R9JhALuu4SddBLEdUdWUfABiNJG1B71wYCudqXzvZAN42dxBu1bwA8l
gallery:
  - /public/uploads/flockingai/117-qianna.png
---

Meet the Theory Starling!  It is a polyvagal theory bird, which means it has powerful physical and psychological adaptations that make it both wondeful and kind. It is known for its happy demeanor, and loves to make its presence known with its loud and clear call.

When it comes to food, the Theory Starling is not a fussy eater. It has a wide range of tastes, but its favorite food is anything made with peanut butter. Peanuts and other nuts are also popular.

The birds are mostly found in the United States and Canada, living in wooded areas, open meadows, and grassy fields. They can be seen nesting in tree cavities and on ledges, and will even make nests in abandoned buildings or other structures.

The Theory Starling has unique mating habits and rituals. During the spring courtship rituals, the males will display their feathers, singing and dancing with abandon. During the mating season, the female will typically lay a clutch of three to five eggs.

The Theory Starling is a very special bird, with some truly remarkable adaptations. For example, they are able to communicate with each other by emitting low-frequency vibrations through their feathers. They can also use their strong beaks to crack open nuts, and pick up small pebbles to build their nests.

People do keep these birds as pets, and they make excellent companions. A good name for a pet Theory Starling would be Merlin, as it is appropriately magical!

A flock of Theory Starlings is called a sorcery, which is quite fitting. They will travel together in large flocks, in search of food, with their unique and friendly personalities.

Overall, the Theory Starling is a truly remarkable bird, with a wide range of physical and psychological adaptations. This bird is sure to capture your heart.

license: MIT

branch_name: refs/heads/master

extension: md

gha_language: SCSS

gha_license_id: MIT

license_type: permissive


text:
# Option_Pricing_Python
I use Python to try all the experiments on the classic text book **<Options, Futures and other Derivatives, 8th edition.>**, focusing on the **Black-Scholes Model** and the sensitivity analysis on Greek Letters. The Charpter: The Greek Letters, Page 377-396. All the results and procedures have been tested and compared with the textbook. You can feel safe to use it. If you are the **new beginer for this course** or the **teacher who wants to find well writen Option Prcing code in Python Version**, I think this project will help you. **Please give me a star or folk if you like it.**

### Structure
There are two parts in this project:
![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Code.JPG)

**The first part** is that I use the basic data, to calcualte the call option price and put option price. And I also calculate the greek letters, do basic sensitivity analysis on this greek letters. All the results have been checked and compared with the text book.

**The second part** is that I use the real example data from a stock company, this portfolio is only part of one day's data, there is no any confidential info, thus, it's okay to use. I use this real example data to calculate the greek letters value in the real suitation and do pressure test on the greek letters. (Change the S0 and Sigma, this is one of the most important things the traders care about.)

**The common parameter set used in the text book is shown as below:**
![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Basic_data.JPG)

**The real example data is shown as below:**
![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Real_example_data.JPG)

### Some Experiment Results
You can find some experiment results in the folder called './fig/', please have a look. If you want to plot other pictures, you can change the code in this project. I have written nearly 500 lines, and I think there will be some materials that are beneficial to you.

![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Gamma_to_T.png)

![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Theta_to_T.png)

![Image text](https://github.com/Neural-Finance/Option_Pricing_Python/blob/main/fig/Pressure_test.png)

branch_name: refs/heads/main


text:
# WP RNCryptor

A WordPress plugin holding the RNCryptor-php library.

## How to install

### Composer

If you're using Composer to manage your codebase add this plugin to your dependencies running:

`composer require enricodeleo/RNCryptor-wp 0.2.0`

Or manually add it to your composer.json:

```JSON
"require": {
  "enricodeleo/RNCryptor-wp": "0.2.0"
}
```

### Legacy way

Download this repo as a zip file and extract it
to your wp-content/plugins directory.

OR

Install this plugin via the official Wordpress Plugin registry. https://wordpress.org/plugins/wp-rncryptor/

# Usage

This Plugin is _intended for developers only_ and just holds the RNCRypto library making it available as a WordPress plugin.
Credits go to [RNCryptor](https://github.com/RNCryptor). For issues, examples and usages check the php library's repository on GitHub [https://github.com/RNCryptor/RNCryptor-php](https://github.com/RNCryptor/RNCryptor-php)

repository: enricodeleo/RNCryptor-wp

repo_name: enricodeleo/RNCryptor-wp


text:
# Interference-Fringe-Removal Documentation

This folder contains the documentation for the Interference-Fringe-Removal program in two folders.

1. The `latex_source_code` folder contains the documentations source code that can be imported into a Latex editor for future version documentation.
2. The `PDFs` folder contains the compiled PDFs of the Latex code.

repository: yxrmz/Interference-Fringe-Removal

repo_name: yxrmz/Interference-Fringe-Removal


text:
# Mojito Globals Addon

[![Build Status](https://secure.travis-ci.org/yahoo/mojito-globals.png)](http://travis-ci.org/yahoo/mojito-globals)

[![NPM](https://nodei.co/npm/mojito-globals.png)](https://nodei.co/npm/mojito-globals/)

The mojito-globals addon provides a global store for mojito that works
transparently on the client and the server. The store is global per request
on the server and per page on the client.

## Usage

Simply require `mojito-globals-addon` to make the `ac.globals` add-on available
in your controller...

repository: YahooArchive/mojito-globals

repo_name: YahooArchive/mojito-globals


text:
---
layout: default
---

# 1995-09-27 - Re: chaos cryptography

## Header Data

From<EMAIL_ADDRESS>(Timothy C. May)

To<EMAIL_ADDRESS>Message Hash: 2a95942586f8898b44188f40cb5e297da57af9e3095a70dc4ac59b5bb9cbacbb

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1995-09-27 05:32:35 UTC

Raw Date: Tue, 26 Sep 95 22:32:35 PDT

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Timothy C. May)
Date: Tue, 26 Sep 95 22:32:35 PDT
To<EMAIL_ADDRESS>Subject: Re: chaos cryptography
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

>Hi all - saw this in New Scientist and thought you might be interested
>(I guess it's more stenography than cryptography):
                    ^^^^^^^^^^^

Yes, chaotic communication is preferred by secretaries around the world.

They follow their dictates.

--Tim May

---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
<EMAIL_ADDRESS>408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

{% endraw %}
```

## Thread

+ Return to [September 1995](/archive/1995/09)

+ Return to<EMAIL_ADDRESS>(Timothy C. May)](/authors/tcmay_at_got_net_timothy_c_may_)"

+ 1995-09-27 (Tue, 26 Sep 95 22:32:35 PDT) - Re: chaos cryptography -<EMAIL_ADDRESS>(Timothy C. May)_


text:
# Overview
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fcloustone%2Fpandas.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fcloustone%2Fpandas?ref=badge_shield)

Pandas is device managment and modeling platform which can be deployed in any environments to provide the following features.

* Integrate with 3rd-party broker, for example, mainflux to provide device connection.
* Device management
* Device model management, user can creating device model using web-frontend.
* Project management,
* Full featured IoT rule engine
* Location Based Service
* Display project's realtime device status based on device model
* SCADA

Pandas is designed and implemented based on micro service architecture,which include the following components.

* Dashboard, the web console to manage all objects(User/Project/Workshop/Device/RuleChain).
* ApiMachinery, the API gateway.
* Dmms: Device model management service.
* Pms: Project management service.
* Rulechain: Rule chain service

![](docs/images/pandas-arch.png)

### Building

> git clone https://github.com/cloustone/pandas
> cd $GOPATH/src/github.com/cloustone/pandas
> make

### Statrup

Start pandas  in docker-compose mode  (in future)
> ./deploy.sh dockercompose up

## License
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fcloustone%2Fpandas.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fcloustone%2Fpandas?ref=badge_large)

repository: rskvp/pandas

repo_name: rskvp/pandas


text:
# Gmail Smart reply

Input = incoming message

output distribution = space of possible replies

we use semi-supervised learning to construct a target response space R comprising only high quality responses.
Then we use the model described here to choose the best response in R, rather than the best response from any sequence of words in its vocabulary.

to improve specificity of responses, we apply some light normalization that penalizes responses which are applicable to a broad range of incoming messages.

to increase the breadth of options shown to the user, we enforce diversity by exploiting the semantic structure of R

improve the utility of suggestions by first passing each message through a triggering model (described in Section 6)
that determines whether suggestions should be generated at all.

We parse each sentence using a dependency parser and use its syntactic structure to generate a canonicalized representation.

user should never see two responses of the same intent

If the top two responses (after omitting redundant responses) contain at least one positive response and none of the top three responses are negative,
the third response is replaced with a negative one.

## Ref

1. Kannan, et al. Smart Reply: Automated Response Suggestion for Email

repository: sanjosh/csdocs

repo_name: sanjosh/csdocs


text:
# Reflective Shadow Maps in WebGL

Demo of approximate real-time indirect lighting with Reflective Shadows Maps using [regl](https://github.com/mikolalysenko/regl).

![](img.png)

[Demo here](https://erkaman.github.io/webgl-rsm/webgl-rsm.html)

# Implementation Details

This is an implementation of Indirect Lighting using [Reflective Shadow Maps](http://www.klayge.org/material/3_12/GI/rsm.pdf).
This technique results in some nice color bleeding effects, which can be seen in the red glow on Lucy(statue)
and the blue glow on the cute rabbit. This is light that has bounced from the colored walls.

We render the scene from the perspective of the light source, and for every
pixel we store the normal, world-space position and flux in a buffer, the RSM.
When shading a fragment, we will now gather the illumination from the adjacent
pixels in the RSM, and sum their contributions. We can by doing this
approximate a lambertian diffuse indirect lighting component, and this results
in some nice color bleeding effects.

The issue with the approach is that lots of samples must be taken for decent results.
Our implementation uses 64 samples, which is a lot, considering all these samples must
be taken for every single fragment on the screen. In order to avoid doing this calculation
for invisible surfaces, we adopt a deferred shading approach. However, it is
still quite expensive.

In the original paper a screen-space interpolation approach is described, that
can greatly decrease the number of times we must perform the indirect lighting calculation.
In order to keep this demo simple, and because of laziness, we did not implement this, however.
Note that this is a possible future improvement to the implemention, though.,

# Build

First install all dependencies by doing

```bash
npm install
```

To then run the demo, do

```bash
npm run start
```

branch_name: refs/heads/gh-pages


text:
---
layout: blog_post
nav: blog
---

I have released intercooler v0.9.1, available on the main site, as well as through bower.

<http://intercoolerjs.org/download.html>

This is mostly a bug-fix release, but it does contain one new attribute, the ic-action attribute I discussed earlier:

<http://intercoolerjs.org/release/CHANGES.html#0_9_1>

This lets you implement purely client-side actions in intercooler without a server request:

    <button ic-action=“fadeOut;remove” ic-target=“closest div”>Close</button>

This would fade out and then remove the closest div to the button, using the proper callback mechanism in jQuery.  Documentation and examples are here:

<http://intercoolerjs.org/attributes/ic-action.html>

This concludes the client-side functionality of intercooler (everything else should be done using standard jQuery techniques) :)

The remaining outstanding items on the road to 1.0 are:

  * [https://github.com/LeadDyno/intercooler-js/issues/60](https://github.com/LeadDyno/intercooler-js/issues/60) - an option for a data-prefix
  * [https://github.com/LeadDyno/intercooler-js/issues/54](https://github.com/LeadDyno/intercooler-js/issues/54) - File upload handling

I hope to have both of these done at some point in January, and we can all have a big 1.0 launch party:

repository: StevenBlack/intercooler-js

repo_name: StevenBlack/intercooler-js


text:
---
layout: default
---

# 1998-09-09 - WebSite Professional 2.3

## Header Data

From<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 3fa226b6e237651e9c32f9a72153bf77795ff59233d227477f95c8c7b0a090e7

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1998-09-09 03:41:39 UTC

Raw Date: Wed, 9 Sep 1998 11:41:39 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>Date: Wed, 9 Sep 1998 11:41:39 +0800
To<EMAIL_ADDRESS>Subject: WebSite Professional 2.3
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Hello!

Thank you for downloading O'Reilly's WebSite Professional 2.3.

There's a ton of great stuff wrapped up in that one package,
so I hope you'll invest a little time to play with it thoroughly.
I'm confident you'll consider it time well spent.

In fact, before long, you may just find yourself among WebSite's
growing ranks of raving fans. Just like these corporations and
institutions:

AT&T			National Cancer Institute
Bear Stearns		Siemens Nixdorf
Boeing North America	Smithsonian Institution
County of Los Angeles	Snap-on Tools, Inc.
Hewlett-Packard		Sprint
Indiana University	Union Pacific Railroad
Intel			United States Geological Survey
JCPenny			University of Miami
Lucent Technologies	Warner Brothers
Motorola		Yamaha Corporation

If, during your trial of WebSite Pro, you have any questions
about its capabilities or functionality, please contact me
directly at<EMAIL_ADDRESS>or call 1-800-998-9938
(707-829-0515) ext. 351.

To download other WebSite Professional 2.3 components you
can go to: http://software.oreilly.com/download/wsp23demo_download.html

To access our Knowledge Base:
http://software.oreilly.com/techsupport/index_ws.html

Thanks again, and have a great day!

--
Michelle Koff<EMAIL_ADDRESS>Technical Sales Associate
O'Reilly & Associates (http://software.oreilly.com)

{% endraw %}
```

## Thread

+ Return to [September 1998](/archive/1998/09)

+ Return to "[techsales@oreilly.com](/authors/techsales_at_oreilly_com)"

+ 1998-09-09 (Wed, 9 Sep 1998 11:41:39 +0800) - WebSite Professional 2.3 -<EMAIL_ADDRESS>


text:
# nmt_try
> My experients of nmt

## Editable Install

``` sh
git clone this repository
make install
```

## Develop

1. Modify notebooks in nbs folder (Write unit tests in the same notebook and create new notebook to write integration test)
2. `nbdev_build_lib` to update python files
3. `make test` to run unit test
4. `make test-slow` to run integration test
5. `make build-all` to run build-lib, build-docs, clean-nbs
6. `git add commit and push`

## Data

If you want to run 95_nc_xxx.ipynb, do following:

1. Download http://data.statmt.org/news-commentary/v14/training/news-commentary-v14.en-zh.tsv.gz
2. Unzip and save it to `./nbs/data/News_Commentary/news-commentary-v14.en-zh.tsv`
3. Run 02_data.news_commentary.ipynb to generate tok-news-commentary-v14.en-zh.csv in ./nbs/data/News_Commentary/

gha_language: Jupyter Notebook


text:
# Library design

The `perceiver-io` library is organized into backend model classes, PyTorch Lightning wrappers and Hugging Face 🤗
wrappers. Backend models are lightweight PyTorch implementations of Perceiver, Perceiver IO and Perceiver AR,
constructed from generic and task-specific [building blocks](building-blocks.md).

Backend models can either be used standalone or wrapped into PyTorch Lightning modules for model training and 🤗
modules for inference. Training with PyTorch Lightning is done for historical reasons and a later version of the
`perceiver-io` library will also support model training with 🤗 training tools directly.

## Backend model wrappers

Backend model wrapping and unwrapping is demonstrated with a Perceiver IO masked language model, starting from a
[pretrained model](pretrained-models.md). The same pattern also applies to all other models in the `perceiver-io` library.
Model construction for training with PyTorch Lightning is covered in more detail in [model construction](model-construction.md).

```python
from transformers import AutoModelForMaskedLM
from perceiver.model.text import mlm  # auto-class registration

# Name of pretrained Perceiver IO masked language model
repo_id = "krasserm/perceiver-io-mlm"

# Load pretrained model (🤗 wrapper)
model = AutoModelForMaskedLM.from_pretrained(repo_id)
assert type(model) == mlm.PerceiverMaskedLanguageModel

# Access to backend model
backend_model = model.backend_model
assert type(backend_model) == mlm.MaskedLanguageModel

# Access to backend config
backend_config = backend_model.config
assert backend_config == model.config.backend_config

# Create Lightning wrapper from backend config and load pretrained weights
lit_model = mlm.LitMaskedLanguageModel.create(backend_config, params=repo_id)

# Access to backend model from Lightning wrapper
backend_model = lit_model.backend_model

# Create randomly initialized backend model
backend_model_rand_init = mlm.MaskedLanguageModel(backend_config)

# Create 🤗 wrapper with randomly initialized backend model
model_rand_init = mlm.PerceiverMaskedLanguageModel(mlm.PerceiverMaskedLanguageModelConfig(backend_config))

# Create Lightning wrapper with randomly initialized backend model
lit_model_rand_init = mlm.LitMaskedLanguageModel.create(backend_config)
```

## Model and checkpoint conversion

Official 🤗 Perceiver models can be converted to `perceiver-io` 🤗 models. For example, the official
`deepmind/language-perceiver` model has been converted to `krasserm/perceiver-io-mlm` with:

```python
from perceiver.model.text.mlm import convert_model

convert_model(save_dir="krasserm/perceiver-io-mlm", source_repo_id="deepmind/language-perceiver")
```

It is also possible to convert PyTorch Lightning training checkpoints to `perceiver-io` 🤗 models. For example, a
checkpoint from fine-tuning `krasserm/perceiver-io-mlm` on IMDb can be converted to a `krasserm/perceiver-io-mlm-imdb`
model with

```python
from perceiver.model.text.mlm import convert_checkpoint

convert_checkpoint(
    save_dir="krasserm/perceiver-io-mlm-imdb",
    ckpt_url="logs/mlm/version_0/checkpoints/epoch=012-val_loss=1.165.ckpt",
    tokenizer_name="krasserm/perceiver-io-mlm",
)
```

The `ckpt_url` argument can also be a local file as in this example. See [pretrained models](pretrained-models.md) for
further details.

repository: krasserm/perceiver-io

gha_language: Python

repo_name: krasserm/perceiver-io


text:
# ToIP  TSS0001: Governance Stack Specification

- Authors: [Drummond<EMAIL_ADDRESS>- Status: [PROPOSED](https://trustoverip.github.io/deliverables/process/lifecycle_management/#proposed)
- Since: 2021-01-27
- Status Note: _Work in progress_
- Supersedes: NA
- Start Date: 2020-12-01
- Tags: #spec, #gswg

## Summary

The Governance Stack Specification contains requirements, roles and processes for a complete governance architecture based on the ToIP model.  The overall purpose of the ToIP Governance Stack is to enable users of the ToIP Technology Stack to make Transitive Trust decisions based on Governance Frameworks that are both human-readable and machine-verifiable.

## Purpose
This repo manages the development and maintenance of the subject ToIP deliverable. It contains the tools necessary to generate multiple renderings formats.

1. Interactive Online Website: [GitHub Pages](https://<ORG_NAME>.github.io/TSS0001-governance-stack/)
2. Printable Documents
    * [PDF Version](./publish/TSS0001-governance-stack.pdf)
    * [HTML Version](./publish/TSS0001-governance-stack.html)
    * [Standalone Markdown](./publish/TSS0001-governance-stack.md)

## Contributor's Guide
Documentation and Specification contributors should familiarize themselves with the [Authoring Process](https://github.com/trustoverip/TSS0001-governance-stack/blob/main/DEV_README.md).

## Related Resources

1. [ToIP Deliverables Portal - Status](https://trustoverip.github.io/deliverables/results/proposed/)
2. [ToIP Contributor's Workflow](https://trustoverip.github.io/deliverables/process/process_concepts/)

gha_language: HTML