A service Oriented Architecture - PowerPoint PPT Presentation

About This Presentation

A service Oriented Architecture


A service Oriented Architecture & Web Service Technology The case for developing SOA Level of Software complexity continues to increase, and traditional architectures ... – PowerPoint PPT presentation

Number of Views:358
Avg rating:3.0/5.0
Slides: 39
Provided by: Pim88


Transcript and Presenter's Notes

Title: A service Oriented Architecture

A service Oriented ArchitectureWeb Service
(No Transcript)
The case for developing SOA
  • Level of Software complexity continues to
    increase, and traditional architectures seem to
    be reaching the limit of their ability
  • Need to respond quickly to new requirements of
    the business
  • Need to continually reduce the cost of IT to the
  • Ability to absorb and integrate new business
    partners and new customer sets

  • Cumulative effect of decades of growth and
    evolution has produced severe complexity
  • Redundant and non-reusable programming
  • Real integration killer - multiplicity of

Requirement for a SOA
  • Leverage existing assets.
  • Existing systems can rarely be thrown away, and
    often contain within them great value to the
  • Support all required types of integration.
  • User Interaction
  • Application Connectivity
  • Process Integration
  • Information Integration
  • Build to Integrate

Requirement for a SOA
  • Allow for incremental implementations migration
    of assets
  • Include a development environment that will be
  • around a standard component framework,
  • promote better reuse of modules and systems,
  • allow legacy assets to be migrated to the
  • allow for the timely implementation of new
  • Allow implementation of new computing models
  • specifically, new portal-based client models,
    Grid computing, and on-demand computing

A service-oriented architecture -- not just Web
  • First, though, it must be understood that Web
    services does not equal service-oriented
  • Web services is a collection of technologies,
    including XML, SOAP, WSDL, and UDDI,
  • SOA is "an application architecture within which
    all functions are defined as independent services
    with well defined invocable interfaces which can
    be called in defined sequences to form business

A service-oriented architecture -- not just Web
  • All functions are defined as services.
  • All services are independent.
  • Operate as "black boxes"
  • external components neither know nor care how
    boxes are executed
  • merely that they return the expected result.
  • The interfaces are invocable
  • At an architectural level, it is irrelevant
  • they are local or remote
  • what interconnect scheme or protocol is used to
    effect the invocation,
  • what infrastructure components are required to
    make the connection.

A service-oriented architecture -- not just Web
  • Interface is the key, the focus of the calling
  • It defines the required parameters and the nature
    of the result
  • It is the system's responsibility to effect and
    manage the invocation of the service,
  • This allows two critical characteristics to be
  • Services are truly independent,
  • they can be managed. Management includes many
    functions, including Security, Deployment ,
    Logging, Dynamic rerouting,and Maintenance

The Nature of a Service
  • Typically within a business environment
  • Service means business functions, business
    transactions, and system services.
  • The difference in the types of services.
  • Business functions are from the application's
    perspective, non-system functions that are
    effectively atomic.
  • Services might be low-level or complex high-level
    (fine-grained or course grained) functions

An SOA - Constituent Parts
  • To determine what the constituent parts of an SOA
    are it is first necessary to break down the
    question into the design-time and run-time
  • The idea that SOA encapsulates both design-time
    and run-time is critical to understanding SOA
  • SOA is really about both physical and logical

SOA Design-time requirements
  • UDDI directory of External web services
  • provides the definition of a set of services
  • a directory of external web services already
    being used by the enterprise.
  • Directory of Enterprise Internal web services
  • internal directory indicates whether the web
    service is externally available
  • re-use available web services when designing new
    business processes.
  • Agile Design Methodology
  • methodology which is oriented towards re-use,
  • methodology needs to emphasize the requirement
    for cross-project information and working.

SOA Design-time requirements
  • Process Driven Development
  • based upon the modeling or re-modeling of
    business processes.
  • The start point should be the expansion or
    re-working of the set of modeled business
  • Workflow Oriented Development
  • One of the key paradigms for SOA development is
    that the business processes are seamless
  • Each step in each process should be linked, as an
    automatic next step
  • Multi-level Design Management
  • Design management must be based primarily on the
    business objectives each project is to deliver

SOA Design-time requirements
  • Agile Toolset For SOA Development
  • abstraction of existing functionality into new
    web services
  • minimize coding, Ability to plug in existing
  • Information Routing Modeling
  • incorporates the need to integrate deliver
    information and to deliver to the right people at
    the right time.
  • SOA solution must also be able to model the flows
    of information across the enterprise and the
    extended supply chain.
  • Debugging And Simulation Capability
  • Multi-Language Capability

