web services technology by ronaldtamarind

VIEWS: 22 PAGES: 10

More Info
									                                        UNIT – 4

WEB SERVICES TECHNOLOGIES & OTHER TECHNOLOGY
       Web services and SOE: the key idea behind SOE (service oriented enterprise) is: a view of
                                                                                                                1
       the enterprise in which everything is seems in terms of services and their interactions and
       interdependencies, providing consistency and simplicity everywhere, and creating new space for agility
       and innovation in enterprise.
        Everything in enterprise is service. Everything enterprise does is service, Everything enterprise delivers
        is service-even products are service. Enterprise itself is service, everything is service.
        Enterprise is any kind of entity “supporting a defined business scope & mission” within which the
        various members or components “must coordinate their functions and share information” to achieve the
        purpose. the enterprise might be a commercial business. It might be government or non-profit, local
        football club.
        An enterprise may be subset or superset of the organization. an IT dept is also an enterprise in its own
        right.
                      Service-Oriented Enterprise Architecture:
 Enterprise Architecture is a discipline through which an enterprise can identify, develop and maintain its
knowledge of its purpose, its structure & itself. Enterprise Architecture identifies and monitors the structures
needed to support that shared mission, it assists in managing change, & responses to change, It provides
guidance & consistency across the whole scope. Continuing globalization, the economic downturn, mergers and
acquisitions, and changing customer demands are forcing enterprises to rethink and restructure their business
models and organizational structures. New products and services need to be developed and delivered better,
faster and cheaper due to increasing international competition. Therefore, enterprises have to be increasingly
efficient, flexible and innovative to be successful. In order to manage all these changes and stay competitive,
enterprises have started to develop
Enterprise architectures. These bring together all architectures modeling specific aspects of an enterprise.
         Scope of Architecture: Enterprise Architecture associated with IT. With each new stage of
         maturity, the scope has needed to expand further from low-level technology and interface to structures
         for data & application and then to a somewhat belated recognition that all of this needed to be linked to
         and driven from business strategy.
                                    IT architecture hierarchy


                                   Business architecture



                             Data                  Application
                             architecture        architecture

                                  Technology architecture
                                                                                                       2
                                  (purpose)

                                  Business architecture



            People system         Information knowledge             Machine system
            architecture          architecture                      architecture



            Manual process        Information process detail        Machine process detail
            detail architecture   architecture                      architecture



                   People                 Knowledge                         things


                            Whole of enterprise structure

