We have discussed on how to design a RESTful web service in our report. Following is the example of Lists XML and Schema. 

EXAMPLE Lists XML and Schema

<?xml version=”1.0″ encoding=”UTF-8″?>

<lists xmlns=”http://www.foo.com/v1/schema.rng”

       xmlns:foo=”http://fooapis.com/v1/base.rng”

       foo:start=’1′

       foo:total=’89′

      foo:count=’2′>

  <list foo:uri=”http://www .foo.com/v1/list/1″

        foo:created=”2009-03-14T00:00:00Z”

        foo:updated=”2009-03-14T00:00:00Z”>

    <id>1</id>

    <name>Shopping</name>

  </list>

  <list foo:uri=”http://www.foo com/v1/list/2″

        foo:created=”2009-03-14T00:00:00Z”

        foo:updated=”2009-03-14T00:00:00Z”>

    <id>2</id>

    <name>ToDo</name>

  </list>

</lists>

<define name=”lists”>

  <element name=”lists”>

    <ref name=”collectionAttributes” ns=”http://fooapis.com/v1/base.rng”/>

    <zeroOrMore>

      <ref name=”list” ns=”http://www.foo.com/v1/schema.rng”/>

    </zeroOrMore>

  </element>

</define>

EXAMPLE list XML and Schema

XML

<?xml version=”1.0″ encoding=”UTF-8″?>

<list foo:uri=”http://www.foo.com/v1/list/42″

       xmlns=”http://www.foo com/v1/schema.rng”

       xmlns:foo=’http://fooapis.com/v1/base.rng’ 

      foo: created=”2009-03-14T00:00:00Z”

      foo:updated=”2009-03-14T00:00:00Z”>

    <id>42</id>

    <name>Favorite Songs</name>

</list>

SCHEMA

<define name=”list”>

  <element name=”list”>

    <ref name=”resourceAttributes” ns=”http://fooapis.com/v1/base.rng”/>

    <element name=”id”>

      <data type=”integer”/>

    </element

    <element name=”name”>

      <text/>

    </element>

  </element>

</define>

EXAMPLE items XML and Schema

XML

<?xml version=”1.0″ encoding=”UTF-8″?>

<items xmlns=”http://www.foo.com/v1/schema.rng”

       xmlns:foo=”http://foo apis.com/v1/base.rng”

       foo:start=”1″

       foo:total=”89″

       foo:count=”2″>

  <item foo:uri=”http://www.foo com/v1/list/1/item/7″

        foo: created=”2009-03-14T00:00:00Z”

        foo:updated=”2009-03-14T00:00:00Z”>

    <id>7</id>

    <content>2 Dozen Eggs</content>

  </item>

  <item foo:uri=”http://www.foo.com/v1/list/1/item/11″

        foo:created=”2009-03-14T00:00:00Z”

        foo:updated=”2009-03-14T00:00:00Z”>

    <id>11</id>

    <content>Cornflakes</content>

  </item>

</items>

SCHEMA

<define name=”items”>

  <element name=”items”>

    <ref name=”collectionAttributes” ns=”http://fooapis.com/v1/base.rng”/>

    <zeroOrMore>

      <ref name=”item” ns=”http://www.foo.com/v1/schema.rng”/>

    </zeroOrMore>

  </element>

</define>

EXAMPLE item XML and Schema

XML

<?xml version=”1.0″ encoding=”UTF-8″?>

<item foo:uri=”http://www.foo.com/v1/list/42/item/33″

       xmlns=”http://www.foo.com/v1/schema.rng”

       xmlns:foo=’http://fooapis.com/v1/base.rng’ 

      foo:created=”2009-11-14T00:00:00Z”

      foo:updated=”2009-11-14T00:00:00Z”>

    <id>33</id>

    <content>Babies by Pulp</content>

</item>

SCHEMA

<define name=”item”>

  <element name=”item”>

    <ref name=”resource Attributes” ns=”http://fooapis.com/v1/base.rng”/>

    <element name=”id”>

      <data type=”integer”/>

    </element

    <element name=”content”>

      <text/>

    </element>

  </element>

</define>

the following is the presentation powerpoint guideline:

