Glauco Castro

---

Biography

Glauco Castro holds a degree in Information Technology, is a SOA Certified Professional certified by SOA School and Oracle Service Oriented Architecture Infrastructure Implementation Certified Professional certified by Oracle. In the certification process for SOA Architect, has over 15 years experience in the IT field as a Systems Analyst, working in the area of BPM, ECM and SOA projects for over 5 years. He is currently the IT Director of Tractus Consulting, responsible for creating solutions for a wide variety of information technology projects.

---

Contributions

• Service-Orientation with Oracle SOA Tools

---

  subscribe to this author

Yuri Marx Pereira Gomes

---

Biography

Yuri Marx is the SOA Architect at CDS and has over 12 years of experience in Development, Design, and System Architecture. Besides being an expert in SOA, he also has extensive experience in Process Development and Software Architecture. With extensive knowledge in various areas of Software Engineering, he has received 22 technical certifications including SOA Architect, Oracle SOA Expert, SCEA, BUSY, RUP, ITIL, CobiT and so on. Today, he is committed in the development and evolution of the SOA development process and also CDS SOA Architecture.

---

Contributions

• Service-Orientation with Oracle SOA Tools
• Functional Size, Effort and Cost of the SOA Projects with Function Points

---

  subscribe to this author

Bookmarks

• Digg This
• De.licio.us
• Slashdot
• Technorati
• StumbleUpon
• Google Bookmark



Service-Orientation with Oracle SOA Tools Published: February 27, 2013 • Service Technology Magazine Issue LXX PDF

Abstract: The Oracle SOA Suite [REF-1] is a middleware offering that can be implemented in compliance with service-orientation principles [REF-2]. Conversely, the features provided by this platform can help optimize the application of these principles to facilitate the connectivity and reuse of shared services and service-oriented solutions. This article explores the marriage of service-orientation with the tools and technologies of the Oracle SOA Suite.

SOA Principles

Preliminary consultation with experienced industry professionals and identification of the market's best practices can help decrease the high potential for error that accompanies first-time, independently executed SOA implementations. The objective of applying the eight SOA principles as identified by Erl is to propagate the best practices of service development, through uniting practices with mature, service-oriented technology.

Let's first recap Erl's eight de-facto principles of service-orientation:

• Standardized Service Contract - Services within the same service inventory are in compliance with the same contract design standards.
• Service Loose Coupling - Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.
• Service Abstraction - Service contracts only contain essential information and information about services is limited to what is published in service contracts.
• Service Reusability - Services contain and express agnostic logic and can be positioned as reusable enterprise resources.
• Service Autonomy - Services exercise a high level of control over their underlying runtime execution environment.
• Service Statelessness - Services minimize resource consumption by deferring the management of state information when necessary.
• Service Discoverability - Services are supplemented with communicative metadata by which they can be effectively discovered and interpreted.
• Service Composability - Services are effective composition participants, regardless of the size and complexity of the composition.

Oracle SOA Tools

Oracle has a portfolio of tools for the SOA development lifecycle and its governance. These tools can be used to help SOA implementation teams apply service-orientation principles, and are commercialized by Oracle into three categories:

• Development Tools
• Oracle SOA Suite
• SOA Governance Tools

Development Tools

Oracle provides two integrated development environments (IDEs) for the SOA stack. The first is Jdeveloper, which is an IDE for application development that includes SOA and its components. The second IDE is the Oracle enterprise pack for Eclipse (OEPE), which enables Eclipse users to build enterprise service bus (ESB) artifacts [REF-3]. Oracle is also expected to provide Oracle service bus (OSB) support within Jdeveloper in the future.

Both IDEs can be installed on Windows, Mac, and Linux using a Java virtual machine (JVM). However, the standard Jdeveloper installation for the SOA Suite includes a WebLogic server (WLS) installation, which is not freeware but a free license for learning, product assessment, and some forms of development for single users.

Oracle SOA Suite

This product suite is composed of components that collectively comprise an environment for the implementation, deployment, and management of SOA implementations. This environment is made complete by the addition of a WebLogic server and database, which are separately downloaded and installed.

The following features and tools of the offering are highlighted:

