1. A service Oriented Architecture & Web Service Technology

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
Strategically, the objective is to build a new architecture that will yield all the value hoped for, but tactically, the existing systems must be integrated such that, over time, they can be componentized or replaced in manageable, incremental projects.
User Interaction -- being able to provide a single, interactive user experience
Application Connectivity -- communications layer that underlies all of the architecture
Process Integration -- choreographs applications and services
Information Integration -- federates and moves the enterprise data
Build to Integrate -- builds and deploys new applications and services

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
this will enable one of the most critical aspects of developing the architecture: the ability to produce incremental ROI. Countless integration projects have failed due to their complexity, cost, and unworkable implementation schedules

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.
The service may be within the same application, or in a different address space within an asymmetric multiprocessor, on acompletely different system within the corporate Intranet, or within an application in a partner's system used in a B2B configuration.

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
Security -- authorization of the request, encryption and decryption as required, validation, etc.
2. Deployment -- allowing the service to be redeployed (moved) around the network for performance, redundancy for
availability, or other reasons
3. Logging -- for auditing, metering, etc.
4. Dynamic rerouting -- for fail over or load balancing
5. Maintenance -- management of new versions of the service

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.
We will look at the two separately, and then propose a single view of an SOA by combining them.

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.
Content Aggregation 
An examples of such entities would be an internet portal or information service provider.
Service Aggregation
An example of such an entity would be a mobile portal the likes of OnStar (

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.
A fundamental aspect of a successful implementation is the reliance on open Internet standards.

23. 12 Steps to implement a SOA
Understand the functional objectives and define success.
Define your problem domain.
Understand all application semantics in your domain.
Understand all services available in your domain.
Understand all information sources and sinks available in your domain.
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.

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).
1. since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web
Service is programmed in Java and running under Linux.
2. This is a major advantage if you want to build an Internet-scale application, since most of the Internet's proxies and firewalls won't mess with HTTP
traffic (unlike CORBA, which usually has trouble with firewalls)

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.
- Highly coupled systems are ideal for intranet applications, but perform poorly on an Internet scale.
- Web Services, however, are better suited to meet the demands of an Internet-wide application, such as grid-oriented applications.

31. A Typical Web Service Invocation
First step will be to find a Web Service that meets our requirements: contact a UDDI registry.
The UDDI registry will reply, telling what servers can provide the service required.
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
The Web Service replies using WSDL.
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.
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
1. A client may have no knowledge of what Web Service it is going to invoke. So, our first step will be to find a Web Service that meets our requirements.
For example, we might be interested in locating a public service. We'll do this by contacting a UDDI registry.
2. The UDDI registry will reply, telling us what servers can provide us the service we require. We now know the location of a Web Service, but we have no
Idea of how to actually invoke it., but what is the actual service invocation? The method I have to invoke can have any name and any number of arguments
We have to ask the Web Service to describe itself (i.e. tell us how exactly we should invoke it)
4. The Web Service replies in a language called WSDL.
5. We finally know where the Web Service is located and how to invoke it. The invocation itself is done in a language called SOAP. Therefore, we will first
send a SOAP request asking for the temperature of a certain city.
6. The Web Service will kindly reply with a SOAP response which includes the infomration we asked for, or maybe 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:
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.
We have just seen a simple Web Service invocation.
If you're more familiar with the term URL (Uniform Resource Locator), don't worry: URI and URL are practically the same thing.

33. Web Services Architecture
Service Discovery
Service Description
Service Invocation
Transport
Service Discovery: This part of the architecture allows us to find Web Services which meet certain requirements. This part is usually handled by UDDI
(Universal Description, Discovery, and Integration). GT3 currently doesn't include support for UDDI.
Service Description: One of the most interesting features of Web Services is that they are self-describing. This means that, once you've located a Web
Service, you can ask it to 'describe itself' and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description
Language (WSDL).
Service Invocation: Invoking a Web Service (and, in general, any kind of distributed service such as a CORBA object or an Enterprise Java Bean) involves
passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how
the server should format its responds. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language).
However, SOAP is by far the

34. What a Web Service Application Looks Like
1. Whenever the client application needs to invoke the Web Service, it will actually call the client stub. The client stub will turn this 'local invocation'
into a proper SOAP request. This is often called the marshalling process.
2. The SOAP request is sent over a network using the HTTP protocol. The Web Services container receives the SOAP requests and hands it to the
server stub. The server stub will convert the SOAP request into something the service implementation can understand (this is usually called unmarshalling)
3. The service implementation receives the request from the service stub, and carries out the work it has been asked to do. For example, if we are invoking
the int add(int a, int b) method, the service implementation will perform an addition.
4. The result of the requested operation is handed to the server stub, which will turn it into a SOAP response.
5. 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.
6. Finally the application receives the result of the Web Service invocation and uses it

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
1. This is often called the marshalling process.
2. (this is usually called unmarshalling)
3. For example, if we are invoking the int add(int a, int b) method, the service implementation will perform an addition

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.
Despite having a lot of protocols and languages floating around, Web Services programmers usually never write a single line of SOAP or WSDL.
If you've ever programmed with CORBA or RMI, this structure will look pretty familiar.

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.
Programming the server side is just as easy. We don't have to write a complex server program which dynamically interprets SOAP requests and generates
SOAP responses. We can simply implement all the functionality of our Web Service, and then generate a server stub (the term skeleton is also used) which
will be in charge of interpreting requests and fowarding them to the service implementation. When the service implementation obtains a result, it will give it
to the server stub, which will generate the appropriate SOAP response. The server stub can also be generated from a WSDL description, or from other interface
definition languages (such as IDL). Furthermore, 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.
WSDL Multiple bindings for a single interface, including distributed communication protocol as well as locally optimized bindings.