1. ( JAHNAVI ) The objective of our report is to compare between SOA and WOA.
*** What is SOA and WOA? SOA is … and WOA is a category of SOA…
*** Before we start the comparsion, we will briefly take a look into the history of SOA to understand how SOA evolved and the current technology stacks that support its implementation .
*** OUTLINE OF HISTORY and the transition  over Edwin by saying that now lets compare SOA and WOA

3. ( Edwin) Adv/Disadv. Compare SOA and WOA

4.  SOAP ( William )
brief on what is SOAP and how it is implemen ted in JAVA , code snipet

5. REST ( DAVID )

REST is a simpler model than SOAP, and builds directly on top of HTTP, rather than adding another layer on top of it. This makes it easier to use, faster, and more compatible with common HTTP caching mechanisms. There was an interesting experiment done at Amazon where they provided equivalent REST and SOAP APIs, and 85% of developers chose the REST APIs, presumably because they were just simpler to work with.

The Java community’s support for REST-based web services is not as mature as SOAP, but there are evolving standards in progress. Specifically, JSR 311, JAX-RS, defines a standard API for building REST-based web services, as easily as SOAP-based services with JAX-WS. JSR 311 is nearing a proposed final draft. It is targeted for inclusion in Java EE 6, which should also integrate JAX-RS with EJB. The reference implementation of JSR 311 is called Jersey. The project is about 1 year old, and has been through 11 releases in that time, as it tracks the progress of the proposed specification.

I WILL SUMMARY THIS PAGE BEFORE THE PRESENTATION

http://java.sun.com/developer/technicalArticles/WebServices/restful/

6.  (Rania) Take points from magnazine

• From our last engagement, I think we just need to tie our individual section into the report.  (David’s email)
• Everyone please include some comparison detail in your part of outline.
• David and William: write more detail on technical/theoretical points on WOA and SOA.
• Rania: Compare companies who use WOA and SOA.
• Jath: How SOA evolve to WOA.
• Edwin: Compare pro and cons in more detail.
• Decide date and time for face-to-face meeting in class this week.

SOA and WOA work at different layers of abstraction. SOA is a system-level architectural style that tries to implement new business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumer. However, since there is significant overlap between SOA and WOA, compare the two is a helpful way to understand the difference.

Similarity:

Ø   Both approaches leverage HTTP.

Ø   Both self-describing data formats such as XML.

Ø   Both concerned about the use of open standards, and can be used to build systems of arbitrary complexity.

Difference:

Ø   SOA tend to have a small and well-defined set of endpoints through which many types of data and data instances can pass.

Ø   WOA tend to have large and open-ended number of endpoints for each one of individual resources. Not an endpoint for each type of resource, but a URI-identified endpoint for each and every resource.

Ø   SOA builds a messaging layer above HTTP using SOAP and providing unique and sometimes prohibitive constraints to the Web developer.

Ø   WOA finds HTTP and related transfer mechanisms to be the ideal layer of abstraction for most applications.

Ø   SOA was designed from the top-down by vendors to be tool friendly.

Ø   WOA was emerged from the bottom up from the Web naturally and has the best support in simple procedural code and an XML parser.

Ø   SOA uses WS-Security and other sophisticated standards for security.

Ø   WOA tends to just use HTTPS for security.

Ø   SOA must contend with the vagaries of XML Schemas for service contracts.

Ø   WOA largely ignores the issue and lets Web services naturally represent whatever formats are desired.

Ø   SOA is fairly cumbersome to consume in the browser and in mashups.

Ø   WOA is extremely easy to consume just about anywhere.

After the comparison, here are pros and cons of SOA and WOA.

SOA

Pros:

Ø  Involve business more closely and directly in defining business process.

Ø  Closer alignment of actual business requirements with software specs.

Ø  Processes/services more adaptive to changes in business requirements due to extra abstraction of business process composition layer. Previously application logic was hardcoded to business logic/requirements which kept on changing.

Ø  Re-use of business logic in the form of services at the macro/enterprise level.

Ø  Integration within enterprise, across enterprise is based on standards for service description, service implementation stack, service registration and lookup, service invocation.

Cons:

Ø  Issues with services being stateless.

Ø  Issues with performance due to technology stack for implementation and due to statelessness as well.

Ø  Currently a service can be assured of transaction only within itself, there is no standard transactional behavior support at the level of a process.

Ø  Service interaction is popularly based on RPC-like request-reply paradigm, which is not as conducive to lose coupling as are event based interactions with an intermediary like a queue.

