EMTM 600 Software Development Spring 2011 Lecture Notes

EMTM 600 Software Development Spring 2011 Lecture Notes 4

Assignments for next time • Read chapters 1, 2, and 4 from the Cloud Computing textbook. Two days before the next lecture email me THREE OR MORE QUESTIONS about stuff you didn’t understand. Each student. EMTM 600 2011 Val Tannen 2

What is a service? 1. 2. 3. 4. A software component … … grouping a set of related capabilities …. . . whose interface is not programming language-specific …. . . and able to function independently in a distributed environment. If there was only 1. and 2. then any software module would do! Part 3. of the definition usually also means “loosely coupled” to specific operating systems, not just language-independent. But it doesn’t preclude interface languages (eg. IDL for CORBA or XML) Part 4. of the definition often comes with the addition: “loosely coupled” to other components/services. EMTM 600 2011 Val Tannen 3

What is Service-Oriented Architecture (SOA)? • Software architecture whose building bricks are (mostly) services. • Service capabilities are typically invoked in a distributed manner, over networks. • A convenient way to integrate existing (legacy) applications by packaging their use into one or more services. • SOA describes how services provide their capabilities by consuming the capabilities of other services, etc. (Just like software modules use each other. ) In particular, it can describe service composition, yielding more complex services by combining simpler ones. • Group of services toward a common goal: service inventory, described by a service catalog. • The usual principles of good software development apply: abstraction, modularity, reusability, incrementality, etc. EMTM 600 2011 Val Tannen 4

Service Implementations 1) Certain kinds of components of software frameworks: • • • CORBA server objects (not a CORBA “service”) Java EE session EJBs. NET “serviced components” (using COM+ services) Capabilities are just OO methods, much like an API, can be invoked directly from other programs. Interfaces are framework-specific, even language-specific. Often ties development to proprietary solutions. 2) (SOAP) Web Services Capabilities are “operations” with XML arguments and XML results. Interfaces are described with WSDL and XML Schema. Vendorneutral. 3) REST Services (a. k. a. RESTful web services or web API) Capabilities consist of retrieving/updating “resources” identified by URIs. EMTM 600 2011 Val Tannen 5

SOA for (SOAP) Web services (1. 0) Web services need to be described, located and invoked. SOA for Web services is a collection of specifications for these three functionalities. The big players are: SOAP = Simple Object Access Protocol (pretty stupid name, no? ), an XML messaging protocol WSDL = Web Services Description Language, a language for specifying the “types” of the operations offered by a Web service A service registry, encompassing a service inventory and a service catalog that collects the metadata , i. e. the (WSDL) descriptions. Originally proposed via UDDI = Universal Description Discovery and Integration, now less automated and more manual… EMTM 600 2011 Val Tannen 6

SOA 1. 0: how it works Service “contract” Service Registry UDDI Business Registries IBM, Microsoft, HP, SAP, etc Publish Find WSDL Service “contract” Service Provider Bind/Invoke SOAP EMTM 600 2011 Val Tannen Service “contract” Consumer WSDL 7

XML Messaging z XML Messaging means that XML documents are exchanged between applications z How could we define a concept of the end-to-end message path in a transport independent manner? Document Centric Messaging XML XML Document A new defined layer HTTP Programming API API SOAP SMTP Application Messaging IIOP Transport Fast! EMTM 600 2011 Val Tannen 8

Communication Protocol Suites (Stacks) … Web service . NET comp. SOAP RESTful Vo. IP Java. EE comp. DNS HTTP RMI SSH TCP UDP IP Application IIOP Messaging “Application” Transport Internet … EMTM 600 2011 Val Tannen 9

SOAP z SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between nodes in a decentralized, distributed environment by using XML z The main use for SOAP is RPC (Remote Procedure Call) which originated in the 1970’s with efforts to expand the functionality of the ARPANet (later became the Internet). z Warning: SOAP does not itself define any application semantics such as a programming model or implementation specific semantics! EMTM 600 2011 Val Tannen 10

