Showing posts with label Web Services. Show all posts
Showing posts with label Web Services. Show all posts

Wednesday, June 15, 2011

Webservices for eighth grader


Son: What is web service?

Father: It is a mechanism for computer to computer communication. This communication is independent of make of computer and its operating system. So Windows machine can talk to Apple machine or to Linux machine without any heavy duty translation. Webservice enforces one language across variety of machines. More over this language is readable by humans as well.

Son: Hmm… So which language it enforces?

Father: Let me correct myself. Webservices do not enforce common language but common script. Like Devnagri and Latin are writing systems, scripts to various languages. Devnagri is used to write Hindi, Gujrati, Marathi, and other languages. Latin is for English, German, and French. For Webservices based communication Script is XML and various languages are WSDL, and SOAP. So XML is a system by which one can create new languages.

Son: It is OK. But then how actual communication happens between computers using web services?

Father: Let us make an analogy. You know, how we listen and how sound travels.

Son: Little bit.

Father: No problem. Let us build a scenario. You are asking questions and I am answering them. So you are Client or Customer and I am Provider or Server.

Son: It is easy. One who asks question is Client and one who answers the questions is Server.

Father: Perfect. Let’s move on. We are talking in English. So there is contact between me and you which says that you can ask only in English and I can answer in English. So there is contract between Client and Server. This contract in web services world is defined using WSDL – Web Service Description Language. WSDL also defines what questions a client can ask from Server. Because Sever cannot answer all questions in world, its ability is limited.

Son: It is getting complicated, but still manageable.

Father: Good. Now when I and you are talking we are using air as medium.

Son: Yes, I know it.

Father: In Webservices you can replace air by HTTP. Just think of browser address bar.

Son: Oh! Yes. I see http with your blog address in browser address bar whenever I open browser on your laptop.

Father: You are smart. One more thing, yours and my ears can hear sound if are within certain frequency range. Can you hear sound from dog whistle?

Son: I know humans can hear sound waves which fall between 20 Hz to 20 KHz.

Father: That’s good. You should get good grades in Science.

Son:Thanks .

Father: So, there should be something similar to frequency range. It is SOAP. This is something which defines how information is packed, flowing over air – HTTP.

Son: Cool. It is very straight forward. Script which defines language is equivalent to XML. Contract between client and server is WSDL. Information pack is SOAP

Father: Fantastic. Now you know what Web Services is.

Friday, April 10, 2009

Book Review: Service Oriented Architecture with Java by Binildas CA, Malhar Barai and Vincenz Caselli. ISBN: 978-1-847193-21-6

Though this book was published in end of Dec 2008, I am able to read now. After reading this book I am not able to understand what the central theme of this book is. This book starts with idea of defining of SOA which it not successful. Then it suddenly jumps to web service and its implementation. Then with all of sudden book starts talking about Data service and finally it compares EAI and SOA.

It seems that book has been compiled as silo for each chapter. None of the chapter seems to be interrelated. There seems to be no connection among chapters.

The only good things about this book are that it compares web service implementation using JAX-WS 2, Axis 2, Spring WS & XFire/CXF and RPC & Document based web services.

Publisher: Packt


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading:
1. A competing book is SOA Using JavaTM Web Services by Mark Hansen
2. The second book is Designing Web Services with the J2EE(TM) 1.4 Platform : JAX-RPC, SOAP, and XML Technologies


One can get more information about book from:

1. Amazon
2. Barnes & Nobel
3. Inform IT

Other Reviews:

1. http://realjavasoa.blogspot.com/2008/09/book-review-service-oriented.html
2. The Server side

Tuesday, March 24, 2009

Service Misconceptions

As the SOA is maturing so the web service, one of the most common way to implement SOA. But misconceptions about Web service are still prevalent among developers, architects and business persons. Here I have listed some of them and giving arguments for them. This list is comprehensive but far from complete.