Ø  Not enough importance is given to the removal of hidden coupling introduced between services due to sharing of persistent data.

WOA

Pros:

Ø  Improved service consumption models that are less expensive and time consuming.

Ø  Easier to implement.

Ø  Unleashing the great power of link architecture to drive information discovery, leverage, and analysis.

Ø  Provides an excellent on-ramp to access the many powerful new online product distribution models currently available.

Ø  Can bring an extensive set of techniques, from syndication to extraordinarily low-impedance Web services.

Ø  URI-identified endpoint.

Cons:

Ø  Tends to mean hardcoded business processes into the infrastructure.

Ø  Using HTTPs for security

Ø  Don’t have clear business requirements/standards with software specs.

Ø  Rely on web protocol, cannot exist without it.

By Pai-Cheng (Edwin) Tung

With any software development cycle, there is always a conceptual design phase.  For conceptual design phase for RESTful webservice, one normally go through an iterative process called resource modeling. It’s important to understand that designing as resources is more complicated than regular object-oriented design. In a typical OO design, one normally has an object that exposes any number of methods.  On the contrary, with HTTP resource, one must exposes a uniform interface: GET, PUT, POST and DELETE methods.  Exposing every single behavior through HTTP resource interface can add a splash of complexity into the mix.  With that said about the resource modeling complexity and due to the scope of this project, we will go through this design section and make the design process as prescriptive as possible.

The following is a list of steps for designing a RESTful webservice.:

1.    Determine the data set
2.    Break data set into resources
3.    Determine resource containment hierarchy
4.    Create a URI for each resource
5.    Select appropriate HTTP verbs for each resource
6.    Design incoming and outgoing resource schemas

To look little closely into each of the design process mentioned above, we will design a simple RESTful webservice listing service.

Step 1 Determine Data Set

The Web Service we’re building needs to understand and document the data that lies behind the resource-oriented API and is to be exposed.

The List service’s data model is simple; there are lists, and lists contain items. An item can only be included in one list at a time. The tables for the list service are shown below:

List
listID: int (primary key)

Name:string

list contains 0-n of item

Item
itemID: int (primary key)

content: string

listID: int ( foreign key )

Step 2 Determine Resources

A resource is something.  It is a noun.  Anything that might be identified by a name or anything interesting enough to have a link may be a resource.
There are essentially two different kinds of things in our resource model: Collections and Resources. Collections are resources that contain one or more singleton resources. Resources might typically model objects that the service wants to expose, but one must keep in mind that the only methods allowed are from the uniform interface. From our list data set it is relatively straightforward to determine that our resources are list and item.

Step 3 Determine Resource Containment Hierarchies

It’s important to understand that from a schema perspective a Collection must not directly contain a Collection or a Resource that contains an embedded Collection. From an addressability point of view collection containment is supported and encouraged. An example may help illustrate the difference:

GET lists would return a collection of list items. Each list item would contain data about the list, for example, name, but not the contents of each list. To obtain the content of the list the request GET list {_list_ _identifier_} is used. From a modeling point of view, the collection of item resources is modeled as a collection of list items.

Based on the resources determined above, it’s relatively easy to determine our collection’s hierarchy. The standard is to specify to pluralize the name of each collection:

* A lists collection that contains a collection of list resources

* A list/1234 resource that identifies a specific list, in this case 1234, which contains the Name of the list and a collection of type item.

* An item/5678 resource that identifies a specific item, in this case 5678, which contains the item’s content

Step 4 Create a URI For Each Resource

Resource    URI
Lists    http://hostname/v1/lists
List    http://hostname/v1/lists/{listID}
Items    http://hostname/v1/lists/{listID}/items
Item    http://hostname/v1/lists/{listID}/item/{itemID}

Some of the URIs in the above table contains identifiers within braces. These identifiers vary at runtime and are usually used to identify a unique resource.

Step 5 Select Appropriate HTTP Verbs For Each Resource

As specified in the Standards for HTTP Web Services, only the specified HTTP verbs can be used and only as specified in RFC2616. In summary:

* HTTP GET must be used to retrieve a representation of a resource or perform a filter operation.

* HTTP HEAD must be used to retrieve header information about a resource.

* HTTP POST must be used to create a new resource.

