XML/ XSD Design Patterns

XML Design Patterns suggested by Oracle

Design Pattern	Characteristics	Advantages	Disadvantages
Russian Doll	Contains only one global element. All other elements are local.	Contains only one valid root element. Could reduce the complexity of namespace, depending on theelementFormDefaultattribute of the schema.	Allows reuse for all or no elements. Supports single-file schemas only.
Salami Slice	Contains all global elements, hence many potential root elements.	Contains all reusable elements. Supports reuse of elements from other documents.	Exposes the complexity in namespace. Renders the root difficult to determine.
Venetian Blind	Is an extension of Russian Doll and contains only one global element. All other elements are local.	Contains only one single root element. Allows reuse for all the types and the single global element. Allows multiple files.	Limits encapsulation by exposing types.
Garden of Eden	Is a combination of Venetian Blind and Salami Slice. All elements and types are global, hence many potential root elements.	Allows reuse of both elements and types. Allows multiple files.	Contains many potential root elements. Limits encapsulation by exposing types. Is difficult to read and understand.

For more information refer http://www.oracle.com/technetwork/java/design-patterns-142138.html

Service-Oriented Architecture (SOA) Design Principles

Services Design Principles

The following guidelines elaborate on services design principles for designing flexible,

extensible and maintainable systems

Services Design Principles

The following guidelines elaborate on services design principles for designing flexible,

extensible and maintainable systems

1.       Services are named to maximize consumability - Services should be named using

  nouns, operations should be named using verbs.

2.       Services have well-chosen granularity - To determine service granularity while

  designing services, consider factors like maintainability, interoperability, consumability, and    

  performance.

3.       Services are cohesive and complete - The noun-verb naming convention for services

  and operations tends to help us focus on the functional cohesiveness of the service

  interface. We can ask the question, "Is the verb something that the noun does?”

  Completeness is particularly relevant when creating a service for a known consumer

  and the focus is on meeting the requirements of the consumer.

4.       Services encapsulate implementation details - The OO design principle encapsulation

  also applies to designing service interfaces. By encapsulating details of service

  implementation -- the algorithms and resources used -- the decoupling between

  service consumer and provider is improved and hence future flexibility is improved.

5.       Services accommodate multiple invocation patterns - service technologies enable a

  further level of encapsulation. A service consumer can use identical coding techniques to   

  invoke services using a variety of different invocation patterns such as

A) Synchronous invocation using SOAP over HTTP(S),

                        B) Asynchronous, messagebased invocation using SOAP over JMS

                        C) Local invocation using Java method calls.

6.       Services can have stateless interfaces - Careful service design can avoid the need for

  stateful conversations and simplify the implementation of a scalable, reliable SOA

  infrastructure.

7.        Stateful services can be modeled using state transitions - A technique for increasing

  consumability is to create service interfaces reflecting the states of the business life

  cycle.

8.       Service operations represent business actions - We should define operations with

  specific business meanings rather than generic operations.

9.       Service operations have coarse-grained parameters - We recommend using coarsegrained  

  parameters for creating flexible operations, enabling new versions of the

  operation to be provided without worrying about existing consumers.

10.   Service operations are designed for concurrency - We recommend the use of an

  optimistic locking strategy, delegating responsibility for concurrency control to

  appropriate application logic.

SOA Governance

What is SOA Governance?

SOA governance refers to the processes used to oversee and control the adoption and implementation of service-oriented architecture (SOA) in accordance with recognized practices, principles and government regulations.

SOA governance consists of three major components:
a registry, a policy and a testing procedure:

• SOA registry is an evolving catalog of information about the available services in the SOA implementation. The registry allows businesses to efficiently discover and communicate with each other.
• SOA policy is a set of behavioral restrictions intended to ensure that services remain consistent and do not conflict with each other. These constraints also ensure that good engineering practices, common-sense customer relations principles and government laws are followed. A specific person may be designated to grant occasional policy exceptions.
• SOA testing is a comprehensive schedule of audits and performance-monitoring procedures intended to ensure that the entire SOA solution is efficient, cost-effective, secure and up-to-date.

Features of SOA Governance

v  Automated discovery, mapping, and management of the service inventory and associated relationships

v  Visualization of services and composite applications runtime and design time

v  Access to services in production, plus those still in development

