WebServices & SOA

Full text

(1)Web Services and Service Oriented Architecture. Snehal Masne www.TechProceed.com.

(2) Today’s Web  Web designed for application to human interactions  Served very well its purpose:  Information sharing: a distributed content library  Enabled B2C e-commerce  Non-automated B2B interactions.  How did it happen?  Built on very few standards.  Shallow interaction model: very few assumptions made. about computing platforms  Result was ubiquity.

(3) Problems Involve a whole learning curve Not based on standardized rules and specifications. Module A. CORBA. Module B. CORBA. CORBA. Module C Module A. RMI. Module B.

(4) What’s next?  The Web is everywhere. There is a lot more we can do!  E-marketplaces.  Open, automated B2B e-commerce.  Business process integration on the Web.  Resource sharing, distributed computing..  Current approach is ad-hoc on top of existing standards.  e.g., application-to-application interactions with HTML. forms.  Goal: enabling systematic application-to-application interaction on the Web..

(5) Web Services Provide Standardized method of communication between software applications. Distributed components are interfaced via non-object-specific protocols Module A C++. Module B Java.

(6) What is a web service?  W3C Definition:  A Web service is a software application identified by a URI, whose. interfaces and binding are capable of being defined, described and discovered by XML artefacts and supports direct interactions with other software applications using XML based messages via internetbased protocols.  Other definitions  “Web services” is an effort to build a distributed computing platform. for the Web.  enabling systematic application-to-application interaction on the Web..

(7) Designing Web Services  Goals  Enable universal interoperability.  Widespread adoption, ubiquity: fast! Enable (Internet scale) dynamic binding.  Efficiently support both open (Web) and more constrained. environments..  Requirements  Based on standards. Pervasive support is critical.  Minimal amount of required infrastructure is assumed. . Only a minimal set of standards must be implemented..  Very low level of application integration is expected. . But may be increased in a flexible way..  Focuses on messages and documents, not on APIs..

(8) Web Services Framework  Describe  Expose—Services register in a repository providing  Business information (White pages)  Service information (Yellow pages)  Binding information (Green pages) describing how to connect and. use the services  Invoke—Remote application can invoke service  Respond—When service is invoked, results are returned to the requester  Manage/Govern – Provided structure and process control.

(9) Fundamentals of Web Services A web service is a programmable component that provides a service and is accessible over the Internet.. Instance. Component. Instance. Instance. Client. Network. Client. Client.

(10) Fundamentals of Web Services Web services stack.

(11) Fundamentals of Web Services Web services stack Service & Information Layer Types Message Operation Port Type. Service Implementation. Binding Port. Web Service Interface (WSDL). Service.

(12) Using WSDL 1. 2. 3.. 4. 5. 6.. Describe the message interchange formats the service can support WSDL may define where the service is available and what communications protocol is used to talk to the service. As extended IDL: WSDL allows tools to generate compatible client and server stubs. Allows industries to define standardized service interfaces. Allows advertisement of service descriptions, enables dynamic discovery and binding of compatible services. Provides a normalized description of heterogeneous applications..

(13) WSDL Document <definition> Abstract (service interface definition) Concrete (service implementation Definition). interface message ______________ service binding. Logical grouping of operations Data description using XML Schema Actual data structures used to pass data. endpoint/port. Service Definition = Abstract + Concrete Service Description = Service Definition + Supplementary Definitions.

(14) XML-eXtensible Markup Language  In Web services, a message is an XML document information item as. defined by the XML Information. ..  The Information items generally maps to the various features in an. XML document, such as elements, attributes, namespaces, and comments …..  All the technologies in Web Services are XML based  Messaging  Description  Registry.  Why?. Are all in XML.

(15) Fundamentals of Web Services Web services stack Packaging Layer Simple Object Access Protocol (SOAP) is a lightweight protocol designed for the exchange of information using XML Defines a modular packaging model and the encoding mechanisms for encoding data within modules .. Envelope Encoding rules. SOAP. RPC representation.

(16) Fundamentals of Web Services Web services stack Protocol Layer Any of the standard Internet protocols may be used to invoke web services over the network .. The initial definition focuses specifically on HTTP/1.1 and the encrypted HTTPS FTP and SMTP can also be used.

(17) Invoking a web service. A client invoking a Web service.

(18) Discovery Layer  The Universal Description, Discovery, and Integration protocol, or. UDDI, specifies a protocol for querying and updating a common directory of Web service information..  UDDI directory approach can be used when Web service information is. stored in well-known locations..  UDDI provides inquiry and publishing API’s  Microsoft, IBM and SAP host the UDDI Business Registry.  Directory entry has three primary parts – the service provider, Web. services offered, and bindings to the implementations..  Dynamically discovered Web services explicitly announce their arrival. and departure from the network..

(19) UDDI Universal Description Discovery 3. and Integration 1.. SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services. Marketplaces, search engines, and business apps query the registry to discover services at other companies. 2. • Businesses populate the registry with descriptions of the services they support. Business Descriptions. Service Types. 4.. Business uses this data to facilitate easier integration with each other over the Web.