1. Web services are not distributed objects
2. Web services are RPC of internet
3. Web services need http/s
a. Have you think of JMS, SMTP, UDP etc based services
4. Web services are not for large amount of data transfer
Please refer:
MTOM specification
5. Debugging of web services is impossible
Please refer:
a. Progress Actional Diagnostics
b. XMLSpy® 2009
6. Web service do not support transaction
Please refer:
a. http://www.ibm.com/developerworks/library/specification/ws-tx/
b. http://www.ibm.com/developerworks/webservices/library/ws-comproto/
c. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx
7. Web service security is sketchy
Please refer:
a. http://en.wikipedia.org/wiki/WS-Security
b. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

Friday, February 6, 2009

Single Service: Multiple Interfaces – Service Design Pattern

In one of my recent project, I encountered an interesting challenge. There was couple of services. Each of these services needs to serve various consumers which have diverse background. Few of the customers were interested in one type of interface (Web Service) while other set of consumers were demanding SOAP over JMS, CORBA calls and few more. This was interesting situation. My SOA instinct told me to look for solution in ESB. But none of ESB was able to provide such diverse channel transformation. Then I discovered that solution lies some where else.

A service should have multiple interfaces in terms of technology & business needs if ESB fails to provide.”

I realized from analysis of various other projects that this is a pattern which is quite prevalent but not explained in detail. I call this pattern Single Service: Multiple Interfaces.






Discovery of this pattern also leads to another pattern – Separation of Service Implementation and Service Interfaces. I will discuss this pattern in detail in some future post.

Thursday, January 29, 2009

Services Life Cycle - Production Point of View

A service life cycle may be expressed from various points of view. Here I am trying to explain life cycle of a service based upon its running conditions. I call this point of view as “Production point of view”. The other point of view could be based upon development life cycle which is more concerned with management aspects.

A service life cycle can be expressed in the state transition diagrams below. There are two separate transition paths:
– service itself
– request processing

• Service
– To be used, a service must be realized by a concrete provider agent.



A service may live in two states:


• UP — the provider agent is capable of accepting and processing requests (i.e. the service is available).
• DOWN — the provider agent is not capable of accepting any requests (i.e. the service is not available).

Naturally service will also transition between these two states. Transition states might be:

Birth: Start of current life  Service starts its current life in Up State
Death: End of current life  Service ends current life from Down State

• Activate — the service can become available which transitions it from Down to Up state.
• Suspend — the service can become unavailable which transitions it from Up to Down state.

Now let us elaborate details of each state

Sub States of Up State




• States
• Idle — the provider agent is not processing any requests currently.
• Busy— the provider agent is processing requests currently.

• Transitions
• Birth with Work: A service may start its life with work in hand and enters into BUSY sub-state of UP state
• Birth without Work: A service may start its life without work in hand and enters into IDLE sub-state of UP state
• Got Work: A service transitions from IDLE sub-state to BUSY sub-state of UP state.
• Work Finished: A service transitions from BUSY sub-state to IDLE sub-state of UP state.
• Retiring: A service leaves UP state (from BUSY or IDLE sub-state) and enters into DOWN state.

Sub States of Down State



• States
• Paused: The service is intentionally paused (e.g. for administrative purposes).
• Stopped: The service is intentionally stopped (e.g. for administrative purposes).
• Over whelmed: The provider agent has exhausted its resources and cannot accept any new requests.
• Crashed: The service is unavailable because of an internal malfunction of the provider agent (e.g. environmental problem).

• Transitions
• A service enters DOWN state in a PAUSED, STOPPED, CRASHED or OVER WHELMED sub-state.
• Stopping - A service may be stopped from any UP or DOWN sub-state except from CRASHED sub-state.
• Crashing: A service may be crashed from any UP or DOWN sub state except from STOPPED sub-state.
• Pausing: A service may be paused from any sub-state of UP state.
• Hanging: A service may be over whelmed from any sub-state of UP state.
• Activate: A service may enter into UP state from OVER WHELMED & PAUSED sub-state of DOWN state.
• Dying: A service may be dead from STOPPED and CRASHED sub-state of DOWN state.


Reference:

http://www.w3.org/TR/wslc/

Monday, January 12, 2009

Book Review: SOA Cookbook: Design Recipes for Building Better SOA Processes by Michael Harvey

ISBN #: 978-1-847195-48-7

SOA Cookbook may be considered one of the few books in SOA world which talk SOA as Process and further the argument with support of real life SOA platforms from leading vendors, namely IBM, Oracle, BEA and TIBCO.