SOAP Features y. Platform independent y. Language independent y. It is transport agnostic but most used is its binding to HTTP y. It is defined by W 3 C at http: //www. w 3. org/TR/SOAP/ y. Extension for carrying attachments (like email) y. Used for RPC (Remote Procedure Call) but with XML arguments and XML result EMTM 600 2011 Val Tannen 11

SOAP Blocks z Envelope element (required) that identifies the XML document as a SOAP message z Header element (optional) that contains header information z Body element (required) that contains mandatory information for the message receiver z Fault element (optional) that provides information about errors that occurred while processing the message EMTM 600 2011 Val Tannen 12

Sample Encoding of Call Requests (*) POST /Stock. Quote HTTP/1. 1 Host: www. stockquoteserver. com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" 5 SUNW EMTM 600 2011 Val Tannen 13

Sample Encoding of Response (*) HTTP/1. 1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn 5 3. 5 EMTM 600 2011 Val Tannen 14

WSDL y WSDL stands for Web Services Description Language y WSDL is written in XML (it’s an XML document) y WSDL is used to describe Web services y WSDL is also used to locate Web services EMTM 600 2011 Val Tannen 15

WSDL Description y WSDL defines an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages y A WSDL document defines services as collections of network endpoints, or ports y Messages are abstract descriptions of the data being exchanged y Port types are abstract collections of operations y The concrete protocol and data format specifications for a particular port type constitutes a reusable binding y A port is defined by associating a network address with a reusable binding. A collection of ports define a service EMTM 600 2011 Val Tannen 16

WSDL Architecture z WSDL is a layered approach to defining a service interface y Abstract – logical view of the service x. Messages: representing data flows to and from the service x. Port Type: representing a set of operations supported by one or more endpoints y Concrete – physical view of the service x. Binding: defines the specific network protocol and data format used for a given port type x. Port: defines a single endpoint for a given binding EMTM 600 2011 Val Tannen 17

WSDL – Logical – Physical 7 1 2 6 3 5 4 EMTM 600 2011 Val Tannen 18

2 EMTM 600 2011 Element Val Tannen 19

3 EMTM 600 2011 Element Val Tannen 20

WSDL Operation patterns One-way Client Request-Response Service 1 Solicit-Response EMTM 600 2011 Val Tannen D

Client Service

Notification C 1 Client 2 B Service A

2 21

" src="https://present5.com/presentation/eb769959e076d1f07cd734350815d827/image-22.jpg" alt="Binding to SOAP Example (*) " /> Binding to SOAP Example (*)

EMTM 600 2011 Val Tannen 22

Good Practices EMTM 600 2011 Val Tannen 23

UDDI z Universal Description, Discovery, and Integration z A project to speed interoperability and adoption for web services y. Standards-based specifications for service description and discovery y. Shared operation of a Business Registry on the web z Partnership among industry and business leaders EMTM 600 2011 Val Tannen 24

UDDI Implementation UDDI Business Registry Manufacturers Programmatic descriptions of web services Programmatic descriptions of businesses and the services they support Programming model, schema, and platform agnostic Uses XML, HTTP, and SOAP Free on the Internet Flower Shops Marketplaces EMTM 600 2011 Val Tannen 25

SOA 2. 0: just compose Web services! Service Registry Publish 3 Publish 1 Find 1, 2, 3 Service Requester Bind 1/ Invoke 1 Service Provider 1 Compose Bind 2/ Invoke 2 Service Provider 2 Publish 2 EMTM 600 2011 Val Tannen BPEL Bind 3/ Invoke 3 Service Provider 3 Business Process Execution Language 26