The scope of enterprise architecture is always the whole of the enterprise –the enterprise as a whole.
Enterprise architecture is important because organizations need to adapt increasingly fast to changing
customer requirements and business goals. This need influences the entire chain of activities of an
enterprise, from business processes to IT support. Moreover, a change in one architecture may influence
other architectures. For example, when a new product is introduced, someone should be made
responsible for it, and business processes for production, sales and after-sales need to be adapted. It
might be necessary to change applications, or even adapt the IT infrastructure. To keep the enterprise
architecture coherent, the relations between the different types of architecture must be clear, and a
change should be carried through methodically in all architectures
        Frameworks: In order to define the field and determine the scope of enterprise architecture
       both researchers and practitioners have produced a number of .architecture frameworks..
       Frameworks provide structure to the architectural descriptions by identifying and sometimes
       relating different architectural domains and the modelling techniques associated with them.
       Well-known examples of architectural frameworks are:
   Zachman.s .framework for enterprise architecture: The Zachman framework is widely known
    and used. The framework is a logical structure for classifying and organising the representations of
    an enterprise architecture that are significant to its stakeholders. It identifies 36 views on
    architecture (.cells.), based on six levels (scope, enterprise, logical system, technology, detailed
    representations and functioning enterprise) and six aspects (data, function, network, people, time,
    motivation).
   The Reference Model for Open Distributed Processing (RM-ODP) is an ISO/ITU Standard
    (ITU, 1996) which defines a framework for architecture specification of large distributed systems. It
    identifies five viewpoints on a system and its environment: enterprise, information, computation,
    engineering and technology.
   The architectural framework of The Open Group (TOGAF) is completely incorporated in the
    TOGAF methodology (http://www.opengroup.org/architecture/togaf8/index8.htm). TOGAF has
                                                                                                               3
            four main components, one of which is a high-level framework defining three views: Business
            Architecture, Information System Architecture and Technology Architecture.
           Jonkers’s frameworks This framework, uses just three layers and three aspects. The layers .
            business, application and technology . roughly correspond to the enterprise, logical system and
            technology levels in the Zachman framework. The aspects . structure, behaviour and information .
            correspond to the network, function and data aspects in the Zachman framework.


                Methodology: An architecture method is a structured collection of techniques and process
                steps for creating and maintaining an enterprise architecture. Methods typically specify the
                various phases of an Architecture’s lifecycle, what deliverables should be produced at each
                stage, and how they are verified or tested. The following methods for architecture development
                are worth mentioning:
__ Although meant for software development, the Rational Unified Process (RUP) (Jacobsonet al., 1999) is of
interest here, as it defines an iterative process, as opposed to the classical waterfall process, that realises
software by adding functionality to the architecture at each increment.
__ The UN/CEFACT Modelling Methodology (UMM) is an incremental business process and information
model construction methodology. The scope is intentionally restricted to business operations, omitting
technology specific aspects. T
---MEMO (Frank, 2002) is a method for enterprise modelling that offers a set of specialized visual
modelling languages together with a process model as well as techniques and heuristics to support problem
specific analysis and design. The languages allow the modelling of various interrelated aspects of an enterprise.


      Technical Architecture Framework for Information Management (TAFIM)
      Architecture Development Method (ADM)
      Federal Enterprise Architecture Framework (FEAF)
      Business Collaboration Framework (BCF)




   WS-Coordination (Web Services Coordination)
WS-Coordination (Web Services Coordination) is a proposed IT industry standard for how individual Web
services can interact in order to accomplish an application task. WS-Coordination is one of a series of
specifications from an industry group that includes IBM, Microsoft, and BEA Systems.
    This specification defines an extensible framework for coordinating activities using a coordinator and set of
coordination protocols. This framework enables participants to reach consistent agreement on the outcome of
distributed activities. The coordination protocols that can be defined in this framework can accommodate a wide
variety of activities, including protocols for simple short-lived operations and protocols for complex long-lived
business activities. Additionally WS-Coordination describes a definition of the structure of context and the
requirements for propagating context between cooperating services.
Note that the use of the coordination framework is not restricted to transaction processing systems; a wide
variety of protocols can be defined for distributed applications.
However, this specification isn't enough to coordinate transactions among web services. It only provides a
coordination framework, and other specifications like WS-Atomic Transaction or WS-BusinessActivity are
needed for this purpose.
                                                                                                                4
               The Model
This specification describes a framework for a coordination service (or coordinator) which consists of these
component services:
• An Activation service with an operation that enables an application to create a coordination instance or
   context.
• A Registration service with an operation that enables an application to register for coordination
    protocols.
• A coordination type-specific set of coordination protocol.




Applications use the Activation service to create the coordination context for an activity. Once a coordination
context is acquired by an application, it is then sent by whatever appropriate means to another application.
The context contains the necessary information to register into the activity specifying the coordination behavior
that the application will follow.
Additionally, an application that receives a coordination context may use the Registration service of the original
application or may use one that is specified by an interposing, trusted coordinator. In this manner an arbitrary
collection of Web services may coordinate their joint operation.

               Extensibility
The specification provides for extensibility and flexibility along two dimensions. The framework allows for:
• The publication of new coordination protocols.
• The selection of a protocol from a coordination type and the definition of extension elements that can be
   added to protocols and message flows.

               Coordination Service
The Coordination service (or coordinator) is an aggregation of the following services:
• Activation service:       Defines a Create Coordination Context operation that allows a Coordination Context to
    be created. The exact semantics are defined in the specification that defines the coordination type. The
    Coordination service MAY support the Activation service. i.e. The Activation service creates a new activity
    and returns its coordination context
• Registration service: Defines a Register operation that allows a Web service to register to participate in a
    coordination protocol. The Coordination service MUST support the Registration service. Once an
    application has a coordination context from its chosen coordinator, it can register for the activity. The
    interface provided to an application registering for an activity and for an interposed coordinator registering
    for an activity is the same.
• A set of coordination protocol services for each supported coordination type. These are defined in the
    specification that defines the coordination type.
                                                                                                           5

                                                   Fig:2


Figure 3 illustrates how two application services (App1 and App2) with their own coordinators
(CoordinatorA and CoordinatorB) interact as the activity propagates between them. The protocol Y and
services Ya and Yb are specific to a coordination type, which are not defined in this specification.
1. App1 sends a CreateCoordinationContext for coordination type Q, getting back a Context Ca that
contains the activity identifier A1, the coordination type Q and an Endpoint Reference to CoordinatorA's
Registration service RSa.
2. App1 then sends an application message to App2 containing the Context Ca.
3. App2 prefers CoordinatorB, so it uses CreateCoordinationContext with Ca as an input to interpose
    CoordinatorB. CoordinatorB creates its own CoordinationContext Cb that contains the same activity
    identifier and coordination type as Ca but with its own Registration service RSb.
4. App2 determines the coordination protocols supported by the coordination type Q and then Registers
    for a coordination protocol Y at CoordinatorB, exchanging Endpoint References for App2 and the
    protocol service Yb. This forms a logical connection between these Endpoint References that the
    protocol Y can use.
5. This registration causes CoordinatorB to forward the registration onto CoordinatorA's Registration
    service RSa, exchanging Endpoint References for Yb and the protocol service Ya. This forms a logical
    connection between these Endpoint References that the protocol Y can use.


Figure 3: Two applications with their own coordinators
                                                                                                            6
CoordinationContext: Contains the activity identifier, its coordination type that represents the collection
of behaviors supported by the activity and a Registration service Endpoint Reference that participants can
use to register for one or more of the protocols supported by that activity's coordination type.
Coordination protocol: The definition of the coordination behavior and the messages exchanged
between the coordinator and a participant playing a specific role within a coordination type. WSDL
definitions are provided, along with sequencing rules for the messages. The definition of coordination
protocols are provided in additional specification (e.g., WS-AtomicTransaction).
Coordination type: A defined set of coordination behaviors, including how the service accepts context
creations and coordination protocol registrations, and drives the coordination protocols associated with the
activity.
Coordination service (or Coordinator): This service consists of an activation service, a registration
service, and a set of coordination protocol services.
Participant: A service that is carrying out a computation within the activity. A participant receives the
CoordinationContext and can use it to register for coordination protocols.
Web service: A Web service is a computational service, accessible via messages of definite,
programming-language-neutral and platform-neutral format, and which has no special presumption that
the results of the computation are used primarily for display by a user-agent.



                                           WS-Transaction
   WS-Transaction - a Web Services specification developed by BEA Systems, IBM, and Microsoft. The WS-
   Transaction specification describes coordination types that are used with the extensible coordination
   framework described in the WS-Coordination specification. It defines two coordination types: Atomic
   Transaction (AT) for individual operations and Business Activity (BA) for long running transactions.
   Developers can use either or both of these coordination types when building applications that require
   consistent agreement on the outcome of distributed activities.
   The WS-Transaction interface defines what constitutes a transaction and what will determine when it has
   completed successfully. Each transaction is part of an overall set of activities that constitute a business
   process that is performed by cooperating Web services. The WS-Transaction specification is an
   activity of the Web Service Interoperability Organization (WS-I Organization) which is
   an industry-wide effort at standardizing how Web services are requested and
   delivered.

              WS-AtomicTransaction: This specification provides the definition of the atomic
              transaction coordination type that is to be used with the extensible coordination framework
              described in the WS-Coordination specification. The specification defines three specific
              agreement coordination protocols for the atomic transaction coordination type: completion,
              volatile two-phase commit, and durable two-phase commit. Developers can use any or all of
              these protocols when building applications that require consistent agreement on the outcome of
              short-lived distributed activities that have the all-or-nothing property.

          WS-BusinessActivity: This specification provides the definition of the business activity
          coordination type that is to be used with the extensible coordination framework described in the WS-
          Coordination specification. The specification defines two specific agreement coordination protocols
          for the business activity coordination type: BusinessAgreementWithParticipantCompletion and
          BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols
          when building applications that require consistent agreement on the outcome of long-running
          distributed activities.
           WS-Transaction Architecture
 WS-Transaction distnguishes the transaction-aware web service in its role executing business-logic, from the
web service acting as a participant in the transaction, communicating with and responding to its transaction
coordinator. Transaction-aware web services deal with application clients using business-level protocols, while
the participant handles the underlying WS-Transaction protocols
                                                                                                                 7



                                     WS-Transaction Global View

A transaction-aware web service encapsulates the business logic or work that needs to be conducted within the
scope of a transaction. This work cannot be confirmed by the application unless the transaction also commits.
Thus, control is ultimately removed from the application and given to the transaction.
 The participant is the entity that, under the dictates of the transaction coordinator, controls the outcome of the
work performed by the transaction-aware Web service. In Figure “WS-Transaction Global View”, each web
service is shown with one associated participant that manages the transaction protocol messages on behalf of its
web service. Figure “WS-Transaction Web Services and Participants”, however, shows a close-up view of a
single web service, and a client application with their associated participants.




                               WS-Transaction Web Services and Participants
                                                                                                                  8
The transaction-aware web service employs a back end database accessed via a JDBC driver, which sends SQL
statements to the database for processing. However, those statements should only commit if the enclosing web
service transaction does. For this to work, the web service must employ transaction bridging. Transaction
bridging registers a participant with the coordinator for the web service transaction and creates a matching XA
transaction within which it can invoke the driver to make tentative changes to the database. The web service
ensures that service requests associated with a specific web service transaction are executed in the scope of the
corresponding XA transaction, grouping changes common to a given transaction while isolating changes
belonging to different transactions. The participant responds to prepare, commit, or rollback requests associated
from the web service transaction coordinator by forwarding the same operations to the underlying XA
transaction coordinator, ensuring that the local outcome in the database corresponds with the global outcome of
the web service transaction as a whole.
 Things are less complex for the client. Through its API, the client application registers a participant with the
transaction, and uses this participant to control termination of the transaction.


       Business Process Execution Language for Web Services
                            (BPEL4WS)
Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language
(WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with
web services. Processes in BPEL export and import information by using web service interfaces exclusively.

*Web service interactions can be described in two ways: executable business processes and abstract business
processes. Executable business processes model actual behavior of a participant in a business interaction.
Abstract business processes are partially specified processes that are not intended to be executed. An Abstract
Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role,
with more than one possible use case, including observable behavior and/or process template. WS-BPEL is
meant to be used to model the behavior of both Executable and Abstract Processes
The origins of BPEL can be traced to WSFL and XLANG. It is serialized in XML and aims to enable
programming in the large.

The concepts of programming in the large and programming in the small distinguish between two aspects of
writing the type of long-running asynchronous processes that one typically sees in business processes.
Programming in the large generally refers to the high-level state transition interactions of a process—BPEL
refers to this concept as an Abstract Process. A BPEL Abstract Process represents a set of publicly observable
behaviors in a standardized fashion. An Abstract Process includes information such as when to wait for
messages, when to send messages, when to compensate for failed transactions, etc. Programming in the small,
in contrast, deals with short-lived programmatic behavior, often executed as a single transaction and involving
access to local logic and resources such as files, databases, etc. BPEL's development came out of the notion that
programming in the large and programming in the small required different types of languages.

       History: IBM and Microsoft had each defined their own, fairly similar, "programming in the large" languages:
       WSFL and XLANG, respectively. With the advent and popularity of BPML, and the growing success of
       BPMI.org and the open BPMS movement led by JBoss and Intalio Inc., IBM and Microsoft decided to combine
       these languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP and Siebel
       Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical
       Committee. Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical
       committee voted on 14 September 2004 to name their spec "WS-BPEL 2.0". (This change in name aligned BPEL
       with other Web Service standard naming conventions which start with "WS-" and took account of the significant
       enhancements made between BPEL4WS 1.1 and WS-BPEL 2.0.) If not discussing a specific version, the moniker
                                                                                                                 9
       BPEL is commonly used[citation needed. In June 2007, Active Endpoints, Adobe Systems, BEA, IBM, Oracle
       and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human interaction
       in BPEL processes can be implemented.
       BPEL Design Goals
There were ten original design goals associated with BPEL:
          1. Define business processes that interact with external entities through web service operations
              defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL
              1.1. The interactions are “abstract” in the sense that the dependence is on portType definitions,
              not on port definitions.
          2. Define business processes using an XML-based language. Do not define a graphical
              representation of processes or provide any particular design methodology for processes.
          3. Define a set of Web service orchestration concepts that are meant to be used by both the external
              (abstract) and internal (executable) views of a business process. Such a business process defines
              the behavior of a single autonomous entity, typically operating in interaction with other similar
              peer entities. It is recognized that each usage pattern (i.e. abstract view and executable view) will
              require a few specialized extensions, but these extensions are to be kept to a minimum and tested
              against requirements such as import/export and conformance checking that link the two usage
              patterns.
          4. Provide both hierarchical and graph-like control regimes, and allow their use to be blended as
              seamlessly as possible. This should reduce the fragmentation of the process modeling space.
          5. Provide data manipulation functions for the simple manipulation of data needed to define process
              data and control flow.
          6. Support an identification mechanism for process instances that allows the definition of instance
              identifiers at the application message level. Instance identifiers should be defined by partners and
              may change.
          7. Support the implicit creation and termination of process instances as the basic lifecycle
              mechanism. Advanced lifecycle operations such as "suspend" and "resume" may be added in
              future releases for enhanced lifecycle management.
          8. Define a long-running transaction model that is based on proven techniques like compensation
              actions and scoping to support failure recovery for parts of long-running business processes.
          9. Use Web Services as the model for process decomposition and assembly.
          10. Build on Web services standards (approved and proposed) as much as possible in a composable
              and modular manner.

               The BPEL language

       **BPEL is an orchestration language, not a choreography language. The primary difference
       between orchestration and choreography is executability and control. An orchestration specifies an
       executable process that involves message exchanges with other systems, such that the message exchange
       sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-
       peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of
       guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different
       realizations (processes that comply with it). A choreography can be realized by writing an orchestration
       (e.g. in the form of a BPEL process) for each peer involved in it. The orchestration and the
       choreography distinctions are based on analogies: orchestration refers to the central control (by the
       conductor) of the behavior of a distributed system (the orchestra consisting of many players), while
       choreography refers to a distributed system (the dancing team) which operates according to rules (the
       choreography) but without centralized control.

       BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led BPEL to
       adopt web services as its external communication mechanism. Thus BPEL's messaging facilities depend
                                                                                                                              10
         on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming
         messages.

         In addition to providing facilities to enable sending and receiving messages, the BPEL programming
         language also supports:
        A property-based message correlation mechanism
        XML and WSDL typed variables
        An extensible language plug-in model to allow writing expressions and queries in multiple languages:
         BPEL supports XPath 1.0 by default
        Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing
         commands in order) and flow (to enable executing commands in parallel)
        A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-
         handlers and event-handlers
        Serialized scopes to control concurrent access to variables

                  Relationship of BPEL to BPMN

There is no standard graphical notation for WS-BPEL, as the OASIS technical committee decided this was out of scope. Some
vendors have invented their own notations. These notations take advantage of the fact that most constructs in BPEL are block-
structured (e.g. sequence, while, pick, scope, etc.) This feature enables a direct visual representation of BPEL process descriptions in
the form of structograms, in a style reminiscent of a Nassi–Shneiderman diagram.

Others have proposed to use a substantially different business process modeling language, namely Business Process Modeling
Notation (BPMN), as a graphical front-end to capture BPEL process descriptions. As an illustration of the feasibility of this approach,
the BPMN specification includes an informal and partial mapping from BPMN to BPEL 1.1. A more detailed mapping of BPMN to
BPEL has been implemented in a number of tools, including an open-source tool known as BPMN2BPEL. However, the development
of these tools has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases
impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL
round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated
BPEL code synchronized, in the sense that any modification to one is propagated to the other.

Adding 'programming in the small' support to BPEL
BPEL's control structures such as 'if-then-elseif-else' and 'while' as well as its variable manipulation facilities depend on the use of
'programming in the small' languages to provide logic. All BPEL implementations must support XPath 1.0 as a default language. But
the design of BPEL envisages extensibility so that systems builders can use other languages as well. BPELJ is an effort related to JSR
207 that may enable Java to function as a 'programming in the small' language within BPEL.

WS-BPEL 2.0
What's new in WS-BPEL 2.0?
New activity types: repeatUntil, validate, forEach (parallel and sequential), rethrow, extensionActivity, compensateScope
Renamed activities: switch/case renamed to if/else, terminate renamed to exit
Termination Handler added to scope activities to provide explicit behavior for termination
Variable initialization
XSLT for variable transformations (New XPath extension function bpws:doXslTransform)
XPath access to variable data (XPath variable syntax $variable[.part]/location)
XML schema variables in Web service activities (for WS-I doc/lit style service interactions)
Locally declared messageExchange (internal correlation of receive and reply activities)
Clarification of Abstract Processes (syntax and semantics)
Enable expression language overrides at each activity

								
To top