SOA y el Business Process

Execution Language (BPEL)

Implementación de Procesos

Modelamiento de Procesos

Implementación de Procesos

¿ Es necesario un cambio de paradigma ?

Muchos Programadores, pocos Ingenieros
de Software
• La industria del software tiene problemas para llenar
sus vacantes !
• El sistema educacional actual prepara muy buenos
programados pero pocos buenos ingenieros de
software
• Hay que ser un buen programador antes de ser un
buen ingeniero de software
• El paradigma Service-oriented computing tiene como
meta separar claramente ambas funciones
 SOA y SOC
• El paradigma de la computación orientada a servicios se
refiere al conjunto de conceptos, principios, y métodos
que representan en la informática al Service-Oriented
Architecture (SOA) en la cual las aplicaciones se
construyen sobre la base de componente de servicios
independientes con interfaces estándar.
• La idea principal del SOC / SOA es la ingeniería de
software explícitamente separada de la programación,
de modo de hacer hincapié en la ingeniería de software,
para restarle importancia a la programación. SOC separa
de desarrollo de software en tres partes independientes
 Los actores
• Service providers: They use a traditional a programming language
such as Java, C++, or C# to write program components. All
components will be wrapped with open standard interfaces, call
services, or Web services if the services are available over the
internet, so that application builders can simply use the services
without further communication with the service providers. The
same services can be used by many applications.
• Service brokers: Allow services to be registered and published for
public access. Help application builders to find services they need.
• Application builders: Instead of constructing software from
scratch using basic programming language constructs, the
application builders represent the end users to specify the
application logic in a high-level specification language, using
standard services as components. Application builders are
software engineers who have a good understand of software
architecture and the application domain.
 Quien usa SOA y SOC
• Las grandes compañias de Software: BEA, IBM, Microsoft,
Oracle, HP, SAP, Intel, Sisco, Sun Microsystems han migrado al
pardigma SOC
• Agencias Gubernamentales: Dpet. Defensa de USA, SIS Chile,
NASA
• Bancos: (Web Banking Services) comercio (web Shopping
Services) aerolineas (Web Booking Services)…
• http://www.sciencedaily.com/releases/2009/03/0903311335
35.htm
• http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&ti
d=11752
 Services
• The service-oriented computing (SOC) paradigm uses
services to support the development of rapid, low-
cost, interoperable, evolvable, and massively
distributed applications.
• Services are autonomous, platform-independent
entities that can be described, published, discovered,
and loosely coupled in novel ways.
• They perform functions that range from answering
simple requests to executing sophisticated business
processes requiring peer-to-peer relationships
among multiple layers of service consumers and
providers.
• Any piece of code and any application component
deployed on a system can be reused and
transformed into a network-available service.
 SOC y Web Services
• Services reflect a “service-oriented” approach to
programming that is based on the idea of composing
applications by discovering and invoking network-
available services to accomplish some task.
• This approach is independent of specific
programming languages or operating systems.
 What is a Web service?
• Without prejudice toward other definitions, we
will use the following definition:
• [Definition: A Web service is a software system
designed to support interoperable machine-to-
machine interaction over a network. It has an
interface described in a machine-processable format
(specifically WSDL). Other systems interact with the
Web service in a manner prescribed by its description
using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other
Web-related standards.]
 Agents and Services
• A Web service is an abstract notion that must be
implemented by a concrete agent. The agent is the
concrete piece of software or hardware that sends and
receives messages, while the service is the resource
characterized by the abstract set of functionality that is
provided.
• To illustrate this distinction, you might implement a
particular Web service using one agent one day
(perhaps written in one programming language), and a
different agent the next day (perhaps written in a
different programming language) with the same
functionality. Although the agent may have changed,
the Web service remains the same.
Esquema de los Web Services
 Requesters and Providers
•The purpose of a Web service is to provide some functionality on
behalf of its owner -- a person or organization , such as a business
or an individual.
•The provider entity is the person or organization that provides an
appropriate agent to implement a particular service.
•A requester entity is a person or organization that wishes to make
use of a provider entity’s Web service. It will use a requester agent
to exchange messages with the provider entity’s provider agent.
•In most cases, the requester agent is the one to initiate this
message exchange, though not always.
•Nonetheless, for consistency we still use the term "requester
agent" for the agent that interacts with the provider agent, even in
cases when the provider agent actually initiates the exchange.
 Service Description
• The mechanics of the message exchange are documented in a Web
service description (WSD).
• The WSD is a machine-processable specification of the Web
service’s interface, written in WSDL.
• It defines the message formats, data types, transport protocols, and
transport serialization formats that should be used between the
requester agent and the provider agent.
• It also specifies one or more network locations at which a provider
agent can be invoked, and may provide some information about the
message exchange pattern that is expected.
• In essence, the service description represents an agreement
governing the mechanics of interacting with that service.
 Semantics