WS-BPEL and WS-CDL z WS - Business Process Execution Language z WS - Choreography Description Language z Languages for “orchestrating” the composition of web services z XML-based syntax z WS-CDL standardized by W 3 C z BPEL 1. 0 was developed jointly by IBM, BEA, SAP, Siebel, and Microsoft z Standardized by OASIS (org “rival” to W 3 C!) as WS-BPEL 2. 0 z Practically full-fledged programming languages y Control constructs for testing conditions and repetition, etc y Variables in which values can be copied and then retrieved y Basic statements are invocations of existing web services z Bindings to WSDL and SOAP/HTTP have been specified z To use them you need execution engines! EMTM 600 2011 Val Tannen 27

BPEL (CDL) cont’d z Developing BPEL “programs” is very much like specifying workflows z But writing directly in the XML-based syntax is horrendous z Development tools with visual interfaces: create boxes corresponding to the control structures and the variables, drag and drop service icons to build the composition z Great for SMALL tasks z It’s dangerous to write a BPEL script as complicated as a program in, say, Java (you can, but you shouldn’t!). EMTM 600 2011 Val Tannen 28

REST Architecture REST stands for unmemorable “Representational State Transfer”. Software architecture principles for distributed systems with hyperlinks (i. e. , the Web!). Clients send requests, servers provide responses. Servers function in a stateless mode. If the interaction logically has state, then the state is maintained by the client and it accompanies each request from client to server. Goal is “use of resources. ” Server response is a resource representation, i. e. , data that captures its state. It contains hyperlinks that may be used in next client request. Thus, a client is either in transition between states or "at rest”, when it can interact with its user, without on the servers or on the network. Hence the cute acronym REST. EMTM 600 2011 Val Tannen 29

RESTful web services The capabilities of RESTful services are based on HTTP (the WWW protocol) whose URI paths and methods (GET/POST, PUT, DELETE, etc. ) capture the interface: Resources are identified by URIs and are of two kinds: collection and element. Methods may work differently on each. Eg. , GET(a collection) returns a list of the URIs of the elements of the collection. While GET(an element) returns the element (according to its MIME type) PUT/DELETE are rarely used outside of RESTful services. PUT inserts/updates information on the server. DELETE removes information from the server. This assumes that the server maintains a forest of URI-indexed information. REST was basically devised to advertise HTTPs capabilities. But it’s a lot simpler than SOAP and developers love it! EMTM 600 2011 Val Tannen 30

WSDL and BPEL for RESTful services Initially, WSDL and BPEL had mainly support for RPC (i. e. , SOAP) style web services. WSDL 2. 0 allows developer to specify RESTful services with the addition of an HTTP-specific sub-namespace. There are proposals for extending BPEL to cover RESTful services, in particular in the open source Apache ODE (Orchestration Director Engine). By the way, WSDL and BPEL specifications are formatted in XML! EMTM 600 2011 Val Tannen 31

Alternatives to XML RESTful services can transfer XML-encoded resource state. But most developers today prefer alternatives which are easier to read by humans: JSON (Java. Script Object Notation). (Not really object-oriented: “objects” are sets of key-value pairs. Can be statically typechecked using JSON Schema. Works well with AJAX and developers love it! YAML (“recursive” (!) acronym: YAML Ain’t Markup Language). Like JSON but even more human-readable. Without quotes or braces, uses indentation instead. SOX (Simple Outline XML) Just a compressed way of writing XML while avoiding some of the angle brackets and tags… EMTM 600 2011 Val Tannen 32

JSON YAML { --receipt: Oz-Ware Purchase Invoice date: 2007 -08 -06 customer: given: Dorothy family: Gale items: - part_no: A 4786 descrip: Water Bucket (Full) price: 1. 47 quantity: 4 - part_no: E 1628 descrip: | High Heeled "Ruby” Slippers size: 8 price: 100. 27 quantity: 1 bill-to: &id 001 street: | 123 Tornado Alley Suite 16 city: East Centerville state: KS ship-to: *id 001 delivery: > Follow the Yellow Brick Road to the Emerald City. Pay no attention to the man behind the curtain. "first. Name": "John”, "last. Name": "Smith", "age": 25, "address”: { "street": "21 2 nd Street", "city": "New York”, "state": "NY", "postal. Code": "10021" }, "phone. Number": [ { "type": "home", "number": "212 555 -1234" }, { "type": "fax", "number": "646 555 -4567" } ] } EMTM 600 2011 Val Tannen XML