v  Visibility, lifecycle, and change management of assets and applied policies

v  Enforcement of governance via approvals and policy management

v  Tracking and reporting of reuse throughout the entire service lifecycle

v  Support for critical decisions based on compliance, performance, and ROI metrics

SOA Patterns

Example SOA Patterns

•          Basic principle:

–        n separate processes better than one

•          Communication:

–        asynchronous query

–        command facade

•          Data integration:

–        VETO: Validation, Enrich, Transform, Operate

–        2 step XRef

–        Forward Cache

–        Federated query

1. Asynchronous Query Pattern

•          Problem: long execution times for queries

–        due to Internet

–        due to distributed systems

•          Solution:

–        de-couple request/response

–        use caching of results

2. The VETO Pattern

•          Problem: invoking a service usually involves:

–        Extract data, modify, convert format, validate

•          Solution:  Separate actions into a 4-action pipeline

•          Actions

–        Validate (the XML document)

•          Simplifies data validation for subsequent steps

–        Enrich

•          Adding value to the data

–        Transform

•          To a target format

–        Operate

•          Interacts with the target service

•          Variation:

–        VET(R)O, where R = Route 

3. The 2 Step XRef Pattern

•          Problem: Integration may involve

–        Content transformation

–        Structure transformation

•          Content-level transformation between source and target can be achieved:

–        By single, complex process

–        By two separate processes

•          One to transform to an abstracted form of target

•          Second to transform to the specific target

4.  Federated Query Patterns

•          Federated query

–        Multiple queries on different data sources

•          Cache pushing may not be appropriate:

–        If data changes regularly

–        If out-of-date data is acceptable

•          E.g., newsfeeds cached once an hour

•          Queries may take variable amounts of time

•          Example patterns:

–        Cache pull (federated query) pattern

–        Long duration request (federated query) pattern 

Reducing Audit levels of Oracle SOA Suite for Production Mode

Reducing Audit levels in Production Mode

In this post will talk about: How to reduce the audit level for composites and thus the data written to the SOA schema.

All production environments should have the Audit level set to Production. This should be standard setting for all SOA domains in production. Please note that each component can be set independently of the composite level however Production should be the minimal of settings. Various performance tests have shown that changing from the audit level from Development to Production results in an average of 34 % - 46 % performance improvement (without tuning the individual component audit settings).

If an organization can turn off auditing (provided the business allows for it) there are substantial performance improvements. Internal performance results have shown the changing from Production to Off can result in an average improvement of over 50%-60% (without tuning the individual component audit settings). However since most organizations cannot turn off auditing we recommend the following steps to be considered for reducing the audit levels.

For synchronous BPEL components if the audit trail is not required then use the following settings:

•         inmemoryOptimization = true

•         completionPersistPolicy = faulted

With these settings the synchronous process only shows in the audit trail if the instance faults. Please note these settings should only be used for synchronous BPEL processes and not for any type of asynchronous BPEL processes.

Another way to reduce the audit level is to turn instance state tracking. On the FMW console Uncheck the "Capture Composite Instance State" this has two benefits

1.        A performance improvement since the state is not captured in the DB

2.        Less data in the DB for purge purposes.

The implication is although you may still see the composite instances in the FMW console, the "state" of composite instances will be shown as a question mark (?), so you cannot decipher from the console whether the composite has completed or not. Please note that the state column will not reflect the states of the individual components (BPM, BPEL, UserTask, Mediator, etc) within the composite. The state of the individual components can be tracked by going to the respective component pages for e.g. to soa-infra à Service Engine à BPEL in FMW console.

Each component also has its own audit level which can be set since the initial setting is Inherit, which will inherit the global audit setting. These settings can be set via FMW console soa-infra àSOA Administration à BPMN (BPEL, Mediator) Properties. Auditing can be further tuned by setting the level of the composite audit level. It is also set to Inherit by default and it inherits the respective component auditing level. So the following settings are being used at several customers:

•         Set global audit level = Production

•         Capture Composite Instance State = Off

•         BPEL Engine Audit Level = Minimal

•         Composite Audit Level = Inherit

•         InMemoryOptimization/completionPersistPolicy = true/faulted (for synchronous processes only!)

The above settings can reduce the composite data traffic by 50% and drastically improved purging times.