• Oracle Mediator - A SCA environment for mediating, transforming, building, and running composed services.
• Oracle Service Bus - A Validate, Enrich, Transform, Route, and Operate (VETRO) implementation, this service bus transforms messages, and virtualizes and composes services in complex scenarios.
• Oracle BPEL Process Manager - A runtime tool that enables service deployment and management, and the orchestration of services with human interaction [REF-4].
• Oracle Business Rules - A business rules engine for the encapsulation, extraction, and execution of business rules from services. The business rules can be changed by the user, without requiring recompilation or redeployment.
• Oracle Event Delivery Network (EDN) - An event-processing engine.
• Oracle Human Task - A tool that creates user interface services for the collection of user input data by corporate services, in order to complete or continue the execution.
• B2B Environment - A feature that allows for EDI, EDIFACT, and custom-developed document transactions.
• Business Activity Monitoring (BAM) - This feature allows business services to be monitored, modified, and input into reports, using data that is processed by the services.
• Oracle Complex Event Processing (CEP) - A feature that identifies realtime business trends through the processing of multiple streams of events.

In addition, the Oracle SOA Suite also includes the following adapters:

• DB Adapter - Connects, uses, and exposes SQL commands as utility services.
• File Adapter - Writes and reads files from file paths as utility services.
• FTP Adapter - Connects, reads, and writes archives in FTP servers as utility services.
• Other Adapters - Encapsulate socket and third-party enterprise resources as utility services, to connect and use legacy systems and applications.

There is also support within SOA Suite for integration with a UDDI registry.

SOA Governance Tools

In another of his books titled SOA Governance: Governing Shared Services On-Premise & in the Cloud [REF-5], Erl describes how the SOA governance program comprises precepts, processes, and people that collectively realize best practices and principles. A well-defined methodology that is regulated and overseen by a governance committee and stakeholders is used to enforce, enable, and enhance these practices and principles.

Using Oracle governance tools to apply the methodology is more efficient when the development process is automated, as these governance tools facilitate the creation of services repositories, documentation of services, and dynamic application of policies. The tools comprising the Oracle SOA governance solution are:

• Oracle Enterprise Repository (OER) - For the automation of the entire SOA development lifecycle and documentation of services with attachment support.
• Oracle Service Registry - For the creation and maintenance of service registries, such as Universal Description, Discovery and Integration (UDDI).

SOA Principles and Oracle SOA Tools

In SOA Principles of Service Design, Erl explains the reasoning for the implementation of the eight principles when creating services. Applying these principles guarantees that services are developed using practices that obtain the highest return on investment (ROI).

Using either a market tool or complete suite of tools to assist in the implementation of SOA principles is usually compulsory, given the complexity of SOA project implementations. The relationships in which the Oracle SOA tools enable the application of the eight service design principles are shown in the following overview (Table 1):

SOA Principle	Oracle SOA Tool
Standardized Service Contract	Jdeveloper Oracle SOA Suite Oracle Service Bus Oracle Web Services Manager Oracle Enterprise Repository
Service Loose Coupling	Oracle SOA Suite Oracle Mediator (SCA implementation) Oracle Service Bus Oracle Business Rules Oracle Human Task Oracle Web Services Manager Oracle EDN Oracle WebLogic
Service Abstraction	Oracle SOA Suite Oracle Mediator (SCA implementation) Oracle Service Bus Oracle Business Rules Oracle EDN Oracle Enterprise Repository
Service Reusability	Jdeveloper Oracle SOA Suite Oracle Mediator (SCA implementation) Oracle Service Bus Oracle BPEL Oracle Business Rules Oracle Enterprise Repository
Service Autonomy	Oracle SOA Suite Oracle Service Bus Oracle WebLogic Oracle Database RAC Oracle Database Partitioning
Service Statelessness	Oracle SOA Suite Oracle BPEL
Service Discoverability	Jdeveloper Oracle Enterprise Repository Oracle Service Registry
Service Composability	Oracle SOA Suite Oracle Mediator (SCA implementation) Oracle Service Bus Oracle BPEL Oracle Enterprise Repository Oracle Service Registry

Table 1 - The relationship each service design principle has with Oracle SOA tools is shown in this overview.

SOA Principles

The application of the service-orientation principles in accordance with each principle's relationship with the components of the Oracle SOA Suite are explored in the following sections.

Standardized Service Contract