SOA Cookbook is divided into nine chapters which encompass preliminary as well as complex aspects of SOA in seamless fashion. This book exposes architects and designers various aspects of SOA and BPM like Orchestration, Choreography, Event Handling, Change Management and services and processes, etc. It is advisable to understand basics of BPEL before hand. Chapter 4 onward, BPEL plays major role in understanding of the book.

With its entire good things book leaves some loopholes to be covered, like distinction between BPM and workflow, usage of B2B in inter enterprise integration, difference in EAI and process integration, etc.

This book is must in any software architects’ book collection to keep reminding basics of SOA and its practical implementations.

SOA Cook book is available here.

Book certainly gives lot of pointers for new thoughts.

Sunday, December 21, 2008

Service Interface / Contract Definition

Recently I have developed a document which will be helpful in documenting service interface or contact. This document is in MS EXCEL format. The document is structured in technology independent way. I will certainly welcome any suggestion and changes with respect to technology and platform.

I hope this document will be helpful tool to lot of us to sail through SOA universe.

The document can be downloaded from Scribd.com.

Documents

Sunday, December 7, 2008

Enterprise SOA Reference Architecture

Here I propose SOA Enterprise Reference Architecture. This is for enterprise and certainly for an application it should be inspiration.



Reference Architecture is independent of platforms offered by various vendors. It is also possible that none of the vendors in market provide complete solution to realize this reference architecture.

Data Persistent Layer

Data Persistent Layer is primarily consists of Enterprise Data - Master, Transaction and Meta. It may also include Datamart and Data driven reporting infrastructure.

In most of the large enterprises Data Persistent Layer consists of relational (RDBMS), hierarchical (LDAP, IMS), unstructured (Emails, chat sessions, file systems, etc) and any other type. These variations in data characteristics warrant unique data handling and treatment technologies.

Service Providers

This Layer consists of different business applications. These applications may be packaged (e.g. SAP, Reteck, etc) or may be custom developed in various technologies (e.g. Java, .Net, etc). Again application in this layer may be service enabled or legacy once, which do not expose their functionalities as service.

At this layer EAI exist. Some may argue that SOA is one form of integration then how EAI can exist at this layer. I will discuss this argument in one of my future posting but not now.
Services Layer

This layer is consists of multiple sub layers which encapsulate different class of services. It encompasses Connectivity Services, Data Services, Business Activity Services and Business Process Services. Each layer in turn consists of other sub-types of services.

This layer exposes different aspects of business - functional and infrastructural aspects. Connectivity and Data services are consisting of Infrastructural services while Business Activity and Process services expose functional Services.

These services though in layers but still breach layered architecture to expose these services independent of layers and for better performance. These services can also be exposed to multiple ESBs if situation warrants.

1. Connectivity services primarily cater to accessing system level functionalities, any adapter & connector services and partner (B2B) integration services.

2. Data services comprises of services, which caters to Business, Technical and Meta data related services.

3. Business Activity Services consist of Atomic business/functionalities and any custom business logic developed by combing one or more Data & Connectivity services.

4. Business Process Services primarily consist of Process integration, Machine and Human centric services. These services primarily comprise of Business Activity services.

Enterprise Service Bus
ESB provides four functionalities:

Orchestration
Routing
Mediation
Enrichment

Some ESBs may provide one more functionality - Choreography. This functionality is associated with BPM systems and currently none of Commercially available ESB provides the same.

Enrichment may be of two types: Data Transformation and Channel Transformation. Most of the analysts & architects keep Data Transformation & Channel Transformation separate functionality.





Presentation Services
These services support various user interfaces (human or machine centric) and let outer world (intra & inter enterprise) interact with enterprises IT assets. The consumers of presentation services are

Human
  • Thin Client

Browser clients: May be based on traditional HTML based or AJAX based

Portable devices: May be based on open standards (WAP) or propitiatory (device or carrier specific)

  • Thick Client

Alway Connected: These clients connect to service providers and consume the services in real time. Traditional think client falls in this category

Offline Clients: These clients do not connect to service providers in Always On fashion but an actor can work in offline mode and when ever connectivity available, services consumed. Java WebStart and Adobe AIR are two most widely used technologies in this field.