References: http://www.oracle.com/technetwork/database/features/availability/soa11gstrategy-1508335.pdf

Dehydration Store Database Growth Management Challenges and Purging Strategies

Dehydration Store Database Growth Management Challenges 

SOA tables may grow excessively due to an ineffective management strategy.  When an ineffective purging strategy has been implemented the SOA suite tables may grow very large leading to an urgent need to reclaim space. The larger the tables the harder it will be to delete rows and reclaim space.

This situation highlights the need to constantly monitor the effectiveness of the growth management strategy and to take corrective actions as soon as possible before the tables become very large.

 Recommended Strategies

The growth management strategies recommended is based on the SOA database profile.

The strategies require testing in order to determine their effectiveness. The testing needs to ensure that the purge scripts have headroom grow; that partitioned tables have sufficient disk space; that growth is monitored and that maintenance is performed with minimal impact to OLTP performance.

Recommendations for Large Database profiles

Installation with large database profile must seriously consider table partitioning as part of their strategy. Table range partitioning is a proven method for managing large tables:

1.       Execute the parallel purge excluding the tables that will be partitioned

2.       Partition the bottleneck tables to the purge script

3.       Reclaim space as part of maintenance cycle

4.       Drop eligible partitions as part of the maintenance cycle

5.       Monitor the inflow and outflow

6.       Monitor database and hardware resources

Recommendations for Medium Database profiles

The installations with a medium database profiles have the potential to become large thus the recommendations are the same as that for large profiles. It is important that medium installation perform rigorous QA testing and monitoring, as table partitioning post go-live might require downtime.

The only additional recommendation is that the CTAS (Create Table as Select) scripts when available may be an alternative to purging. This depends on the size of the database being truly medium and the availability of downtime during the maintenance windows.

Recommendations for Small Database profiles

Small installation with limited CPU, memory and disk space should start with the single threaded purge and then move to the parallel purge:

1.       Execute the single threaded purge

2.       Execute the parallel threaded purge. If the single threaded purge is not performing and then the parallel purge should be tested.

3.       Monitor the inflow and outflow

4.       Monitor database and hardware resources

For more information please refer below whitepaper published by Oracle.

References: http://www.oracle.com/technetwork/database/features/availability/soa11gstrategy-1508335.pdf

Oracle SOA Suite Components 

Service Oriented architecture interview questions

What is the basic life cycle of a SOA composite application?

Use Oracle JDeveloper to design a SOA composite application with various SOA components.

Package the composite application for deployment.

Deploy the SOA composite application to the SOA Infrastructure. The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their life cycle, service engines, and binding components.

Use Oracle Enterprise Manager Fusion Middleware Control to monitor and manage the composite application for a farm's SOA infrastructure.

What is the Service Component Architecture (SCA) used for?

Service Component Architecture (SCA) assembly model abstracts the implementation and allows assembly of components, with little implementation details. SCA enables you to represent business logic as reusable service components that can be easily integrated into any SCA-compliant application. The resulting application is known as a SOA composite application. The specification for the SCA standard is maintained by the Organization for the Advancement of Structured Information Standards (OASIS).

What is the purpose of Service Data Objects (SDO)?

Service Data Objects (SDO) provides a data programming architecture. It provides a standardized view on data, and provides efficient transportation, as well as change capture, in form of a change summary. More specifically, it collects a data graph of related business objects, called DataObjects. This graph tracks the schema that describes the DataObjects. Knowledge is not required about how to access a particular back-end data source to use SDO in a SOA composite application. Consequently, you can use static or dynamic programming styles and obtain connected and disconnected access.

What is the purpose of Business Process Execution Language (BPEL)?

BPEL provides enterprises with an industry standard for business process orchestration and execution. Using BPEL, you design a business process that integrates a series of discrete services into an end-to-end process flow. This integration reduces process cost and complexity.

What is the purpose of XSL Transformations?

XSLT processes XML documents and transforms document data from one XML schema to another.

What is the purpose of Java Connector Architecture?

Java Connector Architecture JCA provides a Java technology solution to the problem of connectivity between the many application servers in Enterprise Information Systems (EIS).

What is the purpose of Java Messaging Service?

(JMS) provides a messaging standard that allows application components based on the Java Enterprise Edition (JEE) to access business logic distributed among heterogeneous systems.

What is the purpose of Web Service Description Language?