* HTTP PUT must be used to update a known singleton resource and may be used to create a new resource ONLY when the client is allowed to control the naming of the resource.

* HTTP DELETE must be used to delete a known resource.

* HTTP OPTIONS must be used to query a resource for information about what operations can be performed on it.

For the List service we want to be able to perform the following:

* Retrieve a collection of lists
* Create a new list
* Retrieve a list
* Retrieve a collection of items contained in a list
* Add a new item to a list
* Delete a list
* Retrieve an item
* Update an item
* Delete an item

The table below shows which HTTP verbs are applied to which resource to provide the behavior required above:

Resource    HTTP Verb    Description
/lists    GET,POSTS    GET returns the collection of lists, and POST adds a new list to the collection
/list/{listID}    GET,DELETE    GET returns a list resource and DELETE removes the list from the collection of lists.
/list/{listID}/items    GET,POST    GET returns the collection of items fro the list and POST adds a new Item to the specified list
/list/{listID}/item/{itemID}    GET,PUT,DELETE    GET returns an item resource, PUT updates a specific item, and DELETE removes the item from the list.

Design Incoming and Outgoing Resource Schemas

The table below describes the list service’s incoming and outgoing schema requirements:

Resource    HTTP Verb    Schema Requirements
/lists    GET     A collection of type list
/lists    POST    A single list type
/list/{listID}    GET    A single list type
/list/{listID}    DELETE    Not Required
/list/{listID}/items    GET    A collection of type item
/list/{listID}/items    POST    A single item type
/list/{listID}/item/{itemID}    GET    A single item type
/list/{listID}/item/{itemID}    PUT    A single item type
/list/{listID}/item/{itemID}    DELETE    Not Required

Summarizing from the table above we need to define the following schema’s for the list service:

* lists
* list
* items
* item

EXAMPLE Lists XML and Schema

<?xml version=”1.0″ encoding=”UTF-8″?>
<lists xmlns=”http://www.foo.com/v1/schema.rng”
xmlns:foo=”http://fooapis.com/v1/base.rng”
foo:start=’1′
foo:total=’89′
foo:count=’2′>
<list foo:uri=”http://www .foo.com/v1/list/1″
foo:created=”2009-03-14T00:00:00Z”
foo:updated=”2009-03-14T00:00:00Z”>
<id>1</id>
<name>Shopping</name>
</list>
<list foo:uri=”http://www.foo com/v1/list/2″
foo:created=”2009-03-14T00:00:00Z”
foo:updated=”2009-03-14T00:00:00Z”>
<id>2</id>
<name>ToDo</name>
</list>
</lists>

<define name=”lists”>
<element name=”lists”>
<ref name=”collectionAttributes” ns=”http://fooapis.com/v1/base.rng”/>
<zeroOrMore>
<ref name=”list” ns=”http://www.foo.com/v1/schema.rng”/>
</zeroOrMore>
</element>
</define>

EXAMPLE list XML and Schema

XML
<?xml version=”1.0″ encoding=”UTF-8″?>
<list foo:uri=”http://www.foo.com/v1/list/42″
xmlns=”http://www.foo com/v1/schema.rng”
xmlns:foo=’http://fooapis.com/v1/base.rng’
foo:created=”2009-03-14T00:00:00Z”
foo:updated=”2009-03-14T00:00:00Z”>
<id>42</id>
<name>Favorite Songs</name>
</list>

SCHEMA
<define name=”list”>
<element name=”list”>
<ref name=”resourceAttributes” ns=”http://fooapis.com/v1/base.rng”/>
<element name=”id”>
<data type=”integer”/>
</element
<element name=”name”>
<text/>
</element>
</element>
</define>

EXAMPLE items XML and Schema

XML
<?xml version=”1.0″ encoding=”UTF-8″?>
<items xmlns=”http://www.foo.com/v1/schema.rng”
xmlns:foo=”http://foo apis.com/v1/base.rng”
foo:start=”1″
foo:total=”89″
foo:count=”2″>
<item foo:uri=”http://www.foo com/v1/list/1/item/7″
foo:created=”2009-03-14T00:00:00Z”
foo:updated=”2009-03-14T00:00:00Z”>
<id>7</id>
<content>2 Dozen Eggs</content>
</item>
<item foo:uri=”http://www.foo.com/v1/list/1/item/11″
foo:created=”2009-03-14T00:00:00Z”
foo:updated=”2009-03-14T00:00:00Z”>
<id>11</id>
<content>Cornflakes</content>
</item>
</items>

