WebServices Frameworks

Java WebServices Development Tools:

Apache CXF: Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.

Apache Axis2: is a Web Services / SOAP / WSDL engine, the successor to the widely used Apache Axis SOAP stack. There are two implementations of the Apache Axis2 Web services engine - Apache Axis2/Java and Apache Axis2/C.

Apache Wink: Apache Wink is a simple yet solid framework for building RESTful Web services. It is comprised of a Server module and a Client module for developing and consuming RESTful Web services.

JAX-WS: JAVA-API( XML-based Webservices, means mainly WSDL/SOAP though REST is possible too )

RI(Reference Implementation): JAX-WS: { javax.xml.ws.**.* , core Web services support } = JAX-WS “RI” [is subset of] Metro
Note: Metro = JAX-WS “RI” + WSIT/Tango ( WSIT/Tango provides support for Security, Reliability, Transactions and Interoperability with .NET 3.0 )

JAX-RS: JAVA-API( RESTful Web Services )
RI(RI(Reference Implementation): JAX-RS = { javax.ws.rs.**.* } = Jersey

AWS Toolkit for Eclipse: The AWS Toolkit for Eclipse is an open source plug-in for the Eclipse Java IDE that makes it easier for developers to develop, debug, and deploy Java applications using Amazon Web Services. With the AWS Toolkit for Eclipse, you’ll be able to get started faster and be more productive when building AWS applications.

Eclipse WST Web Services UI: The Web Services project is a sub-project in the Eclipse WTP Top-Level Project. The project consists of two components: The JST Web services component, which contains tools for developing and interacting with Java Web services and the WST Web services component, which contains tools for Web services development which is not Java specific.

Eclipse with Lomboz plugin: Lomboz is an open source and free J2EE development environment for businesses and individuals. You can develop, test, profile and deploy Web, Web services, Java, J2EE and EJB applications with this IDE. Lomboz has comprehensive support for most J2EE standard application server runtimes, and supports most popular open source runtimes such as JOnAS, and other vendor runtime environments. Lomboz is buillt on the Eclipse open source platform and the Web Tools Platform (WTP) projects.

OpenSource WebService Testing Tools:

• soapUI

• TestMaker

• WebInject

Miscellaneous:

• Tools to view HTTP requests and responses - Wireshark, Fiddler, IEInspector HTP Analyser, Firebug, HttpFox

           Web Development: Client side debugging tools/plugins inside Browser:

            Chrome => Chrome developer Tools ( F12 )

            Firefox  => FireBug/Poster

            IE          => Fiddler

• Tools to test RESTful Webservices - RESTClient(from GoogleCode; A Java application to test RESTful webservices), HTTP4E(REST HttpClient for Eclipse)

• POSTER add-on to Firefox - RESTful Web Services can be tested using a firefox addon called Poster. It's a developer tool for interacting with web services and other web resources that lets you make HTTP requests, set the entity body, and content type. This allows you to interact with web services and inspect the results.

• Microsoft’s WCF & Service Trace Viewer Tool - Windows Communication Foundation (WCF) Service Trace Viewer Tool helps you analyze diagnostic traces that are generated by WCF

ref:

Open Source Web Services Tools in Java - http://java-source.net/open-source/web-services-tools

WebServices (SOAP vs REST) - http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest

JAX-WS and JAX-RS United in CXF - http://sberyozkin.blogspot.com/2011/01/jax-ws-and-jax-rs-united-in-cxf.html

Service Oriented Architecture(SOA) Design Patterns

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.



Why SOA?

The reality in IT enterprises is that infrastructure is heterogeneous across operating systems, applications, system software, and application infrastructure. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.



Service-oriented architectures have the following key characteristics:



1. SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.



2. SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.



3. SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.



4. Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.



ref:



SOA Introduction



What is SOA - http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html



SOA Overview - http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330269,00.html?offer=briefcase



SOA LifeCycle - http://searchsoa.techtarget.com/guide/allInOne/0,296293,sid26_gci1262598,00.html?offer=briefcase



Principles of Service-Orientation -

http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172714,00.html?offer=briefcase



End-to-end testing for SOA and enterprise transactions -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357238_mem1,00.html



SOA patterns



SOA Patterns - http://www.soapatterns.org/



SOA Design Patterns by Thomas Erl - http://www.soapatterns.com/



SOA Design Patterns (by Arnon Rotem-Gal-Oz) -



http://www.rgoarchitects.com/Files/SoaPatterns.pdf



http://www.rgoarchitects.com/Files/SoaPatterns2.pdf



Best of Udi Dahan's Articles -

http://www.udidahan.com/first-time-here/



SOA Patterns: Implementing an SOA Using an Enterprise Service Bus(IBM Redbook) -

http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf



Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6 - http://www.redbooks.ibm.com/redbooks/pdfs/sg246494.pdf



SOA Anti-Patterns - http://www.infoq.com/articles/SOA-anti-patterns



Service Facade -http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1346145_mem1,00.html



Non-Agnostic Context -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1347582_mem1,00.html



Domain Inventory -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1349152_mem1,00.html



Service Normalization -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1350514,00.html



Service Decomposition -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1352917_mem1,00.html



Miscellaneous



How SAML fits into your SOA security scheme -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1337854_mem1,00.html



Tips for tracing enterprise transactions -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357445_mem1,00.html



Enterprise Architecture in the Agile age - Part 1, Styles of EA -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357017_mem1,00.html



SOA management vs SOA governance

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1335764,00.html



Business Process Execution Language (BPEL) Tutorial -

http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330911,00.html

The Principles of Service-Orientation

The adoption of SOA often comes with an expectation that many of the benefits commonly associated with service-oriented technology platforms will be realized simply through their successful implementation. However, some of the longer-term and more strategically significant goals of an SOA transition (such as the attainment of increased business agility) can really only be achieved to their full potential by applying a consistent approach to how automation logic is designed.

Before a service-oriented solution can be built, it needs to be understood what makes an individual service suitable for SOA in support of its strategic goals. In other words, the question of how services can be created to be truly service-oriented needs to be asked early on in the project lifecycle.

The answer lies in a design paradigm that has emerged to uniquely distinguish the service-oriented architectural model from its predecessors. This paradigm is service-orientation and its approach to modeling business automation logic has resulted in a set of commonly accepted principles that, when applied, position and shape the primitive components (services, descriptions, messages) found in a typical service-oriented environment.

Service-Orientation and the Separation of Concerns

Service-orientation has had many influences, but its roots lie in a software engineering theory known as the "separation of concerns." This theory is based on the notion that it is beneficial to break down a large problem into a series of smaller, individual problems or concerns. This allows the logic required to solve the larger problem to also be decomposed into a collection of smaller, related pieces. Each piece of logic addresses a specific concern.

The theory has already been implemented through established paradigms, such as object-orientation and component-based approaches. Service-orientation can be viewed as a distinct (and more recent) manner in which to realize a separation of concerns. More specifically, though, key service-orientation principles provide a unique approach to how the separation is performed. In doing so, these principles establish a foundation paradigm for SOA. If you study the common characteristics associated with contemporary implementations of SOA, you will notice that several are linked to how concerns have been separated.

The Common Principles of Service-Orientation

There are many opinions, originating from public IT organizations to vendors and consulting firms, about what constitutes service-orientation. As part of an on-going industry analysis initiative by SOA Systems Inc., I have been researching and assessing perspectives of service-orientation for quite some time. The purpose of this project is to identify and describe a set of common principles that are supported by all major SOA platforms, thereby establishing a real-world definition of the service-orientation paradigm. Our focus in this series is therefore centered around those principles that have become commonly accepted in the SOA industry and supported by corresponding vendor platforms.

The most recent results establish the following eight principles:

· services share a formal contract

· services are loosely coupled

· services abstract underlying logic

· services are composable

· services are reusable

· services are autonomous

· services are stateless

· services are discoverable

Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be considered core principles that form a baseline foundation for SOA. Although each of the eight principles support or are supported by the others, these four directly enable the realization of the remaining principles. The study of inter-principle relationships is quite interesting and provides a deeper perspective of the unique dynamics introduced by service-orientation.

It is also worth noting that Web services naturally support a subset of these principles, which provides an indication as to why the Web services technology platform is considered so suitable for building service-oriented solutions. Later in this series we will discuss some of the relationships between principles as well as how some are intrinsically realized through the use of Web services. These principles are "common" in that they represent an industry-level perspective of service-orientation as determined by research conducted by SOA Systems Inc.

An aspect of service-orientation that ties directly into our previous discussion of service contracts and loose coupling is that of abstraction. It is through abstraction that we can control what parts of the underlying service logic are exposed to the outside world. By ensuring that these parts are designed in a generic manner so as to accommodate multiple potential service requestors, we can strive to position the service as a reusable IT asset. In this article we will explore different levels of abstraction and then move on to a discussion of how reuse supports the overall strategic goals associated with SOA.

Abstracting functionality and technology

Also referred to as service interface-level abstraction, it is this principle that encourages us to establish services as black boxes, intentionally hiding their underlying details from potential consumers. Abstraction is accomplished through the disciplined use of service contracts. By limiting what is made public about a service to what is documented in the service contract, a high degree of separation can be achieved between what becomes private (hidden) and public (consumable). This is desirable because it supports the loosely coupled relationship.

There is no limit to the amount of logic a service can represent. A service may be designed to perform a simple task or it may be positioned as a gateway to an entire automation solution. There is also no restriction as to the source of automation logic a service can draw upon.

For example, a single service can expose logic from multiple different underlying systems. In fact, as we move toward the standardization of service models that establish a functional context associated with a business entity or task, it is expected that in environments with numerous legacy solutions, one service will commonly expose functionality that relies on a variety of different systems.

Service interface-level abstraction is one of the inherent qualities provided by distributed platforms, such as component and Web services-based architectures. The use of Web services are especially synergetic because they elevate the level of attainable abstraction beyond just functionality. Web services abstract the proprietary implementation details of the underlying automation logic, which frees potential consumers of the service from having to interface with specific vendor technologies. Even though we refer to abstraction as a characteristic of the service, it is actually the individual operations that collectively abstract the underlying logic. Services simply act as containers for these operations. The level of abstraction of any given service is therefore determined to large extent by the collective levels of abstraction attained by each of its service operations.

This puts a great deal of emphasis on the design of the service contract. The more that is expressed in the service contract, the less details we end up abstracting. The more generic we make the service contract, the less process or consumer-specific the service becomes. This then determines the reuse potential of what we choose to expose (to not abstract) through the service contract.

Fostering agility through reuse

Service-orientation encourages reuse in all services, regardless of whether immediate requirements for reuse exist. This fundamental principle forces us to pay extra attention to each delivered unit of automation logic we want to call a "service."

The primary strategic goal associated with reuse is to position each service as an IT asset with "repeatable value." As the amount of reusable assets accumulate, the chances increase to fulfill new business automation requirements by building less and using more of what we already have.

This is expected to reduce the time it takes to build automation logic, thereby improving an organization's overall responsiveness to change. By decreasing the associated effort, the fulfillment of automation requirements is also anticipated to become more cost-effective, leading to the significant potential of streamlining IT development environments. This may sound like a tall order, but many organizations are investing heavily in the creation of a highly reusable service inventory to attain these very benefits.

This principle facilitates all forms of reuse, including inter-application interoperability, composition and the creation of cross-cutting or utility services. As we established earlier, a service is simply a collection of related operations. It is therefore the logic encapsulated by the individual operations that must be deemed reusable to warrant representation as a reusable service.

The emphasis on far reaching reuse also highlights the suitability of Web services as an implementation option for services. By making each service available via an industry standard communications framework, reuse potential can broaden dramatically because the logic encapsulated by a service now becomes accessible to service requestors built with different underlying technologies.

It all comes down to the service contract

Both of these principles bring us back to the required use of the service contract. It is the content of this contract that determines what is and is not abstracted. It is through the design of this content that we can determine how generic and reusable the non-abstraced parts actually are. This raises the need to truly view the design of a service as an investment. Building service-oriented solution logic is almost always more expensive and more time consuming because considerations need to be taken into account that go beyond immediate tactical requirements. An appreciation of what service-orientation is intended to accomplish is therefore useful in justifying this investment.

Continuing our exploration of service-orientation, we now focus on two principles that tend to receive much less attention than they deserve. When it comes to service design, so much of the spotlight is on enabling design characteristics most commonly associated with SOA marketing terminology, namely loose coupling and reuse. While certainly important, if not critical to achieving the long-term goals of SOA transition projects, there is more to consider. Abstraction and the strategic use of service contracts represent two additional principles that, to a large extent, support the realization of reusable, loosely coupled services. But, even the most reusable service is not useful if it cannot be found by those responsible for creating potential consumers. Furthermore, even the most loosely coupled services will have limited reuse potential if they cannot be assembled into effective compositions. This is where the principles of service discoverability and service composition come into play.

Service discoverability

The characteristic of discoverability essentially helps avoid the accidental creation of redundant services or services that implement redundant logic. Because each service operation provides a potentially reusable piece of automation logic, the metadata attached to a service needs to sufficiently describe not only the service's overall purpose, but also the functionality offered by its individual operations.

This service-orientation principle is related to, but distinct from, discoverability on an architectural level, in which case service discoverability refers to the technology architecture's ability to provide a discovery mechanism, such as a service registry or directory. These extensions effectively become part of the overall infrastructure in support of SOA implementations.

On a service level, the principle of discoverability refers to the design of an individual service so that it becomes as discoverable as possible, regardless of whether a discoverability product or extension actually exists in its surrounding implementation environment.

The reasoning behind this is that even if there's no need for a service registry because there simply isn't enough of a service inventory to warrant one, services should still be designed as highly discoverable resources. That way, when a service portfolio grows in size, the evolutionary governance of those services can be better managed because each service is equipped with sufficient metadata to properly communicate its purpose and capabilities.

Service composition

As service portfolios grow in size, service compositions will become an unavoidable and increasingly important design aspect of building service-oriented solutions. The main reason this particular principle is so important is because it ensures that services are designed in such a manner so that they can participate as effective members, or controllers, of these compositions.

The requirement for any service to be composable also places an emphasis on the design of service operations. Composability is simply another form of reuse and therefore operations need to be designed in a standardized manner (and with an appropriate level of granularity) to maximize composition opportunities.

A common SOA extension that underlines the relevance of composability is orchestration. Here, a service-oriented business process can be expressed through a composition language, such as WS-BPEL, essentially classifying the process itself as a service composition represented by a parent process service. Either way, the need for a service to be highly composable is irrespective of whether immediate composition requirements exist.

Composition discoverability

Each of the principles we explain in this series has relationships with others. Service composability, for example, is a characteristic that is influenced by the extent to which several other principles are collectively applied.

Even discoverability ties into effective composition. A fundamental rule of service abstraction is that a service can represent any range of logic from any types of supported sources, including other services. If services encapsulate others, we have a composition. To build an effective composition, the service designer will need a means of finding the most suitable services to act as composition members. Furthermore, once the composition is completed and deployed, potential consumers of the service representing the composition will benefit from an awareness of its existence, purpose, and capabilities.

Discovery supports and enables both of these scenarios, thereby furthering the cause of service-orientation.

ref:

Principles of Service Oriented Design - http://msdn.microsoft.com/en-us/library/bb972954.aspx

SOA Principles - http://www.soaprinciples.com/

Principles of Service Orientation - http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1165286,00.html

Service Oriented Analysis and Design(SOAD)

The interdisciplinary OOAD method facilitating successful SOA deployments, which can be referred to as Service-Oriented Analysis and Design (SOAD).

SOA architectural style aims to provide enterprise business solutions that can extend or change on demand. SOA solutions are composed of reusable services, with well-defined, published and standards-compliant interfaces. SOA provides a mechanism for integrating existing legacy applications regardless of their platform or language.

In SOA, always the focus is on Messages (XML) rather than API.

Conceptually, there are three major levels of abstraction within SOA:

1.Operations: Transactions that represent single logical units of work (LUWs). Execution of an operation will typically cause one or more persistent data records to be read, written, or modified. SOA operations are directly comparable to object-oriented (OO) methods. They have a specific, structured interface, and return structured responses. Just as for methods, the execution of a specific operation might involve invocation of additional operations.

2.Services: Represent logical groupings of operations. For example, if we view CustomerProfiling as a service, then, Lookup customer by telephone number, List customers by name and postal code, and Save data for new customer represent the associated operations.

3.Business Processes: A long running set of actions or activities performed with specific business goals in mind. Business processes typically encompass multiple service invocations. Examples of business processes are: Initiate New Employee, Sell Products or Services, and Fulfill Order.

In SOA terms, a business process consists of a series of operations which are executed in an ordered sequence according to a set of business rules. The sequencing, selection, and execution of operations is termed service or process choreography. Typically, choreographed services are invoked in order to respond to business events.

BPM, EA, and OOAD positioning

SOAD and its ingredients: OOAD, BPM, and EA

The Layers of design

The SOAD service definition hierarchy

SOA Choreography vs SOA Orchestration (From WebService perspective)

Process choreography, as the term is commonly used in the IT world, describes the interplay of various trading partners to implement a multi organization business function. For example, in the supply chain space, the fulfillment of a product purchase may involve the exchange of purchase orders, advance shipping notices, and money between two or more companies. Choreography does not describe how each company would conduct its operations, only how the different companies would interface with each other.

Process orchestration [of web service] is a technique to recursively compose and orchestrate web services to provide a new composite webservice Process orchestration is when a central process coordinates the execution of different Web services operations. The central conductor (as in an orchestra) is aware of the overall goal of the orchestration, the operations involved, and the order of the operation invocation. This centralized management allows Web services to be added or removed without each being aware of its effect on others, as well as compensatory processes to be implemented in case of faults and exceptions.

ref:

Elements of Service-Oriented Analysis and Design - http://www.ibm.com/developerworks/webservices/library/ws-soad1/

Place XML Message Design Ahead of Schema Planning to Improve Web Service Interoperability - http://msdn.microsoft.com/en-us/magazine/cc188900.aspx

Case Study: SOA Design Scenario - http://www.redbooks.ibm.com/redpapers/pdfs/redp4379.pdf

SOA AntiPatterns - http://www.ibm.com/developerworks/webservices/library/ws-antipatterns/



Oracle’s SOA Architect Center - http://www.oracle.com/technology/tech/soa/index.html



IBM’s SOA Center - http://www-01.ibm.com/software/solutions/soa/



Service Façade - http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1346145_mem1,00.html

SOA Design Pattern Application Sequences: Service Facade + UI Mediator -

http://www.oracle.com/technology/pub/articles/erl_soa_design_patterns_app_sequences.html



Non-Agnostic Context SOA Pattern -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1347582_mem1,00.html



Domain Inventory SOA Pattern -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1349152_mem1,00.html



E-business patterns -

http://www.ibm.com/developerworks/patterns/index.html

https://www.ibm.com/developerworks/patterns/library/

Microsoft SOA Modeling Platform - Oslo

“Oslo” is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road. It’s an incredibly ambitious endeavor by Microsoft to finally tackle the modeling space.

The initiative encompasses an entire group of forthcoming products and technologies that will be released by CSD over time. In order to lay the technical foundation for the “Oslo” modeling platform, CSD will first ship a new version of the .NET Framework and Visual Studio – currently referred to as .NET Framework 4.0 and Visual Studio 2010 – containing some key updates to WCF and WF that make it possible to author declarative workflows and services (think of these as XAML -based “models”).

”Oslo” is the codename for Microsoft’s forthcoming modeling platform. Modeling is used across a wide range of domains and allows more people to participate in application design and allows developers to write applications at a much higher level of abstraction.

“Oslo” consists of:

1. A tool that helps people define and interact with models in a rich and visual manner

2. A language that helps people create and use textual domain-specific languages and data models

3. A relational repository that makes models available to both tools and platform components

ref:

Learn Oslo - http://msdn.microsoft.com/en-us/oslo/cc748651.aspx

Oslo Developer Center - http://msdn.microsoft.com/en-us/oslo/default.aspx

Microsoft 'Oslo' - the vNext SOA Platform -http://geekswithblogs.net/cyoung/articles/116456.aspx

Build Metadata-Based Applications With The “Oslo” Platform - http://msdn.microsoft.com/en-us/magazine/dd419662.aspx

Oslo Videos - http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/41013d24-89f4-4ac2-8ee4-f4b7e75ee5c3

Microsoft SOA Website - http://www.microsoft.com/soa/default.aspx

Microsoft SOA product called OSLO - http://www.microsoft.com/soa/products/oslo.aspx

Oslo May 2009 CTP download - http://www.microsoft.com/downloads/details.aspx?FamilyID=827122a5-3ca0-4389-a79e-87af37cbf60d&displaylang=en

An Introduction To Domain-Driven Design – http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

Microsoft solution Architecture - http://msdn.microsoft.com/en-us/architecture/default.aspx

Microsoft Patterns and Practices - http://msdn.microsoft.com/en-us/practices/default.aspx

Service Oriented Architecture(SOA) Design Patterns

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.



Why SOA?

The reality in IT enterprises is that infrastructure is heterogeneous across operating systems, applications, system software, and application infrastructure. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.



Service-oriented architectures have the following key characteristics:



1. SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.



2. SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.



3. SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.



4. Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.



ref:



SOA Introduction



What is SOA - http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html



SOA Overview - http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330269,00.html?offer=briefcase



SOA LifeCycle - http://searchsoa.techtarget.com/guide/allInOne/0,296293,sid26_gci1262598,00.html?offer=briefcase



Principles of Service-Orientation -

http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1172714,00.html?offer=briefcase



End-to-end testing for SOA and enterprise transactions -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357238_mem1,00.html



SOA patterns



SOA Patterns - http://www.soapatterns.org/



SOA Design Patterns by Thomas Erl - http://www.soapatterns.com/



SOA Design Patterns (by Arnon Rotem-Gal-Oz) -



http://www.rgoarchitects.com/Files/SoaPatterns.pdf



http://www.rgoarchitects.com/Files/SoaPatterns2.pdf



Best of Udi Dahan's Articles -

http://www.udidahan.com/first-time-here/



SOA Patterns: Implementing an SOA Using an Enterprise Service Bus(IBM Redbook) -

http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf



Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6 - http://www.redbooks.ibm.com/redbooks/pdfs/sg246494.pdf



SOA Anti-Patterns - http://www.infoq.com/articles/SOA-anti-patterns



Service Facade -http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1346145_mem1,00.html



Non-Agnostic Context -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1347582_mem1,00.html



Domain Inventory -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1349152_mem1,00.html



Service Normalization -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1350514,00.html



Service Decomposition -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1352917_mem1,00.html



Miscellaneous



How SAML fits into your SOA security scheme -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1337854_mem1,00.html



Tips for tracing enterprise transactions -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357445_mem1,00.html



Enterprise Architecture in the Agile age - Part 1, Styles of EA -

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1357017_mem1,00.html



SOA management vs SOA governance

http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1335764,00.html



Business Process Execution Language (BPEL) Tutorial -

http://searchsoa.techtarget.com/generic/0,295582,sid26_gci1330911,00.html

Enterprise Mashups

Mashups are Web sites that integrate a variety of services (e.g., news feeds, weather reports, maps, and traffic conditions) in new and interesting ways.

In web development, a mashup is "a web page or application that combines data from two or more external online sources." The term mashup implies easy, fast integration, frequently using open APIs and data sources to produce results that were not the original reason for producing the raw source data. An example of a mashup is the use of cartographic data from Google Maps to add location information to real estate data, thereby creating a new and distinct Web service that was not originally provided by either source.

ref:

Mashup : http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

What is Mashup - http://blogs.zdnet.com/BTL/?p=2484

Enterprise Mashups : The Icing on your SOA - http://socialcomputingjournal.com/viewcolumn.cfm?colid=817

Enterprise Mashup Blog - http://enterprisemashup.blogspot.com/

Rethinking BPM in a mashup-based SOA world - http://blogs.zdnet.com/BTL/?p=2517

Mashup Feed - http://www.mashupfeed.com/

SOA World Expo: Enterprise Mashup Services -

http://java.sys-con.com/node/325192

http://java.sys-con.com/node/345638

Enterprise mashups - http://www.infoworld.com/d/developer-world/enterprise-mashups-668

Enterprise Mashups - The Icing on your SOA : http://socialcomputingjournal.com/viewcolumn.cfm?colid=817