이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Appendix A. Some Useful Definitions
A.1. Service 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A service is a list of action classes that process an ESB Message in a sequential manner. Each service element consists of one or more listeners and one or more actions. These are set within the
jboss-esb.xml
configuration file.
A.2. Boot-Strapper Mode 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Putting your software into boot-strapper mode tells it what to load and when to do so.
A.3. Message Re-delivery Service 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The Message Re-delivery Service attempts to redeliver messages when none of the end-point references work.
A.4. Action Pipeline 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The action pipeline consists of a list of action classes through which messages are processed. Use it to specify which actions are to be undertaken when processing the message. Actions can transform messages and apply business logic to them. Each action passes the message on to the next one in the pipeline or, at the conclusion of the process, directs it to the end-point listener specified in the ReplyTo address.
The action pipeline works in two stages: normal processing followed by outcome processing. In the first stage, the pipeline calls the process method(s) on each action (by default it is called "process") in sequence until the end of the pipeline has been reached or an error occurs. At this point the pipeline reverses (the second stage) and calls the outcome method on each preceding action (by default it is processException or processSuccess). It starts with the current action (the final one on success or the one which raised the exception) and travels backwards until it has reached the start of the pipeline.
A.5. run.sh 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
run.sh
is the shell script the user runs to launch the JBoss Enterprise SOA Platform. The Microsoft Windows equivalent is run.bat
. The script contains the commands needed to start the server with the profile and port binding which the user has specified in the shell. The script is found in the SOA_ROOT/jboss-as/bin
directory.
A.6. Class-path 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A classpath is a setting that tells the Java Virtual Machine where, on the filesystem, to find user-created classes and packages.
A.7. Business Process Definition 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A business process definition determines the common elements of any runtime instances being used in a process. It is reusable.
A.8. Server Profiles 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A server profile is a set of pre-determined settings for running the JBoss Enterprise SOA Platform in different ways. The following profiles come with the product: all, default, minimal, production, standard and web. They are found in the
SOA_ROOT/jboss-as/server/
directory. The user specifies which profile to run when launching the software by using the -c
switch. If none is specified, the "Default" profile is used.
A.9. Datasource Name 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A datasource name (DSN) is the title given to a particular piece of data. For example, a DSN could refer to the name of a database.
A.10. Decision Table 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A decision table contains a list of actions. These are undertaken by the system when required.
A.11. Stateless Service 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A stateless service is a self-contained service that independently performs tasks instead of having to receive instructions from the user. Additionally, it does not need to use up vast amounts of data to identify objects.
A.12. Service Binding 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A service binding allows you to transport data between clients and services by linking them.
A.13. Enterprise Java Bean 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An Enterprise Java Bean is a Java component architecture designed for enterprise applications. It can be used to create these applications and then deploy them to a server.
A.14. Loose Coupling 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Loose coupling is when two components are linked together to perform certain tasks, but remained unlinked the rest of the time.
A.15. Persistence Mechanism 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A persistence mechanism is a fail-over property. It makes an object persistent, meaning it can automatically start up again after a shutdown and resume the task it was previously performing.
A.16. Resource Adapter 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A resource adapter allows you to modify an application so that other components can be "plugged" into it. These components are then able to communicate with the rest of the system using the adapter.
A.17. Shell Script 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A shell script is a text file containing a series commands for UNIX-based operating systems like Red Hat Enterprise Linux. They call on the shell (terminal) when they run. The Microsoft Windows equivalent is a batch file.
A.18. Web Container 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A web container works with Java servlets. It is responsible for managing their performance as well as making sure they are sending and receiving the correct information. The JBoss Enterprise Application Platform is a type of web container.
A.19. Initial Context Factory 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An initial context factory is where initial context objects are created. These objects are used to create and view naming and directory properties.
A.20. UsernameToken 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The UsernameToken is used to "propagate" a username (and optionally a password) throughout a system to avoid having to login multiple times in a single session.
A.21. Schema Validation 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
This is the process of validating or "checking" code to make sure it works. You can make sure there are no errors in your XML code by running it through a schema validation.
A.22. Byte Array 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
As the name suggests, this is an array of bytes that make up objects like memory. You can create an array of bytes for use with message sending and processing packets.
A.23. Extended Transactional Client 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An extended transactional client allows you to send and receive messages from local queue managers. It also allows you to view and update external queue managers.
A.24. Connection Pooling 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Connection pooling is a back-end way of connecting a server to multiple clients. Once a connection pool is created, an application server can draw on it to perform stored actions (for example, requesting a database to do a certain task). It simplifies common tasks as the actions are ready to go in the connection pool for when the user decides to deploy them.
A.25. Pooled Database Manager 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
As the name implies, this manager works with pooled databases and allows for them to be accessed, managed and configured efficiently.
A.27. Concurrency Control 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
This method of control allows multiple operations to run concurrently while making sure all their processes are running correctly and efficiently.
A.28. Uniform Resource Identifier 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A uniform resource identifier (URI) uses a sequence of alphanumeric characters to identify a resource in the system. A web URL is one type of URI.
A.29. Provider Adapter 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A provider adapter allows applications to receive information from remote providers.
A.30. Implementation Class 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An implementation class defines how an object which belongs to certain classes is implemented.
A.31. Interceptor Class 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An interceptor class is applied to an object to make it perform additional actions that have been defined in the class.
A.32. Transacted Flag 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
You can set your session to have a transacted flag with the value of true or false. It can be set to true on specific endpoints to make them transactional. This means that all the actions of the endpoint can be grouped into one singular action instead of lots of smaller ones.
A.33. Java Connector Architecture (JCA) Transport 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The Java Connector Architecture (JCA) Transport is a Java-based piece of architecture that works as a service integrator. It is a connector that links application servers and enterprise information systems.
A.34. JCA Bridge 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The JCA bridge is a dispatcher which can open and close connections. It identifies connections set by the user and can detect connectors and gateways.
A.35. JCA Adapter 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
The JCA adapter acts as a "go between" that links application servers and enterprise information systems.
A.36. End-point Class 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
An end-point class lets you identify resources and services on your network by providing their network address.
A.37. Service Provider 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A service provider gives access to services, creates descriptions of them and publishes them to the service broker.
A.38. Service Broker 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A service broker hosts the registry of service descriptions. It is responsible for linking a service requester to a service provider.
A.39. Service Requester 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A service requester is responsible for discovering a service. It does so by searching through the service descriptions given to it by the service broker. A requester is also responsible for binding together services obtained from the service provider.
A.40. Messaging Queues 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A message queue is a queue that is generated when an application is deployed. Messages are sent to these queues where they await the message listener.
A.41. Message Listeners 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Message listeners encapsulate the communications end-points needed to receive SB-aware messages. Listeners are defined by services and their role is to monitor queues. They receive any messages as they land in those queues. When a listener receives a message, the ESB server calls the appropriate action class defined in the action definition. The methods in this class process the message. In other words, listeners act as inbound routers, directing messages to the action pipeline. When the message has been modified by the actions on the pipeline, the listener sends the result to the replyTo end-point.
You can configure various parameters for listeners. For instance, you can set the number of active worker threads.
There are two types of listeners: ESB-aware listeners and gateway listeners. Gateway listeners are different from ESB-aware listeners in that they accept data in different formats (such as objects in files, SQL tables and JMS messages). They then convert them from these formats to the ESB messaging format. By contrast, ESB-aware listeners can only accept messages that are in the
org.jboss.soa.esb.message.Message
format. Each gateway listener must have a corresponding ESB listener defined.
With ESB-aware listeners, RuntimeExceptions can trigger rollbacks. By contrast, with a gateway listener, the transaction simply sends the message to the JBoss ESB. The message is then processed asynchronously. In this way, message failures are separated from message receipts.
A.42. ESB-Awareness 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
If application clients and services are referred to as being ESB-aware, this means that they can understand the message format and transport protocols used by the SOA Platform's enterprise service bus.
A.43. Gateway Listener 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
A gateway listener is used to bridge the ESB-aware and ESB-unaware worlds. It is a specialized listener process that is designed to listen to a queue for ESB-unaware messages that have arrived through an external (ESB-unaware) end-point. The gateway listener receives the messages as they land in the queue. When a gateway listener "hears" incoming data arriving, it converts that data (the non-ESB messages) into the
org.jboss.soa.esb.message.Message
format. This conversion happens in a variety of different ways, depending on the gateway type. Once the conversion has occurred, the gateway listener routes the data to its correct destination.
A.44. Senders 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Senders are created by QueueSessions. There is a sender for each queue. The Sender's
send
method is called by its QueueSession's ObjectMessage when ant runtest
is executed. When this happens, the client sends a message to the queue.
A.45. JBoss Rules 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
JBoss Rules is the name of the business rule engine provided as part of the JBoss Enterprise SOA Platform product.
A.46. Rule Base 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
Rule bases are collections of rules. They are used in processing events. The rules help determine how information is stored and processed, which actions are allowed and what action to take when a message is being sent.
A.48. Deserialize 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
To deserialize a file is to transform it back into an object. It is the opposite of serialization.