Enterprise Service Bus

1. Enterprise Service Bus • Customized company message broker • Arriving SOA requests • Using TCP/IP, SOAP, JMS, FTP etc. protocol • Wrapped by ESB layer • To provide web based inputs to an organisations legacy business process orchestration technology • Something of a “buzz” word (c) Ian Davis

2. Asynchronous Messaging • Peer-to-Peer • Peers talk to other Peers one at a time • May expect synchronous or asynchronous response • Asynchronous handled by a callback (new thread) • Publish-Subscribe (one to many messaging) • Provider communicates with Topics • Subscribers dynamically subscribe to Topics (Implicit Invocation / Observer design Pattern) • Topics may be organised hierarchically • Topics forward messages to subtopics/servers (c) Ian Davis

3. Application Servers • Client/Browser Side (Not part of server) • HTML, Javascript, Ajax • Web Tier (e.g. Apache, Tomcat) • Receives requests • Invokes web server-hosted components • JSP (Java Server Pages), ASP, PHP, etc. • Invokes business component tier • JavaBeans, .NET, CORBA • Invokes Enterprise Information Systems Tier • MySQL, Backend Mainframe, etc (c) Ian Davis

4. Enterprise JavaBeans (EJB) • Top layer is a Java Virtual Machine • This hosts components • Session Beans (Synchronous) • Stateless (consecutive requests to any instance) • Stateful (caller binds to one specific instance for life) • Message-driven Beans (Asynchronous) • No explicit reply (c) Ian Davis

5. Mobile Architecture (c) Ian Davis

6. Examples • Software downloaded before execution • Java Applets download jar when used • Javascript embedded in transmitted HTML • Viruses (e.g. Liquid and Hadoop) • Hadoop • Move the code to where it is needed • Move the code to become local to the data • Not massive amounts of data to remote code (c) Ian Davis

7. Message Oriented Choices • Delivery: Best effort, Persistent, Transactional • UDP , TCP/IP, Message Queues • Blocking / Non-Blocking / Asynchronous Sockets • Blocking good for simple connection (layered) • Non-Blocking more flexible since no waiting (layered) • Eg: Cancel attempt to connect, switch to different web page • Asynchronous efficient/elegant/scales well (event driven) • Keep track of connection state – not every connection • Interface: Sockets, RPC, HTTP, SOA, Ajax, Stream (c) Ian Davis

8. Representational State Transfer(ReST) • URL + Parameters returns Document • Leverages Standard Web Technology • GET/POST/PUT Built on top of Email • Stateless • Except for Cookies and/or Session • Server indicates cacheability • AJAX • Small document transfers while viewing (c) Ian Davis

9. Throughout the HTTP standardization process, I was called on to defend the design choices of the Web. That is an extremely difficult thing to do within a process that accepts proposals from anyone on a topic that was rapidly becoming the center of an entire industry. I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST Roy Fielding on his 2000 PhD thesis (c) Ian Davis

10. RESTful Web Services • Web services only uses HTTP as a transport layer (to fool firewalls) • Representational State Transfer (REST) • Resources identified by a URL • Message passing mechanism • GET (Parameters follow URL) • POST (Parameters body of HTTP message) • PUT (Upload to a named URL) • DELETE (Delete now/later something at named URL) (c) Ian Davis

11. ReST Constraints • Client/Server → Parallel evolution (Adaptable) • Stateless → Scalable • Cacheable → Efficient • Layered → Transparency • Mobile Apps → Powerful • Uniform Interface → Usable Wikipedia (c) Ian Davis

12. Uniform Interface • Identification of all universal resources • Naming of things (conceptual separation) • URL / URI • Manipulation of resources • Client read, change or delete a named resource • Self descriptive messages • Nothing is assumed by the server (Extensible) • Hypermedia (Resources explain themselves) • Circumvents Firewalls by using HTTP port (c) Ian Davis

13. Get versus Post • GET → Retrieve Parameterized URL • Visible so bad for sensitive data • Can be changed which is bad for security • Can be cached, bookmarked, in history • Length restrictions on parameterization • POST → Send data to the server in email • Hidden so better for sensitive data (but not safe) • Can’t be cached, bookmarked or remembered • No length restrictions (c) Ian Davis

14. Semantic Web • Effort to give XML entities real semantics • Namespaces disambiguate entity names • XMLSchema types the contents of an entity • RDF describes semantic information as graph • Resource Description Framework • RDFS uses RDF to describe objects • OWL defines ontological relationships (isa/hasa) • SPARQL permits queries about semantics (c) Ian Davis

15. Service-oriented Architecture(Web Services) • Fix interoperability problems • Vendors agree on standards for application integration • This provides interoperability across hardware, software, companies and infrastructures • Provide internet-scale distributed systems • Vendors agree on standards for distributed computing (c) Ian Davis

16. SOA design considerations • Boundaries are explicit • Crossing process, machine, trust expensive • Services are autonomous • Can change code, language, machine transparently • But must preserve backwards compatibility • Services simply receive messages and reply • Not objects, no interfaces, inheritance etc. • Client/server policy part of connecting design • Things like message reliability, security, encodings (c) Ian Davis