SCHEMA
<define name=”items”>
<element name=”items”>
<ref name=”collectionAttributes” ns=”http://fooapis.com/v1/base.rng”/>
<zeroOrMore>
<ref name=”item” ns=”http://www.foo.com/v1/schema.rng”/>
</zeroOrMore>
</element>
</define>

EXAMPLE item XML and Schema

XML
<?xml version=”1.0″ encoding=”UTF-8″?>
<item foo:uri=”http://www.foo.com/v1/list/42/item/33″
xmlns=”http://www.foo.com/v1/schema.rng”
xmlns:foo=’http://fooapis.com/v1/base.rng’
foo:created=”2009-11-14T00:00:00Z”
foo:updated=”2009-11-14T00:00:00Z”>
<id>33</id>
<content>Babies by Pulp</content>
</item>

SCHEMA
<define name=”item”>
<element name=”item”>
<ref name=”resourceAttributes” ns=”http://fooapis.com/v1/base.rng”/>
<element name=”id”>
<data type=”integer”/>
</element
<element name=”content”>
<text/>
</element>
</element>
</define>

Abstracting enterprise information from underlying systems. eBay employs SOA as a software-based integration tier to manage more than two petabytes of data; there are 30,000 software builds per week. “eBay has built a service architecture and uses it to enable integration across disparate technology stacks. For example enabled open interoperation between our C++ and Java technologies via services.”

Reducing application inventories., IBM had 77 shareable and reusable services in production — ranging from authentication to order fulfillment the most notable outcome of IBM’s internal SOA efforts is the fact that Big Blue was able to reduce its inventory of 16,000 applications in 1998 to 4,000 applications today. It’s how they went from more big integrated code applications to more component-based Web services.

“Rocking the boat,” bringing IT closer to the business, and improving business productivity. IT movers and shakers at Wachovia Bank used SOA techniques to “rock the boat” and changed their organization’s culture. Wachovia’s SOA consists of business services and frameworks available for reuse across the enterprise. Reuse was the driving force behind the project. One of the most notable improvements gained from the SOA has been in the productivity of the investment brokers. Before, a lot of them were modeling deals in Excel, and it would take anywhere from half an hour to a couple hours. One new shared service enabled developers to put together a high-performance modeling application that shaved this modeling time down to minutes. Another business unit was able to develop an equity desktop application in 90 days that traditionally would have taken six to 12 months to design and build from scratch.

Breaking up inflexible systems that were unresponsive to the business. Harley Davidson’s credit and loan origination process relied on tightly coupled financial systems that were cumbersome to adapt to new marketing programs. That made it difficult to seasonally adjust programs, such as for the annual springtime surge of showroom visitors who have dreams of riding motorcycles on the open road. Bu busting apart all of those systems, and put the SOA in the middle of all that. They were e able to change any one of those systems and not have to go and touch and test every single system.”

Cutting operational costs. Hewlett Packard implemented an SOA that has seen up to $70 million in savings. The initial paybacks from SOA came through consolidation, reduction of redundancy and reuse across services. At least $1 million of the savings happened right out of the starting gate — “The cost savings actually start on implementation.. Return on investment starts Quarter 1.

Delivering new products and services. Ameriprise Financial,which has had an SOA effort underway since 1999, has been able to save millions of dollars in development costs through reuse of crucial business services. Savings around avoiding duplicate build functions. What tends to happen in large companies is that’s its easier often to just think about building a new service that does 80 percent of the same thing as an existing service.”

Handling growing transaction loads as simply as possible. Amazon, the online retailer, needed a flexible architecture to handle what is now a base of 60 million customers and one million partners. The company originally used a mainframe, but it wasn’t enough,. The solution was to build Web services that could form a transaction layer to handle online business applications, while shielding the retailer’s databases. Without Service orientation works, they never could have built Amazon’s platform , Now Amazon developers can keep services as simple as possible, and not to get attached to any one technology or standard.