SOA Run-time requirements
  • Consolidated Process Management
  • ability to present transactional and information
    flows visually by business process,
    organizational unit and server.
  • Process Oriented Monitoring Administration
  • Run Time env should display information at the
    process level and allow activation/de-activation
    of any process (stopping the process at a
    specific step) as a means of handling
  • Business Activity Monitoring (BAM)
  • SOA tool-set should include BAM capability the
    run-time environment should feed data to the BAM

SOA Run-time requirements
  • Persistence Of Message-Based Asynchronous Process
  • SOA requires a data store external to the
    applications that provide the underlying
    functionality, akin to an Operational Data Store,
    to store potentially long-term but essentially
    transient process related data
  • Scalability Of The Environment
  • Scaleable means that the toolset supports the
    deployment of further servers, the assignment of
    specific processes or organizational units to
    servers and the management of software across
  • Resilience
  • must provide sufficient resilience to support the
  • User Access And Security
  • SOA solution offers a browser-based,
    role-oriented experience for the user which
    incorporates task lists based on the users roles
    and the relevant collaboration and knowledge
    content as well as links to the key web sites for
    the role.

SOA Run-time requirements
  • Workflow
  • Availability of work-flow functionality in any
    SOA solution facilitates the Easy linking of
    processes/process parts or Browser-based task
    lists for the users
  • Event driven
  • The link between processes (or between a process
    and the external world) will often be in the form
    of an event.
  • Simulation capability
  • The ability to simulate traffic across any
    process is very useful when reviewing performance
    and scalability questions.
  • Error Management
  • A key criterion for any SOA run-time environment
    is its error management. The criteria for error
    management are
  • Visibility of errors, Re-start capability, Error
    notification, Workflow linking

SOA Model
  • A service provider
  • provides a service interface for a software asset
    that manages a specific set of tasks.
  • A service requester
  • discovers and invokes other software services to
    provide a business solution..
  • A service broker
  • acts as a repository, yellow pages, or clearing
    house for software interfaces that are published
    by service providers.

Service Requester
  • Content Aggregation
  • Activity where an entity interacts with a variety
    of content providers to process/reproduce such
    content in the desired presentation format of its
  • Service Aggregation
  • Activity where an entity interacts with a variety
    of service providers to re-brand, host, or offer
    a composite of services to its customers.

Service Provider
  • Independent software vendors are prime examples
    of potential service providers.
  • They own and maintain a software asset that
    performs tasks.
  • Software assets could be made available as an
    aggregation of services or broken down into
    distinctly separate software service resources.
  • Processes that are proven and generalized for a
    diverse set of applications would be good
    candidates for service providers.
  • For example, if a bank felt that its business
    process for loan processing was a strong enough
    asset to be made publicly available and was
    willing to support it as a business offering,
    then that bank could view itself as a loan
    processing service provider.

  • Is an entity that collects and catalogs data
    about other entity and then providing that data
    to others (a form of SOA Broker.)
  • Usually, a registry would collect data such as
  • Entity name,
  • Description, and contact information.

In UDDI terms, this Registry role is often
referred to as the White Pages.
Enabling technologies
  • XML The Extensible Markup Language
  • SOAP
  • Simple Object Access Protocol is an XML-based
    lightweight protocol for the exchange of
    information in a decentralized,
  • WSDL
  • The Web Services Description Language is an XML
    vocabulary that provides a standard way of
    describing service IDLs.
  • UDDI
  • The Universal Description, Discovery, and
    Integration specification provides a common set
    of SOAP APIs that enable the implementation of a
    service broker.

12 Steps to implement a SOA
  1. Understand the functional objectives and define
  2. Define your problem domain.
  3. Understand all application semantics in your
  4. Understand all services available in your domain.
  5. Understand all information sources and sinks
    available in your domain.
  6. Understand all processes in your domain.