Web Service Description Language (WSDL) file provides a standardized view on the capabilities of a service. Bindings provide the entry points into the composite at runtime.

What is the purpose of SOAP over HTTP?

SOAP provides the default network protocol for message delivery.

What are the components comprise an Oracle SOA Suite installation?

The following components comprise an Oracle SOA Suite installation:

Service Infrastructure

Oracle Mediator

Oracle Adapters

Business Events and Events Delivery Network

Oracle Metadata Repository

Oracle Business Rules

Oracle WSM Policy Manager

Oracle BPEL Process Manager (Business Process Execution Language)

Human Workflow

Oracle Business Activity Monitoring

Oracle User Messaging Service

Oracle B2B

Oracle JDeveloper

Oracle Enterprise Manager

The following components are included with Oracle SOA Suite, but available as a separate download:

Oracle Service Bus (provides service virtualization and protocol transformations for oracle SOA appl)

Oracle Complex Event Processing

What is the purpose of Oracle Mediator?

Oracle mediator is used for route, validate, filter and transform data from service providers to external partners.

Route: Determines the service component (BPEL process, business rule, human task, and mediator) to which to send the messages.

Validate: Provides support for validating the incoming message payload by using a schematron or an XSD file.

Filter: If specified in the rules, applies a filter expression that specifies the contents (payload) of a message be analyzed before any service is invoked.

Transformation: If specified in the rules, transforms document data from one XML schema to another, thus enabling data interchange among applications using different schemas.

What is the purpose of Oracle Service Bus?

Oracle Service Bus provides standalone service bus capabilities, enabling separation between application developers and target systems or services. Oracle Service Bus receives messages through a transport protocol such as HTTP(S), JMS, File, and

FTP, and sends messages through the same or a different transport protocol. Service response messages follow the inverse path. Oracle Service Bus handles the deployment, management, mediation, messaging, security and governance of implementing SOA to enterprise applications.

What is the purpose of Oracle Adapters?

Oracle Adapters use JCA (Java Connector Architecture) technology to connect external systems to the Oracle SOA Suite. Oracle SOA Suite provides the following technology adapters to integrate with transport protocols, data stores, and messaging middleware:

BAM

FTP

Java Messaging Service (JMS)

Advanced Queuing (AQ)

Files

Message Queuing (MQ) Series

Legacy Adapters

Application Adapters

What is the purpose of Business events?

Business events are messages sent as the result of an occurrence or situation, such as a new order or completion of an order. In Oracle SOA Suite, the mediator service component subscribes or publishes events. When an event is published, other applications can subscribe to it.

What is Oracle Metadata Repository ?

Oracle Metadata Repository MDS stores business events, rulesets for use by Oracle Business Rules, XSLT files for Oracle Service Bus and Oracle Mediator, XSD XML schema files for Oracle BPEL Process Manager, WSDL files, and metadata files for Complex Event Processing.

What is Oracle Business rules used for?

Oracle Business Rules, initiated by a BPEL process service component, enable dynamic decisions at runtime. In addition, the human task and mediator service components can make use of rules for dynamic routing.

What is the purpose of Oracle WSM Policy Manager?

Oracle WSM Policy Manager provides the infrastructure for enforcing global security and auditing policies in the Service Infrastructure.

What is the purpose of Oracle BPEL Process Manager?

Oracle BPEL Process Manager enables you to orchestrate synchronous and asynchronous services into end-to-end BPEL process flows. You also integrate technology adapters and services, such as human tasks, transformations, notifications, and business rules within the process.

Oracle Business Activity Monitoring (Oracle BAM) is a complete solution for building real-time operational dashboards and monitoring and alerting applications over the Web. Oracle SOA Suite makes it easy to expose SOA events, such as BPEL processes, to the BAM engine.

Oracle Complex Event Processing (Oracle CEP), a data management infrastructure that supports the notion of streams of structured data records together with stored relations. Oracle CEP is included with Oracle SOA Suite, but available as a separate download. It is optimized to handle very large volumes of events, such as those found in bank transactions, that cannot be managed by Oracle BAM. In addition, Oracle Complex Event Processing can perform complex correlations and pattern matching.

Oracle B2B is an eCommerce gateway that enables the secure and reliable exchange of messages between an enterprise and its trading partners.

