Question for all of you EXPERT.NET architects

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mike Miller - 05 Aug 2004 07:04 GMT

Question: How do you develop a web service that uses unknown types?

The ideas is that my web service performs a generic function. I want
anyone to be able to consume it, but I can't know what type of objects
they are going to pass to in (like I said it performs some generic
functionality - I don't want to recompile it ever).

So I create a simple web service with with a method like:

string GetTypeInfo(object t){
return t.GetType().ToString();
}

I want to consume it with something like:

string s = WebService.GetTypeInfo(new Widget());

Now the big question:
The Widget type is NOT referenced in the web service (the whole point
is its generic remember). Now to me it makes sense that the client
(web service consumer) would serialize the object to xml, and pass the
xml and xsd describing the object over the wire via soap. The server,
would deserialize the xml to an object using the xsd by doing the
following: if the type is unknown, the deserializer could define a new
type via system.refelection.emit and then create an instance of it and
populate it. Does this make any sense? Is there something built into
the webservices to do this? If not, has anyone tried to roll your
own?

So why would I want to do this? Because lets say you have a business
tier and a data tier that are loosely coupled. My business tier holds
my model and my data tier populates the model (using a persistance
framework like hibernate). I don't want to recompile my data tier
simply because my model changes - I want it to be LOOSELY coupled, but
I don't want to be tied to simple value types and strings (I want to
do something useful).

Thanks for taking to read and answer my question.
Mike

Reply to this Message

Kent Tegels - 05 Aug 2004 08:01 GMT

Mike Mille wrote:

> Question: How do you develop a web service that uses unknown types?

I'm posting my response of list to avoid starting a holy war. I don't
believe in the no-win scenario...

http://sqljunkies.com/WebLog/ktegels/archive/2004/08/04/3768.aspx

Thanks!

Kent Tegels

SQL Sever Express Blog (Good for FAQs): http://tinyurl.com/6r4gb

SQL Server Express BOL (The docs you need): http://tinyurl.com/4ctjx

Kent's Blog: http://www.tegels.org/

Reply to this Message

Mike Miller - 05 Aug 2004 14:48 GMT

Ken the link you sent is not working? I was not trying to start a
holy war just get a answers to a question (the more input the better).
The scenerio I mentioned is just one of many for me and solving this
problem would be huge.

Thanks,
Mike

> Mike Mille wrote:
>
[quoted text clipped - 14 lines]
>
> Kent's Blog: http://www.tegels.org/

Reply to this Message

Kent Tegels - 05 Aug 2004 15:16 GMT

It appears that both DNJ and SQLJ are down at this time. Give 'em a
couple of hours to sort that out.

Thanks!

Kent Tegels

SQL Sever Express Blog (Good for FAQs): http://tinyurl.com/6r4gb

SQL Server Express BOL (The docs you need): http://tinyurl.com/4ctjx

Kent's Blog: http://www.tegels.org/

Reply to this Message

Cowboy \(Gregory A. Beamer\) [MVP] - 06 Aug 2004 18:10 GMT

You could set up the object, conceivably, by using System.Reflection.Emit,
but you leave a lot of possibilities when you except any type of object.
While you may receive a factory and build your own factory, you might find
that there factory was a mill, while yours looks more like a car factory.

This is not a major problem if you are merely dinking around with the
variables and sending it back in the same serialization method. But, in
those cases, the factory object is a BS concept you made up simply to dink
around with properties. If that is all you are doing, why deserialize the
stupid class anyway, as you can consume the serialized XML and change things
and bounce it back.

Apologies if I appear a bit snarky on this one, but I, like Kent, believe
you should know what your app is doing. If someone wants to fire some
generic BS that you are not going to officially handle, it is better to
leave it as an XML string and store it that way than it is to create a
complete BS object simple to pretend you are talking the same language.

Signature

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

> Question: How do you develop a web service that uses unknown types?
>
[quoted text clipped - 35 lines]
> Thanks for taking to read and answer my question.
> Mike

Reply to this Message

Mike Miller - 09 Aug 2004 05:32 GMT

I guess I am attemping the wrong approach for a service oriented
architecture - although I think I have correct end goals in mind. I
think everything said so far is valid. So is anyone building things
like generic core services for the enterprise that can be consumed by
multiple applications. I am talking about things like logging and
auditing, configuration, search, and persistance. Things every
application needs, but in many cases most don't care how they are
implemented, simply that they work. Most of these services will be
wrapped with functionality in the application to meet the business
requirements, they are simply building blocks to get there faster,
without coping and recompiling the same old code blocks over and over
again. If you are using these types of services how are you passing
data (xml that conforms to a xsd the service publishes)? If your not
what is your approach?

Thanks for all the input-
Mike

Reply to this Message

Jeffrey Hasan - 09 Aug 2004 23:41 GMT

Mike, I think you nailed the issue in the first sentence of your most recent
post:

"I guess I am attemping the wrong approach for a service oriented
architecture - although I think I have correct end goals in mind."

SOA is based on the concept of qualified (i.e., well-defined) message
exchange between Web service endpoints. This is not incompatible with your
goals, because SOA does not dictate what the inner workings of a Web service
how. However, SOA does dictate that the messages being exchanged must be
well qualified. This is why you are attempting the wrong approach for SOA.

That being said, why can't you use a more generic, collection-based custom
object to transmit your Web service requests if you really don't want to be
pinned down to specific custom data types. For example, the ADO.NET DataSet
is simply a fancy collection of rows. There's nothing to stop you from
implementing a collection-oriented custom data type that is, say, a
collection of strings, where each string is a particular generic command to
the Web service.

But whichever way you cut it, you will find that you can't clearly explain
to your clients how to call your Web service. If you tell them to pass in a
"generic collection of input parameters" then you leave the door open for
them to make mistakes, to send you improperly formatted Web service
requests, and then things could get ugly! So, my perspective is that SOA's
enforcement of qualified types is ultimately in your favor. And don't
forget, you can always upgrade your Web service interface if the
functionality changes... you just then need to publish 2 different versions
of the WSDL document for the Web service.

Jeffrey Hasan, MCSD
President, Bluestone Partners, Inc.
-----------------------------------------------
Author of: Expert SOA in C# Using WSE 2.0 (APress, 2004)
http://www.bluestonepartners.com/soa.aspx

> I guess I am attemping the wrong approach for a service oriented
> architecture - although I think I have correct end goals in mind. I
[quoted text clipped - 13 lines]
> Thanks for all the input-
> Mike

Reply to this Message

Question for all of you EXPERT.NET architects

Free Magazines