Requirements

System

System requirements are mostly engineering level requirements. They put constraints on how the component should be engineered.

ID	Description	Release	Priority
S-1	Threading model that avoids context switches for outbound SMTP interactions	Kenai	P2
S-2	Routing of inbound messages to particular operations based on SMTP-specific feature. This is a similar requirement to something like the SOAP Action URI.		P2
S-3	Full internationalization of all logging and error messages	Kenai	P1
S-4	Full Junit tests for all classes		P1

Installation

Installation requirements are constraints on how the component should be installed and what should be available before, during, and after installation of the component.

ID	Description	Release	Priority
I-1	Full Javadocs and Documentation		P1

Design Time

Design time requirements are application-level requirements that the product must satisfy during design-time. Most design-time constraints refer to how the user interacts with the Netbeans GUI.

ID	Description	Release	Priority
DT-1	Support adding SMTP Extensibility Elements individually in the WSDL Editor	Kenai	P1
DT-2	Support adding SMTP Templates	Kenai	P1
DT-3	Support for validating SMTP Extensibility Elements in the WSDL editor	Kenai	P1

Runtime

Runtime requirements are application-level requirements that the product must satisfy during runtime. The runtime constraints detail how the component should act during the actual processing of messages in the JBI Framework.

ID	Description	Release	Priority
RT-1	Basic Outbound SMTP. Ability to send email messages with subject and content to an email address	Kenai	P1
RT-2	Basic Inbound SMTP. Ability to receive email addresses and forward it to JBI components	Kenai	P1
RT-2.1	Full support of SMTP timeouts		P2
RT-3	Full support for RFC 2368 (mailto:) protocol including multiple recipients, bcc, cc.	Kenai	P1
RT-3.1	Support mailbox address specifications that are basic (foo@sun.com), have phrases (User ), have comments, and use routing as per RFC 822	Kenai	P1
RT-3.2	Support for any header in the mailto: protocol, with specific interpretation of the cc, bcc, to headers within the SMTPBC	Kenai	P1
RT-3.3	Support URL encoding of mailboxes and headers	Kenai	P1
RT-4	Add “From” attribute in extensibility elements. Ability to dynamically specify the “From” email id in the runtime.	Kenai	P1
RT-5	Support for multiple recipients, bcc, and cc lists. Ability to send emails to multiple recipients specifying bcc and cc lists in the mailto URL. Also in the Inbound scenario, accept emails which are in cc and bcc lists.	Kenai	P1
RT-6	Support for HTML Formatted messages. Ability to send and receive HTML formatted messages.		P2
RT-7	Sending Undeliverable mail messages. Sending delivery status failure notification emails.		P2
RT-8	Configurable SMTP Port. The ability for a user to configure the port on which the SMTP server has to run.	Kenai	P1
RT-9	Encoding Support. Support for encoders using “use” and encodingStyle Attribute. Support for custom encoder.	Kenai	P1
RT-10	Ability to connect to external SMTP servers which requires authentication and SSL.	Kenai	P1
RT-11	Ability to specify the email ids in “to”, “cc” and “bcc” list in the runtime.	Kenai	P1

Use Cases

Use Cases describe particular scenarios that a user will go through in interacting with the product.

ID	DT-UC-1
Use Case Name	Adding individual SMTP Extensibility elements to a WSDL The “Adding individual SMTP Extensibility elements to a WSDL” Use Case describes a scenario where individual extensibility elements are added to a WSDL document through the WSDL Editor. (Screenshots will be attached at a later date)
Requirements Addressed	DT-1
Pre Condition	A new, empty WSDL Document is created in the WSDL Editor.
Normal Flow	1. Create a new Binding Element from the root node.. 2. For this new Binding Element add a “SMTP Binding Element”. 3. Associate the Binding Element with a PortType. 4. Add a Binding Operation for the Binding Element. 5. For the new Binding Operation, add a “SMTP Binding Operation”. 6. On the Input node for the new Binding Operation, add a new “SMTP Message”. 7. Create a new Service Element from the root node. 8. Create a new Port element from the Service element. 9. Add a SOAP Address element.
Exception Flow
Post Condition	A WSDL is populated with all known SMTP Extensibility Elements

ID	DT-UC-2
Use Case Name	Adding a SMTP template to a WSDL The “Adding a SMTP template to a WSDL” Use Case describes a scenario where the wizard assists the user in generating SMTP Extensibility Elements.
Requirements Addressed	DT-2
Pre Condition
Normal Flow	1. The use case begins with the creation of a WSDL Document in the WSDL editor using the wizard. 2. The fourth step in the wizard shows a drop down list which displays many bindings. 3. Select the SMTP binding. 4. Select the only Binding Subtype. 5. Click okay.
Exception Flow
Post Condition	The generated WSDL should have SMTP extensibility elements at the binding level, the binding operation level, the binding operation input level, and the port level.