(20) Web Services Pros and Cons Pros  Global method for describing and finding Internet–based business services  Packaging and publishing of applications in a readily understood format  New revenue streams through syndication of existing application as Web Service. Cons  Emerging technology  Managing and Tracking changes is a challenge  Transactions not fully addressed  Multiple, evolving security standards  Processing overhead.

(21) Future Vision and Challenges  Technology vendors plan to develop, market, and lend online Web. services to fulfill virtually any business function..  Companies will be able to simply search a public directory of. applications and download those that fit their needs..  Right now we have only tools and standards which are still not matured,. but it’s needless to say that its time to learn and practice some web services development. Challenges.

(22) Example  Google  A great search engine  but what if I want my own GUI?.

(23) Google web service  Google offers a web service that performs searches for. you  Why?  clients can build custom GUIs  google.com can make money! // ask google to search for us... google = new GoogleSearchService(); result = google.doGoogleSearch("4a8/TvZQFHID0WIWnL1CMmMx0sNqhG8H", txtSearch.Text, 0, 10, false, "", false, "", "", ""); // display resulting URLs... foreach (ResultElement re in result.resultElements) lstURLs.Items.Add(re.URL);.

(24) (1) Building a web service  Start by creating a project of type “ASP.NET Web. Service”.

(25) A web service is…  One or more objects that respond to web-based. method calls  there is no GUI design to a web service  only raw classes with methods… public class Service1 : System.Web.Services.WebService { . . . }.

(26) Example  Looks like C#, but keep in mind these are web-based methods  client could be calling from any platform  parameters passed using XML public class Service1 : System.Web.Services.WebService { [WebMethod] public int Add(int x, int y) { return x + y; } [WebMethod] public string[] Attendees() { <<open DB, read attendees into array, return it>> } }.

(27) (2) Building a client  Start by creating a client…  WinForm, WebForm, console-based, anything you want!  for fun, let's use VB….

(28) Reference the component  As usual, we need to reference component  this will activate IntelliSense  this will make sure we call it correctly  this will enable underlying XML +. SOAP communication.  How?  project references, right-click, Add web reference…  type URL for web service, e.g. . http://localhost/WebService/Service1.asmx web server. service name. class name.

(29) Program against component  Treat web service like any other class!  use new to create instances  make method calls  pass parameters. Private Sub Button1_Click(...) Handles Button1.Click Dim i, j, k As Integer. i = CInt(TextBox1.Text) j = CInt(TextBox2.Text) Dim obj As localhost.Service1 obj = New localhost.Service1() k = obj.Add(i, j) MessageBox.Show("Sum = " + k.ToString()) End Sub.

(30) Underlying execution… web service client app. obj.Add(i, j); proxy <Add> <n1>10</n1> <n2>20</n2> </Add> HTTP request: Service1.asmx. obj obj.Add(10, 20);. .asmx Web server.

(31) Service Oriented Architecture  Allows a collection of services to communicate with each other and.   .  . unifies processes by collecting smaller service modules in an ad hoc manner. Operational Implementation Architectural Business Principles.

(32) SOA Concept  SOA enables a standards-based marketplace of service. consumers and service providers across an enterprise community or across the Web  SOA is a specification-based architecture to transition the technical landscape to a standards-based, vendor independent, and loosely-coupled information sharing environment  Decoupling the service contract from the service. implementation  Promoting design and invocation by contract.

(33) Basic Components of SOA. Basic Component of SOA.

(34) De-mystifying SOA  SOA is…. A design philosophy and Architecture.  SOA is NOT…. A technology or a methodology. A means. Not an end. A solution. Not a product. Achieved through Web. Only Web Services. Services and related technologies.

(35) SOA Requirements • • • • •. Agility Use of standards Separation of concerns Reuse Interoperability between different systems and programming languages. • Clear and unambiguous description language • Retrieval of the service • Security.

(36) The Architecture SOA - an evolution in objectives From. To. Function oriented. Process oriented. Build to last. Build to change. Prolonged development cycles. Incrementally built and deployed. Application silos. Orchestrated solutions. Tightly coupled. Loosely coupled. Structuring applications using components or objects. Structure applications using services. Known implementation. Implementation abstraction.

(37) The Architecture Building an SOA - a Closer look at services Services in a Service-Oriented Architecture are always: Stateless: SOA services neither remember the last thing they were asked to do, nor care what the next is. Discoverable: A service must be “discoverable” by potential consumers of the service Self-describing: The SOA service interface describes, exposes, and provides an “entry point” to the service. Composable: SOA services are, by nature, composite..

(38) The Architecture Building an SOA - a Closer look at services. Single-instance Only one implementation of a given service should exist in an SOA. Loosely coupled Loose coupling allows the concerns of application features to be separated into independent pieces. Governed by policy Services are built by contract. Independent of location, language, and protocol Services are designed to be location-transparent and protocol/platform-independent.