During development, XSD and WSDL artifacts can be stored within the Metadata Store (MDS) for reference by multiple service implementations, to enable a consistent view of the canonical data model.

The Standardized Service Contract principle requires a service contract to be created before the creation of a Web service, as well as consideration of the data structure or XML schema definition (XSD) that will be used. This approach is crucial for identifying the canonical data structure of the entire organization to provide an organizational view of the information, as opposed to the traditional departmental view by which vertical applications are developed.

Development tools need to have the following characteristics in order to realize the Standardized Service Contract principle:

• Visual development with wizards and drag-and-drop features to create XSDs, WSDLs, and policy files (contract-first strategy).
• Direct connectivity with service repositories, such as the Oracle enterprise repository, to reuse services, WSDLs, XSDs, and policies, and to publish new assets in the repository with all of the taxonomies defined.
• Functionality to generate the source code of the service from the contract.
• A code completion and validation tool to improve the development experience.

The characteristics of the Oracle Jdeveloper are illustrated in Figures 1 to 4:

The Oracle Jdeveloper and OER are suitable for creating new services, while ESB offerings effectively realize the reuse of existing organizational assets by creating a wrapper to standardize the assets with the correct contract standards.

Oracle's service bus can internally register and expose a non-standard service to service consumers as a standardized contract, with the option of creating transformations and other internal actions before returning the response message.

Policies can be standardized by the application of the Standardized Service Contract principle, in an environment that allows for the creation, maintenance, and application of the policies to services. The Oracle Web services manager (OWSM) from the Oracle SOA Suite has ready-to-use policies in its repository, and can create new policies and centralize the ones that are inherited from existing policies. The OWSM is a Web tool that is accessed from the Oracle SOA enterprise manager, as shown in Figures 6 and 7:

Service Loose Coupling

Services need to impose low consumer coupling requirements when decoupled from their surrounding environment, in accordance with the Service Loose Coupling principle. The requirement for low consumer coupling refers to service orchestration and the use of services by systems, business processes, and compositions. Any tool that implements the VETRO pattern supports loose coupling, as follows:

• Validate - Service contract developers are allowed to delegate validations to the VETRO product, meaning the schema or service logic does not have to implement the validation.
• Enrich - The service consumer can consume the service by passing simple values to the operations, while the VETRO component enriches the parameters passed to the consumed service.
• Transform - The consumer can call a service using a simple interface. The VETRO tool transforms the input message to a message of higher complexity as required by the service.
• Route - The complexity involved in coupling multiple services from the service consumer can be abstracted. The service consumer couples in a simple interface that is exposed by the VETRO tool, while the routing and orchestration are performed internally.
• Operate - All of the internal compositions, validations, enrichments, and routes can be executed and exposed in a simple interface to the service consumers.

Oracle SOA tools offers two VETRO options for SOA developers (Figures 8 and 9):

Table 2 defines the most suitable use cases for each tool:

	Mediator	Service Bus
Characteristics	Lightweight service bus Limited VETRO implementation Developed through Jdeveloper Transformation with XSLT SCA component	Heavyweight service bus Full VETRO implementation Developed through OEPE Transformation over Xquery or XSLT No SCA implementation
Use Case	use in intra-composite scenarios	use in inter-composite scenarios

Table 2 - The different uses for the Oracle mediator and the service bus are summarized.

The extraction, isolation, and encapsulation of business rules in separate services enable the application of the Service Loose Coupling principle, since services are typically used to process business rules but not entire functions. Using Oracle business rules allows services to be created that can expose business rules as services themselves. The business rules can be dynamically changed over the Web using declarations and expressions after deployment, and are specified using decision tables of if-then-else structures in natural language (Figure 10).

Another method of reducing coupling between services is to encapsulate graphical user interfaces (GUIs) in services and for use in the VETRO and BPEL tools. Creating traditional Web applications to input data into services is not necessary, since the GUI services expose forms to the user via the corporate portal to gather the information required to complete the flow. The Oracle human task tool implements this functionality through tools to generate forms based on data objects. This is shown in the screenshots depicted in Figures 11 to 13:

Two methods can be used to execute the Service Loose Coupling principle. The first involves applying policies during runtime to decouple from service contracts, while the second uses application server resources to decouple services from their surrounding environment. The Oracle Web services manager can be used to apply policies to services at runtime, in order to decouple the services from the SLAs. The latter method can be implemented by pointing to external resources that use the Java naming and directory interface (JNDI), which is present in Oracle WebLogic and other Java EE application servers.