A very brief page

The WS Future Vision vs. Today’s Reality • The standards landscape is still confusing, and sometimes confused. JBI (Java Bus. Integr. ) a message-passing plug-in architecture based on BPEL • Hope: WS-I (Web Services Interoperability Organization) (http: //www. ws-i. org) for guidance, best practices and resources • Today most companies use web services for simple, tactical integration projects (see next) • Developers still grappling with SOA design principles • Human-based discovery working just fine for the moment; local registries are very useful in EAI (Enterprise Application Integration) EMTM 600 2011 Val Tannen 34

Using Web services in Enterprise Application Integration Pros: • XML is a flexible data exchange format that can deal with complex data types better than CORBA-IDL. • Web services separate not only interfaces from implementations (so does CORBA) but also from the transport protocol. That’s because XML transport is easily supported by all protocols. All this motivated Microsoft to put out. NET! The response of the Java world has been interoperability standards between the Java technologies and the Web services standards: • JAXP (Java API for XML Processing • JAX-WS (Java API for XML Web Services) (formerly JAX-RPC) • SAAJ (SOAP with Attachments API for Java) • JAX-RS RESTEasy (available through JBoss/Red Hat) • Con: XML processing and HTTP transport are SLOW! EMTM 600 2011 Val Tannen 35

Web Services in the J 2 EE Architecture The Java-Web Services specs (JAX-RPC for J 2 EE and JAX-WS for Java (5) EE) say that any Java Bean can be adapted to implement a Web service. Best practice: do it with session EJB! Reason: security! presentation controller HTML Servlets JSP Java Beans SOAP/ WSDL EMTM 600 2011 bad security domain Session EJBs data mapping Entity EJBs data source App. Serverspecific JDBC Web Serverspecific Val Tannen 36

Adapting a Session EJB to become a Web Service 1. Adapt the session EJB’s remote interface to a JAX-RPC/JAX-WS compliant SEI (Service Endpoint Interface) 2. Compile the SEI to a WSDL file (automated with the Apache open source tool Java 2 WSDL) 3. Compile the WSDL file into deployment information (automated with tool: WSDL 2 Java) which is vendor-specific; better standardized in JAX-WS. 4. Make the Web service deployment information compatible with the EJB deployment information (vendor-specific) 5. Add a SOAP HTTP request handler (automated with tool: endpt. Enabler, appears to be also vendor-specific, but it’s better standardized in JAX-WS) 6. Deploy the Java EE application; it now includes a Web service EMTM 600 2011 Val Tannen 37

From the SEI to a WSDL document with Java 2 WSDL • One session EJB -> one SEI (normally) • Several SEIs, processed together by Java 2 WSDL-> one service. • Each SEI -> just one port (endpoint) in the service. • The name of the SEI becomes the name of the port. • The name of the SEI concatenated with “Service” becomes the name of the service. • Each method in the SEI becomes an operation of the unique port. • The name of the method becomes the name of the operation. • The name of the method concatenated with “Request” and “Response” become the names of the input and output messages of the operation. EMTM 600 2011 Val Tannen 38

Request-Response Operation (*) public interface Stock. Quotes extends java. rmi. Remote { public float get. Avg. Price(String symbol, int no. Days); } Java 2 WSDL EMTM 600 2011

Val Tannen 39

More complex architectural ideas • The session EJB transformed into a web service that we just saw is an instance of the Web Service Broker pattern combined with the Remote Façade pattern. • However, we often have multiple application services we want to organize and expose as coarse-grain web services. Then we use Web Service Broker (registry) in conjunction with Application Service and possibly with Service Locator. EMTM 600 2011 Val Tannen 40

More complex architectural ideas, cont’d • The web server can be bypassed: no need for a proxy in the web server, the web service requests can be sent directly to the EJB container. • In EJB 2. 0 they would first have to be adapted to JMS and a message-driven bean would receive them. The MDB follows the pattern Service Activator. • However, the EJB 3. 0 container supports Web services directly. Just annotate an EJB with @Web. Service(, its methods with @Web. Method and their arguments with @Web. Param. • JAX-WS specifies how to obtain a WSDL file from that, no need for a separate SEI. • In EJB 3. 0, the Service Activator components come with the implementation! EMTM 600 2011 Val Tannen 41

Best practices for using WS with Java EE • A Java EE application can be a WS endpoint server but it can also be a client to other Web services! If those are also implemented in Java we can use the same Java <-> WSDL tools in both apps! • Do not use Web services between the logical layers of a Java EE application. Reasons: • • Serialization/deserialization overhead XML parsing overhead No good transaction support (yet) No good security support (yet, but see OASIS WSS later) • In general, avoid fine-grain use of Web services, for the same reasons. (And note that these reasons are similar to those behind the Remote Façade pattern!) • More generally, defining services with the right granularity is the key to SOA success. EMTM 600 2011 Val Tannen 42

More best practices for WS / Java EE • Use Web services for widely distributed fat clients; SOAP over HTTP will work in places where RMI over IIOP won’t, such as integration with. NET apps. • Web services do provide an alternative to using MOM (Message Oriented Middleware). Implementing asynchronous Web services follows the same patterns used for MOMs and messaging-based enterprise application integration (EAI). • We can combine Java EE advantages with asynchronous services using Message-Driven Beans (and therefore JMS). This is sometimes called SOAP over JMS but it’s really SOAP over whatever protocol JMS is built on, with JMS as an adapter. EMTM 600 2011 Val Tannen 43

Web Services and Security • SOAP has in essence the same security issues as CORBA, RMI, or MOM. (DCOM is even less secure because of the COM registry): clear need for authentication and authorization. • But SOAP is so simple that it is used without thinking that: • SOAP services are accessible through HTTP on port 80; • • Firewalls don't block communications on port 80! It’s not enough to use SSL (https instead of http), it doesn’t do authentication and authorization! • In contrast, CORBA, MOM, and Java EE programmers include security as a basic concern routinely and have tools that simplify their job • To secure SOAP and therefore web services, the security must be implemented by the application, not by the transport protocol. EMTM 600 2011 Val Tannen 44

Web Services and Security, cont’d • Standards for secure SOAP took a long time to be formulated but now we have: (WSS) Web Services Security 1. 1 a. k. a WS-Security 1. 1 from OASIS (http//: www. oasis-open. org) • Based on security tokens inserted in the SOAP messages and on digital signatures. “Security tokens assert claims and can be used to assert the binding between authentication secrets or keys and security identities. An authority can vouch for or endorse the claims in a security token by using its key to sign or encrypt (it is recommended to use a keyed encryption) the security token thereby enabling the authentication of the claims in the token. An X. 509 certificate, claiming the binding between one’s identity and a public key, is an example of a signed security token endorsed by the certificate authority. “ EMTM 600 2011 Val Tannen 45

More on Web Services and Security • OASIS WSS is a very flexible mechanism; the idea of security token will be probably adopted in the future by other security specification, such as the Java Security API. • Through the Java Web Services Developers Pack 1. 6, we can now use in Java EE an implementation of OASIS WSS called XWSSecurity which can be used in conjunction with JAX-WS. • OASIS WSS 1. 1 is now also implemented by. NET EMTM 600 2011 Val Tannen 46

Claimed benefits of SOA • Increased “intrinsic interoperability” and ability to “federate”, i. e. , positive impact on EAI • Increased vendor diversification options • Increased organizational agility • Increased business and technology domain alignment • Increased ROI • Reduced IT burden Biggest risks • Inadequate performance • Neglect of user needs EMTM 600 2011 Val Tannen 47