ID	DT-UC-3
Use Case Name	Validating SMTP Extensibility Elements in the WSDL Editor The “Validating SMTP Extensibility Elements in the WSDL Editor” Use Case describes a scenario where validation of SMTP Extensibility Elements is invoked from the WSDL Editor.
Requirements Addressed	DT-3
Pre Condition	A WSDL containing SMTP Extensibility elements
Normal Flow	1. Click on the validate button in the WSDL Editor tool bar. 2. On the WSDL file in the Project explorer, right-click to bring up the menu. 3. Click on the “Validate XML” option.
Exception Flow
Post Condition	The WSDL Validation window should pop up at the bottom of the editor. In a normal flow case, there will be a statement saying no errors were found. In the exception flow case, there will be a dialog showing all the errors.

ID	RT-UC-1
Use Case Name	SMTP Outbound Use Case The SMTP Outbound Use case describes a scenario where the concrete binding of an abstract operation uses SMTP as the transport mechanism. The abstract operation is invoked by a BPEL process.
Requirements Addressed	RT-1
Pre Condition	A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete HTTP/SOAP Binding. The BPEL invokes a web service operation with a concrete SMTP Binding
Normal Flow	1. This use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete HTTP SOAP binding so the client must use SOAP over HTTP to properly invoke the operation. 2. The HTTP Binding Component receives the message, converts it from the SOAP message to a Normalized Message, and forwards the Normalized Message through the Normalized Message Router (NMR) to the awaiting BPEL process. 3. The BPEL process receives the message for the abstract operation and then invokes a different In-Only abstract operation. This abstract operation has a concrete SMTP binding. 4. When the BPEL process invokes the abstract operation, a Normalized Message is generated and sent to the NMR. 5. The SMTP Binding Component picks up the Normalized Message, converts it to a proper SMTP message, and sends it to an SMTP server that will process the request. The SMTP message will contain at minimum the “To” address.
Exception Flow
Post Condition	A mail message should appear at the account specified by the “To” address in the SMTP message

ID	RT-UC-2
Use Case Name	SMTP Inbound Use Case The SMTP Inbound Use case describes a scenario where the concrete binding of an abstract operation uses SMTP as the transport mechanism. The abstract operation is implemented by a BPEL process.
Requirements Addressed	RT-2
Pre Condition	A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete SMTP Binding.
Normal Flow	1. The use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete SMTP binding so the client must use the SMTP protocol to properly invoke the operation. 2. The SMTP Binding Component receives the SMTP Message (which must have at minimum the “To” field populated). 3. The SMTP Binding Component converts the SMTP Message to a Normalized message and sends it to the NMR. 4. A BPEL process being handled by the BPEL Service Engine handles the abstract message, and returns a status message of either DONE or ERROR. 5. Based on the status message, the SMTP BC returns the proper message to the web service client.
Exception Flow
Post Condition	The web service client reports no errors

ID	RT-UC-3
Use Case Name	SMTP Address with the “mailto:” URL The “SMTP Address with the “mailto:” URL” Use Case describes a scenario where the location attribute of the is set to variations of the mailto URL scheme.
Requirements Addressed	RT-3.1, RT-3.2, RT-3.3
Pre Condition
Normal Flow	1. Create a BPEL project. 2. Create a WSDL in the WSDL Editor. 3. Add a node to a port. 4. Set the location attribute is set to any number of valid mailto URL variations. 5. The rest of the BPEL project is created and deployed through a Composite Application project.
Exception Flow	1. Create a BPEL project 2. Create a WSDL in the WSDL Editor. 3. Add a node to a port. 4. Set the location attribute is set to any invalid mailto URL variations. 5. The rest of the BPEL project is created and deployed through a Composite Application project.
Post Condition	In the normal flow scenario, deployment succeeds. In the exception flow scenario, the deployment fails.

ID	RT-UC-4
Use Case Name	SMTP “From”, “Subject”, and “Message” Attribute The “SMTP “From”, “Subject”, and “Message” Attribute” Use Case describes a scenario where any combination of these attributes are present in an underlying SMTP Message when invoking or implementing a web service that uses SMTP as the transport mechanism.
Requirements Addressed	RT-4
Pre Condition
Normal Flow	The use case is equivalent to the SMTP Outbound Use Case and the SMTP Inbound use case, but with combinations of these attributes being set.
Exception Flow
Post Condition

ID	RT-UC-5
Use Case Name	SMTP Support for multiple recipients through “bcc” and “cc” The “SMTP Support for multiple recipients through “bcc” and “cc”” Use Case describes a scenario where a single message is sent to multiple recipients. If we view SMTP as a transport mechanism for abstract messages, then each recipient may be seen as a different channel for which to send messages.
Requirements Addressed	RT-5
Pre Condition	A deployed SMTP Outbound project with a mailto URL set to include bcc and cc values
Normal Flow	This use case is equivalent to the SMTP Outbound Use Case. The difference is that the location attribute of the element will include a valid mailto URL that contains bcc and cc headers. In an Outbound Use Case, the SMTP BC will send the same message to each address specified in the bcc and cc headers as well as the original mailto recipient.
Exception Flow
Post Condition

This page (revision-24) was last changed on 08-Mar-07 21:59 PM, -0800 by 192.18.17.3.
This page was created on 07-Dec-06 02:40 AM, -0800 by 192.18.17.3.

More info...