Services that need to connect to a database can use the database connection pool, which is configured in the WebLogic and exposed through the JNDI. The services are not affected if the address of the database server changes, because the connection pool keeps the same JDNI name. The only parameter that has to be changed is the database server address, which can be done via the WebLogic console without impact on the service.

An effective method for decoupling services is to use events. Publishing an asynchronous event in a message queue and consuming events from other queues decouples service contracts from both the service producer and service consumer, since both services will know only the queues and their messages and not the contract.

The EDN that is included in the Oracle SOA Suite supports these events and their queues, while all of the tools in the Oracle SOA Suite can publish and consume asynchronous events. Service consumers can leverage the Oracle continuous query language (CQL) to find the correct event for consumption in queue. The EDN can also consume events from and publish events to sources outside of SOA Suite, using JMS or AQ.

Service Abstraction

Service contracts can only contain essential information about the services, and requires the visibility of and access to service operations to be regulated. Two regulation strategies can be used, the first of which is to change the service contract. The second strategy is to register the service with a VETRO offering in order to define and regulate access to the service, without changing the service itself. The second approach has less impact on service dependencies and is more effective overall.

Only essential operations and parameters are defined and exposed in the service contract to service consumers in VETRO implementations, while enrichment, routing, and transformation functions are used to call services to simplify and abstract complex calls from service consumers.

The Service Abstraction principle dictates how the service documentation can be accessed by service consumers, which is enabled by the Oracle enterprise repository. This enterprise repository catalogs services and their information, which is provided only to authorized parties (Figure 14):

Extracting and encapsulating business rules that frequently change in new services help improve abstraction, since business rule implementation in services requires the internal rule structure to be known before the change-rule request can be sent to the TI area. Business rules that reside in the Oracle business rule component can be changed by the business rule owner over the Web, using natural language and Rete algorithmic fact tables.

Service Discoverability

Services are supplemented with communicative metadata that allows them to be effectively discovered and interpreted. The application of the Service Discoverability principle involves using a tool that queries all of the available services that can meet the business requirements of service consumers. For example, Account entity services can be found by service consumers in the OER (Figures 15 to 19):

Queries in the OER can be executed from the Jdeveloper, VETRO tools, and Oracle BPEL. Another component that supports discoverability is the Oracle service registry, which implements a UDDI with all of its characteristics and benefits to promote manual or runtime queries of services so that consumers can use the right service.

Service Reusability

The Service Reusability principle states that services contain and express agnostic logic, and can be positioned as reusable enterprise resources. Implementation of this principle requires the logic that performs the service tasks to be at a central access point and not directly accessible to other services, which can be achieved by applying the Logic Centralization design pattern.

The Oracle Jdeveloper is integrated with the Oracle service registry (UDDI implementation) for the discovery of services in design-time. Searching for services that have already been developed and deployed is enabled, and the OER can be used to make refined searches of services and their documentation.

Reusability is achieved when services from the OER in the Oracle service bus, mediator, or BPEL are consumed. Each of these tools allows the OER to be visually queried. The Oracle mediator, service bus, and BPEL increase reusability by exposing simpler contracts and using features to compose the services that were previously incompatible. Encapsulation of the business rules in separate services increases reusability, as does rule centralization by the Oracle business rules.

Service Autonomy

The Service Autonomy principle states that services are to exercise a high level of control over their underlying runtime execution environment. The autonomy of a service can be measured as the following (Table 3):