• The semantics of a Web service is the shared expectation about the
behavior of the service, in particular in response to messages that
are sent to it.
• In effect, this is the "contract" between the requester entity and
the provider entity regarding the purpose and consequences of the
interaction.
• Although this contract represents the overall agreement between
the requester entity and the provider entity on how and why their
respective agents will interact, it is not necessarily written or
explicitly negotiated.
• It may be explicit or implicit, oral or written, machine processable
or human oriented, and it may be a legal agreement or an informal
(non-legal)
 Overview of Engaging a Web Service
• There are many ways that a requester entity might engage and use
a Web service.
• In general, the following broad steps are required,
– (1) the requester and provider entities become known to each other (or
at least one becomes know to the other);
– (2) the requester and provider entities somehow agree on the service
description and semantics that will govern the interaction between the
requester and provider agents;
– (3) the service description and semantics are realized by the requester and
provider agents; and
– (4) the requester and provider agents exchange messages, thus
performing some task on behalf of the requester and provider entities.
• Some of these steps may be automated, others may be performed
manually.
 Web Services
• Web services are currently the most promising SOC based
technology
• They use the Internet as the communication medium and
open Internet-based standards including
– Simple Object Access Protocol (SOAP) for transmitting data,
– Web Services Description Language (WSDL) for defining services,
– Business Process Execution Language for Web Services (BPEL4WS) for
orchestrating services.
• SOC lets developers dynamically grow application portfolios
more quickly than ever before (?!!!) by
– creating compound solutions that use internal organizational software
assets, including enterprise informationand legacy systems, and
– combining these solutions with external components possibly residing
in remote networks.
 El caso de problema de desarrollo
• La tarea de programación consiste en el
desarrollo de un sistema online para una
tienda de libros que toma órdenes de clientes,
procesa esas órdenes y emite el cargo usando
los servicios que ofrecen los bancos remotos.
Si se logra realizar el cargo entonces el libro
será pedido a la editorial respectiva y enviado
al cliente.
Esquema de solución SOC
 SOC Solution
• It is very difficult to program such a system from scratch using
C++ or Java. However, if all the components can be found in
the service repository, the development task in SOC would be
simple. What an application builder would have to do is (1)
draw the model ; (2) provide a text file containing the data to
be changed between the services, for example, the data
behind the message "getOrder" must contain the client's
name, address, credit card information; (3) define the logic
and flow (for example, in the nod "processOrder", we need to
define the order: first place the charge, wait for the result of
the operation; if the charge is successful, accept the order,
otherwise, reject the order).
 Elementos de un Modelo
• Actor: An actor is a model element that represents a system or a component with
clear boundary that interacts with other actors. An actor is implemented as a
service agent that can reside locally or remotely.
• Action: An action is a model element that represents an operational process to
change internal status of an actor.
• Attribute: An attribute is defined to provide security, safety, performance, timing
or reliability information. An attribute can be associated with any model element.
• Condition: A condition is a predicate on data elements used to determine the
course of a process taken by actors.
• Data: A data element is an information carrier that represents the internal status
of an actor.
• Event: An event is a model element that represents an observable occurrence with
no time duration of input to an actor or output from an actor.
• Relation: A relation is defined to provide relationship information between any
model elements. There are different relations defined between any two model
elements.
 Actores
• Client: It is the interface between the end user and the system. It takes the
end user’s order and sends the order to the actor: Bookstore. The order
contains the book information to be ordered and the credit card
information of the end user.

• Bookstore: It is the main actor we focus on in this example. It sends

charge message to the bank actor, which contains the credit card
information and the amount of charge. Depends on the return message
from the bank, the bookstore actor will either reject the order or ask the
publisher actor to deliver the book. Once it receives the delivery
confirmation from the publisher, it notifies the client.

• Bank: It charges the credit. It returns the failure message if the charge
fails, otherwise, it confirm the completion of charge.

• Publisher: It receives the order from the bookstore and requests its
shipper to deliver the book. Once the book is shipped, it returns the
confirmation to the bookstore.

• Parcel service: It receives the shipping request from the publisher, ships
the book, and confirms the shipment.
Condiciones y Datos
Condition in the actor bookstore
(in this example, we discuss the
bookstore actor only). One
condition is defined: ChargeFail,
it is false if the bank confirms
charge, otherwise, it is true.

Data in bookstore actor: Data

item from the client: (book
detail, credit card detail, deliver
address). Data to bank actor:
(credit card detail, amount to
charge); Data to publisher: (book
detail, deliver address). Data
to client: (rejection) or
(confirmation).
WSDL
 What is WSDL?
• WSDL stands for Web Services Description
Language
• WSDL is written in XML
• WSDL is an XML document
• WSDL is used to describe Web services
• WSDL is also used to locate Web services
• WSDL is a W3C recommendation
 The WSDL Document Structure
Element Defines

<types> The data types used by the web service

<message> The messages used by the web service

<portType> The operations performed by the web service

<binding> The communication protocols used by the web service

 Un documento WSDL
<definitions>
A WSDL document can also
<types>
definition of types........ contain other elements,
</types> like extension elements,
<message> and a service element
definition of a message....
</message> that makes it possible to
<portType>
group together the
definition of a port....... definitions of several
</portType>
web services in one
<binding> single WSDL document.
definition of a binding....
</binding>
</definitions>
 Ejemplo de un WSDL