(39) The Architecture Building an SOA - a Closer look at services. As Coarse-grained as possible Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service – the more coarse-grained a service is, the richer the function offered by the service. Potentially Asynchronous Asynchronous communication is not required of an SOA service, but it increases system scalability through asynchronous behavior and queuing techniques..

(40) SOA Infrastructure Standards • WS-RM • WS-RM policy • WS-Policy • WS-Addressing • WS-Notification. • WSS • SAML • XACML • XML-Signature • XML-Encryption • WS-Trust • WS-Policy • WS-SecurityPolicy • XKMS. • UDDI • ebXML • WS-Discovery Security. Messaging. Service Discovery. Mediation. Governance. Management. • WSDM • WS-Management. • XSL • BPEL • WS-Policy • XQuery • XPath.

(41) Steps to Implement SOA Create/Expose Services 2. Register Services 3. Secure Services 4. Manage (monitor) Services 5. Mediate and Virtualize Services 6. Govern the SOA 1.. Source: SOA Software, Inc., 2008..

(42) 1. Create & Expose Services . Three primary choices   . . . Rebuild existing applications using SOA paradigm Expose existing application logic as a set of services A combination of rebuild and expose. Enterprises typically use a combination of rebuild & expose Granularity is a key criterion for Web Service. 2. Register Services  . Application architects & developers need to know that a service exists Use a registry. Source: SOA Software, Inc., 2008..

(43) 3. Secure Services   . May have inadvertently created gaping security holes May have exposed sensitive information principles of security. 4. Manage Services  . Look for potential disaster Need to be able to monitor for    . Basic Availability Performance Throughput SLA agreement. Source: SOA Software, Inc., 2008..

(44) 5. Mediate & Virtualize Services .  .    . . As SOA matures may need to:  Introduce new versions  Increase capacity by running multiple instances  Provision applications to use specific instances of services Solution is Virtualization XML transformation can be used to allow consumers to use an old version of service that no longer exists. Consumers can provide different policy requirements for different classes of users Transport bridging can be provided  E.g. HTTP and JMS Meditation between different standards implementation or versions of standards Mediation between different messaging styles  RSS, SOAP, REST, Plain old XML (POX) Content-or-context-based routing to deliver advanced load-balancing and highavailability capabilities. Source: SOA Software, Inc., 2008..

(45) 6. Govern the SOA     . Use a governance framework Design Time Issues Run Time Issues Tools needed for active participants Service Developer needs tools to: . . . Service Consumer needs tools to: . . Publish, categorize, define meta-data, virtualize Choose policy, participate in capacity planning & access workflow Facilitate service discovery, selection & access workflow. Operations Staff need to: .  . Monitor service performance Troubleshoot problems, monitor dependencies Version services, virtualization & proxy management. Source: SOA Software, Inc., 2008..

(46) Govern the SOA Cont’d . Security Staff needs tools to: Manage policy, report policy, check compliance, audit security Enterprise Architect needs tools to:  Monitor application, manage relationships  Define & validate design policy  Assign services to proxy  Virtualize services Enterprise IT Management . . .  . . Manage reuse metrics Gather service reuse statistics Gather SOA statistics. Source: SOA Software, Inc., 2008..

(47) Enterprise Service Bus (ESB)  ESB is the backbone of SOA that acts as a message. broker providing a message queuing system using industry standard specifications for messaging such as SOAP, or JMS (Java Message Service).  Expert Sally Hudson, an IDC analyst, describes the Enterprise Service Bus as an open standards-based messaging means designed to provide interoperability between larger-grained applications and other components via simple standard adapters and interfaces..

(48) ESB Architecture ERP. Transformation (XSLT). .NET. JCA. Web Services. SOAP/ HTTP. SOAP/ HTTP. Connection Layer. Communication Layer Reliable Asynchronous Secure Messaging. SOAP/ HTTP C/C++ Legacy Application. Connection Layer. JMS. J2EE.

(49) According to the SOA A Web service is:  An interface that describes a collection of. network accessible. operations  Described using a service description language  Published by making this service description available to users  Found by sending queries to a registry matching service descriptions  Bound-Invoked by using the information contained in the service description  Composed with other services to create new services (service orchestration).

(50) How it all works together.

(51) SOA vs CORBA & DCOM.

(52) Benefits  Provides location independence: Services need not be. associated with a particular system on a particular network  Protocol-independent communication framework renders code reusability  Offers better adaptability and faster response rate to changing business requirements  Allows easier application development, run-time deployment and better service management.

(53) Benefits (cont.)  Loosely coupled system architecture allows easy. integration by composition of applications, processes, or more complex services from other less complex services  Provides authentication and authorization of Service consumers, and all security functionality via Services interfaces rather than tightly-coupled mechanisms  Allows service consumers (ex. Web Services) to find and connect to available Services dynamically.

(54) Thank You Questions???.

(55)

No results found