Level	Description	Oracle Strategy
Service Contract	Service contracts are designed in alignment with one another to avoid overlapping expressed functionality.	The Oracle service repository has service contracts and related assets catalogued, classified (taxonomy-defined), documented, and governed by people and by a process, decreasing overlap issues. A service that is virtualized in an Oracle service bus has its contract protected from changes required by consumers, because the service bus can use transformations, enrichment, and routing functions to form application-level services without impacting the Enterprise level services.
Shared Resources	The logic and resources that comprise the underlying service implementation are shared with other parts of the enterprise.	Many shared resources can be used by the services in the Oracle WebLogic’s managed resources, such as database connection pools, message queues, adapters, and LDAP connections. The OEM provides monitoring and reporting on system and service usage to enable proactive resource allocation. These resources are managed by Oracle WebLogic, and can be configured at runtime by the administrator to increase capacity and other parameters for scaling without changes in the services. Oracle WebLogic allows clustered and cloud-based environments to be created for services without changing the services.
Service Logic	The underlying logic is isolated, but data resources are shared with other parts of the enterprise.	Resources in the Oracle database are kept available with Oracle real application clusters (RACs), to construct a database cluster without changes in the service. RAC installation is not a simple process, although it is an established technology and well supported. RAC is principally for failover.
Pure Service Logic	The underlying logic and data resources are isolated and dedicated to the service.	Services in the Oracle service bus can be reallocated to different physical servers without impacting the service consumers that are coupled to the virtual address provided by the service bus. The physical address of the consumed service can be dynamically changed in the service bus’ Web interface. This principle can be implemented by partitioning the tables used by services in the Oracle databases, which creates a physical partition to isolate a table or certain number of rows and improve performance. For example, a service uses 2013 data stored in a trip table, even though trip data has been stored since 1990. The database administrator can create a partition for the trip table with data from 2013. The service code does not need to be modified, because the Oracle database engine abstracts the complexity of data management.

Table 3 - An overview summarizing the description and corresponding strategy to be implemented for service autonomies on different levels.

Service Statelessness

The Service Statelessness principle states that services are to minimize resource consumption by deferring the management of state information whenever necessary, which is most efficiently executed by the BPEL tool. This component encapsulates the business process or composition that needs to save the state of the data between service calls.

The BPEL component can execute both short and long-term service instances, including human tasks, to allow users to enter data into a service that is in a business process or service composition. Data entered by users are persisted by the BPEL in the workflow execution, meaning neither the human task tool nor the services needs to perform any persisting (Figure 20).

The results that are returned by the service to the BPEL component are automatically saved so that the service can resume execution. The BPEL engine provides the human task with the service results that were previously persisted, which the human task shows to the user in a GUI. The user is then required to approve or reject the credit to the client, after which both the CCStatusService and human task will process the data for the BPEL component to persist again when necessary.

The Oracle BPEL component can hydrate and dehydrate the data between service calls while saving all of the data in the internal repository.

Service Composability

Service composability is the ability of services to form compositions with one another that are independent of service size or complexity, in order to solve business requirements.

Three Oracle tools that can be used to create service compositions are as follows:

• Oracle BPEL - This tool orchestrates services to perform complex operations, exception handling, and transactions. The BPEL component is a tool for creating service compositions, since new services can be produced after BPEL implementation. This product exclusively manages state services that compose with human tasks and other long-running scenarios, and is therefore recommended for stateful scenarios only.
• Oracle Mediator - The mediator does not save the state and is therefore lighter and more scalable to allow for the rapid composition of designs, although it possesses fewer features than the BPEL.
• Oracle Service Bus - This is a scalable VETRO tool that is suitable for composing services. This tool is generally used for medium to complex compositions, which are created either in the Web interface or OEPE.

Conclusion

Oracle SOA Suite features and capabilities can be leveraged to directly apply and support each of the eight service-orientation principles, thereby perpetuating a sophisticated SOA environment that can optimize service reusability and integration. Additionally, the monitoring and reporting capabilities of the OEM and OSB can provide the information required to effectively evolve the service landscape and maintain alignment with business needs.

Acknowledgements

Special thanks to Peter Hughes of Estafet Limited for his valuable technical review and content contributions. Also, thanks to Juergen Kress and Bob Rubhart.

References

[REF-1] Getting Started With Oracle SOA Suite 11g R1: www.packtpub.com/getting-started-oracle-soa-suite-11g-r1-hands-tutorial/book

[REF-2] Prentice Hall Service Technology Series. SOA Principles of Service Design by Thomas Erl, www.servicetechbooks.com

[REF-3] Implementing the Enterprise Service Bus Pattern to Expose Database Backed Services: www.oracle.com/technetwork/articles/soa/jellema-esb-pattern-1385306.html

[REF-4] WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g: www.packtpub.com/ws-bpel-2-0-for-soa-with-oracle-soa-suite-11g/book

[REF-5] Prentice Hall Service Technology Series. SOA Governance: Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable , www.servicetechbooks.com