Enabling the “separation of powers” between corporate, divisions, and departments. senior vice president and chief SOA architect for Citigroup, said the company’s SOA governance structure is federated in nature, with a “separation of powers” similar to the way the US federal government is structured. That includes an “executive branch” (IT) oversees operational aspects, as well as development and design; a legislative branch” (executive management and board of directors) establishes the goals and directions of SOA efforts; and a  “judicial branch” (enterprise architectural boards) that deals with conflict resolution and compliance audits. In addition, Snow added, Citigroup’s SOA initiatives are divided along a separation of powers between the federal (enterprise) level, state (divisional) level, county (line of business), and municipal (departmental) level.

Moving business rules out of applications. OnStar, the vehicle communications platform, was moving its software business rules, now embedded in applications, to a middleware layer of reusable components. The company moved eight application platforms to the SOA middleware layer, starting with Emergency Services, Vehicle Services, Business Objects and Billing.  Such applications help handle service calls and provide remote vehicle diagnostics.

Making movies. Well, not directly use SOA to make movies, but to help run the companies that make movies. DreamWorks Animation SKG, producer of the Shrek trilogy (number 3 is due out in 2007), made a transition to SOA to simplify and consolidate key business operations. The company took a smelly green monster of an IT infrastructure — in the form of 12 legacy ERP applications running on Sun servers — and made it a bit more handsome, in the form of Linux servers, Oracle databases, and JBoss middleware. the reusability of SOA-based components as the greatest advantage coming out of the project increases the speed to write and deploy new applications with many of the reusable components that’s now part of the architecture The SOA model also supports company directories, employee bulletin boards, vacation requests, and cafeteria menus. It also supports a new copyright-tracking application with authorization and authentication features for incoming film scripts.

TORONTO – Nortel* (NYSE/TSX: NT) and IBM (NYSE: IBM) offer a software-based foundation that easily brings together business applications and processes with the latest unified communications and collaboration tools such as click-to-connect, presence, location and Voice over Internet Protocol (VoIP). This new foundation is built on the principles of service oriented architecture (SOA) so that businesses can communicate with colleagues, partners, and customers in new ways without compromising service, security or existing technology investments.

SOA Solutions for Business

SAP the world’s leading provider of business software offering applications and services that enable companies of all sizes s to become best-run businesses., announced that companies in Europe, the Middle East and Africa (EMEA) are continuing to embrace service-oriented architecture (SOA) and apply the latest technology advancements delivered through the SAP NetWeaver® technology platform to accelerate innovation, standardize business processes and drive competitive differentiation.Taking advantage of an SOA strategy with SAP enables organizations to optimize business operations in a multitude of ways that range from providing users with access to real-time data, increasing responsiveness to customers and collaborating better with partners, to rapidly addressing new regulatory requirements or even reducing carbon footprints through the elimination of paper processes.

With the SAP NetWeaver technology SOA moves IT architectures to higher levels of adaptability – and moves companies closer to the vision of real-time enterprises by elevating Web services to an enterprise level.

SAP’s core banking strategy sees SOA as the basis of the end-state architecture for a new generation of agile banking platforms, which will consist of a collection of ‘banking enterprise services’ that can be orchestrated by means of business process design and management tools. SOA enables banks to maximize the reuse of existing inhouse and third-party IT applications – for example, an application that a cashier uses to access customer account information in-branch can be reused by the customer to access their account online – the same service, just a different type of access.

SOA Solutions for Financial Services

Financial Service organizations face a number of challenges, including the need to consolidate acquired systems and data, the need to provide superior customer services across multiple products and channels and the need to meet an increasingly complex web of compliance, privacy and regulatory needs. Incompatible IT systems necessitate manual interventions across system boundaries, resulting in redundancy and errors. It is through removal of such barriers that information can be made available to those that need it, when they need it, both within the organization and out to subsidiaries and partners.

SOA Solutions for Health Care

An enterprise service is typically a series of Web services combined with business logic that can be accessed and used repeatedly to support a particular business process. Aggregating Web services into business-level enterprise services provides a more meaningful foundation for the task of automating enterprise-scale business scenarios.

Escalating costs of medical care, pharmaceuticals and medical equipment continue to be one of the most significant causes for concern in the healthcare industry. Healthcare providers recognize that integration help them achieveb etter service levels

SOA Solutions for Retail

It is fast becoming clear to retailers that integration improve in-store operations and realize greater efficiencies in their supply chain,.

SOA and GIS