12 Steps to implement a SOA
  • Identify and catalog all interfaces outside of
    the domain you must leverage (services and simple
  • Define new services/information bound to the
  • Define new processes, services, and information
    bound to the processes.
  • Select your technology set.
  • Implement Deploy SOA technology.
  • Test and evaluate

Web Service
What a Web Service in a Few Words?
  • Web Services are the basis for Grid Services,
    which are the cornerstones of OGSA and OGSI.
  • Understanding the Web Services architecture is
    fundamental to using GT3.X and GT4.X and
    programming Grid Services
  • What exactly are Web Services?
  • To put it quite simply, they are yet another
    distributed computing technology (like CORBA,
    RMI, EJB, etc.) They allow to create
    client/server applications.

Web Service
  • The clients (the PCs at the store)
  • contact the Web Service in the server
  • send a service request asking for the catalog
  • The server returns the catalog through a service
  • This is a very sketchy example of how a Web
    Service works.

Web Services have certain advantages over other
  • Why cannot we use RMI, CORBA, EJBs, and
    countless other technologies.
  • So, what makes Web Services special?
  • Web Services are platform-independent and
    language-independent (standard XML)
  • Most Web Services use HTTP for transmitting
    messages (such as the service request and

Web Services also have some disadvantages
  • Overhead. Transmitting all data in XML is not as
    efficient as using a proprietary binary code.
  • What you win in portability, you lose in
  • This overhead is usually acceptable for most
    applications, but you will probably never find a
    critical real-time application that uses Web
  • Lack of versatility. Currently, Web Services are
    not very versatile, since they only allow for
    some very basic forms of service invocation.
  • CORBA offers programmers a lot of supporting
    services (such as persistency, notifications,
    lifecycle management, transactions, etc.)
  • Grid Services actually make up for this lack of

One important characteristic that distinguishes
Web Services
  • While technologies such as CORBA and EJB are
    oriented toward highly coupled distributed
    systems, where the client and the server are very
    dependent on each other
  • Web Services are oriented towards loosely coupled
    systems, where the client might have no prior
    knowledge of the Web Service until it actually
    invokes it.

A Typical Web Service Invocation
  1. First step will be to find a Web Service that
    meets our requirements contact a UDDI registry.
  2. The UDDI registry will reply, telling what
    servers can provide the service required.
  3. the location of a Web Service is now known, but
    the actually invocation method is still unknown.
    The second step is to ask the Web Service to
    describe itself
  4. The Web Service replies using WSDL.
  5. The Web Service is located and invocation method
    is known. The invocation is done using SOAP (a
    SOAP request is sent asking for the needed
  6. The Web Service will reply with a SOAP response
    which includes the information we asked for, or
    an error message if our SOAP request was

Web Services Addressing
  • At one point, the UDDI registry tells the client
    where the Web Service is located. But, how
    exactly are Web Services addressed?
  • The answer is very simple just like web pages.
    We use plain and simple URIs (Uniform Resource
    Identifiers). For example, the UDDI registry
    might have replied with the following URI
  • http//webservices.mysite.com/weather/us/WeatherSe
  • This could easily be the address of a web page.
  • However, remember that Web Services are always
    used by software (never directly by humans).
  • When you have a Web Service URI, you will usually
    need to give that URI to a program. In fact, most
    of the client programs we will write will receive
    the Grid Service URI as a command-line argument.

Web Services Architecture
  • Service Discovery
  • Service Description
  • Service Invocation
  • Transport

What a Web Service Application Looks Like
What a Web Service Application Looks Like
  • Client application invoke the Web Service, by
    calling the client stub.
  • The client stub will turn this 'local invocation'
    into a proper SOAP request.
  • The SOAP request is sent over a network using the
    HTTP protocol.
  • WS container receives the SOAP requests hands
    it to the server stub.
  • The server stub converts the SOAP request into
    something the service implementation can
  • The service implementation receives the request
    from the service stub, and carries out the work
    it has been asked to do.
  • The result of the requested operation is handed
    to the server stub, which turns it into a SOAP
  • The SOAP response is sent over a network using
    the HTTP protocol.
  • The client stub receives the SOAP response and
    turns it into something the client application
    can understand.
  • The application receives the result of the Web
    Service invocation

What a Web Service Application Looks Like
  • Web Services programmers usually never write a
    single line of SOAP or WSDL.
  • Once we've reached a point where our client
    application needs to invoke a Web Service, we
    delegate that task on a piece of software called
    a client stub.
  • The good news is that there are plenty of tools
    available that will generate client stubs
    automatically for us, usually based on the WSDL
    description of the Web Service.
  • A Web Services client doesn't usually do all
    those steps in a single invocation. A more
    correct sequence of events would be the
  • We locate a Web Service that meets our
    requirements through UDDI.
  • We obtain that Web Service's WSDL description.
  • We generate the stubs once, and include them in
    our application.
  • The application uses the stubs each time it needs
    to invoke the Web Service.

Programming the server
  • Implement all the functionality of our Web
  • Generate a server stub
  • server stub can be generated from a WSDL
    description or from other interface definition
    languages (such as IDL).
  • Charge of interpreting requests and forwarding
    them to the service implementation
  • generate the appropriate SOAP response
  • Note Both the service implementation and the
    server stubs are managed by a piece of software
    called the Web Service container, which will make
    sure that incoming HTTP requests intended for a
    Web Service are directed to the server stub.

Web services Framework
  • Simple Object Access Protocol (SOAP)
  • Web Service Description Language (WSDL)
  • support a service interface definition that
    is distinct from the protocol bindings used for
    service invocation
  • WS-Inspection
  • mechanisms for registering, discovering
    interface, endpoint implementation description
    and for dynamically generating proxies based on
    bindings for specific interfaces.
Write a Comment
User Comments (0)
About PowerShow.com