Service Oriented Architecture

1)A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA, see Prior serviceoriented architectures (new window). Whether you realize it or not, you've probably relied upon SOA, perhaps when you made a purchase online. Let's use Land's End as an example. You look at their catalog and choose a number of items. You specify your order through one service, which communicates with an inventory service to find out if the items you've requested are available in the sizes and colors that you want. Your order and shipping details are submitted to another service which calculates your total, tells you when your order should arrive and furnishes a tracking number that, through another service, will allow you to keep track of your order's status and location en route to your door. The entire process, from the initial order to its delivery, is managed by communications between the Web services -- programs talking to other programs, all made possible by the underlying framework that SOA provides.

Services If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. See Service (new window). Connections The technology of Web services (new window) is the most likely connection technology of service-oriented architectures. Web services essentially use XML (new window) to create a robust connection. The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained (new window). A service provider can also be a service consumer.

2.A)Web Services make up a connection technology. It is a way to connect services together into a service-oriented architecture. Primary elements of Web Services are:   

Repository Messaging Service

B) Application server definition: An application server is a component-based product that resides in the middle-tier of a server centric architecture. It provides middleware services for security and state maintenance, along with data access and persistence. Java application servers are based on the Java™ 2 Platform, Enterprise Edition (J2EE™). J2EE uses a multi-tier distributed model. This model generally includes a Client Tier, a Middle Tier, and an EIS Tier. The Client Tier can be one or more applications or browsers. The J2EE Platform is in the Middle Tier and consists of a Web Server and an EJB Server. (These servers are also called "containers.") There can be additional sub-tiers in the middle tier. The Enterprise Information System (EIS) tier has the existing applications, files, and databases. For the storage of business data, the J2EE platform requires a database that is accessible through the JDBC, SQLJ, or JDO API. The database may be accessible from web components, enterprise beans, and application client components. The database need not be accessible from applets. See the related content links below for more information.

C) Middle-tier databases: There are many database options available for middle-tier databases, because they essentially store temporary data. This is in contrast to EIS-tier databases that are often seen as databases of record, which are expected to last "forever." When you are considering a database product for an EIS-tier database, it is reasonable to choose a relational database product from a well-known, established company. In contrast, middle-tier databases - because they are temporary - open up the possibilities of using technologies that might significantly improve performance and reduce development as well as maintenance costs. Listed below are the two primary reasons to consider middle-tier persistence, along with reasons why the databases are temporary:

1. Persistent cache in the middle tier. The data stored in the middle-tier only is what is needed to support the processing in the middle tier. All the data is eventually written to the EIS-tier database. 2. Consolidated data in the middle tier. This data is consolidated only in the middle tier. You can think of it as "publishing" a catalog to the middle tier. Much like a catalog, the data in the middle tier may be there for weeks, months, or even a year - but it is very unlikely to be there for years or decades as in the case of a master database. D) Web Services adapters::

Web Services adapters allow Web Services connections to systems that were not originally developed with Web Services in mind. Adapters can be written in-house or purchased from third-party software vendors. Some examples of systems that could use adapters include: Internally developed systems Packaged software Database systems CORBA DCOM When a message router uses Web Services, it is shown one line is shown connecting to the message router instead of one line to each of the connected systems as shown in Web Services message routers. The following figure shows two of the internal systems using adapters. This is meant to represent that some internal systems may need adapters that are not part of the internal system. These adapters could be written in-house or purchased from third-party software vendors.

E) Web Services message routers Message routers direct data from a requesting resource to a responding resource and back. These are also known as application brokers, message brokers, or XML data routers. A router "knows" which of the other internal systems needs to receive a certain types of updates. The individual internal systems can pass updates to a router and would not need to know who receives such updates. A message router usually needs to transform the data in some way in order to match the format of the data expected by the receiving system