GIS programs rarely plan effectively for expanding organizational adoption beyond their initiative’s initial scope. Employing a Service-Oriented Architecture (SOA) approach to GIS development, specifically expose GIS capabilities as Web services allow to create a flexible and extensible GIS that can quickly respond to changing and future organizational needs.

For example, address-location service to communicate with a marketing service so that organization can target its direct mail campaigns to addresses within a specific geographic region.

SOA and Intel

Intel offer a “vendor neutral” service-oriented architecture development tool that sidesteps the need for an enterprise service bus but promises to navigate between different network protocols and application file formats.

SOA Expressway is intended to speed up the conversion of large and small enterprise infrastructures to multiple, interoperable services, regardless of the technology origin of the service. It can integrate applications or services built inMicrosoft (NSDQ: MSFT)’s .Net, for example, with database servers or Web server applications built in Java.

SOA and Oracle

Oracle SOA Suite is a complete set of service infrastructure components for building, deploying, and managing SOAs. Oracle SOA Suite enables services to be created, managed, and orchestrated into composite applications and business processes. With Oracle SOA Suite’s hot-pluggable components, organizations can easily extend and evolve their architectures instead of replacing existing investments.

SOA and Airline

Service-oriented architecture has helped KLM fulfill its businessobjectives and has provided KLM with

the means to expand electronic services with innovation as a central feature of its approach. The new

SOA-based electronic-booking and Internet check-in applications are delivering significant performance

The SOA underpins the Reservation & Pricing Services Layer (RPSL) that supports the migration

of more than 30 e-commerce and operational applications from KLM legacy systems to the Amadeus

booking system, an industry-wide standard commodity service provider for airlines

to facilitate the move to third-party commodity services

•  The term SOA was coined in 1996 research paper by Gartner analyst   Yefim V. Natis.      
•  SOA is a software architecture that starts with an interface definition and builds the entire       application topology , interfaces, interface implementations and  interface  calls. 
•   SOA principals arose out of work with distributed objects. 
•   Experience with distributed object technologies (for example, COM and CORBA) led to a set of design principals, guidelines and best practice. 
•    It became popular to refer to these distributed objects as services. 
•  SOA could be thought of as the application of object-oriented principals to client – server architectures. 
•  Despite its early appearance, the term SOA became more prominent some years later around 2002/2003. 
•  Web services technologies provided a new interface definition language called WSDL (Web Services Definition Language )that is suitable for use in a SOA. 
• The term SOA was hijacked by marketers to lend credibility to their web  service products, with the message “you need our web services product for  SOA”. 
• SOA is not dependent on web services technologies.
• SOA predates them! 
• However, web services technologies are suitable for SOA. 
•  Remember: SOA is an architectural style, not a product.

SOA   BACKGROUND: 

“Core business capabilities are encapsulated within the independent software services and these services are leveraged by various front – end applications to fulfill the business requirements. 

• Message-based interactions
• Black – box implementations
• Communication over the network
• Platform neutrality
• Service description
• Loose coupling between system components.  

 

SOA/WOA

 WEB ORIENTED ARCHITECTURE:

Web-oriented architecture (WOA), a descriptive term for a subset of service- oriented architecture (SOA), has recently arisen as the next buzz-phrase to help further confuse the IT architect.  

WOA is simply a way of implementing SOA by creating services hat are RESTful resources, allowing any service or data to be accessed with a URI.

For many scenarios, this method dramatically simplifies things over the traditional WS approach. WOA resources are stateless and self-descriptive. Additionally, building SOA across intra-enterprise and in-the-cloud services becomes much easier with WOA.  

Long version:       WOA is an architectural style that is a substyle of SOA based on the architecture of the www with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages.    

Shorthand version:          WOA = SOA + WWW + REST 

WOA also provides an excellent on-ramp to access the many powerful new online product distribution models  currently available today. Distribution of SOA is a woefully neglected topic and WOA can bring an extensive set of techniques, from syndication to extraordinarily low-impedance Web services.  

 

By :   JAHNAVI   ATHULURU.

Break down project into assignments.

1. SOA/WOA background and history – http://en.wikipedia.org/wiki/Service_Oriented_Architecture
2. Various Implementations
3. REST vs SOAP ( what are the adv and disadv of each)
4. Tech industry toward SOA ( what companies are using SOA, what are they using it for )
5. Answer our project thesis

Assigning team member project assignment.