While this is not a Standard Template and should not be treated as one, it is the result of my attempt to come up with A Table of Contents for a Detailed Design Specification using WebSphere Process Server.
1: Purpose of the Document
The need for a detailed design document is authored here.
2: Scope of the Document
List out specifically what the document covers and excludes.
3: Solution Overview
This section will give a brief background of the implementation of the solution.
4: SCA Elements
All elements of Business Transactions are referred to as Service Components. Examples of SCA elements are as follows:
Access to Web Services
Enterprise Information System Service Assets
Business Rules
Workflows
Databases
This section should list out the SCA Elements.
5: Business Objects / SDO (Service Data Objects)
Business objects define the data flowing between SCA components. Business objects provide an abstraction for data access and are based on a data access technology called Service Data Objects (SDO). SDOs provide a universal means of describing disparate data. Business objects provide rich features to map, manage, and transform data to underlying IT and are described through a standards-based XML schema
This section should list out the SDO’s in detail.
6: CEI
Common Event Infrastructure and the use of a Common Utility Framework for the purpose of:
Logging
Auditing / Archiving / Re Processing
Error / Exception Handling
Notifications
Security
With the Common Event Infrastructure (CEI), service components can emit events that can be captured by business monitors such as WebSphere Business Monitor for real-time monitoring of business processes.
This section should List the specific Events that will be handled by the CUF/CEI.
7: Supporting Services
Supporting services are components that are needed in any integration solution, including data transformation and synchronization services. This Section will list the details of the Supporting Services.
Mediation Flows
WebSphere Enterprise Service Bus provides the ESB functionality, with mediation flows that can operate on messages to perform
• XML-based data transformation
• protocol transformation between various transports
• custom Java operations
• routing
This section will detail out all the mediation flows
Interface Maps
Using interface maps, you can invoke components by translating calls to them. It is possible for interfaces of existing components to match semantically but not syntactically. This is especially true for components that already exist and services that need to be accessed.
This section will detail out the Interface Maps
Business Object Maps
Business object maps, you can translate one type of business object Into another type of business object. You can use these maps in a variety of ways, for example, in an interface map to convert one type of parameter data into another.
This section will detail out the BO Maps
Relationships
You can use relationships to establish relationship instances between object representations of the same logical entity in disparate back-end systems. For example, the same customer’s address might need to be updated in various back-end systems, such as an enterprise resource planning (ERP) system and a customer relationship management (CRM) system. These relationships can be established and managed automatically using the relationships service component. These relationships are typically accessed from a business object map when translating one business object format into another.
This section will list the relationships to be accessed from a BO.
Selectors (Dynamic Service Selections)
You can use selectors for dynamic selection and invocation of different services, which all share the same interface. WebSphere Process Server offers a Web-based interface to enable dynamic updates to the selection criteria and target services, which means that a module that has been deployed at a later time can still be called by this selector component, enabling dynamic changes to the integration solution
This section lists out the Dynamic Service Selections.
8: SCA Element Implementations:
There are Multiple ways of implementing a SC Element
Business Processes
A business process component implements a Business Process Execution Language (BPEL)-compliant process. You can develop and deploy business processes that support long- and short-running business processes and a compensation model within a scalable infrastructure. You can create BPEL models in WebSphere Integration Developer or import from a business model that you have created in WebSphere Business Modeler or any other modeling tool that supports the BPEL standard.
Human Tasks
Human tasks are stand-alone components that you can use to assign work to employees. Additionally, the human task manager supports the ad hoc creation and tracking of tasks. WebSphere Process Server also supports multi-level escalation for human tasks, including e-mail notification and priority aging.
Business State Machines
Business state machines provide another way of modeling a business process. Some processes are easily described as a sequential flow of activities, and they can be modeled as business processes. However some processes are driven by events rather than a sequence, and in this case, the business state machine is a better fit for modeling the process. One example is an ordering process where you can modify or cancel the order at any time during the order process until the order is fulfilled.
Business Rules
Business rules are a means of implementing and enforcing business policy through externalization of business function. As a result, dynamic changes of a business process are enabled for a more responsive business environment.
9: SCA Elements Interface (How to call this component)
By definition, an interface is the place at which independent and often unrelated systems meet and communicate with each other. An interface can be defined by any programming or interface definition language. WebSphere Process Server currently supports a Java interface definition and an XML definition (Web Services Description Language (WSDL) port type). The arguments described in an XML schema are exposed to programmers as SDOs. The WebSphere Integration Developer tooling primarily generates interfaces using the WSDL representation.
10: SCA Elements Reference (What this component calls)
An SCA reference specifies other SCA services that a component uses. These can be soft links that do not have to specify which specific component will be used.
12: Project Build & Design
Libraries
List of Project Libraries referenced / used.
Modules
How the Business Integration Module is developed and the artifacts (services choreography into Business Processes) that are built. Any Import, Export and Service Components that are used should be listed here.
13: Assembly & Deployment
How the Module is packaged, deployed and tested in the development/testing/staging/ production environments.
14: Conclusion
15: Signoff
No comments:
Post a Comment