COM application initiates the purchase order.

A mediator service component receives the purchase order. It validates, performs code conversion, transforms the purchase order to a canonical, and routes the document. (Canonical refers to a canonical data model that is used to transition between different document standards.)

A BPEL process service component receives the purchase order, orchestrates any required business process, and can invoke a human task, business rule, and error handling as required.

A mediator service component receives the purchase order, validates, performs code conversion, transforms the canonical to the target purchase order, and routes the document.

B2B receives the purchase order, identifies the partner, identifies the agreement, validates the purchase order, translates the purchase order to EDI, generates the EDI envelope, generates acknowledgments, and manages the secure exchange of the purchase order with the external trading partner.

Oracle JDeveloper is the development component of Oracle SOA Suite. It forms a comprehensive Integrated Service Environment (ISE) for creating and deploying composite applications and managing the composite. Oracle JDeveloper enables developers to model, create, discover, assemble, orchestrate, test, deploy, and maintain composite applications based on services.

The SOA Composite Editor enables you to create, edit, and deploy services, and also to assemble them in a composite application, all from a single location. These components are integrated together into one application and communicate with the outside world through binding components such as Web services and JCA adapters.

The SOA Composite Editor enables you to use either of two approaches for designing SOA composite applications:

The top-down approach of building a composite application puts interfaces first and implementation next. For example, you first add BPEL processes, human tasks, business rules, and Oracle Mediator routing services components to an application, and later define the specific content of these service components.

The bottom-up approach takes existing implementations of service components and wraps them with Web service interfaces for assembly into a composite application. For example, you first create and define the specific content of BPEL processes, human tasks, business rules, and Oracle Mediator routing services components, and later create a SOA composite application to which you add these service components.

Additional editors provided by J editor

Oracle BPEL Designer: You can create a BPEL process service component in the SOA composite application of Oracle JDeveloper and then design it by using the BPEL Designer, which is displayed, when you double-click a BPEL process in the SOA Composite Editor.

Oracle Mediator Editor: You can create a mediator service component in the SOA composite application of Oracle JDeveloper, and then design it by using the Mediator Editor, which is displayed when you double-click a Mediator in SOA Composite Editor.

Human Task Editor: You can create a human task service component in the SOA composite application of Oracle JDeveloper and then design it by using the Human Task Editor, which is displayed when you double-click a human task in the SOA Composite Editor.

Business Rules Designer: You can create a business rules service component in the SOA composite application of Oracle JDeveloper and then design it by using the Business Rules Designer, which is displayed when you double-click a business rule in the SOA Composite Editor.

Oracle Enterprise Manager

You can configure, monitor, and manage your SOA composite application during run time from Oracle Enterprise Manager Fusion Middleware Control Console. Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer a farm.

A farm is a collection of components managed by Fusion Middleware Control. It contains Oracle WebLogic Server domains, one Administration Server, one or more Managed Servers, clusters, and the Oracle Fusion Middleware components that are installed, configured, and running in the domain.

You deploy SOA composite applications designed in Oracle JDeveloper to the SOA Infrastructure. The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their life cycle, service engines, and binding components.

The SOA Infrastructure provides you with access to all deployed SOA composite applications, service engines, service components, business events, and other elements. Fusion Middleware Control organizes a wide variety of performance data and administrative functions into distinct, Web-based home pages for the farm, domain, servers, components, and applications.

Fusion Middleware Control provides a wide variety of administrative and performance data for the SOA components, composite applications, and composite instances within the SOA infrastructure, enabling you to administer and pinpoint issues.

The basic life cycle of a SOA composite application is as follows:

Use Oracle JDeveloper to design a SOA composite application with various SOA components.

Package the composite application for deployment.

Deploy the SOA composite application to the SOA Infrastructure. The SOA Infrastructure is a Java EE-compliant application running in Oracle WebLogic Server. The application manages composites and their life cycle, service engines, and binding components.

Use Oracle Enterprise Manager Fusion Middleware Control to monitor and manage the composite application for a farm's SOA infrastructure.

Services provide the outside world with an entry point to the SOA composite application. The WSDL file of the service advertises its capabilities to external applications. These capabilities are used for contacting the SOA composite application components. The binding connectivity of the service describes the protocols that can communicate with the service, for example, SOAP/HTTP or a JCA adapter.