A service Oriented Architecture

1
A service Oriented ArchitectureWeb Service
Technology
2
(No Transcript)
3
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
  business
• Ability to absorb and integrate new business
  partners and new customer sets

4
Problems

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

5
Requirement for a SOA

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

6
Requirement for a SOA

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

7
A service-oriented architecture -- not just Web
services

• First, though, it must be understood that Web
  services does not equal service-oriented
  architecture.
• 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
  processes".

8
A service-oriented architecture -- not just Web
services

• 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
  whether
• 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.

9
A service-oriented architecture -- not just Web
services

• Interface is the key, the focus of the calling
  application.
• 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
  realized
• Services are truly independent,
• they can be managed. Management includes many
  functions, including Security, Deployment ,
  Logging, Dynamic rerouting,and Maintenance

10
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

11
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
  requirements.
• The idea that SOA encapsulates both design-time
  and run-time is critical to understanding SOA
• SOA is really about both physical and logical
  architectures.

12
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.

13
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
  processes.
• 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

14
SOA Design-time requirements

• Agile Toolset For SOA Development
• abstraction of existing functionality into new
  web services
• minimize coding, Ability to plug in existing
  middleware,
• 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

15
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
  Tools
• 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
  problems/implementation.
• Business Activity Monitoring (BAM)
• SOA tool-set should include BAM capability the
  run-time environment should feed data to the BAM
  module.

16
SOA Run-time requirements

• Persistence Of Message-Based Asynchronous Process
  Data
• 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
  servers.
• Resilience
• must provide sufficient resilience to support the
  business
• 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.

17
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

18
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.

19
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
  customers.

• 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.

20
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.

21
Registry

• 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.
22
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.

23
12 Steps to implement a SOA

1. Understand the functional objectives and define
   success.
2. Define your problem domain.
3. Understand all application semantics in your
   domain.
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.

24
12 Steps to implement a SOA

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

25
Web Service
26
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.

http//www.casa-sotomayor.net/gt3-tutorial/core/se
rvice_data/sd_ogsa.html
27
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
  response.
• This is a very sketchy example of how a Web
  Service works.

28
Web Services have certain advantages over other
technologies

• 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
  response).

29
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
  efficiency.
• This overhead is usually acceptable for most
  applications, but you will probably never find a
  critical real-time application that uses Web
  Services.
• 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
  versatility.

30
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.

31
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
   information.
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
   incorrect

32
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
  rvice
• 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.

33
Web Services Architecture

• Service Discovery
• Service Description
• Service Invocation
• Transport

34
What a Web Service Application Looks Like
35
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
  understand
• 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
  response.
• 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

36
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
  following
• 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.

37
Programming the server

• Implement all the functionality of our Web
  Service
• 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.

38
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.