Voice Based Client

Voice based clients are gaining popularly to reduce load on contact center. To facilitate this type of user interface, IVR plays great role.

Machine

These types of interfaces are not very obvious but very prevent at enterprise level. Application level interaction (Software to software) and interaction with various devices like RFID tags, Bar code readers, etc (Hardware to Software or vice versa) are part of this type of interfaces.



Integration with Outer World

Most of the large enterprises also get integrated with external world. This integration is both ways - information flow is in both directions. To further complicate the scenario, enterprises increasingly using SAAS. This situation requires special attention and tools. In case of integration with business partners B2B Engine plays major role in conjunction with Partner services. SAAS services may be consumed directly or via B2B engine. In case of Human interaction (CRM - Salesforce.com) B2B Engine should be bypassed but for m/c interaction or substantial data transfer (Document management for insurance companies) B2B engine should be engaged.


Security




Security in SOA is one of the biggest concern due to distributed & heterogeneous systems interacting with each other. The security related aspects should be handled at each level of enterprise. In the proposed model security is considered from physical and virtual perspective. It also takes into account security from network and application view.

At monitoring front it take care of Technical - For support staff, Process & Managerial - For business process owners & managers and Executive - for top rung of business leadership requirements.



Governance

Governance is one of the burning issues in SOA environment. To discuss SOA Governance's Technical architecture, it is necessary to understand SOA Governance model.

Following figure depicts the SOA Governance Model.



The picture below intends to depict SOA Governance Technical Architecture.



Service Life Cycle Management

Service Life Cycle Management essentially helps in managing service life cycle from its conception to decommission. This is one of the vital components, which determine the success of SOA initiative in any enterprise and also its long-term viability.

Rule/Policy Repository & Engine

Rule/Policy Repository contains various Business Rules and Governance & Security Policies. The engine part of the same will help in execution of Rules and Policies as and when demanded.

Service Directory

Service directory essentially consists of UDDI, which facilitates consolidated listing of services.


Event Management

To exploit SOA to its full extent event handling plays crucial role. In SOA environment Events can be classified into three categories


1. Generic Event
Event fired/raised in response of event or interaction with other service/s.

2. Time Based Event
Event fired/raised at particular moment of time to perform certain task

3. Heart Beat Event
Event fired/raised by services at regular interval to announce its existence and may be level of throughput it is working.

Generic Event Handling

These are events which fire/raise other events or results due to interaction of services in ecosystem.



1. Event Generator generates events with minimal data set.

2. These events should be formatted as per the event protocol defined in ecosystem, so that theses event are available to entire ecosystem for further processing.

Ø Event Pre-processing: Check that mandatory attributes are present in the incoming events
Ø Event Refinement: Introduce the other system-generated attributes like start time etc.
Ø Situation Refinement: Check the target status on which action would be performed
Ø Impact assessment: Required result assessment after that impact applies on the target

3. Event factory determine the specific type of action, which the given event have.

4. Event listener executes the specific action, which stated at the specific action code. There we have some general action apply to all type of system is present in generic action code and specific to specific action is present in the specific action listener

5. Event listener executes the action and calls the required system to complete it.

6. Some event, which completed their actions, and no further support needed from any other services are terminated

7. Some events which need further processing from some other services or may be generate other event in response of event is send back to the event engine

8. Event in response of event is again run as a new event and again it initiates its processing cycle in the event engine

Time Based Event Handling

Scheduled event delivered to a service at specific time in the future. Event deliveries can be deferred for short periods of time (such as seconds or minutes) or for long stretches of time (for example, hours later for batch processing). Until that delivery time, the Event is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.



Heart Beat Event Handling

Heartbeats, a common software construct, verify the continual operation of a specific service. With heartbeats, a targeted service continually broadcasts a signal across its environment. System works normally when client services can detect a targeted service's heartbeat signals

There is number of interdependent services in SOA ecosystem such that, if one failed, others will also fail.

Heartbeat generally propagated across SOA ecosystem using publish/subscribe paradigm.



Transaction Management

Transaction Management is one of the most difficult aspects of any enterprise architecture due to varying level of understanding among stakeholders, various technological platforms involvement and spread of transactions – intra & inter enterprise.

