sMash_for_zOS-users

Editor's Notes

• #10: This image is of the “long tail” a popular concept in the Web 2.0 space… There is a class of business applications across small, medium and large businesses that are not well supported today. We refer to this type of application as the long tail of business applications. In contrast to the more ubiquitous, three lettered acronym applications (e.g. CRM, SCM, ERP), the applications found in the long tail are focused on more situational business needs and play a more supporting vs. primary role in the overall mission. Solutions to these situational business needs evolve as the needs of the situation change. Examples of these applications include applications for sales analysis, business dashboards, contact management, reporting, trade show mgmt, marketing resource mgmt, collateral distribution, and help desk functions. The value of these applications is often difficult to measure using traditional business metrics. These are applications built to address an immediate rather than long-term, strategic need and as such, are often relegated to lower skilled programmers (and CTOs who like to stay current) who follow a more casual, sometimes “ad hoc” approach to development. Frequently there is little or no budget for these applications and development takes place under the radar of central IT management by small teams working under an informal, unstructured approach. Little or no focus is given to scalability, maintainability, availability, etc. although many of these applications become mission-critical over time. Within the enterprise context these applications are frequently hosted in “lighter weight” environments rather than the production environment where mission critical applications are hosted. In an IBM MI study (Oct, 2005) Just over half of all respondents believed that the ad hoc application created as part of last ad hoc project profiled is now mission-critical to their company.
• #11: IBM executives are frequently meeting with customers either via phone or in person. Enabling them to quickly check for status of a specific customer and research evolving ‘situations’ is a critical element of managing customer satisfaction. The Customer Client Support Portal application was built to deliver detailed information to management with a ‘need to know’. However, management often finds themselves remote from a workstation or laptop. Access to CCSP through a mobile device was made available to deliver ‘on-demand’ information to executives on the move. Summary information is now available to mobile devices such as the Blackberry. The executives also have the ability to drill into specific situation details… This ‘situational’ application was built with an investment of less than 60 hours and less than 2000 lines of code. It accesses the primary CCSP database, provides more than 18 different formats for information and reuses services provided as part of the backend portal system. Goals of CCSP Mobile: Ease of use, simple to maintain & update, improve customer satisfaction. Reuse same services as main Portal application. Time to value: Written in < 60 hours. Consisted of < 2000 lines of code.
• #13: Key points: This slide introduces 3 WebSphere sMash differentiating themes which are used throughout the rest of the presentation – speed, simplicity and agility
• #14: Key points: sMash does not required a “PhD in JEE” to rapidly deliver robust applications Easy migration for developers already familiar with PHP, and Groovy is simple to pick up for those familiar with Java/JEE Tooling creates REST services and ATOM feeds by default
• #15: Key points: Enforcement of previous point – sMash is about dynamic scripting vs. programming. Java is only there for extensibility / interoperability Deeper dive into PHP support, PHP / Java / Groovy integration, in later section.
• #16: Key points: REST is a key Web 2.0 enabler, we’ll have a lot of discussion around REST in this briefing. Deeper dive in second section. ZRM is another key differentiator for the sMash platform and facilitates the development of data access applications in minutes Screenshots show an overview of a JSON (JavaScript Object Notation) data model, sample client scripts using ZRM API to access data and URLs for REST access
• #17: Key points: Fits into your programming style Many “simplicity” topics in sMash but we’ll focus on tooling first. Easy to use and feature-rich visual browser-based IDE (as well as Eclipse and command-line support) Screenshot shows the Flow Editor in the Application Builder – aggregating feeds and REST services to generate a consolidated report in MS Excel Event driven programming model similar to traditional UI programming. Configuration based on adherence to conventions and simple configuration file. More on programming model and configuration strategy in deep dive section.
• #18: Key points: Application Builder is a feature-rich Web development environment which makes sMash application development even simpler Includes extensive wizards and editors not available on Eclipse and command-line interfaces Application Builder is a significant differentiator for the IBM solution Screenshot is from the JSON (JavaScript Object Notation) structure editor
• #19: Key points: Demonstrates the breadth of the editors included in the Application Builder Visual UI Editor is suitable for simple pages today – more sophisticated and highly dynamic sites will still require AJAX scripting Flow editor allows ATOM feeds and REST services to be visually wired together and further enriched with script invocations. Visual flow is persisted in XML using a simplified BPEL syntax
• #20: Key points: “ Lightweight” but robust JSE-based runtime means less time waiting and more time developing Screenshot shows Application Builder “My Applications” page – where individual applications can be started/stopped
• #21: Key points: The simplified runtime model provides many benefits, but also requires a mental shift for existing JEE developers / administrators Full notes: One of the simplifications of WebSphere sMash is the notion that each application is a standalone runtime. Rather than loading runtime components 'just in case' the application might use them, the application runtime contains just the set of features that a single application is using and is thus small and efficient. There is no deployment process for WebSphere sMash applications. You simply have a set of files that represent your application and a set of dependencies on extension modules. You can copy the application to a machine, resolve the dependencies and start the application. Multiple applications can, of course, run simultaneously but they run independently providing isolation, simplifying versioning issues, and enabling easier management.
• #22: Key points: sMash defines a new level of consumability for IBM products. Gone are multiple DVDs of installation sources, replaced with a 5Mb core download which then pulls dependencies when required Packaging is done through Apache Ivy – a configuration-driven dependency manager extensively used by Java teams The organization of libraries into modules, and the associated dependency management scheme and remote repositories, greatly simplify the whole area of locating and resolving dependencies. Full notes: WebSphere sMash is designed so that application are based on a very small core that is approximately 5.4M that includes the Groovy support. The core provides all of the framework and runtime support including the HTTP runtime stack. To add to the core you may download modules by declaring dependencies in Ivy and then the package management system manages those dependencies allowing you to share dependencies, demand load dependencies and manage updates to the dependencies.
• #23: Key points: Screenshot is of a sMash Flow included in the Travel Request sample available from the sMash repository, and shows a simple approval process implementation
• #28: REST is based on a collection model. The action performed by the RESTful service is based on the combination of the URI and the HTTP methods. The table summaries the results of the combinations. In WebSphere sMash, the action is defined in the following format /resources/<collectionName>[/<memberID>[/<pathInfo>]] Where /<collectionName> identifies the resource that is the target of the action and the handler for that resource is by convention in the <apphome>/app/resources directory. Based on the type of resource, collection or collection member,
• #43: Change and Release Management for Software Development