Programming Model and Design
Work with and understand generated artifacts
Module
| Business Integration View | J2EE View |
 |
 |
Showing posts with label 1-Programming Model and Design. Show all posts
Showing posts with label 1-Programming Model and Design. Show all posts
Tuesday, June 16, 2009
Support iterative development and synchronization of applications
Programming Model and Design
Support iterative development and synchronization of applications and business models with Business Process Management (BPM) tools
You can use the following tools to support iterative development and synchronization of applications and business models.
- WebSphere® Business Modeler
- IBM® WebSphere Integration Developer
- IBM WebSphere Process Server
- IBM WebSphere Business Monitor
With these tools, you can model a business solution, compose and assemble the solution, implement it, deploy it to a runtime server, and monitor business metrics of the solution on the server. You can continue to refine the model and the implementation iteratively.
The WebSphere® family of products allows you to develop a model of the application that you want to implement and then import that model into WebSphere Integration Developer where you can refine it into a sophisticated application. You can continue to develop both the model and the application and keep them synchronized.
Phases of modeling for iterative development
You can model a process and develop and test its implementation in parallel, using synchronization tools to keep the model and the application synchronized. Some of the work requires a good understanding of the artifacts that are used in the integration environment.Related links
Package assets within modules, mediation modules and libraries
Programming Model and Design
Package assets within modules, mediation modules and libraries to support effective component reuse and application maintainability
Modules
A module is a container for your services and is both a project in the WebSphere Integration Developer workbench, and the unit of deployment to the WebSphere Process Server. That means that any solution that you build will be deployed to the server as one or more modules. For those who are familiar with J2EE, a module is packaged and deployed as an enterprise archive (EAR) file. One of the advantages of the Service Component Architecture is that you don't have to be concerned with the underlying packaging. A module provides services that can be used by other modules and that can be accessed by external clients used by your partners or customers. A module is a collection of components, imports and exports.
Mediation modules
Mediation modules contain mediation flow components. A single mediation module can contain only one mediation flow component.
Libraries
Often, interfaces, business objects, business object maps, events, relationships, roles, and Web service ports need to be shared so that resources in several modules can use them. The library is a project that is used to store these resources.
Unlike modules or mediation modules, library projects can share resources. In order for a module or mediation module to use the resources from a library, the library has to be added as a dependent to the module. A library cannot be deployed by itself. However, you can add a library to the module and select to deploy it with the module. Also, you can add library dependencies to a library; for example, if one library uses resources in another library, then you would need to add the library dependency.
Effective component reuse and application maintainability
Artifacts in a library are public. Artifacts in a module are private. Designers of WebSphere® Integration Developer applications should organize artifacts by taking into consideration logical function and visibility. For example, related data types that are used by various pieces of a system should be placed into a library. Other modules can then easily reuse this library. Only one copy of each artifact needs to be created and maintained using this method. Likewise, related business logic features of the application should be grouped into modules. Componentizing an application in this way will yield a more flexible, easily maintained application. Adding new features to the application will also be easier.
Related links
Determine the implications of process or component design decisions
Programming Model and Design
Determine the implications of process or component design decisions (performance, component versioning, adaptability, complexity)
The building blocks of a business solution are Service Components Architecture (SCA) components wired together to form modules that can be deployed to the WebSphere® Process Server. The WebSphere Integration Developer's assembly editor lets you build applications by assembling the SCA components.
Components are the parts of the module that are the actual services. On the inside, they are implemented using implementation types, which include business processes, state machines, human tasks, and others. The WebSphere Integration Developer tools generate implementations that the assembly editor can use for components. The structure of the component is simple; it has the following parts:
- An implementation
- Optionally, one or more interfaces
- Optionally, one or more partner references
Performance
If you require high performance, put components in the same module.
Components within a module are collocated for performance, and can pass their data by reference. Components in the same module can talk to one another directly while components in different modules can only talk to one another indirectly via export/imports. Direct calls are faster than indirect calls. In addition, passing data by reference is significantly faster than passing data by value.
Component Versioning
When you need to run different versions of the same component at the same time, use component versioning.
- Business process components
You can create new versions of your business process, so that multiple versions of those same processes can co-exist in a runtime environment.
- State machine components
You can create new versions of your business state machine, so that multiple versions of those same state machines can co-exist in a runtime environment.
- Human task components
You can create new versions of your human task, so that multiple versions of those same tasks can co-exist in a runtime environment.
Adaptability
If you want your process/component to be readily adaptable to changing business conditions, implement them as business rules and/or selectors.
- Business rules
Business rules within a business process allow applications to respond quickly to changing business conditions.
Business rules greatly improves application flexibility. They externalize and manage business logic separately from the main business process. They allow you to make changes at runtime to keep up with the evolving on-demand business environment. - Selectors
You can dynamically invoke a component using selectors.
You can call a selector from any of your service-oriented components. The selector’s job is to use dynamic information to determine which component should be called to do the work. The set of destination components is also configurable, allowing you to provide additional destinations at runtime.
Complexity
A component's complexity depends on which implementation type you select to implement it.
You can implement a component using any of the following implementation types.
- Java objects
An implementation of a component in Java™ is referred to as a Java object. - BPEL process
A BPEL process component implements a business process. - State machines
A state machine is an alternative way of creating a business process. A state machine is suited for processes related to changing states rather than a flow of control. A state defines what an artifact can do at a point in time. A state machine is an implementation of this set of states. - Business rules
Business rules complement business processes and state machines. If there is condition with a variable, for example, a business rule can change the value in that variable at run time. Created by a visual programming language, a business rule makes a decision based on context. The decision can be simple or complex. Business rules are nonprocedural and the rules can be changed independently of an application. - Selectors
Integrated applications contain many ways to interact. A selector is used to route an operation from a client application to one of several possible components for implementation. - Human task
A human task component implements a task done by a person. It represents the involvement of a person in a business process. - Interface map
An interface map resolves differences between the interfaces of interacting components. - Mediation flow
Mediation is a way of mediating or intervening dynamically between services. A mediation flow implements a mediation. - Stand-alone references
Stand-alone references are references to applications that are not defined as Service Component Architecture components (for example, JavaServer Pages or servlets). Stand-alone references permit these applications to interact with Service Component Architecture components.
Related links
Design effective mediation flows
Programming Model and Design
How to Design effective mediation flows
Mediation is a way of mediating or intervening dynamically between services. A mediation flow implements a mediation.
Mediation has several useful functions. For example, you can use mediation when you need to transform data from one service into an acceptable format for a subsequent service. Logging lets you log messages from a service before they are sent to the next service. Routing lets you route data from one service into an appropriate service determined by the mediation flow. A mediation operates independently of the services it connects to. A mediation in the assembly editor appears as a mediation flow component between exports and imports.
Mediation flows overview
Mediation service applications intercept and modify messages that are passed between existing services (providers) and clients (requesters) that want to use those services. Mediation services are implemented using mediation modules that contain mediation flows.
Related links
- Developing custom mediations for WebSphere Enterprise Service Bus
- Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer
- The WebSphere ESB mediation
- Using WebSphere Enterprise Service Bus mediation modules
Determine the best component implementation type and characteristics
Programming Model and Design
Determine the best component implementation type and characteristics when building a business process
A business process is any course of action or procedure that an organization follows to achieve a larger business goal. When you break it down, a business process is actually a series of individual tasks that are executed in a specific order.
Service implementation types are the implementations of the service components. A BPEL process component implements a business process. A State machine is an alternative way of creating a business process. A state machine is suited for processes related to changing states rather than a flow of control. A state defines what an artifact can do at a point in time. A state machine is an implementation of this set of states.
Process types
You can use the business process editor to build either microflows or long-running processes.
Choosing between a business process and a state machine
You can model service-oriented applications using either the process editor or the state machine editor
Related links
Design and use interfaces
Design and use interfaces
Interfaces
Interfaces are the means of exchanging data between components. An interface provides the input and output of a component.
The inputs and outputs of each component, specified by the interface, determine which data can be passed from one component to another. An interface is created independent of the implementation of the component. An interface may also be created for a component that has no implementation; that is, the implementation will be done later.
The inputs and outputs of each component, specified by the interface, determine which data can be passed from one component to another. An interface is created independent of the implementation of the component. An interface may also be created for a component that has no implementation; that is, the implementation will be done later.
Creating interfaces
Interfaces are the means of exchanging data between components. In this section, you will learn about the relationship between interfaces and implementations, the parts of an interface, different ways of starting the interface editor and developing an interface, and see some tutorials and samples about interfaces.
Interface maps
Interface maps are created in the interface mapping editor to resolve and reconcile differences between the interfaces of interacting components.
Design and use business objects and the business object framework
Programming Model and Design
Design and use business objects and the business object framework API when developing a solution
Business objects
Business objects define the data flowing between components.
They are containers for application data, such as a customer or an invoice. Data is exchanged between components by business objects. The underlying structure of a business object is an XML schema definition (XSD).
A business object contains fields which have a name, a type (scalar type or another business object), a default value (for scalar types) and cardinality. Business objects can extend (define a superset of fields) other business objects through parent/child relationships, however, a business object can only inherit from a single parent. These objects can also be used in conjunction with each other to perform a task.
Business object framework API
In WebSphere Process Server, the business object framework is made up of the following elements:
- Business object definition
- Business graph definition
- Business object metadata definition
- Business object services (service APIs)
Service Data Objects (SDO)
Service data objects complement Service Component Architecture. Service Component Architecture defines the services as components and the connectivity between them. Service data objects define the data flowing between components.Each component passes information as input and output. When a service is invoked, data objects are passed as an XML document with document literal encoding when using a WSDL port type or as a Java™ object when using a Java interface. Data objects are the preferred form for data and metadata in Service Component Architecture services. Similar to components, service data objects separate the data object from its implementation. For example, a component interacts with purchase orders while the purchase order itself might use JDBC, EJB, and so on, to perform the updates to the data. Service data objects let the integration developer focus on working with business artifacts. In fact, service data objects are transparent to the integration developer. They are defined by a service data objects Java Specification Request (JSR).
Service Message Objects (SMO)
Service message objects are enhanced business objects that include the application data and header information related to the transport protocol used to invoke a service such as SOAP or JMS. A service message object is composed of a body that contains the application data (also known as the payload or operation message) in a business object, and headers containing additional context information.
Service message objects are used inside mediation flow components. When a mediation flow component is invoked, the business object that is input to the mediation flow is wrapped with additional context and header information and becomes a service message object. This contextual information, such as SOAP header information can be accessed from within the mediation flow component.
Service Data Objects and business objects
Service Data Objects and business objects define the data flowing between components that are defined in Service Component Architecture.The Service Data Object (SDO) technology is an open standard for enabling applications to handle data from heterogeneous data sources in a uniform way. SDO incorporates J2EE patterns but simplifies the J2EE data programming model.
Part of the IBM® WebSphere® Application Server capabilities that are built into WebSphere Process Server, SDOs provide a framework for data application development that simplifies the J2EE data programming model.
WebSphere Process Server includes business objects, which are enhanced SDOs, based on the data-access technology. SDOs provide a universal means of describing disparate data (for example, JDBC ResultSet and XML Schema described data). Business objects include some extensions that are important for integration solutions and are used to further describe the data that is being exchanged between Service Component Architecture services. Business objects are part of the Service-oriented architecture (SOA) core of WebSphere Process Server.
A business object is a set of attributes that represent a business entity (such as Employee), an action on the data (such as a create or update operation), and instructions for processing the data. Components of the integration application use business objects to exchange information and trigger actions. Business objects are flexible because they can represent many kinds of data. For example, in addition to supporting the data canonicalization model of traditional integration servers, they also can represent data returned from a synchronous EJB Session Bean facade or a synchronous business process, and then they can be bound to IBM WebSphere Portal portlets and JSF components.
Business objects are the primary mechanism for representing business entities, or documenting literal message definitions, enabling everything from a simple basic object with scalar properties to a large, complex hierarchy or graph of objects.
In WebSphere Process Server, the business object framework is made up of the following elements:
- Business object definition
- Business graph definition
- Business object metadata definition
- Business object services (service APIs)
A business object definition is the name, set of ordered attributes, properties, version number, and application-specific text that specify a type of business object. A business graph definition is the wrapper added around a simple business object or a hierarchy of business objects to provide additional capabilities, such as carrying change summary and event summary information related to the business objects in the business graph. A business object metadata definition is the metadata that can be added to business object definitions to enhance their value when running on WebSphere Process Server. This metadata is added to the business object’s XML schema definition as well known xs:annotation and xs:appinfo elements. Business object services are a set of capabilities provided on top of the basic capabilities provided by Service Data Objects. Examples are services such as create, copy, equality, and serialization.
Apply the SCA programming model
Programming Model and Design
Websphere Integration Developer v612
Contact us...
Websphere Integration Developer v612
Contact us...
Apply the SCA programming model
Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.
SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA divides up the steps in building a service-oriented application into two major parts:
SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA divides up the steps in building a service-oriented application into two major parts:
- The implementation of service components which provide services and consume other services.
- The assembly of sets of components to build business applications, through the wiring of service references to services.
SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware APIs.
Service-Oriented Architecture (SOA)
Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. With the Smart SOA approach, you can find value at every stage of the SOA continuum, from departmental projects to enterprise-wide initiatives.
Components
In an SCA, a component is the actual service. Components are the building blocks of a business solution that are wired together.
Interfaces
An interface provides the input and output of a component. It is created independent of the internal implementation of the component.
Related links
Subscribe to:
Posts (Atom)
