ARCHITECTURE
SOLUTION ACCELERATOR
GUIDE
This document may not, in whole or in part, be photocopied, reproduced, translated, or reduced to any
electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc.
Information in this document is subject to change without notice and does not represent a commitment
on the part of BEA Systems, Inc.
TRADEMARKS
BEA, Tuxedo, and WebLogic are registered trademarks and BEA WebLogic Enterprise Platform, BEA WebLogic
Server, BEA WebLogic Integration, BEA WebLogic Portal, BEA WebLogic Platform, BEA WebLogic Express,
BEA WebLogic Workshop, BEA WebLogic Java Adapter for Mainframe, and BEA eLink are trademarks of BEA
Systems, Inc. All other company and product names may be the subject of intellectual property rights reserved by
third parties.
BEA makes no representation that the interconnection of products in the manner described
herein will not infringe on existing or future patent rights, nor do the descriptions contained
herein imply the granting or license to make, use or sell equipment constructed in accordance
with this description.
BEA reserves the right to make changes without further notice to any products herein to
improve reliability, function, or design.
All company and product names in this document may be trademarks of the company with
which they are associated.
o Transactional integrity
o Performance optimization
BEA Solution Accelerators provide patterns and code samples from numerous successful
field engagements. These patterns and samples provide a starting point for actual projects.
Obviously, more complex projects may require field customization.
1.2 AUDIENCE
This document is aimed at the medium to advanced level, intended for Solution Architects
and Technical Consultants who need to design and implement an SOA Solution using
WebLogic Platform 8.1.
This information is also useful for Project Managers involved in orchestrating projects
requiring an SOA Solution.
Application integration is one of the most critical issues faced by enterprise information
technology managers. Traditional application development and integration approaches have
been inflexible and have not been standards-based; they have not, therefore, facilitated an
agile enterprise IT environment which can support the changing needs of a dynamic
organization.
On the other hand, application integration requires certain application development tasks,
such as developing and assembling components, connecting them to back-end systems,
implementing process flows and work flows, developing user interfaces, testing and
debugging.
The interconnections shown could also be built with Web Services. That would not make this
an SOA-based system, because it lacks other characteristics such as loose coupling,
intermediary based, and shared infrastructure.
The following diagram shows the high-level conceptual architecture for EAI:
2.2.4 Disadvantages
None of the traditional approaches described above is ideal. Some of the problems are:
• Custom or proprietary integration between message bus and applications. Both EAI and
business process-based integration reduce the number of integration points compared
with the peer-to-peer approach. However, all three approaches require custom or
proprietary integration between the message bus and each application, and different and
proprietary data formats were involved at each integration point.
• Tight coupling between message bus and applications. All the applications need to know
the inner workings of the other applications they are integrated with. The integration
between systems is granular and tightly coupled by message type. The business process
management (BPM) tools used in traditional EAI implementations were proprietary.
This prevented the use of best of breed products.
o Multiple data formats. Each data source has its own API and data format. The
developer must understand each data source in sufficient detail to manage the data
integration. This often requires multiple specialists to implement and maintain the
integration, driving up complexity and cost.
o Custom information integration framework. The developer has to manage all the
integration issues such as the relationships between data sources and data formats.
This leads to one-off solutions and inconsistencies that are difficult to maintain.
o Limited reusability. The integration code tends to be specific to each application and
data source, making it difficult to reuse.
A set of standards based interaction patterns defined by SOA enable a consumer application
to utilize services. These approaches define how services are described, advertised,
discovered, and communicate with services.
Unlike the approaches described earlier, in SOA, all patterns around a service are
implemented on standards-based technologies. Most communication middleware systems,
such as RPC, CORBA, DCOM, EJB, and RMI, rely on similar patterns. No implementation
is perfect; issues exist with interoperability as well as defining acceptable standards.
SOA attempts to eliminate these weaknesses. For example, each middleware system has a
fixed granularity: functions for RPC, objects for CORBA, and so on. Services, however, can
be defined as functions, objects, applications, or other things. This makes SOA adaptable to
any existing system, and does not force the system to conform to any particular level of
granularity.
SOA helps information systems move toward a “leave-and-layer” architecture, meaning that
instead of altering existing systems to provide a Web Services interface, they are wrapped
with a layer that provides the Web Services interface. Instead of replacing existing
architectures, SOA transforms systems and applications into agile services. SOA covers not
only the information from packaged applications, custom applications and legacy systems,
but also the functionality and data from IT infrastructure such as security, content
management, search, and so on. SOA-based applications are faster to build because they can
easily add functionality from these infrastructure services.
The following figure provides a high-level view of enterprise applications using service-
based integration. Note the resemblance to Figure 2: EAI Conceptual Architecture.
However, the key differences are that this system uses standards-based services and includes
process/data services, orchestration, and composition. The standards-based services become
the integration points between applications. Orchestration and composition of services add
flexibility, reuse, and integration of services.
The following table highlights the differences between distributed component architectures
and SOA:
• Standards-based
• Loosely coupled
• Shared services
• Coarse grained
• Federated control
These attributes are discussed in detail in later sections.
Providers describe their services in standard language in a service contract and publish it with
a broker. Clients query service brokers (or registries) for the services they want, and receive
the contract and information on accessing the service. The client or consumer then binds to
the service and calls the provider directly.
Service
Interface Implementation
Services for data access are the most common, widely used, and easily implemented services
in an SOA architecture; separating the data layer and the application layer is generally
straightforward. As data resources are widely accessed and shared, they become the first
target for implementation as services.
XML is widely used for application data exchange. An infrastructure that provides abstract,
uniform data access, regardless of the source, is valuable in SOA implementations. XML
Data Services (XDS) supplies access to multiple types of data resources, data modeling
capabilities, translation and transformation of physical data to logical data, and XML-based
access to logical data.
Component services are implemented by using individual application APIs to expose reusable
functionality. These services can be implemented using distributed computing technologies
such as J2EE EJB, COM/DCOM, and CORBA.
Function-specific portals such as Sales Portal and Employee Portal are examples of
composite applications; these would require business, component, and data services.
• Service Repository
• Service Finder and Broker
• Single Sign-on
• Content Brokering
• Logging Service
• Monitoring
• Unique ID Generator
• Data Services
• Security Services
Fine-grained services are best consumed by coarse-grained or composite services rather than
directly by end applications. If an application is built using fine-grained services, the
application will have to invoke multiple services over the network, each of which exchanges
small amounts of data. Consumers of coarse-grained services are not exposed to the fine-
grained services that they use. However, coarse-grained services can’t provide granular level
security and access control, as they may use multiple fine-grained services.
A coarse-grained service might be Create New Customer, which would need to validate the
customer with some external service and create the customer record in a CRM application.
A composite service might be Provision New DSL Line, requiring a service call to validate
the order, creating or verifying a customer, checking for product availability and allocating
the resources for the line.
The following diagram depicts the different levels of service granularity and their
relationships.
SOA provides conceptual design patterns for service-based distributed systems. Web
Services provide standards-based technology to implement an SOA in a cost-effective
manner using communication methods available everywhere today. When the Web Services
Definition Language (WSDL) is used to define the service interface, then the service is a
Web Service.
CORBA IDL, Tuxedo FML (more of a data format definition than an interface definition
language), COM/DCOM Microsoft IDL, and CICS common area (COMMAREA) were the
other service definition languages prior to the wide acceptance of WSDL.
In the past, CORBA, EJB, COM/DCOM, CICS, and Tuxedo provided service-based
application development and integration technologies for implementing an SOA. CORBA,
SOA provides an architecture to manage the many loosely coupled services developed using
Web Services or other similar technologies. Web Services can be implemented using J2EE
based application servers, Enterprise Service Bus (ESB), or the .NET framework.
J2EE Connector Architecture (J2EE CA) based adapters are usually used to integrate ESBs
with enterprise systems. The ESB supplements its core asynchronous messaging backbone
with intelligent transformation and routing to ensure that messages are passed reliably.
Services participate in the ESB using either Web Services messaging standards or the Java
Message System (JMS).
An important distinction between JMS and Web Services is that JMS is a Java programming
API, whereas Web Services provide a standard wire-level protocol (SOAP over HTTP). This
means that JMS does not remove the interoperability problems associated with proprietary
messaging solutions. Every JMS provider (e.g. WebLogic, Sonic, Firano) implements a
proprietary protocol between the JMS client and the JMS server. Therefore, there is no
interoperability between JMS clients and servers; for example, a Sonic JMS server can only
be accessed by a Sonic JMS client.
ESBs can provide global messaging with location transparency; however, an ESB by itself
can’t provide the complete infrastructure for SOA. For example, it is difficult or impossible
to implement application logic, components, process flow logic, and workflows using an
ESB, but those can be implemented and service-enabled rapidly by the BEA Platform. For an
enterprise that is not geographically distributed, an ESB is not required to implement SOA.
Businesses can benefit from handling events due to real-time system state changes. For
example, instead of periodically checking to reorder items for a warehouse, the warehouse
management system can trigger an event when a threshold for low item count is reached.
That event can then kick off alerts to re-ordering systems.
Advanced EDA implementations must support complex event processing, in which multiple
related events are aggregated using policy-based rules and a single business event or service
is triggered. iSpheres, a BEA partner, provides an example implementation of this feature. It
is also possible to custom-build this feature using the BEA Platform.
EDA and SOA are complementary architectures. An EDA source can be an SOA consumer
or server application, and an EDA consumer can be an SOA client program. BEA WLI’s
Message Broker, various Event Generators and Adapters, along with BPM, are fully capable
of tying EDA-based and SOA-based implementations together.
SOA is used when a business problem requires a request/response or real-time solution, and
the client knows the service provider ahead of time. EDA is suitable when business requires
one-way messaging, involves long-running asynchronous process, and the event source
doesn’t need to know who the event receivers are.
For the following applications, SOA and Web Services may not be the recommended
architecture:
SOA is a strategic solution with significant tactical applications and benefits; however, there
is a threshold to be passed to get the full benefit of SOA. SOA usually requires analysis of
costs and benefits.
From here, Web Services will be used as the default SOA implementation. Some popular
Web Services patterns are discussed and used in the solution implementation.
Liquid Data uses existing connectivity tools (JDBC drivers, adapters etc.), and provides
access, transformation, joins, cache and security functionality needed by enterprise-class
portal and web applications for accessing multiple data sources.
• Cheaper, better, faster development – an IT developer can write simple queries against a
logical view that hides the complexity of heterogeneous sources, and can automatically
access, transform and join data from multiple sources. Queries are faster to write, easier
to maintain, and can be written by project teams rather than relying on expensive
integration resources.
• IT responsiveness and adaptability - IT can be more responsive to changes in business
requirements because they can easily create or change queries on existing unified views.
• Data consistency across applications and business processes - enables standardized views
of business information across systems.
• Application ease of maintenance - the abstraction layer isolates applications from
changes to underlying data sources. This eliminates the need to modify and test
potentially hundreds of portlets and applications that would have been impacted by
One of the key benefits is the ability to provide a single view of business information (a
single view of customer, product, or trade etc.) in one standard way, significantly reducing
development and operational costs across multiple projects.
WebLogic Portal delivers the first enterprise portal infrastructure for streamlined portal
development. WebLogic Portal is the only enterprise portal platform that also simplifies the
production and management of custom-fit portals (Employee Self Service and Options
Center).
WebLogic Portal allows companies to build portals that combine functionality and resources
into a single interface. It also allows companies to enforce business policies, processes, and
security requirements, and provides personalized views of information to end users. To the
end user, a portal is a Web site with pages that are organized by tabs or some other form of
navigation. Each page may contain nested sub-pages, and does include one or more portlets—
individual windows that display anything from static HTML content to complex Web
Services.
A page can contain multiple portlets, giving users access to different information and tools in
a single place. Users can customize their view of a portal by adding their own pages, adding
the portlets they want to those pages, and changing the look and feel of the interface.
Once you can build Web applications and Web Services with Workshop, you can build any
WebLogic Platform application – including Portals and Integration applications – using the
same simplified Workshop approach of visual development, events, properties, and controls.
o Java Controls hide the J2EE complexity in connecting to any asset, and can be used
in any Workshop application, from Web applications and Web Services to portal and
integration applications.
• Now, with WebLogic Workshop 8.1, developers can create custom Java Controls or use a
host of new Java Controls from BEA partners.
Basic characteristics were described in more detail in 3.2 Characteristics and Benefits of
SOA. Intermediate and Advanced characteristics are explained below.
The current BEA Platform can enable an SOA and support most of the characteristics listed.
While the advanced features can be implemented using BEA Platform, as our services
management product partners are doing, they are not available out of the box.
Complexity Areas
• Departmental
• Typically a single tactical solution for a business problem
Simple • Web Services-based integration and service enablement – basic connectivity to
important resources (mostly services-based data access layer)
(Level 1)
• Provides an Application Platform Suite (Portal, Integration, Messaging) that allows
development of fine-grained and coarse-grained services
• Service-oriented development of applications (SODA)
• Inter-departmental
• Provides a framework for composite application development with more than one
application involved
Medium
• Promotes policy-based computing, policy management/SLA management
(Level 2)
• ESB Support/distributed large deployment support (manage/deploy/administer)
• Registers, discovers, manages, and monitors all shared WS across the enterprise
platform
• Enterprise-wide
• Control & management of large distributed enterprise – agent based/fan-out
technologies
Complex
• Policy-directed command-control fabric/uptime requirements/performance
(Level 3) requirements
• Built in governance models for specific business processes
• Federated management (Level 4, most advanced, globally distributed)
Phase Characteristics
• Initial stages of a long-term SOA plan
• Introduction of a SOA Platform
• 12-24 week projects
Phase 1 • Reusable solution for a tactical problem using SODA for the first time
• Some reuse of services within a business unit
• Quick integration to legacy applications using Web Services
• Data accessed via services
• Additional applications for multiple business units/functions are built-on the Phase 1
SOA platform
• Wider reuse of services among business functions/units
Phase 2 • Visibility into issues of reuse, discovery, publication, duplicate efforts, and policy-
based control of services
• Identification of shared services for security, registration, policy enforcement (QoS,
SLA, routing etc.)
• Many enterprise-wide applications built and deployed on the SOA platform
• Company-wide participation in defining the infrastructure (for interoperability, reuse,
common services)
Phase 3 • Reduce e-business application development and maintenance costs
• Enterprise level discovery, reuse, and publication of services
• Wide sharing of services among business units, partners, and customers
• Policy-based control of services
The recommended path for an enterprise to reach SOA Nirvana follows the green arrow; it
shows that as the project timeline grows, complexity levels can increase.
4.4.3 Integration
This pattern is applicable for providing coarse-grained functionality to service interfaces by
combining a multitude of applications (new, legacy, and packaged), components, processes,
and other services. These pieces are integrated using service composition and process
orchestration software. This pattern uses both of the previous two patterns.
Some of the common Web Services patterns are native web services, web service proxy,
document-centric web services, and orchestration web services.
2. Encourage adoption. It's important to articulate the value and benefits of shared
services to application developers and IT managers throughout a distributed
enterprise to spur adoption. Nobody benefits more in the long term from shared
services than application developers, who can be freed to focus on higher-value
applications. Convince them to leverage shared services first rather than building
redundant functionality, and to build great service interfaces.
3. Get the governance right. Architecture is important, but the gating factor in
realizing a shared services infrastructure is often having the correct IT governance
model. Shared services only work when centralized IT and distributed business units
agree on a federated governance model. The model must give business units the
flexibility to adapt their applications to meet changing needs, and give IT the control
to ensure that these rapidly changing systems meet enterprise reliability, security, and
interoperability standards.
• The number of service calls is related to the amount of information passed during each
call. While fine-grained services take few native type or object parameters, coarse-
grained services take documents as parameters, which contain all the data to complete a
business transaction.
• Coarse-grained services can be created by composing or assembling fine-grained
services; by using methods such as Tuxedo, J2EE EJBs, Servlets, and JDBC; or by
invoking services on back-end systems via an adapter, APIs or Web Services. Composing
coarse-grained services using fine-grained services provides the same benefits as using
SOA for the application. However, that does not mean exposing every single method in
an EJB as a Web Service; that is not required and may not be an appropriate solution. For
example, EJBs can be reused as Controls in WLI and used to compose coarse-grained
services. Making all fine-grained services into Web Services and accessing those services
via a service interface would have performance overhead.
• Choose coarse-grained, document-oriented service to match the higher-level business
process requirement. Fine-grained services can be implemented using Web Services, or
J2EE components, or Controls. Coarse-grained services should be composed using fine-
grained services as much as possible to take advantage of the overall services benefits. It
is also recommended that a services management layer is applied for coarse-grained as
well as fine-grained services.
• Synchronous service calls should be used when an immediate response is required and
the consumer is waiting for the response for a predetermined period. For this model to be
successful, the service provider should be implemented to respond in real time for the
maximum request loads. Also the service should always be available. As the synchronous
model is implemented to handle predetermined loads, it is not capable of handling
unexpected higher-priority requests. The server needs to be designed to handle all the
requests simultaneously. If the service provider starts to respond more slowly, it will be
unable to accept additional consumers. Such characteristics can be implemented by
service management policies or using server virtualization techniques.
• In the asynchronous model, consumers send requests to the server and continue to do
other processing. The server returns the response whenever it completes the service, and
the elapsed time depends on the server’s load. The server should be implemented to
queue the maximum expected number of requests, and it need not process all the service
requests simultaneously.
• If high-volume service requests are expected and the server can only handle a limited
number of services simultaneously, then asynchronous service invocation is
recommended. Asynchronous service can be easily scaled up or down by adjusting the
request queue length.
• If real-time response is required, then the synchronous model is the obvious choice.
However, the system should be implemented to handle a predetermined number of
service requests. Adding more servers is the only way to scale up this implementation.
• In most composite services, numerous applications will be involved. It is almost
impossible to guarantee request/response between many applications in a synchronous
service call. In such cases, asynchronous publish/subscribe or point-to-point messaging
model guarantees delivery of messages and responses between multiple applications.
• The asynchronous service invocation model is best suited for highly reliable, coarse-
grained, document-oriented services. Synchronous service invocation is more suited for
fine-grained, lightweight service calls. One drawback of asynchronous messaging is that
the response order may not match the request order.
WebLogic Platform is capable of supporting both synchronous and asynchronous service call
models. Synchronous Web service calls use SOAP over HTTP, and the asynchronous model
uses SOAP over JMS. WebLogic Integration supports synchronous, asynchronous and WS-
Acknowledgement service invocation models.
• Services that are useful to more than one application can be reused by being identified,
implemented, and published. Reusable services can be identified by finding commonly
used services, and must be implemented with special consideration for reuse. But
o Provides a Portal for communication within the organization and a services catalog.
• Use SOA for evolutionary growth of agile IT. Related benefits of SOA are incremental
development and deployment of business applications, reuse of business components in
multiple experiences, and low-cost assembly of some new business processes.
• Plan for shared infrastructure cost recovery, metering and charging for services.
• Fund shared services infrastructure, remembering that ROI is realized in the long-term
rather than in the short-term. SOA is strategic solution with solution realization for
tactical problems. Business units share the infrastructure and leverage common
investments.
• Implement data services early.
• Use a business service perspective for selecting and implementing coarse-grained
services. Business processes with high maintenance and operational costs are ideal
candidates for the benefits of SOA.
• Follow the recommended implementation path shown in the SOA Project Type Matrix:
start small with a pragmatic use case, plan ahead, grow SOA infrastructure, and add
applications/projects in an evolutionary approach.
• The network-centric, policy-based, distributed nature of SOA-based applications requires
IT support and operations groups to understand the differences between traditional
applications and SOA-based applications. Support and operations groups need to
understand and learn the new administrative tools for the SOA platform and services
management vendor products.
6.3.1 Assumptions
SOA is the long term strategic solution for the enterprise Many more enterprise-wide
applications will be deployed using the shared SOA infrastructure.
5. Wrap legacy and custom applications as services and define their interfaces.
6. Identify, define, and implement common services such as logging, security, data
transformation, and encryption.
9. Implement application and shared services identified above, and test in development
and staging environments.
10. Plan for application deployment. The shared services layer and application layer can
be deployed in separate servers or on the same server. Deployment planning should
consider the following: high-availability of services, service virtualization using load
balancers, performance requirements and server capabilities.
Non-functional requirements determine application architecture. Here are the most common
non-functional requirements (NFR) for a software application:
• Security
• Scalability
• Performance
• Manageability
• High availability
• Extensibility
• Flexibility
The BEA Platform satisfies almost all of the above architecture requirements.
• Loose coupling
• Dynamic discovery of services
• Availability of services as needed
• Policy-based control of services
The required solution is a data access portal with multiple data sources. BEA’s Portal and
Liquid Data products provide the features required to implement this solution.
BEA Liquid Data provides Control and Web Services-based conceptual data access to Portal.
Back-end data resources are accessed by Liquid Data, using JDBC for databases and Web
Services for the custom application.
Note that the requirements do not require data updates from the Portal. The proposed high-
level Web Services-based solution for these requirements is shown in this diagram.
7.2 CHALLENGES
Overall the enterprise lacks agility and is unable to keep up with growing and dynamic
business needs. Key challenges faced by this organization are:
7.3 REQUIREMENTS
In order to resolve these challenges and make the enterprise IT more agile, the enterprise
chose SOA as their strategic IT solution. In order to resolve their application needs and to
enable SOA, the enterprise listed the following requirements:
Unlike the previous simple example, this implementation is for a very large enterprise with
many applications and numerous challenges. This enterprise has chosen SOA and Portal-
based UI as their strategic solution. These considerations have been accounted for by
prescribing the following steps:
2. The COE should draw the current enterprise architecture and list business processes
and use cases.
3. Using BEA’s SteelThread methodology, determine the best use case for pilot SOA-
based application implementation. The SteelThread methodology identifies the use
case that covers more depth (end-to-end, complex) than functionality. The remainder
of the steps apply to the selected business processes and their use cases.
4. Identify enterprise systems and applications that need to be integrated and determine
how they will provide service-oriented integration.
7. Collect and define common services and specify policies for enforcement.
10. As this enterprise’s applications are accessed from both inside and outside the
firewall, it requires both agent-based and gateway (fabric) based Web Services
management solutions.
13. Plan for application deployment. The shared services layer and the application layer
can be deployed on separate servers or the same server. Deployment planning should
consider the following: high availability of services, service virtualization using load
balancers, performance requirements, and server capabilities. In addition, use of a
WSM product or fabric in the solution requires planning for their deployment, and
integrating those products with the network infrastructure and application platform.
7.5 IMPLEMENTATION
The previous section describes the steps for reaching the solution; this section describes the
solution architecture. The required solution is an enterprise SOA with multiple applications
and back-end systems. BEA Platform provides all basic features required to implement this
solution.
Here are the most common non-functional requirements (NFR) for a software application:
• Security
• Scalability
• Performance
• Manageability
• High availability
• Extensibility
• Flexibility
The BEA Platform satisfies almost all of the above architecture requirements.
• Loose coupling
• Dynamic discovery of services
• Availability of services as needed
• Policy-based control of services
JDBC and Controls calls are not going through WSM components. As per best practices, not
all component integration needs to go through a WSM component if the components are not
all Web Services-based. Other interconnection protocols are Java RMI, JDBC, and Adapters
(native EIS protocols). The next figure shows the proposed high-level Web Services-based
solution for these requirements.
SOA has many benefits, due to its flexibility and policy-based computing. By the same
token, it increases the responsibility of the OA&M staff, because they have to manage
additional components, servers, and policies related to SOA (WSM). The following sections
discuss deployment and OA&M from the SOA perspective.
8.1 DEPLOYMENT
The choice of deployment model depends on the network architecture, and on how, logically
and physically, applications and operations and management need to be separated. This is
typically dictated by an organization’s IT policies. BEA provides the flexibility of co-
deployment or separate deployment, so it is possible to choose any deployment model to
support the IT policies.
Separate applications by tiers (presentation, integration, process, and data) and separate
applications from administration and management. This gives the best control and flexibility,
but additional hardware servers and software licenses do add cost. Use of WSM products
increases the number of components that need to be deployed in the same server, or the
number of servers that need be managed.
Coarse-grained service. A service that implements more functionality and returns more data
than a fine-grained service, for example, Create New Customer.
Composite service. A service that implements an entire business function by calling other
services, which may be fine-grained or coarse-grained, for example, Provision New DSL
Line.
Data access service. A service that accesses data, which may reside in a legacy or other
custom system, and provides a uniform API and loose coupling for that access.
Portal. A Web site providing a single, unified point of access for varied applications and
information. Access to portals and their associated resources is dictated by the user’s role,
allowing administrators to easily manage the site’s contents.
Project complexity. In this document, the technical complexity of a project, where 1 is the
simplest and 3 the most complex. A project with complexity level 1 would be a departmental
project with a single application, and complexity level 3 would indicate an enterprise-wide
project with multiple heterogeneous applications.
Project phase. In this document, the growth over time of a project, where phase 1 is the
earliest and simplest and phase 3 is the latest and most complex. A project in phase 1 might
be in the initial stages of implementing a long-term SOA plan, with some rapid integration
QoS – Quality of Service. A requested level of service from a function or application; for
example, in a networking application, QoS values might be exactly-once, at-most-once, and
duplicate-okay.
SLA – Service Level Assurance or Agreement. A contract between a service provider and
a consumer that states what services will be provided, and in what timeframe, by the
provider.
Service. A well-defined, self-contained function that does not rely on context from other
functions. In a WebLogic Integration environment, a service is a named business function
within an Enterprise Information System (EIS), implemented in terms of interactions
provided by the adapter for the EIS. Services provide a communication mechanism to an
EIS.
In a WebLogic Portal environment, a service may be data processing and storage, data
interchange, or data presentation provided by a Web application. For example, a service
called Shipping may perform three functions: it records the shipping information related to a
customer's order; it calculates shipping costs; and it tracks the shipping status of the order.
Service provider. A service that advertises itself, publishing its offered services, generally
through a service broker, and performs services for consumers. A service provider can also
be a service consumer.
Service broker. A program that takes and retains information about provided services, their
locations and how to call them, and routes requests from consumers to the correct providers.
SOAP (Simple Object Access Protocol). Set of standard rules for formatting an XML
message so that it can be interpreted by different Web services.
Synchronous. An attribute of a service; a caller to a synchronous service must wait for the
called service to return before continuing: the caller is synchronized with the service. See
also asynchronous.