In general any enterprise grade transaction framework follows ACID but due to presence of long running business processes and involvement of asynchronous communication traditional ACID becomes irrelevant. To accommodate long running business processes and asynchronous communication relaxed ACID is used which allows violation of ACID but with capability of correcting the violations in reasonable time period and with little business impact.



SOA capable enterprise grade Transaction Framework should have following features:

· Multi level undo/redo
· Coalescing of transactions
· Automatic aggregation of nested transactions
· Supports batching of transactions (Aggregation)
· Rollback of aggregated transactions for error recovery
· Listener support
· Synchronous and Asynchronous Transaction
· Compensatory Service
· Transaction Propagation

Exception & Error Management

Exception & Error Management is consist of
Exception & Error Handling
Exception & Error Logging
Exception & Error Notification
In any enterprise under SOA ecosystem Exception & Error Management poses following challenges:

Exception & Error Handling

No predefined format for passing exception information among participating services
Web services do not have capability of maintaining stack trace
Lack of common exception vocabulary across enterprise

Exception & Error Logging

Scattered logs across services/applications
Varying formats of logs across services/applications
Toggling logs at run time is service/application dependent

Exception & Error Notification

Every enterprise/LOB has its own unique notification requirement
Toggling Notification at run time is necessity
SLA and exceptions are coupled
To counter these challenges there must be a comprehensive Exception and Error Management framework which can manage at enterprise level and form the foundation for Remediation framework.

On the high level, Exception and Error Management framework’s architecture can be depicted as follows:









Remediation Framework

Remediation framework plays very important role in any SOA ecosystem. It can be though of extension of Error & Exception Management and Transaction Management frameworks. Remediation framework leverages Error & Exception Management Framework by utilizing logged error & exceptions. It also supplement Transaction Management Framework via helping to implement relaxed ACID where human intervention might be needed. Remediation framework also makes whole of SOA ecosystem robust via utilizing compensatory services.



Relationship

In SOA ecosystem Security, Governance, Operations, Quality are closely related. Each face of SOA ecosystem affects other.







Documents

Saturday, December 6, 2008

Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects

Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects by Matjaz, Ramesh, Pooranchandra and Frank (ISBN: 978-1-904811-17-6)

At first glance this would appear to be another "me too" title, and while in some ways that may be true. However there are a couple of things that set this book apart and it can be of value to those experienced in Integration & SOA as well as those new to the subjects.

Those who are new to the book I will recommend read as much as possible and this book must be one those. This book covers basic essentials of Integration, SOA, WebServices and BPEL in very simple and lucid language, which can help any greenhorn.

The most important part of this book is its language. The most glaring lapse in this book is assuming SOA means web services.

It has explained concepts of EAI in very concise & to the point in first chapter. While explaining Integration Infrastructure authors have drawn nice picture, which covers almost all aspects of integration tool stack. But in the section of Integration Technologies section, it fails to mention that MoM, TPM, ORB, App Server and ESB are various generations of the same and no word about “Several hybrid and proprietary products”.

The second chapter covers SOA in technology agnostic as well as Java &. Net specific way. This chapter nicely covers basic concepts of SOA, which include not only ESB but also web services and its Java and .Net implementation. This chapter also tries to cover process-based architecture in the end, which makes things little bit clumsy.

The third chapter covers XML, Schema, XML document security, and XML parsing. This chapter covers a lot but also leaves behind a lot. It totally neglects non Java XML parsers.

The forth chapter seems to be inspired from IBM’s eBusiness patterns. This chapter also touches Web Services Interoperability (WS –I) stuff, which is pretty elaborated.

The fifth chapter covers BPEL and integration with emphasis on process orientation. This chapter is good reference for BPEL and especially Oracle way of BPEL in its Fusion Middleware.

The last chapter covers ESB in detail. The name of the chapter and content of it does not match.

The most wanted but missing part in this book is references for each chapter in particular and for book in general.

In summary I would suggest that this is a good book for anyone involved in SOA and integration project. It will provide a good introduction for those new to the discipline of Integration and SOA. While acting as a useful refresher for those with more experience




go and grab the book at packtpub.com