<message name="getTermRequest"> In this example the <portType> element
<part name="term" type="xs:string"/> defines "glossaryTerms" as the name of a
</message> port, and "getTerm" as the name of an
operation.
<message name="getTermResponse“ The "getTerm" operation has an input
<part name="value" type="xs:string"/> message called "getTermRequest" and an
</message> output message called "getTermResponse".
The <message> elements define the parts
of each message and the associated data
<portType name="glossaryTerms">
types.
<operation name="getTerm"> Compared to traditional programming,
<input message="getTermRequest"/> glossaryTerms is a function library,
<output message="getTermResponse"/> "getTerm" is a function with
</operation> "getTermRequest" as the input parameter,
</portType> and getTermResponse as the return
parameter.
UDDI
 What is UDDI
• UDDI is a platform-independent framework for
describing services, discovering businesses, and
integrating business services by using the Internet.
• UDDI stands for Universal Description, Discovery and
Integration
• UDDI is a directory for storing information about web
services
• UDDI is a directory of web service interfaces
described by WSDL
• UDDI communicates via SOAP
 UDDI Benefits
• Any industry or businesses of all sizes can
benefit from UDDI.
• Before UDDI, there was no Internet standard
for businesses to reach their customers and
partners with information about their
products and services. Nor was there a
method of how to integrate into each other's
systems and processes.
•
 UDDI Benefits
• Problems the UDDI specification can help to solve:
– Making it possible to discover the right business from the millions
currently online
– Defining how to enable commerce once the preferred business is
discovered
– Reaching new customers and increasing access to current customers
– Expanding offerings and extending market reach
– Solving customer-driven need to remove barriers to allow for rapid
participation in the global Internet economy
– Describing services and business processes programmatically in a
single, open, and secure environment
 How can UDDI be Used
• If the industry published an UDDI standard for
flight rate checking and reservation, airlines
could register their services into an UDDI
directory. Travel agencies could then search
the UDDI directory to find the airline's
reservation interface. When the interface is
found, the travel agency can communicate
with the service immediately because it uses a
well-defined reservation interface.
SOAP
 What is SOAP?
• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP communicates via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C recommendation
 SOAP Building Blocks
• A SOAP message is an ordinary XML document
containing the following elements:
– An Envelope element that identifies the XML
document as a SOAP message
– A Header element that contains header
information
– A Body element that contains call and response
information
– A Fault element containing errors and status
information
 Syntax Rules
• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP
Envelope namespace
• A SOAP message MUST use the SOAP
Encoding namespace
• A SOAP message must NOT contain a DTD
reference
• A SOAP message must NOT contain XML
Processing Instructions
 Skeleton SOAP Message
• <?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
 Business Process Execution Language
(BPEL)
• El Business Process Execution Language (BPEL) es un languaje
basado en XML para modelar business processes que fue
introducido el año 2002 por IBM, BEA Systems y Microsoft
• Se usa para describir orquestaciones y coreografías de web
services
• La Orquestación de Servicios Web define qué orden se deben
de ejecutar las funciones del proceso (visión interna de los
procesos de negocio).
• La Coreografía de servicios Web a su vez define la interacción
entre los servicios Web (vista externa de los procesos de
negocio).
• La coreografía de servicios Web describe así el intercambio de
mensajes la interacción de varias partes interesadas.
 Business Processes Modelling con
BEPL
• WS-BPEL define una gramática para la
descripción del comportamiento de un proceso
de negocio basado en la interacción entre el
proceso y sus socios (webservices)
• Se describe las coordinación deseada entre las
interacciones de los servicios entre los distintos
partners
• Un proceso se considera como un conjunto de
interacciones de Web Wervices coordinadas
entre ellas
 Actividades Básicas
• Son actividades atómicas que no estan
constituidas por otras actividades

Nombre Explicación

assign Asignación de valores a variables

invoke Invocación síncrona (del tipo request/response) de un Webservice
receive/reply Ofrecimiento de una interfaz a un Webservice síncrona o asíncrona
throw Indicación explicia de un error
terminate El procesamiento de una actividad debe ser terminado
wait Un proceso debe esterar un lapso de tiempo
empty Ejecución de una actividad vacía (no hacer nada)
por ejemplo, cuando se encuentra un error
 Actividades Estructurales
• Contienen (recursivamente) otras actividades

Nombre Explicación

sequence Contiene actividades que deben ejecutarse secuencialmente

while Las actividades deben ejecutarse mientras se cumpla una
condición lógica
switch Ejecusción condicionada de actividades (distinción de casos)
for each En un ciclo tienen que ser recorridos todos los elementos
(por ejemplo, de un arreglo o un conjunto)
flow Las actividades pueden ser ejecutadas en paralelo o en cualquier orden
pick Similar a la distinción de casos switch, pero aquí se espera a un
evento externo (por ejemplo, a la llegada de un mensaje, un instate de
tiempo o el término de un período de tiempo)
Ejemplo

Asignación
de roles

Asignación
de variables
Ejemplo (cont.)
Tratamiento
de errores

Control de flujo