Process Integration Presentation: October 27th Abstract & Articles

Abstract:

• A business process is "a collection of related, structured activities that produce a service or product that meet the needs of a client.”

• BPEL stands for Business Process Execution Language, and comes from a standards consortium consisting of BEA Systems, IBM, and Microsoft, BPEL combine.

• Business processes are the lifeblood of any organization. It is the visibility, efficiency and effectiveness of these processes that enable organizations to reach and exceed their goals and differentiate them within a fiercely competitive market.

• Through the process layer, business users can define, manage and measure their processes - this fundamental capability empowers business people to take direct ownership of their processes without having to defer to IT to implement each and every change.

• What were point solutions can now be made available as services throughout the business, as organizations move to architectures that are more service-oriented.

Readings:

• http://www.bpmodeling.com/
• SOA Approach to Integration: XML, Web Services, ESB, and BPEL in Real-World SOA Projects, by Matjaz, B. Juric et al., Packt Publishing © 2007
• http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf
• http://en.wikipedia.org/wiki/Business_process_modeling
• http://en.wikipedia.org/wiki/Business_Process_Execution_Language
• http://en.wikipedia.org/wiki/Business_process_management
  

CIS 8020 Assignment 2 SS Google Visualization

A consulting company is using census data provided by an epidemiologist to analyze the population trend of Atlanta Metropolitan area for the last 9 years and decide if it makes business sense for extension of Health Care infrastructure.

The same data is best understood if represented in a graphic form which has been demonstrated in my website using Column Chart from Google Visualization API. Refer to the visualization shown below.

Population Trend - Atlanta Metropolitan Area : 2000-2008

In this case, the source data for the presentation has been hosted and published in Google Docs (extracted from original census data).

We have also used tooltip to zoom on a particular column to get the actual value for a County.

Additionally, we can use the same API for representing similar data in various graphic forms for example Pie Chart, Line Chart, Tables, Motion Chart, Area Chart, Bar Chart etc.

A similar model can be used for visualization of data from Sales, Revenue, and Inventory etc.

Since any Excel file can be used as source data, the visual representation is automatically updated without any change in code just by republishing the changed data and hence can be used for tracking any dynamic data.

The API is easy to use and is highly parameterized. Hence the type of chart, size, font, color etc. can be modified quickly as required.

CIS 8020 Assignment 2 JM Google Maps

A small Atlanta company wants to have a map on its website that tracks all of their Atlanta office locations.  Besides just presenting this as just an image, they want to have the ability for users to interact with the map and be able to tell what the primary function of the office is.

Google Maps API is a good choice for the solution to this problem. It generates dynamic maps which can be easily integrated to any web page and allows end users to interact with. All the company needs to do is configure a few coordinate settings in the Google Maps API to make it work. The following is a prototype:

Compared to creating it from scratch, Google's Maps API is easy to use and setup. Creating a customized map interface only requires adding the Google JavaScript code to a page, and then using JavaScript functions to add points to the map.  It saves time in development and maintenance. It also saves on network bandwidth and processing power since the application is hosted by Google.

REST Presentation: October 6th Abstract & Articles

Abstract:

REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

Readings:

•Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000. - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

•Principled Design of the Modern Web Architecture by ROY T. FIELDING and RICHARD N. TAYLOR, ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002, Pages 115–150.

•http://www.infoq.com/articles/rest-introduction
•http://www.infoq.com/articles/designing-restful-http-apps-roth
•http://www.youtube.com/watch?v=YCcAE2SCQ6k
•http://www.ietf.org/rfc/rfc3986.txt
•http://soa.dzone.com/news/rest-%E2%80%93-good-bad-and-ugly
•http://rest.blueoxen.net/cgi-bin/wiki.pl?WhatIsREST#nid652
•http://www.prescod.net/rest/
•http://www.prescod.net/rest/rest_vs_soap_overview/
•http://www.petefreitag.com/item/431.cfm
•http://en.wikipedia.org/wiki/Representational_State_Transfer
•http://www.xfront.com/REST-Web-Services.html
•http://dret.net/netdret/docs/soa-rest-www2009/
•http://rest.elkstein.org/2008/02/what-is-rest.html

When to and When not to use REST

Architects and developers need to decide when this particular style is an appropriate choice for their applications.

A RESTFul design may be appropriate when:

• The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.

• A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, then the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.

• The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.

• Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.

• Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use technologies such as Asynchronous JavaScript with XML (AJAX) and toolkits such as Direct Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with, rather than having to start from scratch with new technology.

A SOAP-based design may be appropriate when:

• A formal contract must be established to describe the interface that the web service offers. The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.

• The architecture must address complex nonfunctional requirements. Many web services specifications address such requirements and establish a common vocabulary for them. Examples include Transactions, Security, Addressing, Trust, Coordination, and so on. Most real-world applications go beyond simple CRUD operations and require contextual information and conversational state to be maintained. With the RESTful approach, developers must build this plumbing into the application layer themselves.

• The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards such as WSRM and APIs such as JAX-WS with their client-side asynchronous invocation support can be leveraged out of the box.